The Process Is Not the Point
Walk into enough engineering organizations and you start to notice a strange inversion. The teams that talk the most about agile are rarely the ones shipping the most. They have the certified scrum masters, the velocity charts, the story-point poker, the burndown graphs on the wall. And they are slow, defensive, and miserable. Meanwhile some team three floors down with no ceremonies you'd recognize is shipping every week and arguing about the product instead of the process.
This is not an argument against agile. It is an argument against religion. Agile, scrum, and kanban each contain real ideas that make teams better. They are also each surrounded by a thick layer of ritual that people perform because they were told to, without any memory of what the ritual was for. Your job as a PM is to keep the ideas and quietly discard the ritual, and to do it without starting a holy war.
This essay is a practical sorting exercise. What in each methodology actually works, what is cargo cult, and how to decide what fits your team. I am not going to tell you to adopt one framework wholesale. I am going to tell you to steal the good parts and leave the rest, which is exactly what the people who wrote these methods would have wanted.
What the Manifesto Actually Said
The Agile Manifesto is four lines and twelve principles, written in 2001 by seventeen people who were tired of heavyweight, documentation-heavy software processes that took years to deliver anything. It is worth reading in full, because almost nobody who invokes "agile" has actually read it, and what it says is both more modest and more radical than what gets done in its name.
The Four Values
It values individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. And then, crucially, it adds: "while there is value in the items on the right, we value the items on the left more." It does not say documentation is worthless. It says working software matters more.
Read that first value again. Individuals and interactions over processes and tools. The single most popular thing done in agile's name is the adoption of heavy processes and tools. The manifesto is, in its very first line, a warning against the thing most "agile transformations" actually do. The irony is total and it is the key to everything that follows.
The Real Intent
The intent was to shorten the loop between building something and learning whether it was right. Long planning cycles meant you committed to a year of work based on guesses, then discovered at the end that the guesses were wrong. Agile said: build a little, ship it, learn, adjust. The whole point is to convert expensive late surprises into cheap early ones. Everything else, every ceremony and artifact, is in service of that loop or it is noise.
Scrum: The Useful Skeleton
Scrum is the most widely adopted agile framework, which means it is also the most widely abused. Stripped to its bones, scrum is a few simple ideas: work in fixed-length iterations, plan each one, review what you built, and reflect on how you worked. That skeleton is genuinely useful. The problem is everything that gets bolted onto it.
What Actually Helps
Timeboxing is the best idea in scrum. A fixed cadence forces decisions. You cannot plan infinitely or polish forever, because the sprint ends. That constraint is healthy. It creates a natural rhythm for shipping, learning, and re-planning that prevents work from drifting indefinitely.
- A regular cadence. Whether one week or two, a predictable rhythm lets the team and stakeholders sync. Everyone knows when things get planned, shipped, and reviewed.
- A prioritized backlog. One ordered list of what matters, owned by one person. This alone resolves more conflict than any ceremony, because it forces the organization to say what comes first.
- A review of working software. Showing real, running software at the end of each sprint keeps everyone honest. You cannot fake a demo of something that does not work.
- A retrospective. A scheduled moment to ask "how do we work better" is the engine of improvement. When it actually changes something, it is the most valuable hour of the sprint.
What Is Cargo Cult
Now the ritual. Story points argued to two decimal places. Velocity tracked as a performance metric and weaponized against the team. Planning poker that takes two hours to estimate work that will change anyway. The daily standup that has become a status report read aloud to a manager. Burndown charts nobody looks at. Sprint commitments treated as contracts, so the team sandbags estimates to protect itself.
None of these shorten the loop between building and learning. They are theater. Velocity in particular is the most corrosive: the moment velocity becomes a target, it stops measuring anything, because teams inflate estimates until the number looks good. You have turned a planning tool into a lie generator. Estimation is useful for the team's own planning; it is poison the instant it leaves the team as a metric.
The Roles Question
Scrum prescribes a product owner, a scrum master, and a development team. The product owner role is real and valuable; someone has to own priority. The scrum master role is more contested. On a healthy, experienced team it is often unnecessary overhead, a full-time job invented to facilitate meetings that a good team runs in five minutes. On a dysfunctional team it can genuinely help, by protecting focus and removing blockers. The honest answer is that it depends, and "we must have a scrum master because scrum says so" is exactly the religion to avoid.
Kanban: Flow Over Iteration
Kanban came from manufacturing, by way of Toyota, and its core insight is different from scrum's. Where scrum organizes work into fixed iterations, kanban organizes around continuous flow. There are no sprints. Work moves across a board, from "to do" through "in progress" to "done," and the central discipline is limiting how much work is in progress at once.
The Work-In-Progress Limit
The single best idea in kanban is the WIP limit. You cap how many items can be in any column at once. If the "in progress" limit is three and three things are in progress, you cannot start a fourth. You have to finish something first. This sounds trivial and it is transformative, because the default failure mode of every team is starting too much and finishing too little.
When everyone has four things half-done, nothing ships, context-switching destroys productivity, and the board looks busy while delivering nothing. A WIP limit forces the team to swarm on finishing rather than scattering on starting. Stop starting, start finishing. That phrase is the whole philosophy.
Flow Metrics That Mean Something
Kanban also brings better metrics than scrum's velocity. Cycle time, the time from starting a piece of work to finishing it, is a real measurement of how fast you deliver. Lead time, from request to delivery, measures what the customer actually experiences. These are honest numbers. Unlike story points, they are grounded in calendar time, and you cannot game them by inflating estimates.
- Cycle time. How long work takes once started. Shrinking it means you ship faster, full stop.
- Throughput. How many items finish per week. A simple count of completed work, no estimation required.
- Aging work in progress. Which items have been stuck too long. This surfaces the things quietly rotting on the board.
Where Kanban Falls Short
Kanban's looseness is also its weakness. Without the forcing function of a sprint boundary, some teams drift. There is no natural moment to re-plan, demo, or reflect, so those things have to be scheduled deliberately or they don't happen. A pure kanban team with weak discipline can flow continuously toward the wrong thing without ever stopping to ask whether it is still the right thing. The cadence that scrum imposes is a feature kanban gives up.
When Each One Fits
The methodologies are not interchangeable. Each fits a different kind of work, and a lot of dysfunction comes from forcing a team into the wrong one because it is the company standard.
When Scrum Fits
Scrum fits work that can be planned in chunks and benefits from a regular cadence of stakeholder sync. Feature development on a roadmap, where you can reasonably commit to a couple weeks of related work, suits sprints well. It also fits teams that are still maturing and benefit from the structure and the forcing functions. The cadence gives newer teams a rhythm they would not otherwise build for themselves.
When Kanban Fits
Kanban fits work that arrives unpredictably and must be handled as it comes. Platform teams, support and bug-fix work, operations, anything interrupt-driven. Sprint planning is pointless when half your work didn't exist when the sprint started. It also fits very mature teams that don't need the scaffolding and just want to optimize flow. If your work is a steady stream of varied, urgent items, forcing it into two-week boxes is friction with no benefit.
The Dysfunction of Process Worship
When process becomes religion, specific and predictable pathologies appear. Learning to recognize them is half the battle, because they always wear the costume of discipline and rigor.
Means Become Ends
The clearest symptom is when people defend a practice by appeal to the methodology rather than to outcomes. "We have to estimate everything because that's scrum." "We can't skip the standup, it's a ceremony." When the justification for a practice is the name of the framework rather than the result it produces, the means have become ends. The practice now exists to satisfy the process, not the product.
The Certification Industrial Complex
There is an entire industry built on certifying people in these methods, and certifications create a constituency with an interest in maximalism. Someone who paid for and earned a credential in a heavyweight version of scrum has every incentive to insist that the heavyweight version is necessary. This is not malice; it is human. But it means a lot of process maximalism is driven by sunk cost and identity, not by what the team needs.
Ritual as Anxiety Management
Much process worship is really anxiety management. Uncertainty is uncomfortable, and elaborate ritual creates the feeling of control. The detailed estimates, the precise burndowns, the ceremonies performed exactly to specification, these soothe the anxiety of not knowing how things will go. But the feeling of control is not control. The estimates are still guesses; you have just dressed them up. A team that is honestly uncertain ships more than a team that performs false certainty.
Process as a Weapon
The ugliest version is when process becomes a tool for blame and control. Velocity used to pressure teams. Estimates used as commitments and then held against people when reality differs. Standups turned into surveillance. When this happens, the team responds rationally: it games the process, sandbags estimates, and stops telling the truth. The process meant to create transparency now manufactures lies, and you cannot get the truth back without dismantling the weapon.
Adapting to Your Team
The right process is the one your specific team needs right now, and that changes over time. Here is how to actually figure it out rather than adopting someone else's prescription.
Start From Problems, Not Frameworks
Don't ask "should we do scrum or kanban." Ask what is actually going wrong. Are we starting too much and finishing too little? Add WIP limits. Do we never stop to reflect and keep repeating mistakes? Add a retrospective. Are stakeholders constantly surprised by what we're building? Add a regular review. Each practice should be the answer to a specific problem you have, not a component of a framework you adopted.
Add Ceremony Reluctantly, Remove It Freely
Every meeting, artifact, and ritual has a cost in time and attention. Treat that cost as real. Add a new practice only when there is a problem it clearly solves, and run an experiment: try it for a few sprints, then ask whether it earned its time. Be equally willing to kill practices that have stopped paying off. A standup that has become a status report should be changed or dropped, not preserved out of habit.
Match the Process to the Team's Maturity
A new team, or one that is struggling, often benefits from more structure. The scaffolding helps them build habits they don't yet have. A senior, experienced, high-trust team usually needs much less. They coordinate fluidly and elaborate process is just friction. The mistake is applying the same heavyweight process to both, which over-constrains the strong team and under-supports the weak one. Process should be proportional to need.
What to Keep From Each
If you strip away the religion, here is the practical inheritance from each tradition, the parts genuinely worth keeping on almost any team.
- From the manifesto: shorten the loop between building and learning, and value working software and real interaction over process for its own sake.
- From scrum: a regular cadence, a single prioritized backlog with one owner, a review of working software, and a retrospective that actually changes something.
- From kanban: WIP limits to force finishing over starting, and honest flow metrics like cycle time and throughput instead of gameable points.
- From all of them: a bias toward small batches, frequent delivery, and continuous adjustment over big upfront plans.
That list is short, and that is the point. Almost everything valuable in twenty years of agile methodology fits in five bullets. The rest is local adaptation, and a great deal of it is ritual you can safely discard.
A Final Word
The people who wrote the Agile Manifesto were rebelling against heavy, prescriptive process. It is a bitter joke that their rebellion calcified into the heaviest, most prescriptive process culture many of us have ever worked in. The certifications, the mandatory ceremonies, the velocity dashboards, the consultants, all of it is precisely the thing they were trying to escape. To honor the original idea is to be willing to throw away the apparatus that grew up around it.
So hold all of it loosely. Use scrum when cadence helps, kanban when flow helps, and your own judgment always. Keep the practices that shorten the loop between building and learning, and drop the ones that only perform control. The goal was never to do agile correctly. The goal was always to ship good software and learn fast. Keep your eyes on that, and the methodology becomes what it was meant to be: a toolbox, not a faith.
Key Takeaways
- The Agile Manifesto's real intent was shortening the loop between building and learning. Judge every practice by whether it does that, not by whether the framework prescribes it.
- Scrum's useful skeleton is cadence, a prioritized backlog, a review of working software, and a retrospective. Its cargo cult is gamed velocity, two-hour estimation, and commitment-as-contract.
- Kanban's best idea is the WIP limit, which forces finishing over starting, plus honest flow metrics like cycle time that cannot be gamed the way story points can.
- Scrum fits plannable, cadence-friendly work; kanban fits unpredictable, interrupt-driven work. Most mature teams land on a hybrid and that is correct, not a compromise.
- Start from problems, not frameworks. Add ceremony reluctantly and remove it freely. Match process to your team's maturity, and change it through small experiments rather than religious argument.