The new Scrum Guide is much better than the old one – less prescriptive and more clear, although there are still some parts where you may find inconsistencies. Without further introduction, I’d like to walk you through major changes, focusing on those which I believe will have the biggest impact on how we work and how Scrum is being implemented and perceived in organizations. If you want to compare all changes side by side, see for example here.
First – Scrum is not made only for product development anymore. Scrum is for solving complex problems. Of course, product development is a complex problem, but an IT implementation project is a complex problem too. I believe that now Scrum is more generic than it was previously, and with this and some more changes made, it can be easily adapted for activities other than product development (such as the above mentioned project management).
The main purpose of Scrum is to support value generation.
Focus on value. It is not any more a set of processes which you follow while developing, delivering and sustaining the product. It is a framework that helps people, teams and organizations generate value. Something which was hidden behind ‘practices’ in the old version, now is given to you transparently in one the very first sentences of the Scrum Guide. Hopefully it will help us to avoid having the Zombie Scrum.
Lean thinking added. There are no direct references to the lean thinking in any other part of the Scrum Guide, although increased attention to focus and waste reduction is often mentioned. Will it increase our awareness on these topics?
No more Development Team – now we only have a Scrum Team and accountabilities (not roles) in it.
Small change but with a significant impact on various things – relationships in the Scrum Team, Product Owner’s empowerment in the organization, scaling. Let’s go through them one by one.
Relationships in the Scrum Team. I saw many cases where Product Owner was a manager, someone defining and delegating tasks to the Development Team, and a person a bit higher in the organizational hierarchy. Now Product Owner is a Scrum Team member, same as Developers and Scrum Master are. All of them are equally accountable for collaboration with stakeholders, product development or maintenance. This change should have positive impact on cooperation and communication inside the Scrum Team and make team integration easier.
Product Owner’s empowerment in the organization. Product Owner needs to have decision making abilities and the organization need to respect his/her decisions. To assure this, Product Owners often come from middle or even top management level. I see significant challenge here to integrate such a person into the Scrum Team, so that this integration is on the similar level as for Developers. And what is more – there might be a new challenge to fight for empowerment of Product Owner in the organization.
Scaling. In most of the organizations we have more than one Scrum Team working on the same Product, and of course, we would love to have a single Product Owner managing a single Product Backlog. In this exemplary case – 1 Product Owner working with 1 Product supported by 5 Scrum Teams, how to keep the Product Owner equally engaged in all 5 teams as a Scrum Team member? Will he find time to participate in 5 retrospectives during one Sprint with equal attention? Isn’t that a wrong pattern – to be a member of more than one team?
This is one of several reasons why I believe a sub-team similar to the ‘old’ Development Team may naturally born within the ‘new’ Scrum Team.
Another reason that may support creating the sub-team is Daily Scrum – a meeting, which according to the new Scrum Guide is not for the whole Scrum Team, but for Developers only. So are we one Scrum Team, or not fully?
It’s a clear definition of the end accountability of the Scrum Master. He is no longer only a teacher, coach or mentor, he is now a person accountable for the effectiveness of the Scrum Team. Replacing ‘servant-leader’ with ‘true leader’ is a very powerful change as it will now be much easier to explain to organization why we need to have Scrum Masters. It’s to increase effectiveness of teams. It will be also easier to evaluate Scrum Master’s performance.
The only concern I have (and that’s why I don’t like this change) is that in strongly hierarchical organizations, it may lead to the situation where Scrum Master becomes manager to the team. Especially if they wrongly implement further Scrum Guide changes – ‘facilitation of events’ was replaced by ‘ensuring that all Scrum events take place’, ‘removing impediments’ was replaced by ‘causing the removal’, and so on. When you are in a very traditional environmenti, it’s easy to fall into the trap of Management 2.0 inside the Scrum Team.
In the new Scrum Guide there are three clear points to cover during the Sprint Planning (no need to keep the order!):
- [WHY] Product Owner proposes how we can increase product value.
- Scrum Team, all together, create a Sprint Goal.
- [WHAT] Developers through discussion with Product Owner select Product Backlog Items which support Sprint Goal realization.
- [HOW] Developers create a plan for the upcoming Sprint.
Why (Sprint Goal) + What (selection of Product Backlog Items) + How (Sprint plan) = Sprint Backlog.
There is more clarity when it comes to the Sprint Planning output right now, and this additional ‘why’ part will hopefully increase focus on value creation and support elimination of waste. It is also a great opportunity for Developers to challenge Product Owner’s ideas and share their own.
Product Goal is not a new artifact, but it is one of the commitments (see below) – a long-term objective for the Scrum Team. In the old Scrum Guide there was not much about long-term goals. The only statement connected with the long-term vision can be found in description of an Increment : Increment is a step towards a vision or goal.
Product actually requires a long-term vision, therefore it is often added to the Scrum framework implemetations anyway. It never was a part of Scrum Guide itself though. Now this need of expressing long-term goal and vision is fulfilled by Product Goal.
Product Backlog emerges to define “what” will fulfill the Product Goal.
Scrum Guide 2020
This change will have huge impact on how we work with product (or projects) using Scrum. Basically, having long-term goal is a great thing, but the key point here is what happens when you reach it (or are close to reaching it)? The Scrum Guide says: [Scrum Team] must fulfill (or abandon) one objective before taking on the next. Reading this I would like to share with you several questions:
- How to work on and plan the next Product Goal? You can only have one Product Goal in the Product Backlog, with all Product Backlog Items related to it. How to plan next one then, how to refine it? Should we create a separate Product Backlog for the next planned Product Goal, or is it allowed to start filling the existing Product Backlog with Items not related to the Product Goal that is currently being worked on?
- Is Product Goal just a Project Milestone for IT implementation projects, so kind of a gateway to run projects (not products) with Scrum?
- When can I abandon the Product Goal? Should I?
- How often can I switch Product focus? The Product Vision directed the Team through the whole Product lifecycle. With the long-term Product Goal (but still shorter than the Product Vision), I’m a bit concern that it will become harder to keep consistency in product development. The Team may just catch every mid-term opportunity instead of keeping long-term consistency.
From one hand I appreciate this change, especially that I believe it will support Product Owners in keeping clean and small Product Backlogs, giving a green light to delete from Product Backlog all items “for later”, “to remember”, “maybe sometime”. On the other hand, it opens doors to possible bad patterns which may arise when you wrongly respond to the questions asked above.
Increment in the old Scrum Guide was not described with such clarity as it is right now. Now there is no doubt that:
- Definition of Done is applied to each Product Backlog Item, not to the Increment itself.
- Increment is born from each Product Backlog Item.
Scrum Teams should create their backlog in a way that each and every Product Backlog Item directly creates additional value – an Increment.
It is also a hint that it’s better to work on Increments (= Products Backlog Items) one by one, as releasing one of them already brings value, rather than working on multiple in parallel.
Three additional small comments about the Definition of Done and Increment.
First – now, the Definition of Done is created by the Scrum Team, in case it’s not coming from the organization. The old Scrum Guide stated it was the Development Team’s effort only. See one of my previous articles about Definition of Done here to read about possible reasons for this change.
Second – If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. No way – why is that?! Isn’t that something against Agile fundamentals – fast feedback loop? Isn’t that something against Scrum fundamentals – empirical planning? Whenever you can present some work, even not finished, but ‘showable’, use the Sprint Review to gather early feedback on it and do use the new knowledge during next Sprint planning. Just remember to clearly mark that this work is not Done yet. For more explanation see here, were I answer questions about Sprint Review.
Third – now Increment needs to be usable, not potentially releasable. I expect that due to this change we will more often be engaged into discussions starting with question like “Is Proof of Concept an valuable Increment? We cannot release it on production, but it is usable and can provide some feedback regarding the new technology which we plan to use.” Do not fall into the trap of creating Increments which are not usable by your customers!
The new Scrum Guide introduces commitments for each artifact to enhance transparency and focus:
- Product Backlog -> Product Goal
- Sprint Backlog -> Sprint Goal
- Increment -> Definition of Done
Very good change that is cleaning up and clarifying all ‘old Scrum Guide’ ambiguities around Definition of Done or Sprint Goal and it’s place in the framework. Now we have a clear connection between all important Scrum terms and put additional focus on… focus.
What are your thoughts on the new Scrum Guide? Share them in comments and do not hesitate to ask any questions you may have.