I’m on a journey to go through the complete Scrum Guide (2020 version) and turn it inside out. Hoping to find a satisfying answer to the question: “Does Scrum make sense?”
I started with “Purpose of Scrum” and “Empiricism”. I came to the conclusion that the premise of Scrum is sound. Then I looked into the Scrum Values, which can indeed bring the pillars of empiricism to life.
Then I discussed the Scrum Team. And I wondered how often is it that a Scrum Team and its stakeholders work in an environment where all Scrum Values can be upheld, the team has no hierarchies and everyone understands the Scrum theory well enough to make effective use of the framework.
The fourth topic was the Developers, who should own the What, How, and When to achieve a Sprint Goal. And the last two weeks I wrote about my issues with the Product Owner and Scrum Master accountabilities and asked if they aren’t too prescriptive.
My next iteration of this journey will discuss the purpose of the Scrum events.
Minimizing meetings
The Sprint is the event that contains all other events. Every Sprint starts with a Sprint Planning, has Daily Scrums, a Sprint Review, and a Sprint Retrospective at the end. And then the cycle repeats.
According to the Scrum Guide, the five events listed will minimize the need for meetings outside of Scrum. At first glance, I find this a weak statement. What does “minimize” even mean? The dictionary says you’d reduce it to the smallest possible amount. But how are you going to measure this?
However, if a Scrum Team would consciously put efforts into questioning the validity of meetings outside of Scrum, they can both help reduce the number of meetings and enforce the effectiveness of the Scrum events.
The usefulness of other meetings outside of the Scrum events always was a point of discussion for my Scrum Teams. For example, I remember how we questioned the validity of a steering community for the development of a new product. We convinced the people who suggested this to attend the Sprint Review.
Inspect and adapt
Crucial and inescapable for anyone who reads the Scrum Guide thoroughly is how every event is created to enable transparency to inspect and adapt Scrum artifacts. After all, Scrum is positioned as a framework to create value in a complex product environment. And Scrum’s answer to complexity is transparency, inspection, and adaptation. Or as the Scrum Guide calls it, empiricism.
It is therefore mindboggling to me how so many Scrum Teams misuse the Scrum events. But without the intention to use the learning loop, Scrum events will devaluate to be no more than status meetings or complaint sessions.
A sure sign of a failed Scrum implementation is when Scrum Teams consistently have no changes to their plans or the way of working as an outcome of the Scrum events. When Scrum events don’t bring you new insights to adapt, you either don’t need Scrum or you fail to use Scrum for what it is intended.
Prescribed events
The Scrum Guide 2020 is very clear about following the prescriptions of the Scrum events: “Failure to operate any events as prescribed results in lost opportunities to inspect and adapt.”
I find this statement too harsh. I do agree you need to understand the purpose of the individual events to get the most out of them. But if you take into consideration how often the Scrum Guide has changed since 2010 and how much the prescriptions of the events changed over the years.
A fine example of evolving insights is the evolution of the Sprint Planning. Earlier versions of the Scrum Guide instructed you to first select items for the Sprint and then create the Sprint Goal while. Now, the Scrum Guide has turned this around.
I wonder how the writers can be so sure they have nailed it this time. Because otherwise they should respect and expect different ways to accomplish the goals of the Scrum events.
With that in mind, I don’t like the bold statement that opportunities WILL be lost when you don’t follow the prescriptions. It makes all the sense to warn Scrum practitioners of misunderstandings and misapplications potentially leading to failure. But it makes no sense to me to put it so bluntly.
Rectification March 7th, 2023: After a debate between Joshua Wiechman, Gunther Verheyen, and me I want to rectify the above paragraph. Over the years, the Scrum events have been stripped from all “how to do” instructions. The only things left are why each event exists, who participates, what should be the input, and what should be the outcome. Considering this, I agree with Scrum Guide 2020 the statement that “Failure to operate any events as prescribed results in lost opportunities to inspect and adapt.” Because deviating from the basics is deviating from the core premise of Scrum.
Same time and place
The final piece of information we receive about the events (in general) is that they optimally should be held at the same time and place to reduce complexity. To me, this makes all the sense. I think it also shows you are serious about these events. For example, if you’d have the Daily Scrum at various times throughout the week, it may be difficult to remember when they actually take place. But it also gives the impression you squeeze this event into the agenda filled with items that are deemed more important. Because otherwise, you would have moved those items.
I do have more to say about consistency and the frequency of the Scrum events, but I will discuss this when I touch upon the Sprint.
Clear and logical
I find the section about the Scrum Events to be clear and logical. It clearly states why the events exist and why it is important to have them. It connects the events nicely with the empirical foundation of Scrum: transparency, inspection, and adaptation.
I only have one criticism. I am not convinced that a failure to operate the events as prescribed will always result in lost opportunities to inspect and adapt. Scrum has evolved over the years and I think it continues to evolve. So new practices may emerge from experiments with these events as they did in the past. Therefore I would recommend changing it to “Failure to operate any events as prescribed may result in lost opportunities to inspect and adapt.”