The New Scrum Guide 2020 - with Maria

Twenty-twenty is the 25th anniversary of Scrum – on another note, it’s also my 25th year, 95 was a great year - and to celebrate it, Jeff Sutherland and Ken Schwaber released an updated version of the Scrum Guidelines. You can check it out here, and I recommend you to read it (although I might be biased). If you do not want to have a look into it and your time value lies somewhere else, I invite you to stick around until the end of this blog post and see what has changed and the things I am most excited about. I will explain how Scrum came to be 25 years ago, why it changed now, and what changed.

How did Scrum go from a Rugby term to a worldwide known project management framework?

Way back in 1986, Hirotaka Takeuchi and Ikujiro Nonaka, two business professors, wrote “The New Product Development Game”, where they analysed teams from different companies and compared them based on how good and innovative they were.

They concluded that companies that had flexible processes, cross-discipline, autonomous and goal-driven teams and an environment where the management only intervened to remove blockers from the process, were doing a lot better than companies that had a very traditional cascade process (does this ring a bell?).

In 1993, Jeff Sutherland (one of the Scrum authors) joined a company called Easel. He was asked to deliver a new line of products aimed at big clients in only six months. Jeff got together with his team, talked them through the project, the requirements, and realised that if they used the same old development methodology they would fail. Based on that, he told his team to study and look for project management books and articles and went to talk with the director of Easel. Jeff told the director that they were going to destroy all of the Gant charts created for the project and would not follow any of the detailed plans already written. The director, taken by surprise, surely thought that Jeff was mad and wanted to know why. Jeff asked him how many Gant charts had he seen during his life, to what the director answered “Hundreds” and Jeff added “And how many of those were right?”. I can only imagine how this conversation went and I play it over and over again in my head as I find it rather brilliant. So, instead of following the waterfall methodology and the Gant charts, Jeff told the director that in a month the team would be able to show him running software. He could see something working, try it out and give feedback on it.

Jeff’s team learned about Hirotaka and Ikujiro’s findings and decided to put them in practice to deliver Easel’s project. The eventual outcome of this story, as you can imagine, is history. Scrum is now used worldwide by a variety of industries, so you can draw your conclusions.

Why now?

First of all, this is not the first time that the Scrum Guide has been updated and surely it won’t be the last. Scrum fosters continuous improvement and that is also applied to the growth of the framework. The process itself has to be inspected, adapted and improved (see what I did there?).

Over the years, the changes made to the Scrum Guide made it prescriptive. The problem here is that in a complex world, prescription does not work. Teams are different, projects are different, the background is different, (you get my point, right?), and because of this, having a set of rules that tell teams how to work is not helpful. That’s why the 2020 version aims to go back to its roots and turn into a minimally sufficient framework.

Sutherland said “While this version has significant changes, it’s important to remember that Scrum is still Scrum and there is only one Scrum,” and I find it beautiful. Is this something like your first love? The truth of the matter is, finding where the value lies is important and making decisions based on this information is crucial. Having the courage to do so is part of the Scrum values, right? The updates to the Guide were made based on the experiences that Jeff and Ken had and on the feedback from the community of Scrum users that work and implement with these practices. So they took the feedback from the users and adapted the guide from what it was to what it needed to be.

What changed?

Alright, finally we got here. I am sorry it took so many paragraphs, I get excited when I start talking about Scrum. There are seven big changes when comparing the 2020 Scrum Guide to the 2017 version.

1. It’s easier to read. You can say they got rid of the waste (lean all the way). The guide went from 20 pages to less than 13, which will make my job of convincing developers to read it, or at least parts of it, many times easier.
2. As mentioned above, it’s less prescriptive. The Scrum guide went back to being a minimally sufficient framework. It does not specify everything you should do to deliver value.
3. There is only One Team. You might remember the distinction between the Scrum Team and the Development Team. This fostered a separation between the Product Owner and the Development Team. To “fix” this, there is only One Team, with one objective, that makes choices together, commits to one goal and that goes through this crazy software development world together. The development team should not do something they do not agree upon because the Product Owner said so. Everyone in the Team should care about what they are delivering and the impact that will have on the user.
4. Self-Managing replaced Self-Organizing. Not only do Scrum team members choose how they work and who does what, but they also have a say on what they work on.
5. Sprint Planning has to go over the “What”, the “How” and the “Why”.
6. The Daily Scrum no longer has the big three questions. Different teams plan their day differently. You can decide on how to do your daily, as long as you focus on the progress towards the sprint goal.
7. Creation of Product Goal, that is the same for the Product Backlog as the Sprint Goal is to the Sprint Backlog. It brings the focus back to the "Why?". Questions like "Why are we developing this product?"; "What is the value of it?"; "How will it impact our users?". The idea is that each sprint brings the product closer and closer to the overall Product Goal.

What am I most excited about?

First of all, I like the idea of having only One Team instead of the distinction between the Scrum Team and Development Team. The shared responsibility towards the product is something that should really be fostered. We want teams that care about their product, that understand the value of what they are doing and that take care of quality. I enjoy working with teams where I feel passion and drive. Where colleagues help each other, share good tips and also provide feedback on each other's work.

One of the most intriguing people I met whilst being a Scrum Master was a developer that was really tough when doing reviews. He asked a lot of questions, was polite and sensitive but also direct and straight to the point (I might have heard some “this code is utter crap, what were you thinking of when writing this?” in a review or two). The peculiar thing was why everyone asked him for code reviews. He may have been direct, but people also understood he was often right and had the spirit and passion to do the right thing.

Anyways, I digress, going back to the point. Adding One Team that handles “stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required”, whilst still having the three roles (product owner, scrum master and developers) with different accountabilities sounds great to me.

To build upon that, adding three topics to go over in Sprint Planning was a great move. It happened often in the past – this is my experience – that during planning teams were disconnected. The overall feeling was apathetic and boring. There was no eagerness, there were no questions asked. There was no concern about the product and delivering value.

That’s why I think that adding “Why is this Sprint valuable?” to the “What can be done this Sprint?” and “How will the chosen work get done?” will help not only with transparency but also with the definition of the Sprint Goal and motivation.

Lastly, my favourite addition from the 7 – seems that 7 is the magic number after all – is the addition of one extra artefact, the Product Goal. We live in a mad world, where there is too much of everything. Too much content, too much information, too much noise, too many options. This makes it very hard for us to make good choices and very easy for us to forget the “why” we are doing something. When was the last time you asked your team “Why are we developing this?”,“What is the added value we are creating?” or “How are we measuring it and where is the feedback from the user?”. It is important that we as product developers don’t lose track of the bigger picture and where our creations fit in.

That’s why the introduction of the Product Goal really gets me going. It enhances the focus. It brings back what really matters - the value to the user. It’s not about your team being able to do everything that is on the Product Backlog, it's about your team delivering the value that the Product Backlog items are all about. In the end Scrum is all about delivering value to the user and that is what we should focus on.

Curious to Work with us?

APPLY NOW