​​The updated scrum guide has been out for more than a year, so many have already written about it. But I would like to take this opportunity to share a few thoughts about the scrum guide as such and also comment on some of the features in the latest update.

Is scrum guide underrated?

The scrum guide is in my experience often overlooked by teams or organizations. I dare to believe I might know some of the reasons. When I was first learning about scrum and I was trying to live by it with my colleagues, we needed a lot of guidance. We needed a hands-on approach by our more agile-seasoned colleagues to actually help us set the basics and actually start working in the framework. We needed to discuss the nitty-gritty details of the daily work and all the various aspects of backlog management. We sought after organizational how-tos and best practices to wrap our heads around this interesting, yet somehow elusive concept of scrum.

Scrum is easy to understand but difficult to master. It is mainly a cultural shift compared to traditional project management and development approaches, so why is it so hard to get right? Sometimes the actual cultural shift is the culprit, but it is also demanding for organizational and planning discipline.

The actual nuts and bolts are often what teams struggle with and that's where they seek a lot of help in the earlier phases of their maturing. The scrum guide however does not give many answers in this regard. And that's why a lot of people don't find much practical use in reading that document. It seems to me it is rarely a go-to place for teams or scrum masters when searching for scrum answers.

But the scrum guide was never meant to be a detailed guide. And that is a good thing. Its purpose is to set the boundaries just where they are absolutely necessary, outline the philosophy, and leave the space for interpretation where the scrum team is supposed to bring in its brains and creativity. It tries to be as precise as possible without being taxative. And for this very reason, it needs to be minimalistic. (If only our legislators approached their work this way…)

In my opinion, the more the team matures, the less it should try to seek exact how-tos about living in scrum, but the more it should return to the bare basics - to the scrum guide.

That helps to gain some distance from the daily routines and undesired habits and look at their doing from the above to get rid of unnecessary habits and rather focus on the actual philosophical value than a process. Matured teams have a pretty good idea about the philosophy of scrum and want to live by it. Going back to the guide can be an enlightening experience for them. Approach the scrum guide as it's been triple distilled before it got its current shape.

Recent updates

At the end of 2020, the scrum guide received yet another update. Although some of the changes seem minor or sound just like a wording change, to me it seems like a good step towards helping to clear up several common misconceptions. You can find the changelog easily on the internet, so it is not my aim to cover the update extensively. I want to talk about a few particular changes, which I find the most interesting.

1. Ditched the 3 questions for dailies

Everyone knows the 3 questions that are the core of the daily - what did I do, what will I do, and do I have any impediments, right? So the guide got rid of them. Why is it a good thing? Because the ultimate team's purpose of the daily is to evaluate sprint backlog's achievability and to make decisions upon this evaluation. Decisions to make the team create the most value within the sprint (and to still meet the sprint goal). Maybe by dropping some sprint backlog items. Maybe by re-assigning backlog items between the developers. Maybe by helping each other out.

These questions were sometimes obscuring the actual goal of the daily. As if it was forbidden to talk about anything else other than that. Does it mean that these 3 questions should not be used from now on? No, it doesn't. It certainly is necessary that the devs share their progress and sync on it. If the team finds them useful, it will use them. The guide just suggests that these questions are not the pivotal point of the daily and give more freedom to the team to tailor the daily to their needs.

2.Stressing the core scrum values and principles

The guide now tries to be clearer about the core scrum values and principles of empiricism. It reminds us that being transparent, inspecting, and adapting based on the findings is a vital part of the process. This is as opposed to extensive planning and attempting to achieve perfection for the first time.

Commitment, openness, and respect are the values that shape the actual outcome. The often-used practices like estimating, tracing velocities, and plotting burn-downs are icing on the cake. But the team should be able to bring high value even without them.

3. Team unification

Formerly, scrum the guide defined a developer team and a scrum team. Scrum team = development team + scrum master + product owner. From now on, there is just a scrum team.

To me this is not just a cosmetic change. Sometimes the teams gained a dynamic of the product owner being an outsider. A customer for the team. Subliminally perceived as a competitor or a hindrance to the development team. In some teams, even the scrum master was seen as an outsider.

Team unification is an attempt to get rid of the us-and-them mentality. When perceived right, all the team members have a common goal to solve problems to create high business value. And the devs can (and should) be in close touch with the product owner to work out how to keep achieving that continuously. It needs to be clear that to the developers, the product owner is not an enemy, but someone who they can use to get answers, opinions, and business insights from, to be efficient. They can negotiate with him about the possible approaches to solving particular problems. When there is a good idea to achieve something in a more efficient or simpler way than originally intended, devs should understand that both them and the product owner will benefit from it. And the product owner should understand that too. They are teammates.

4. Commitments for scrum artifacts

The hierarchy of artifacts and their commitments is now clearer. A product has its goal. That determines the product backlog's priority. A sprint has a goal, which defines the sprint backlog. And finally, a product increment must meet a definition of done. This is nothing really revolutionary or entirely new, but more clearly formulated, something that most people intuitively already sensed and used.

In general I see this update as an evolution rather than a revolution. Or better said - another cycle of distillation. Cheers!