Fordel StudiosThe team does sprint planning every two weeks. They estimate tickets in story points. They commit to a sprint backlog. They have a daily standup. They do a sprint review and a retrospective. All the ceremonies are present. None of the values are.
The sprint backlog is treated as a contract. Engineers are not allowed to pull work that is not in the sprint. Requirements are specified before development and treated as fixed. The sprint review evaluates whether the team did what was planned, not whether the plan was correct. The retrospective produces items like "improve communication" and "better estimates" that disappear between the meeting and the next sprint. This is waterfall on a two-week cadence with Jira tickets.
What Agile Actually Meant
The agile manifesto was a reaction to waterfall's core failure: the assumption that software requirements can be fully understood before implementation begins, and that a plan made at the start remains valid as you learn. The manifesto's core insight was that software development is an empirical process — you learn by building, and the plan should update based on what you learn.
Scrum was designed to operationalise this: short cycles to limit the blast radius of wrong assumptions, a retrospective to update the process based on what was learned, a product owner who is continuously available to refine requirements as the team learns more. The scrum practices are valuable when they serve the underlying principle. They become harmful when they are followed ritually without the principle.
“The sprint retrospective that produces "we should communicate better" and then does not change anything is not continuous improvement. It is an alibi. The team can say they did the retrospective. Nothing changed.”
Where Scrum Goes Wrong in Practice
Three common failure modes: First, the sprint is treated as a commitment rather than a forecast. Teams that miss sprint commitments are treated as having failed rather than having learned that their estimates were wrong. This trains teams to under-commit and pad estimates, which destroys the forecasting value of story points.
Second, the retrospective is facilitated but not actioned. Items go onto a board. Nobody is assigned accountability for changing anything. The same items appear in the next retrospective. The team stops believing the retrospective produces change and starts treating it as a compliance exercise. Third, the sprint review evaluates execution rather than learning. "Did we build what we planned?" is the question. "Did building it teach us something that changes the plan?" is not.
The Certification Problem
Scrum has a certification industry: Scrum Master, Product Owner, Scrum Professional. These certifications teach the vocabulary and ceremonies. They do not teach judgment — when to follow the process and when the process is getting in the way of the work. The result is organisations full of certified practitioners running broken versions of the framework they were certified in, with enough vocabulary to explain why the problems they have are actually correct implementations of the methodology.
The agile values are correct: empirical learning, responding to change, continuous delivery, and direct communication. The ceremony is not the value. Find the teams that have the fastest cycle times and the most learning. Mostly they look nothing like textbook Scrum. They have absorbed the values and discarded the parts of the ceremony that slow them down.
