The 2020 version of the Scrum Guide was published last month. There again have been refinements for the better. Many noticed it being leaner. The 2020 version is 13 pages long as the 2010 version was. The guide itself describes the Scrum framework as defined by the authors. When implementing Scrum in your organization, I’d recommend also having a look at how the Scrum Guide itself evolved over the years.
Scrum itself has been described as a revolutionary approach — in contrast to Kanban which is regarded as being evolutionary. Kanban implementations begin with: “Start where you are and make this visible”. Scrum starts with: “Have this whole set of accountabilities, artifacts, events to be in place, and here is how the rest of the organization needs to interact with you — display those values and adhere to those principles.”
Scrum Guide 2020:
Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.
For Product Owners to succeed, the entire organization must respect their decisions.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment.
Companies don’t like revolutionary approaches, and neither should members of civilized societies. Revolutions require war chests and cause additional disruption within organizations and societies. In many cases, those which led the revolution are not fit to live in the new society they helped build. The skills, values, and mindset of revolutionaries simply don’t match the more civilized behavior needed after the revolution. Some bridges burnt can’t be rebuilt.
What companies like are transformations. Shifting resources from somewhere, allocating a budget to something, a promotion or new title printed on a business card, maybe having some additional responsibilities for an employee who was dissatisfied anyways — those are the things that enterprises excel at, it is their daily business.
Scrum might be precious, it certainly is costly. Training or hiring Scrum Masters is the least of the TCO (Total Cost of Ownership) of having this framework. The disruption in the typical PMO (Product Management Office), the risk of setting up a team of many disciplines (thereby imposing fear on or angering their managers), the business risks attached to a late product delivery because of restructuring efforts. There might even be people leaving the company because of these efforts — and in many cases, those leaving are not usually the least qualified or the least productive. One CEO explained it like this:
“We are 3,000 people on a giant cruise ship. But what we need to be is 3,000 people in a few hundred yachts. So, how do I get my people safely into those smaller boats?” (The journey to an agile organization)
Even companies that are already developing an agile mindset would go for some Inspect & Adapt cycles in a Scrum implementation to determine whether the investment would be worth the results. Other companies will go for Project Plannings, milestones, and yearly budgets.
Expect to find many teams in a state of transformation towards the minimum set of rules described in the Scrum framework.
This is not bad, it is how companies act. Enterprises invest resources towards a transformation by weighing them against the expected results which they might gain from it multiplied by the risk factor. Enterprises that are not really focused on business value but rather on processes, or functional hierarchy — might also additionally slow these down transformation because of different more selfish reasons of employees like a promotion or having more directs.
Even when having everything described in the Scrum framework in place, expect flux. Scrum Teams setting their boundaries by the framework will evolve, but might still not be, what one would necessarily call mature, or high performing teams. Dealing with lacking skills, overcoming dysfunctions, lack of domain knowledge, setting up workflows, new tools for collaboration, all these are stages to become not only a Scrum Team as described in the scrum guide but a high performing team.
Expect to find many Scrum Teams in a state of transformation towards “a high performing team still within the Scrum framework” or “somewhere different”.
The Scrum Guide — being a framework — doesn’t describe a process of how to get to be a Scrum Team, nor the steps needed to evolve from there. Since Scrum Teams are focused on business value, this might give the organization an incentive to hand over enough resources for the team to continue what they are doing. Other than getting money, clarity in process and responsibilities, the Scrum framework doesn’t provide to team development. It describes the one fixed state where everything a Scrum Team needs is in place for the first time.
This is no criticism by the way. Since the inventors of Scrum would have no idea of the state every organization wanting to use the Scrum framework currently would be in — how could they provide the steps needed to get there? Even a framework like SAFe, which has hundreds of pages in their training material, describes four different stages of their idea of an enterprise, only has one roadmap on how to move to the first stage and not on how to move in between.
Let’s have a look at how the team is supposed to evolve by looking at the Scrum Master. According to the 2020 guide, the Scrum Master is:
Coaching the team members in self-management and cross-functionality;
Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
Facilitating stakeholder collaboration as requested or needed.
Leading, training, and coaching the organization in its Scrum adoption;
(Scrum Guide 2020)
The Scrum Master is responsible for training, leading, coaching, facilitating, and helping. Having been a trainer and teacher, I know he doesn’t do all of these things at once. Sorry — can’t be done. Even disciplining and teaching — two of the duties of a teacher — are two complete opposites. They are different stances towards team and organization. A good article on that topic has been published at scrum.org.
Since a Scrum Master also evolves in regards to personal skills and maturity: Another article on that topic with a nice south park picture.
What I don’t like about the second article is, that the chart with the expected benefits from having an Expert is shown as high — which is good — but this could also be misinterpreted in a way that the expert also should act as an expert only towards the team. Having an expert Scrum Master, who only takes the expert/mentor stance in a Scrum Team that just has been assembled, would provide no benefits to the company at all. Having a Scrum Master taking the teacher stance towards a Scrum Team which has been working in this setup successfully for years, would even qualify as being harmful. An expert can do all of these stances, knows when to employ them and how to determine team maturity. A good practice for experts unsure about this: Provide the team with the means to determine maturity by themselves, or ask.
You might have noticed the many white areas at the end. As Geoff Watts wrote in his beautiful Scrum Mastery book — the aim of the Scrum Master should be to make himself obsolete. A silver lining for the colleagues who — measured by their results — obviously have been doing good work: I’m sure an organization you provided so much value for, would let you stay in a team — just in case some conflict management might be needed (should you decide you want this).
The Scrum Master should do his work differently in teams of different maturity, maybe even with team members of different maturity, especially when helping setting this team up.
I’d like to continue with a look at the revisions of the Scrum Guide. Those are also shown in a nice article by Paddy Corry, here you’ll find a picture showing all changes. Some deprecated practices worth mentioning in this context between 2010 and 2017:
The Product Owner keeps an updated Release Burndown posted at all times.
Each Scrum Team meets daily for a 15-minute status meeting called the Daily Scrum.
Also, the change of commitment to forecasting has been discussed extensively. In many cases, there has been a shift from prescriptive to optional or best practices — and sometimes the other way round. The Scrum Master himself was introduced in 1998, the Product Owner in 2001. The only version valid is, of course, the most current. The old scrum guides described some practices, which in teams which are struggling with scrum, are maybe useful.
It might(!) be useful for a Scrum Master to explain in a young team:
“Dear colleagues, today I’m going to show you how to generate burndown charts. We’re going to have these at least for the next three sprints.”
It might be useful for a Scrum Master in a team, which has worked in different departments before, to declare:
“Dear colleagues, today I’m going to show you how to conduct a “scrum daily”, which is in some aspects similar to the status meetings you had until now, but not in all. It’ll be a session by the team and for the team in the future. The different managers of your departments are here with us today and might ask questions, but I’d like them to leave after having been present for some weeks. We’ll start with answering three questions — and we’ll move on to any working mode which allows you to inspect your progress to the sprint goal as soon as you got the idea what this is about.”
It might be useful to arrive as a Scrum Master in a team having worked together in a waterfallish approach before and declare:
“Dear colleagues, we had our third sprint review yesterday. Today we have our planning for the next two weeks. I noticed none of the items you planned were finished during the last 6 weeks. You can adapt your plan to whatever you need, but please make it so, that you can finish. Let’s show some commitment.”
It might be useful to show up in the planning in the same team two weeks later and declare:
“Dear colleagues, up until now you had quarterly releases. When we started with scrum two months ago we went to 2 week sprints, but nothing finished. Usually I’d recommend even shorter cadences and do a root cause analysis with you, but I’m seeing you’re getting a lot of pressure from our organization which I can’t resolve right now. I’m working on it, but would six weeks be sufficient to finish the documentation and be comfortable with? Maybe not call it Scrum yet.”
It might be useful to arrive as a Scrum Master in a new team after one month and declare:
“Dear colleagues, I helped you set up a scrum board. You seem not to need it. Would you prefer me to help you moving your cards for the next two sprints to show why this provides value in my opinion, or should we remove the board and you’ll come up with an own solution on how to provide transparency to each other.”
It might be fun to arrive as Scrum Master even in a mature team and tell:
“A chicken and a pig are together when the chicken says, “Let’s start a restaurant!” The pig thinks it over and says, “What would we call this restaurant?” The chicken says, “Ham n’ Eggs!” The pig says, “No thanks, you’d only be involved but for me it would be a real commitment!”
One thing you can be certain about, regardless of team-maturity: It wouldn’t be useful to ask a team starting with Scrum to set up their refinement as the pre-2013 grooming, and no one should complain if you call this SCRUM, Scrum, or scrum.