A Decision Framework

Teams that can describe next week's work today are Scrum candidates. Teams that can't describe tomorrow's work today are Kanban candidates.

Score yourself on a 1–5 scale: 1 means "we have a prioritized roadmap and most sprints go roughly to plan." 5 means "half our work arrives unplanned — incidents, customer escalations, ad-hoc requests from other teams." Most product-feature teams land at 1–2. Most platform, DevOps, and support teams land at 4–5. Teams at 3 are genuinely ambiguous — and "Scrumban" (Scrum cadence with Kanban-style pull for unplanned work) is a reasonable answer for them.

The key insight: predictability isn't about discipline. A team can be extremely disciplined and still have unpredictable work because the domain demands it. Don't confuse "we can't predict" with "we don't plan."

Scrum's sprint is a time-box commitment: the team agrees to protect a fixed period from scope changes. That only works if the organization will actually respect the boundary.

Ask two questions: Can your product owner say "no, that waits until next sprint" to a VP without getting overruled? And can the team realistically attend planning, standup, review, and retro every cycle without those ceremonies getting cancelled for "something more urgent"? If both answers are yes, you can sustain Scrum's cadence. If either is no, sprints will collapse into continuous flow with extra meetings — the worst of both worlds.

Kanban doesn't require cadence commitment. You can still hold regular retrospectives and planning sessions, but nothing breaks if you skip one or shift it by a few days. For teams in organizations that routinely override plans, Kanban's lack of a sprint boundary is honesty, not sloppiness.

Structure is scaffolding — it compensates for what the team hasn't yet built as muscle memory. A team of six engineers who've worked together for two years might not need a formal definition of "ready" because they've internalized it. A team that formed last month does.

Concrete signals that point toward more structure (Scrum):

• More than two engineers joined in the last quarter
• The team has no shared history of what "done" means
• Work regularly gets started without clear acceptance criteria
• Retrospectives reveal repeated miscommunication

Signals that point toward less structure (Kanban or fundamentals-only):

• The team has stable membership and shared context
• Engineers self-organize effectively without role assignments
• Work items are well-understood and relatively uniform
• The main coordination problem is throughput, not alignment

New teams almost always benefit from starting with more structure and relaxing it as trust builds. The reverse — adding structure to a team that's already struggling — feels punitive and breeds resentment.

Scrum is an all-or-nothing framework by design. You can't run "half a sprint" — either you commit to the time-box and the ceremonies, or you don't have Scrum. Adopting it means changing how the team plans, reviews, and reflects in one move. That's a big-bang transition, and it works best when the team is bought in and a scrum master (or equivalent) is ready to coach through the first few rough sprints.

Kanban is incremental by nature. You start by visualizing your current workflow on a board — no process change required yet. Then you add WIP limits. Then you start measuring cycle time. Each step adds value independently. If a step doesn't work, you remove it without unwinding everything else.

For teams skeptical of process change or burned by past methodology adoptions, Kanban's incremental path is lower-risk. You prove value at each step before committing further. Scrum's big-bang approach is faster to full adoption but has a higher failure rate in teams that aren't ready for the commitment.

The wrong methodology is recoverable — but the recovery cost varies. A team that tries Scrum for two sprints and decides it doesn't fit has lost a month of adjustment and some goodwill. A team that reorganizes around SAFe and buys enterprise tooling has a much harder reversal path.

Assess your switching cost honestly: How many people need to change their daily habits? Are you buying tools or making org-chart changes to support the methodology? Are external stakeholders being retrained on how to interact with the team? The more touch-points, the higher the cost of getting it wrong — and the stronger the argument for starting with the simpler option.

For most teams making their first methodology choice, the answer is: start with Kanban (low commitment, easy to reverse) or Scrum (moderate commitment, reversible in one sprint). Don't start with a scaling framework. Don't start with something that requires cross-team coordination you don't have yet. Match the weight of the methodology to the weight of the decision.