The Most Important Element of Scrum
I recently attended a great virtual Licensed Scrum Master training facilitated by Thoralf J. Klatt during which we had to create a poster explaining Scrum in 5 minutes. Despite the apparent simplicity of the exercise, I found it disturbing… Where do you start? What do you describe exactly?
My deep conviction is that many people don’t understand Scrum. They see 3 roles, 5 events and 3 artifacts, but they fail to get the real purpose of the framework. Instead, they cherry pick what they like and neglect other aspects. Ask people to explain it to you in a few minutes and you will get what people think are the most important parts of Scrum as a result. You will get their understanding and biases of Scrum. Undoubtedly, most of them will start their presentation by one of these sentences:
“There are 3 roles: the Product Owner, the Scrum Master and the Development Team, and they are responsible for X and Y.”
A role angle may be an expression of the need for having a clear responsibility matrix. Why is that? Well, it could come from traditional thinking where different groups of experts had to work in their specific domain of knowledge, or maybe from a contractual distribution of accountability across the roles (job titles, entities or even service providers), or a lack of collaboration in the team… In any case, there is something to do with accountability!
“There is this timebox called a Sprint that starts with a Sprint Planning in which we define X and Y.”
Second sentence is expressed from a process standpoint. How do we organize? How do we structure our work? How do we put order in this mess? Again, traditional thinking has gotten us used to milestones and clear methods. People may get confused when forecasts are more vague, or not firmly committed. They may have a need of controlling what happens in the team, or troubles with delegation and decentralization of decision making.
“There is a Product Backlog that contains Product Backlog Items in which we describe X and Y.”
Finally, people can express Scrum from a requirements standpoint. Before, we had that countless documents that expressed what the developers were supposed to work on: how does it translate to Scrum? How do we control what gets built? How do make sure the team has enough to do? How do we keep track of past work? Etc. I think you can see the pattern here.
I’m not saying these points are not true. They are indeed part of Scrum and the Scrum Guide describes them very well. However, they reveal a bias which explains which core element people put their focus on. I think they are highly representative of a SHU 守 state of mind in which learners are still focused on how to implement the practices they have been taught. A higher level of abstraction is what enables teams to understand the true purpose of Scrum and propels them further.
So if not in these elements, what is the purpose of Scrum, its essence? How would I present Scrum in 1 minute?
Each and every agile framework and practice has an intended purpose that can be different from others, but that always relates to at least one value or principle described in the Agile Manifesto. Scrum relates to almost all of them. But what is the most important element of Scrum? What is the magical element on which all others rest? The core mechanism?
“The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created”
Here is the key. A working product increment at every sprint. Each and every element of Scrum is oriented towards this target of having a real, tangible, releasable, “done” gift box. This regular and frequent feedback loop between the customer and the team is the most important element of Scrum. It allows the customers to inspect it and reflect on their real needs. It allows the team to gather feedbacks and adapt based on their new understanding of the needs, the vision, the market, the product etc. It allows the customer to express her feelings regarding what has been done and show her satisfaction. It also allows the team to focus, constantly self-organize during the sprint and, most of all, crush any impediment that may arise.
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Continuous improvement is therefore a behaviour resulting from this desire to have a “done” increment of product at the end of every sprint. Daily scrums are as many opportunities to inspect and adapt towards this goal, as well as backlog refinement and sprint planning to give a better sense of what to expect at the end of the sprint. Finally, the definition of “done” acts as a working agreement between all parties involved about what is the expected level of quality for the product increment.
But that still doesn’t explain the purpose of Scrum. When I did the exercise, I had not had enough time to do something great, so I used one of the previous examples. But now, I’ve had the occasion to think about it more deeply. I will simply formulate my vision of Scrum in a few minutes and I’m sure you’ll see plenty of things to say about my biases:
A team has an idea to solve a customer’s problem. So they self-organize to deliver a working product regularly in a very short time frame. At the end of this period, they inspect it together with the customers and gather feedbacks in order to adapt their plans. This time constraint means that the team has to stay focused on their goal, so they timebox everything, including their meetings which are kept to the necessary minimum for their constant inspection and adaptation. The same is true for their artifacts whose sole purpose is to increase transparency. Finally, in order for the team to be self-organizing, its members come from diverse backgrounds and each brings different perspectives to the picture. By doing so, they continuously improve their ability to satisfy the customer.
