Now that we’ve reviewed the significant changes to the official definition and practice of Scrum introduced in the November 2020 edition of the Scrum Guide, it’s time for me to weigh in on what I think is good – and what’s not so good – based on my experience with Scrum out in the real world. Since I’m – more than somewhat surprisingly – basically an optimist, I’ll start with the Good.
The overall simplification of terms and descriptions is generally a welcome improvement to the Scrum Guide. Even more significant to me is the removal of all of the legacy references to software development that I’ve had to explain my way around for the last several years. Scrum is now officially applicable to any complex “product” domain. Yay! This is, of course, a belated recognition of the reality of the way Scrum is being used today.
Other positive changes include the addition of the Product Goal as an official artifact. I have been coaching and teaching this practice for over a decade, using the formerly defined optional artifact, the Product Vision, as a placeholder for this important element of product development with Scrum. Tying the Product Backlog to the Product Goal as a commitment is another significant and powerful driver of effectiveness. This is really good stuff.
I am also very pleased that the Development Team has given way to Developers. The team-within-a-team structure was always confusing and completely unnecessary, so good riddance. It is now even more apparent that the Scrum Master, Product Owner, and Developers are co-equal members of the Scrum Team who share ultimate accountability for the outcomes they collectively produce.
Another big positive is the assignment of self-managing authority to the Scrum Team. The myth that individuals on a Scrum Team need to be managed by some external organizational structure – a manager in other words – is now well and truly extinguished in the formal description of Scrum. Now it’s up to organizations to catch up with Scrum. The role of management in a Scrum environment has always been an open question, but now the Scrum Guide provides a workable answer from the perspective of the Scrum Team. I don’t for one second believe organizations will wake up tomorrow morning and decide to scrap their outdated, outmoded, and ineffective functional management models and overall hierarchical, authoritarian management structures, but at least the official practice of Scrum is no longer on the fence in this area.
The Not So Good
The not-so-good revolves around the loosening up of some of the definitions on the Scrum Team membership. First off, the “roles” no longer formally exist, being replaced with “accountabilities.” The implication is that the accountabilities could shift around the members of the Scrum Team without constraint. The problem here is that organizations could – as organizations will – attempt to overload individuals with multiple accountabilities and claim the Scrum Guide says it’s okay to do so. Well, the Scrum Guide also says each Scrum Team has exactly one Scrum Master, exactly one Product Owner, and a variable number of Developers up to the Scrum Team maximum size of 10 members. The apparent contradiction here is just the kind of thing organizations like to take advantage of so that they can more ruthlessly exploit their employees all the while claiming to be doing Scrum “by the book.” It would have been so much better if the accountabilities were assigned to roles on the Scrum Team and just leave it at that.
The other really not good aspect of the 2020 definition of Scrum is in the area of the Product Owner. As I mentioned in Part 2 of this series, the following statement (page 5) opens up the official practice of Scrum to one of the most common single failure points I have experienced over the years – overloading the Product Owner.
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.
So, how many Scrum Teams can an individual Product Owner serve and support? In my experience, one is optimal, two is possible if you’re willing to absorb waste in terms of time spent waiting on the Product Owner and on Developers making their best guess about what to do when their Product Owner simply isn’t available at all. What about three Teams? Four? Just multiply the waste by an order of magnitude with each additional Team and you won’t be disappointed in the resulting reality. Even worse, the 2020 Scrum Guide places no limit on the number of Scrum Teams a Product Owner can serve. This is, to me, the worst possible way of thinking about the Product Owner and, as with the Scrum Team accountabilities, opens the door to organizational bad behavior. It turns out, the more ruthlessly organizations exploit their Product Owners, the less effective the entire organization becomes. I’ll say it again, with feeling: Do not share an individual Product Owner across multiple teams!
And with that I am done with this review of the changes introduced in the 2020 Scrum Guide. On balance, I think the changes are positive, with just the Scrum Team-related negatives. Avoid those opportunities to wreck your Scrum Team and you should be fine with the rest of Scrum as defined in the 2020 Scrum Guide.
Until next time, keep calm and Scrum on!