Cargo Cult Scrum

In my coaching capacity I have seen a common pattern in many of the teams I joined as an Agile Coach, where I was brought in because those teams were floundering.

In Daily Standups I learned what stories the developers were "working on", but at the end of the Standup I had no idea what progress the developers were making, or if their statements of "no impediments" could really be honest for a 3 point story now in its eighth day of implementation.

The Sprint Retrospectives produced hugely imbalanced lists of "What went Right?", "What went Wrong?", and "What should we Change?" Typically, the "Wrong" list had many items, and the "Right" list was one or two items at best. Yet their current Scrum Master did not make the connection that every "Wrong" item was a candidate for the (often empty) "Change" list.

Sprint Planning often took many hours. The resulting Sprint Backlog contained something they called "stories", but there was no discernible cohesion or usable business functionality in the backlog items.

Infrastructure Without Results

In other words, these teams were embracing Cargo Cult Scrum.

The concept of a Cargo Cult originated late in the 1800's but the most fascinating examples come out of World War Two. Here is an excerpt from the fascinating Cows, Pigs, Wars and Witches by anthropologist Marvin Harris:

"The scene is a jungle airstrip high in the mountains of New Guinea. Nearby are thatch-roofed hangars, a radio shack, and a beacon tower made of bamboo. On the ground is an airplane made of sticks and leaves. The airstrip is manned twenty-four hours a day by a group of natives wearing nose ornaments and shell armbands. They are expecting the arrival of ... cargo planes filled with canned food, clothing, portable radios,...."

That is, these New Guineans were going through the motions they had observed by American forces years before, but not generating any anticipated results.

If you are a Scrum Master, I implore you to avoid this pathological situation.

Basic Blocking and Tackling

The Scrum events are infrastructure to your expected delivery, just as the sticks and leaves airplane was infrastructure to the New Guineans’ unrealized hopes. Without a clear understanding of each Scrum event, and the outcome of each, a Scrum Master is clearly disadvantaged. The Scrum Guide does offer limited guidance—enough to get us started.

The Sprint: the “heartbeat” of Scrum, and the scaffolding within which all the other Scrum events occur.

Sprint Planning: define the work to be performed for the Sprint, including the value and quantity of the work,

Daily Scrum (Standup): inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.

Sprint Review: inspect the outcome of the Sprint and determine future adaptations.

Sprint Retrospective: plan ways to increase quality and effectiveness.

 In The Effective Scrum Master I elaborate on these events—specifically, both their outputs and outcomes.

The Sprint

Goal and Output: Deliver a working, tested, and trustworthy product solution that meets the needs and expectations of the product stakeholders.

Desired Outcome: An acknowledgement that the developers have delivered tangible, observable value to the product’s stakeholders, a value that justifies the time and expense incurred producing the product solution.

Sprint Planning

Goal and Output: Populate the Sprint Backlog with stories that meet the Product Owner’s business objectives for the sprint. Each story placed into the Sprint Backlog should be sized by the developers, and the developers have assured the Product Owner that all of the stories can be completed within the sprint. 

Desired Outcome: A shared understanding of the value and priorities of what the team will deliver in the sprint, and a whole-team commitment to deliver the stories and other work items they have pulled into the Sprint Backlog.

Daily Standup

Goal and Output: Provides a forum for each team member pursuing work in the Sprint Backlog to inform the Scrum team of the member’s progress and impediments.

Desired Outcome: A shared understanding of what each team member is committing to complete for each other in the next business-day, and active remediation by either the team or the Scrum Master to remove any impediments to the flow of work in the sprint.

Sprint Review

Goal and Output: To obtain feedback from the product stakeholders on whether the current increment of the product aligns with their expectations, and to acquire stakeholders’ suggestions for product improvements.

Desired Outcome: A transparent and shared understanding among all product stakeholders of the team’s achievements or shortfalls in the completed sprint, and ideas from stakeholders for future product (not development process) improvement.

Sprint Retrospective

Goal and Output: To look back on the now-completed sprint and identify at least one specific goal which will improve the team’s processes for future sprints.

Desired Outcome: A shared understanding of the team’s operational efficiency and effectiveness in the previous sprint, a shared understanding of the root causes for any inefficiencies, and commitment to a process improvement that can be implemented beginning in the next sprint.

I will also add the essential Refinement activity that is not an “official” Scrum event, but it should have been.

Product Backlog Refinement

Goal and Output: To preview the highest priority stories in the Product Backlog, establish correct acceptance criteria and other requirements, and size these stories if possible.

Desired Outcome: A shared understanding of the scope, effort, and requirements (of which acceptance criteria are part) of the highest priority work items in the Product Backlog. The elaboration of these work items during Refinement may also result in their re-prioritization by the Product Owner as an informed sizing of effort emerges from the discussion.

Embracing Shared Intent

Lastly, I found early in my Agile career that a slight regrouping of the Scrum events is profitable for better understanding what I should take away from each event. I constructed this illustration to capture the shared intent of many Scrum events plus the activities of Product Owner acceptance of the sprint’s outputs.

That is, each sprint should ensure:

• That the team is properly constructing an Increment of usable and deliverable functionality, and we have accurate visibility into whether we will succeed in meeting our Sprint commitment.
• That the delivered Increment is fit for purpose (works as intended, does not cause harm).
• That some steps to eliminate waste and improve team efficiency and effectiveness have occurred—or, at least, been considered.

It is often said that Scrum is “simple to understand but difficult to implement.” I am not sure I agree. The nuances of Scrum—that is, what is behind the Scrum Guide—can make the operational model of Scrum a challenge even to understand. Doing a Daily Standup is simple, but conducting a ruthless and probing Daily Standup is altogether different. When anyone on my team simply says, “I am working on story 5822” I have to “pull the cord” and stop the train, so to speak. Telling me the story you are implementing is not the goal: I can see that already in Jira or Azure DevOps. Tell me what you have accomplished, not just that you are doing something. Tell the whole team what we need to know so we can realistically weigh our chances of a successful Sprint delivery.

As effective Scrum Masters we should never settle for Cargo Cult theater. For additional insight into the nuances that every Scrum Master must consider, I recommend you look at the work from Alan Shalloway at https://successengineering.works/. (Disclaimer: I have no financial relationship here.) Alan fills in where Scrum is lacking by exploring the application of systems thinking, Value Stream analysis, Flow, Lean, Theory of Constraints and other concepts to create a set of “first principles” for Agile delivery.

I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.