Scrum Guide 2020, waterfall strikes back?

The new Scrum Guide has been released this week and I felt obliged to share my review of this document with you.

Link to the scrum guide here.

Changes between 2017 and 2020 Scrum Guides

They are 7 major changes:

1. Less prescriptive …. which I challenge and disagree because of the wording
2. One team, one Product is a good reminder
3. Product Goal instead of Vision will lead to a lot more upfront thinking and analysis to define such a goal
4. A Home for Sprint Goal, Definition of Done, and Product Goal: that’s a lot of goals, a lot of constraints ….I feel processes, controls here
5. Self-Managing over Self-Organizing: that’s a very bad choice. Moves away from agile to more leanish and allows management to force reorg and developers have to comply and resiliently manage themselves through it.
6. Three Sprint Planning Topics: this is overprocessing for me. Sprint planning is a deal, an alignment. This is helpful for Scrum Trainers and Scrum Coaches but I can’t see the value for the developers
7. Overall Simplification of Language for a Wider Audience -> I disagree. It is about giving the keys to management and other Office´s of Methods and Tools or PMO

Deep dive in the text

Scrum Definition

“In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

A Product Owner orders the work for a complex problem into a Product Backlog.

Comments: The person ordering the work in the early stages of the scrum was the customer and the Product Owner was the one able to translate the needs of the customer into a vision. That vision is decomposed into Product Backlog Items (PBIs) in the Product Backlog. That made sense in an agile way of working.

In the new version of Scrum, the Product Owner becomes again the voice of the customer or is the customer: he/she orders the work. This is a roll-back to the early stages of the scrum before 2010. Here, the new Scrum Guide validates the idea that Scrum is only for the Development Team and it is no longer a Scrum Team composed with a PO as a team member in charge of functional items.

Interpretation risks:

This will reinforce the position of bad project managers patronising the development team where he/she will own the project budget and the team and scrum master are in a customer/provider relationship. I fight against this toxic behaviour for 13 years

Who will benefit from this update?

The impact of Scrum per se has been reduced at an operational level only. Sutherland has Scrum at Scale, Schwaber has Nexus to cover the organizational aspects of scrum. 2020 Scrum Guide is giving more space for the scaling methodologies and will help mostly the training providers and the methodology coaches by giving them an unnecessary credit. It mostly undermines all the scrum teams who find their way in an agile working model as a complex adaptive behaviour: self-organised and without authority in the scrum team.

The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

With little operational experience, every agile team are producing value during a sprint while using team dynamics.

The wording is explicit, the scrum team is a productive system. It is no longer an experimenting team. We can play with words and balance between knowledge value and business value. The complex-systems-like approach that we had in the earlier versions where we avoided to have goals and enforced the idea of forecasting is skipped away.

The new scrum guide is embracing linearity in a very Lean manner.

This is an argument that scrum is no longer Agile.

The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

It looks similar that the earlier version but “adapt” has been replaced by “adjust”.

Adapt gave the idea of embracing change: “you adapt something to an emerging context”.

Adjust has a different meaning: “the plan remains unchanged and you proceed to adjustments to ensure alignment”. Adjustment is an action when you discover variability in the system and you action countermeasures to recover the initial system. When a product line stops becomes of a defect you adjust the tool and relaunch the line. When the production line has to respond to customer demand or different solutions, you adapt the tool.

Repeat “

… and you repeat the process

The change in the scrum definition is not innocent. The big picture for non-native English speakers hasn’t changed. The chosen words will mostly help the traditional management by relegating scrum as an operational tool for development teams only.

Scrum Theory

“Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.”

Here comes “lean thinking”. Even if the word Scrum was strongly inspired by Takeuchi and Nonaka, Scrum has strong relations with Kaizen (Japan) and a bit with Lean (USA).

Lean thinking has a feeling of noblesse and most of the MBA classes have an L6S program for their future managers. Unfortunately, in 1995, the Lean Institute designed the evolution of Lean Manufacturing called Agile Manufacturing. 25 years ago, the Lean Institute raised the point that linearity doesn’t work any longer in a global and connected future. That connected future is non-linear and it is called the complex adaptive system. People like Snowden, Kruse and Niedschmidt have clearly described it as the future of work.

Scrum practitioners (those doing the real work and not observing or talking about) have understood that the future is agile and not lean.

Mentioning “lean thinking” as the foundation is rude and has been added since the latest version.

Transparency

“work must be visible to those performing the work as well as those receiving the work” is interesting for “those receiving the work”. I preferred the old form.

“perceived state” is not a good choice. I would prefer something like “decisions are made on real data”.

“Inspection without transparency is misleading and wasteful”. This is for those who didn’t understand that scrum is lean now. “Wasteful” wasn’t necessary and not relevant in that context.

Inspection

“The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events.

Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.”

“Goal”, “agreed goals”, “variances”, “pointless” and “provoke” seems to be the new language.

With all due respect, I don’t believe that this document has been written by Sutherland and Schwaber. It looks that the ghostwriter has a six sigma background. I’m sorry, the scrum was engaging and even words like “Controler” or “supervisor” has been used before, the way it has been written was less directive.

Adaptation

“If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.

Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.”

Again, the words, terms that I find a bit aggressive or process-oriented. I like the last sentence, it is up to the Scrum Team to adapt. A long long time ago, all the stakeholders of a scrum system have to adapt like in the Review Meeting, the inspect and adapt of the stakeholders. Why not mentioning it here?

Scrum Values

Successful use of Scrum depends on people becoming more proficient in living five values:

Commitment, Focus, Openness, Respect, and Courage

“The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. “

Commitment and goals are back. That´s a good point.

Scrum Team

“The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”

No sub-teams are clear, but I expected a clear statement that people might be members of a single team and not multiple teams like we usually see. I miss also the mention that a Product Owner and the Scrum Master are dedicated to a single team and not to a collection of teams.

On the other hand, the notion of no-hierarchy makes sense but it is contradictory with the notion of “ordering work… into the Product Backlog”. The verb “to order” inherits a notion of authority I.e. hierarchy. This will lead to a couple of unnecessary debates in the organizations in the coming weeks.

“The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. “ Ten is quite large for a Scrum Team.

“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” This is also confusing. If I read it well, if a team becomes too large they have to split into different teams sharing the same goal, the same product backlog and the same product owner. This is in the opposition with what has been mentioned before, This allows the creation of some kind of Feature teams with a lot of dependencies between them. It will also support the inefficient idea of proxy-Product Owners for the sub-team, even it has been mentioned before that they are no sub-teams. How weird is that?

“The Scrum Team is responsible for all product-related activities …” Mentioning “Product” is not helping Scrum Teams working on Services, Data or non-Product-related activities like one of my Board-of-Directors Scrum team. The word “Product” will cluster Scrum as a Product Development only framework and that makes me sad.

“The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.” It is a positive enhancement. The shared accountability of the Scrum Team including the Scrum Master is something that was missed. It will help to position the Scrum Master as an active member of the value creation process and not an outstanding “process Controler”.

Developers

“Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”

“- Creating a plan for the Sprint, the Sprint Backlog;

• Instilling quality by adhering to a Definition of Done;
• Adapting their plan each day toward the Sprint Goal; and,
• Holding each other accountable as professionals.”

Planning over following a plan is in the DNA of Agile and was a key differentiator of Scrum as a scaffolding of Agile. Using the word “plan” is emphasising the idea that the Developers are doing professional work. The intention was maybe to enforce that idea but it supports a waterfall principle that patterns (plan) precede data (outcome). It is a bad idea to use a plan instead of planning.

Product Owner

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

Here “Vision” has been replaced by “Product goal” and this is a very bad idea. In the early ages of Scrum, we had the Vision and the Sprint Goal. Sprint Goal has been removed to allow empiricism and Vision were the Northstar or the Purpose of team´s engagement. A Product Goal is very explicit and tells the team that they are here for that specific goal only. Business Analyst has now a green card to transform their requirement “catalogue” into a Sprint Goal and Developers have to execute all necessary activities to reach that goal without challenging it.

If you have still a doubt that Scrum is back to Product Development :

“The Product Owner is also accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal;
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible and understood.”

It is a mantra!

Scrum Master

“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.

He/she is no longer ensuring that the agile values are respected and understood.

“ They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.”

Who are they? If the order is respected “theory and practice”, Scrum masters are shifting from Team coaching to PMO.

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.”

This is interesting too. What kind of true leaders are they? Do we have now a PO that orders the Product Backlog, the Scrum Master leading the team in a Scrum manner, and the Developers to execute those orders? Sounds bad and intrinsic motivators have been forgotten for the sake of the Product. Seriously?

The Scrum Master is a servant-leader and that word should replace the word “true leader”. A true leader cannot be a coach, it is a conflict of interest. A servant leader on the other hand can coach.

Scrum Events

I will make this short even the wording is very bad and hurts my brain and guts all the time.

Here are my biggest concerns:

- “No changes are made that would endanger the Sprint Goal;” Here comes Sprint Goal! In Scrum Teams, when the developers are discovering that the Goal is not achievable, or that the commitment becomes more complicated, or that the Sprint Goal becomes incoherent, should the Development Team stick to that goal? In “real Scrum”, scope change isn´t allowed during a Sprint (changes outside the Scrum team) but changes at Team level is a constant (dev team changes) that´s why Grooming and Refinement meetings are used.

“Scope may be clarified and renegotiated with the Product Owner as more is learned.” I understand the idea behind but I cannot accept that in the Scrum Guide. The Dev Team doesn’t negotiate the scope with the Product Owner (he/she works in the team), it is the product owner, as the voice of the scrum team, who negotiates the scope with the customer.

“Each Sprint may be considered a short project.” This is very risky. This will be used as an argument for sprint contracts. From a project management perspective, mentioning it isn’t that bad. But you have to consider how the market is behaving and how poor project management knowledge is in companies.

Sprint Planning

Topic One: Why is this Sprint valuable?

Topic Two: What can be Done this Sprint?

Topic Three: How will the chosen work get done?

There is a third topic: what is the purpose of the sprint.

Sprint Retrospective

“The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”

It is a very bad introduction of the meaning of a Sprint Retrospective. It is again a good opportunity for a 5Ws.

The retrospective is the event where the scrum team reflects on their way-of-working and it’s not limited to quality and effectiveness. The scrum team is also composed of humans having “real” intelligence. Quality and effectiveness it’s not a goal. I never saw teams gathering to make things worse and be idler.

Scrum Artifacts

“Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:

• For the Product Backlog it is the Product Goal.
• For the Sprint Backlog it is the Sprint Goal.
• For the Increment it is the Definition of Done.

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.”

The words, again are weakening the general idea of Scrum. The Artefacts are ensuring alignment of all stakeholders involved in the development of the solution, or to solve the identified problem.

Product Goal, Sprint Goal has almost been part of the Definition of Done. It has been called the levels of done: done for the product, done for the sprint, done for development, etc… I can’t see any value here to split it.

Product Backlog

“The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.”

The Product is an ordered list of what is need to improve the product means that the Product already exists. If yes, who creates the Product? And, is the Scrum team some kind of development support team? I guess it doesn’t unless the incoherence was intentional. The Product Backlog is a list of all functional items need to create a solution to address customer´s needs and business requirements. That list evolves over time to maximise the impact of customer´s needs.

It is not the single source of work undertaken by the Scrum Team, the Sprint Backlog, including functional and non-functional items, is the second source of work.

Commitment: Product Goal

Nothing more to add, just a very bad idea.

Sprint Backlog

“The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).”

Now you have to create a ticket in your Jira or AzureDevOps with Sprint Goal in it. Sorry, the sprint goal is helping you to create a sprint backlog, it is maybe the Definition of Done of your Sprint I.e. the headers of your Kanban board, but it has nothing to do with the Sprint Backlog.

My conclusion:

I don’t know who wrote that document but I have serious doubts that Sutherland and Schwaber did.

In the community, people are repeating the intention of that new version like making scrum more accessible to a larger community. I have to say, they failed.

It is a confusing document and it will create more conflicts in running scrum teams that it will solve problems.

If that document, and I hope from all my heart that it doesn’t, represents the new scrum, it will be the most important fall back in centuries. It moves Scrum away from agile to become a lean six sigma process-oriented normative approach.

From some running conversations I launched on Facebook, it sounds that there is a difference between the word-said and the words-written.

The early intention was to simplify the definition of scrum. Is the job done? Can you handover the scrum guide to your customers and ensure that they understand it without attending a training?

Another intention was to become accessible for non-IT people. Is the job done? Mentioning Product that much position scrum for Product Development only. This sounds maybe trivial, but if you work on large SAP projects and the Project Manager tells you stop doing scrum because you completed the Development phase and you are running into the Testing phase, you have to stop doing it by now.

On the other hand, the new scrum guide is limiting the work area of scrum at team level increasing the opportunities for “at scale” approaches.

Forget that version and consider the older versions.

The scrum guide 2020 is the Windows Millenium of scrum. Do what we all did at that time: we kept Windows XP.

Pierre

Word count

Originally published at https://agilesqr.com on November 19, 2020.