Image
I have been a Professional Scrum Trainer since 2010, which means I have sat in the room when organizations decide Scrum is not working. Sprint Planning on Monday, Daily Scrum at nine, Sprint Review on the last Friday, Retrospective right after; every event on the calendar and every artifact named correctly. Nothing changed.These organizations usually ask whether they are running the wrong process, but the actual gap is more basic. Scrum carries a standard protocol and an agenda, and adopting the protocol while ignoring the agenda produces all the ceremony and none of the results.What a Standard Protocol IsA protocol is a set of steps that must happen in a fixed order for a defined situation. It removes professional judgment from the execution, and a checklist can tell you whether it was followed.When a patient presents with a particular condition, the medical protocol dictates the sequence of interventions. The hospital does not ask what the attending physician finds most sensible this week. The outcome of following the protocol is a record of compliance, not a record of insight, because compliance was the point.Protocols fit situations that are well understood and repeatable. Walter Shewhart, at Bell Labs in the 1920s, called this common-cause variation: the inherent, predictable noise inside any stable process, later adopted as a term by Deming. Applying judgment to each instance of common-cause variation increases instability, which is why a protocol removes it.What an Agenda IsAn agenda names an outcome, not a sequence of steps. A protocol tells you what to do. An agenda tells you what you are trying to achieve.The agenda of a hospital is a healed patient. The protocols exist to serve that outcome, and for routine conditions they do. But a doctor who notices a symptom that does not fit the standard presentation has encountered what Shewhart called special-cause variation: a signal from outside the normal pattern, traceable to a specific source. The protocol cannot tell her what to do next. The agenda tells her why it matters enough to investigate.You cannot standardize your response to a discovery that changes what you thought you were treating, and a protocol that tries to will only get in the way.Scrum's Protocol LayerThe Scrum Guide names the protocol layer clearly: one Sprint as a container, four events, three artifacts, and three accountabilities, which the Guide calls "the parts required to implement Scrum theory." These are Scrum's answer to common-cause variation: the predictable rhythm that every Sprint shares, managed the same way each time.Required. Either Sprint Planning happened or it did not, and either a Product Backlog exists or it does not; the compliance question is answerable in a single afternoon.The Guide also says "Scrum exists only in its entirety." You cannot claim partial compliance with a required sequence and still call it Scrum. The structure is not optional, and the Guide does not pretend otherwise.Scrum's Agenda LayerThe Scrum Guide builds Scrum "on empiricism and lean thinking," the idea that "knowledge comes from experience and making decisions based on what is observed." This is Scrum's answer to special-cause variation: the unexpected things that complex work produces, the market shifts, the technical discoveries, the Sprint Reviews that reveal your assumptions were wrong. A claim about how knowledge works, not a step in a checklist.The agenda that follows: because complex work cannot be planned in full upfront, you must check frequently, adapt based on evidence, and keep the work visible enough that checking is possible. The three pillars of Scrum, Transparency, Inspection, and Adaptation, are the agenda made into a rhythm. The five values, Commitment, Courage, Focus, Openness, and Respect, are the conditions for the agenda to hold.The Guide calls the framework "purposefully incomplete, only defining the parts required to implement Scrum theory." A protocol that is purposefully incomplete is a contradiction. The incompleteness belongs to the agenda layer. Scrum does not specify what you discover. Only that you must go looking.The Scrum Guide Expansion Pack, which I co-authored with Jeff Sutherland, John Coleman, and others, shows what the agenda layer looks like when it gets its own document. None of the eleven expansions adds a mandatory step or new required event. Every one adds purpose: what you are trying to achieve, and why the structure exists to serve it.The Protocol Without the AgendaOrganizations copy the protocol because it is visible and teachable. You can build a certification course around it. What you cannot do is transfer the agenda the same way, because the agenda requires teams to actually change behavior based on what they observe.In the Pacific Islands after World War II, some communities copied the form of Allied military operations, building wooden airstrips and bamboo control towers to summon the supply planes. They got the form exactly right while missing the mechanism entirely. Practitioners call the same pattern in software "cargo cult Scrum": ceremonies on schedule, empirical process absent.In practice it looks like this: the Daily Scrum runs for fifteen minutes every morning, the three questions get asked, and nobody changes anything based on the answers. The Sprint Review runs on the last Friday, the team demos the increment, and the Product Owner says it looks fine. The next Sprint starts without a single decision made differently. The protocol ran.The Agenda Without the ProtocolSome teams understand the empirical argument, share the values, and genuinely intend to inspect and adapt. They skip the structure and lose the forcing function.Without a Sprint, inspection happens "when there is time," which in product teams usually means rarely. Without a Sprint Review, adaptation stays a principle rather than a scheduled act. The protocol turns the agenda from a philosophy into a regular rhythm. Remove the events and the agenda becomes something teams mean to honor and mostly defer.One Objection Worth ConsideringThe easier objection is that this whole distinction is philosophical wordplay that practitioners do not need, and I can wave that one away, because the distinction predicts exactly the failure pattern these organizations experience.The harder objection is one I partly share. Scrum's own communication strategy adds to the confusion. The Guide presents a protocol and then calls the framework "purposefully incomplete." That is both a set of rules and an open question. It is easy to read the document as a complete rulebook and miss the agenda running underneath it. The 2020 revision strengthened the empirical framing and reduced prescription. Teams that learned Scrum from earlier versions often received only the protocol and missed the revision. None of the training that followed told them what had changed.Two Questions, Not OneWhen you look at a Scrum implementation, two questions apply. The first asks whether the protocol is being followed: do the events run, do the artifacts exist, are the accountabilities held? An audit can settle that in a day.The second asks whether the agenda is being honored. Does the Sprint Review produce decisions that change what gets built? Does the Retrospective change how the team works? Does the Daily Scrum lead anyone to do something differently that day? That question requires watching what changes over several Sprints, not reading a checklist.The protocol is necessary but not sufficient. The agenda is what determines whether any of the protocol was worth running. You cannot skip the structure and hope the values fill the gap, and you cannot follow the structure and assume the values showed up on their own.Both questions asked and answered regularly is Scrum working. One without the other is either theater or philosophy, and both of those were cheaper than the transformation budget.Ralph Jocham is Europe's first Professional Scrum Trainer, co-author of "Professional Product Owner," and contributor to the Scrum Guide Expansion Pack. As an ICF ACC certified coach, he works with organizations to build Product Operating Models where strategic clarity, operational excellence, and adaptive learning create measurable competitive advantage. Learn more at effective agile.References[1] Schwaber, K. and Sutherland, J. 'The Scrum Guide', current edition. Source of the protocol layer elements ("the parts required to implement Scrum theory," "Scrum exists only in its entirety"), the empiricism statement ("founded on empiricism and lean thinking," "knowledge comes from experience and making decisions based on what is observed"), and the incompleteness statement ("purposefully incomplete, only defining the parts required to implement Scrum theory"). All quotes fetched and confirmed verbatim. Available at: https://scrumguides.org/scrum-guide.html[2] The Write Direction, 'Protocol vs Policy: The Critical Difference Explained'. Source of the protocol definition: a prescriptive sequence of actions that removes professional judgment, where "the policy says what we believe" while "the protocol says what you do next." Fetched and confirmed. Available at: https://www.thewrite-direction.com/blog/protocol-vs-policy/[3] Wikipedia, 'Common cause and special cause (statistics)'. Source of Shewhart's original terminology (chance cause / assignable cause, introduced at Bell Labs in the 1920s), Deming's renaming (common cause / special cause), and the key distinction in management response: common-cause variation is reduced by improving the system and worsened by individual intervention, while special-cause variation is resolved by identifying and eliminating the specific assignable cause. Fetched and confirmed. Available at: https://en.wikipedia.org/wiki/Common_cause_and_special_cause_(statistics)[4] Lorique, 'When Scrum becomes a Cargo Cult'. Source of the cargo cult Scrum pattern and the distinction between following Scrum's form and engaging its empirical process. Fetched and confirmed: describes teams performing ceremonies without the empirical process, using the Pacific Islander parallel. Available at: https://www.lorique.net/posts/agile/when-scrum-is-a-cargo-cult/
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Reordering Your Backlog Is Zero Sum. Deleting From It Is Not. | 0 | 9.38 | 13-09-2026 |
| 2 | Nobody Owns Whether it Worked. | 0 | 8.63 | 29-09-2026 |
| 3 | 5 Things the Product Owner Shouldn’t Be Doing | 0 | 16.4 | 29-09-2026 |
| 4 | Scrum's Meetings Are Capped at Five Hours a Week. Something Else Filled Your Calendar. | 0 | 17.09 | 20-09-2026 |
| 5 | O que sabemos agora que não sabíamos no início da Sprint? | 0 | 10.22 | 04-09-2026 |
| 6 | Which Class Should You Arrange Next? | 0 | 9.78 | 07-09-2026 |
| 7 | Your Team Isn't Slow. Your Handoffs Are. | 0 | 8.51 | 22-09-2026 |
| 8 | Your Scrum Team Might Be Excellent at Building the Wrong Thing | 0 | 13.28 | 27-09-2026 |
| 9 | Your Retro is a Support Group, Not an Engine. | 0 | 8.63 | 08-09-2026 |
| 10 | Does Your AI Know the Scrum Guide? Twelve Questions to Find Out | 0 | 9.71 | 21-09-2026 |