Intelagile
A Framework Cheatsheet That Starts With Constraints
Scrum, Kanban, SAFe and XP are outputs. The inputs are how work arrives, how long the feedback loop is, and who can change priority.
Most framework comparisons start with the framework: here are the roles, here are the ceremonies, here is the cadence. That is a description of the answer, not the method for choosing it.
The choice follows from three properties of the work, and you can usually determine all three in an afternoon. Get them wrong and the framework becomes a set of meetings nobody can justify.
Three questions that decide it
How does work arrive? A queue of similar items that arrive continuously is a different problem from a defined body of work that a team has to decompose. Support tickets, incidents and service requests arrive. A product increment does not.
How long is the feedback loop? If a customer can see and react to a working increment within two weeks, a timeboxed framework gives you a decision point. If the customer can only react at a quarterly review, the timebox is internal and the framework is doing less than you think.
Who can change priority, and how often? One person who can reorder the list on a Tuesday is the precondition for Scrum's product owner role. A committee that meets monthly cannot play that role, no matter what the org chart says.
The cheatsheet
| Constraint | Framework that fits | What it optimizes | What breaks first |
|---|---|---|---|
| Continuous arrival of small similar items | Kanban | Flow and cycle time | Without a WIP limit it becomes a status board |
| Defined product scope, one decisive priority owner, access to users | Scrum | A demonstrable increment every timebox | A product owner who cannot decide, or users who cannot be reached |
| Many teams on one product with shared dependencies | SAFe | Alignment across teams and planning intervals | Coordination cost; the planning event grows faster than the value |
| Engineering quality is the binding constraint | XP | Technical discipline: tests, pairing, small releases | Customer access; XP needs an on-site customer to steer |
| Regulated delivery with an external approval gate | None of the four alone | Predictability of the approval, not the code | Every framework above assumes the gate is inside the team |
Two things about that table are worth stating plainly.
First, the frameworks are not a ladder. SAFe is not "more agile" than Scrum, and Scrum is not "more advanced" than Kanban. They solve different coordination problems, and moving up the scale usually means adding coordination to compensate for an organization that cannot decide.
Second, the last row is the one that matters in federal work. Every framework in the list assumes that the team controls its own definition of done. When a security authorization, a system integration test or a customer acceptance board sits outside the team, the constraint is the queue in front of that gate, and no amount of sprint planning moves it.
What each framework hides
A framework is a set of defaults, and defaults hide the assumptions they were built on.
Scrum hides the product owner. The framework is indifferent to whether that person can actually decide, and a Scrum team with a product owner who must consult three stakeholders is a team with no priority signal. It will still run the ceremonies correctly.
Kanban hides the limit. The board is the visible artifact and the WIP limit is the control. Most teams adopt the board and skip the limit, which produces a very clear picture of an overloaded system.
SAFe hides the cost. Program increment planning aligns a lot of people, and alignment has a price in meetings and coordination overhead. That price is worth paying when dependencies are real and expensive when they are imagined.
XP hides the customer. Test-driven development and pairing improve quality whether or not anyone is steering, but the framework's short cycles only pay off when somebody outside the team is reacting to them.
None of those are arguments against the frameworks. They are the questions to ask before adopting one, because the hidden assumption is the thing that will fail.
Choosing in an afternoon
Write the answers to the three questions on one page. Then pick the framework whose hidden assumption you can satisfy, not the one whose ceremonies you like.
If work arrives continuously, start with Kanban and set a limit before you build the board.
If you have a defined scope and one person who can decide, start with Scrum and protect that person's authority.
If you have many teams and real dependencies, you probably need something like SAFe, and you should budget for the coordination rather than pretend it is free.
If quality is the problem, XP practices will help regardless of the framework around them.
Then revisit at ninety days. The constraint changes as the program matures, and the framework should change with it. A team still running the same ceremonies for the same reasons two years later is not practicing a framework. It is maintaining a habit.