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

We are not alone: Insights into our Company Exchange Concept

To be Agile is to always question what we have to improve. We can inspect what we practice within our company and try to find ways to improve. However, if we look to what’s happening externally, we can learn new ways of doing things and, most importantly, learn from mistakes of others.

“Learn from the mistakes of others. You can’t live long enough to make them all yourself.”

― Eleanor Roosevelt

This should be a good starting point to make us want to have a way to interact with other companies that share the Agile way of working, to know what they do and understand how they do it.

The Why

Creating a #network of people and interacting with them over a specific topic can be very interesting. We can make people have some cool time to think and discuss about a lot of topics, but why is it so important to do these exchanges with other companies? What can we gain with that? This is the main question we should answer in order to make the efforts and time spent to be worthwhile. 

The other day I heard that what we evolved in the last 2 years to be comparable to what another well-known tech company achieved over the period of 10 years. Growing this fast can be really overwhelming and may cause real damage to us as an organisation, depending in how we deal with our growing pains. 

If we want to be more effective in what we do, striving to build the best digital products on the automotive market, to get in touch with other companies to #share and #learn from them is extremely important. Unless we think that we know it all and can prevent everything. But I personally don’t think so.

Let’s get some valuable knowledge

To get more #knowledge is the immediate thing that comes to my mind when I think on the reasons to participate in exchange initiatives. But what can we learn from other companies?

In terms of #Agility, there are a lot of topics we can gather some insights on from others, understanding their (best) #practices and deriving ones we could apply in our environment. 

This knowledge transfer can be quite different depending on the companies with which we interact. To better understand that, we can look at the following clusters that are relevant in our case:

  1. First and maybe the most important cluster is the companies from the Daimler/Mercedes-Benz universe. Collaboration within this universe will provide us more insights about what is happening in the Daimler world. At the same time, this can make us more relevant by sharing what we do and inspiring other departments and subsidiaries to implement or enhance the Agile way of working. In terms of #compliance, this relationship between companies of the same group is much simpler in what we can #exchange, making this one of our focus.
  2. Another cluster we want to collaborate with includes the large companies that are in the process of Agile transformation. We are especially interested in experiences on the topic of #scaling with Agility. We have grown a lot over a short period of time and are facing the challenges of that process. Sharing with others and learning about their pains and mitigation strategies can help us prevent some problems by acting with conscience on those possible outcomes.
  3. We can also expect that we can learn a lot from the companies of our size assuming they experience similar issues living Agile. The learnings we can get from each other’s experiences may be of an enormous importance because of these similarities – similar problems could be solved by similar solutions. I know, it depends, but it might work or be just #valuable input to work with.
  4. In this last group I put the companies that we must be really careful to share our experience with, our #competitors. To understand with whom we can interact and what kind of information is allowed to be shared from the compliance perspective is one of our main concerns.

Beyond the knowledge

Networking is also an important aspect of this kind of initiative. By working #together in work sessions we can dig into new and old questions and generate new knowledge that comes out of the collective intelligence. This exchange events are not only about knowledge transfer but also a way to generate insights and solutions, encouraging the out-of-the-box thinking.

To get inspiration from new ideas, new perspectives and learning new trends can and must be in the list of objectives. Fresh ideas are always welcome, we really want to use this exchange activities to link the outer world, to get new and valuable information and also, I believe, to enforce our #ideas and ways of working.

As a side effect of all points mentioned above, when organising and participating in knowledge exchange events, we want to raise #attention to what we do and how we want to do it, especially that of our direct stakeholders. Being prominent on the market by being a live actor on organisational topics can also help us consolidate our position in the purpose of making Mercedes-Benz the Digital Champion of the Automotive Industry. On one hand, we are doing it by building products in the way that customers love, and we are proud of. On the other hand, by being pioneers on the organisational level and reinforcing the Agile way of working across the Mercedes-Benz digital universe.

Yes, we are trying to show off. But at the same time, we must be humble and know that we cannot know it all and can always learn from other experiences.

Exchange is a two-way communication path

Obviously, with the knowledge exchange initiative, we seek to get valuable information, but we also want to #give something back. Give-and-Receive concept ensures that we can get interested participants in such activities and brings value to each one of us.

For example, we already received a huge interest in #Holacracy, the organisational framework which is used in Mercedes-Benz.io, and how it connects to an Agile way of doing things. We should not try to impose our ways or make others follow the same path, but we can share our experience of being organised as we are, the challenges and how we are dealing with them. 

To share what we do can be very valuable for others but is also a good #opportunity to show how we organise ourselves, our values and how we foster them as well as how we want to be as an Agile company. While providing some food for thought to others, we are positioning ourselves as a valuable player on the digital companies’ market.

The How after the Why

We work in a holacratic organisation, we have skill-based circles that contains the roles that are needed within the organisation. Once the need to exchange the knowledge with others was identified, we created the Company Exchange Coordinator role in the Agility circle and settled its purpose and accountabilities.

The Agility circle includes two important Scrum roles: Scrum Master and Product Owner and is divided respectively in two sub-circles for “The What” (for POs) and the “The How” (SMs). These are the home base for all the Product Owners and Scrum Masters in the company. 

If you want to know more about Holacracy, check this blogpost from Susanne Kopp.

The Company Exchange Coordinator role for Agility is the role that I fill, along with Karina Ivanenko, and it has the #purpose of hardening and establishing collaboration between Mercedes-Benz.io and other companies for exchange of knowledge and ways of working. We work together in this coordination role, we combine the needs and interests of our two roles, me as a Scrum Master and Karina as a Product Owner, in two different locations, Portugal and Germany, so we can expand the spectrum of possibilities across locations.

What we must do is defined in our role #accountabilities – another important part of a holacratic organisation. In our case, the main point, in my opinion, is to develop a way to exchange information and experiences with other companies in an organised and compliant way.

Since this is a coordination role, the idea is not to do everything but to be a point of contact and guidance for actions related to exchanges with other companies regarding Agility. 

It is important to mention that we are not the only people in the company who are driving the topic of knowledge exchange. Apart from the Company Exchange Coordinator role, there is one dedicated to the collaboration with Universities – University Exchange Coordinator. These both roles exist not only in the Agility circle but also in the circle for Concept, Usability & Design (CUD).

The four dimensions of our company exchange: Mercedes-Benz.io’s Agility and CUD circle, collaborating with companies and universities

We are working together in these 4 dimensions to foster exchanges with 2 different kinds of entities (companies and universities), for now in 2 different areas (Agility and CUD) but in the #future it can be done in other subjects/circles.

Current status

In this group of 4 roles of exchange coordination, we have been working on the definition of the goals and measures to reach them. We have identified some goals that are relevant for all dimensions as well as specific goals that must be handled and fostered in each individual role.

Company Exchange was kicked off by organising our first meet-up in our offices in Stuttgart, in a joint venture with Detecon International GmbH, where we were able to #evaluate the goals that we want to achieve with this initiative. We were happy to see that it was valuable for most of the participants and that such format makes sense in regards to the set goals.

“It is beyond a doubt that all our knowledge begins with experience.”

—  Immanuel Kant

We received companies like Deutsche Telekom, Deutsche Bahn, Bosch or Haufe-Umantis and everyone got a chance to speak out their experiences regarding Agility and the challenges of scaling product development to multiple teams (agile@scale). Different realities, structures, states, sizes, methods, frameworks… a lot of information was shared in presentations with some space to get answers to the raised questions. 

But it was not only a time for company presentations, we gathered the knowledge and experience in the room and set a challenge for a small workshop. It was a great moment for everyone to interact, discuss ideas and reach #common ideas and views over agility topics from people that share a #mindset but have different realities.

This experience gave us a clearer view of what we can achieve with these exchange initiatives, raised a lot of ideas and some doubts for us to work with.

Next steps

We are still working on this exchange concept; we want to make all the goals #transparent to everyone and to define ways to measure the result of the time and effort involved in it.

We also want to establish contact with further companies that may be interested in this kind of exchange. If you are interested in this topic, know some cool companies that may be open to this exchange and may also want to be part of the related initiatives, please contact us and let us know!

And if there’s a thing that I can recommend is, while going fast, look out-of-the-circle if you want to go far.