Thoughts on the 2020 Scrum Guide – Part 6: The Good and the Not So Good

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 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!

Thoughts on the 2020 Scrum Guide – Part 5: Scrum Artifacts

Last but most definitely not least, we come to the Scrum Artifacts as defined in the 2020 Scrum Guide. This section has also been reduced in size while seeing some pretty significant changes to long-standing Scrum definitions. So let’s dive right in.

Artifact/Commitment Pairings

One of the major changes to the definitions of the Scrum Artifacts is the pairing of each Artifact with a concomitant Commitment that ensures the Artifact is used properly and contributes to the Empirical approach and upholds the Scrum Values for the Scrum Team and its stakeholders

Product Backlog/Product Goal

The definition of the Product Backlog is now significantly simpler than in any previous edition of the Scrum Guide. The Product Backlog is now defined simply as an emergent, ordered list of everything needed to “improve” the product – whatever that might mean. Now don’t get me wrong, I’m a big fan of seeking out simplicity, but this one goes some distance too far for me, removing helpful guidance that has helped make the Product Backlog an effective Artifact for Scrum Teams for decades.

On the plus side, the 2020 definition of the Product Backlog specifically calls out the use of the ongoing activity of Product Backlog Refinement, whose purpose is to break Product Backlog Items into small, precise items that the Developers can implement during a Sprint. This section also specifically designates the Developers as the sole source of sizing estimates for Product Backlog Items. The only role for the Product Owner is this estimating activity is to ensure that the Developers understand any potential trade-offs and to help them decide which option to pursue. Otherwise, the Product Owner stays out of it.

The new Commitment that pairs with the Product Backlog is the Product Goal, which describes the desired future state of the product and serves as the long-range target that the Scrum Team uses to plan and deliver Product Increments effectively. Crucially, the Product Backlog emerges to define what is needed to fulfill the Product Goal.

This is a nice addition to Scrum practice because it formally addresses one of the major complaints about Scrum, which is the apparent focus on short-term goals at the expense of broader product-level thinking, both in terms of the business objectives and architecture and design of the product itself.

The Product Goal is the first item added to the Product Backlog. The rest of the Product Backlog emerges to satisfy the Product Goal as the Scrum Team and stakeholders learn more about what is needed to produce a successful product.

Finally, the Scrum Team is not allowed to move on to a different Product Goal until they have achieved or abandoned the existing Product Goal. This is an important practice as it prevents Scrum Teams from losing focus when the organization attempts to push multiple products onto a Product Backlog. There can only ever be one Product Goal in the Product Backlog.

Sprint Backlog/Sprint Goal

There is less new in this area since both of these items have existed for some time in Scrum practice. The new definition provides nice clarity on the importance of having a Sprint Goal that drives the creation of the Sprint Backlog and the delivery of work during a Sprint. This section of the 2020 Scrum Guide reiterates that the Sprint Plan contains the why, what, and how of the Sprint and is driven by the commitment to achieving the Sprint Goal. Otherwise, the established practices around making adjustments to achieve the Sprint Goal continue to apply.

Increment/Definition of Done

A major simplification in terms is the removal of “Potentially Releasable Product” as a modifier in front of “Increment.” The new definition of the Increment ties it directly to the Product Goal, as each Increment must demonstrate progress toward achievement of the Product Goal. Each Increment must be completely done and add measurable value to the product. In a new clarification, the Scrum Team may produce multiple Increments each Sprint and can even release one or more Increments during the Sprint. The Sprint Review is still necessary to gather data about the sum of all the Increments produced during a Sprint (if more than one), but the Sprint Review is specifically defined as NOT being some kind of gate preliminary to the release of one or more Increments. This has long been standard practice so in that sense the Scrum Guide is catching up with the real world of Scrum practice.

An Increment cannot be considered complete until it meets the Definition of Done – hence the Definition of Done is the commitment that pairs with the Increment. The Definition of Done describes in detail the quality measures that must be met for the Product to be successful.

The Developers are “required” to meet the quality standards defined in the Definition of Done, meaning that no outside force can compel the Developers to abandon their Definition of Done, nor can Developers simply ignore the Definition of Done if it is inconvenient, hard work, etc. When more than one Scrum Team works on the same product, all Teams must agree upon a shared Definition of Done that controls the quality of work across the product.

That’s it for this time. Until we meet again, stay safe, stay focused.

Thoughts on the 2020 Scrum Guide – Part 4: Scrum Events

There are no major changes to the Scrum Events in the 2020 Scrum Guide with the standard lineup continuing to hold: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. A set of changes related to the Scrum Events concerns the pairing of Commitments to the basic Scrum Artifacts, a topic I will cover in the next installment in this series.

Scrum Events Overview

The section introducing the Scrum Events is noticeably shorter than in the 2017 Scrum Guide. The new introductory section states that the Scrum Events exist to provide a formal opportunity to inspect and adapt Scrum Artifacts and to provide the transparency needed to be able to do so. Scrum Events should occur at the same time and place in each instance to reduce complexity.

This is a nice simplification of the purpose of the Scrum Events, emphasizing the action of Empirical Process Control and the importance of establishing a regular, repeating cadence, which improves the effectiveness and efficiency of the humans actually doing the work.

The only other change of note is that the Sprint now includes refining the Product Backlog explicitly, whereas previously this activity was implied as occurring during each Sprint.

Sprint Planning

This is the Event that has seen the most significant changes in the 2020 Scrum Guide. The essence of Sprint Planning is unchanged, but now there are three topics to cover – why, what, and how, instead of just two – what and how. Furthermore, the Product Owner is now responsible for making sure the Scrum Team is prepared to discuss the most important Product Backlog items and how they contribute to realization of the Product Goal (more on this next time when I cover Scrum Artifacts). This is a good addition that puts the onus on the Product Owner to understand how the pieces fit together before Sprint Planning begins.

Topic One: Why is this Sprint valuable? This is the new element of Sprint Planning. Basically, the Product Owner describes how this Sprint will add to the value of the product and then the entire Scrum Team collaborates to formulate a Sprint Goal that clearly communicates the why the Sprint is valuable to stakeholders. This change makes great sense as it alleviates the issue of the Product Owner not really having a clear understanding of the purpose of the current Sprint. It’s not just about piling on more stuff or keeping people busy; the purpose of every Sprint is to add value to the product.

The other two topics covered in Sprint Planning, what work to pull in off the Product Backlog and how to accomplish those items, are largely unchanged, though the explanations have been simplified and all references to software development practices have been removed. Again, good changes in my opinion.

Daily Scrum

The new description of the Daily Scrum spells out its purpose very nicely: it is a formal opportunity for the Developers to inspect progress toward the Sprint Goal and adjust the Sprint Backlog as needed to make the best possible progress each day.

The major change of note here is the removal of the “three questions” from the official practice of the Daily Scrum. In place of the three questions, this statement describes the activity of the Daily Scrum (page 9):

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Notice that the “next day of work” can be today if the Daily Scrum occurs in the morning, which is clearly a very strong and effective practice.

Sprint Review

The major change here is a dramatic simplification of the description and working of the Event. Essentially, the Sprint Review is now described as a working session during which the Scrum Team and stakeholders collaborate on what to do next to move the product forward. This is not just a presentation of work completed during the Sprint, though it does still contain that element. It is more about what was accomplished, what has changed, and what the next steps could be. Pretty straightforward.

Sprint Retrospective

Once again, the description of this closing Event of the Sprint has undergone a significant simplification with a clear, concise statement of purpose: “to plan ways to increase quality and effectiveness” (page 10). Items to be inspected include “individuals, interactions, processes, tools, and their Definition of Done,” assumptions that did not work out and the origins of those faulty assumptions, and the standard what went well, challenges encountered, and how those challenges were or were not addressed successfully.

The most impactful improvements rise to the top of the stack and “may” be added to the next Sprint Backlog. In the 2017 Scrum Guide the highest priority improvement item had to be added to the next Sprint Backlog. This is a small change that may or may not impact how teams practice Scrum. Strong Scrum Teams always put significant effort into improvement items resulting from their Sprint Retrospective.

That’s it for this installment. Next up: Scrum Artifacts. Until then, stay safe, stay sane, and keep a good thought.

Thoughts on the 2020 Scrum Guide – Part 3: The Scrum Roles

Now we’re getting into some of the more significant changes introduced in the 2020 Scrum Guide.

Accountabilities Instead of Roles

This seems like a strange usage of terminology to me, having “accountabilities” instead of “roles.” The accountabilities are labeled much like the former Scrum Roles: Scrum Master, Product Owner, and Developers (in place of Development Team), yet the use of the term accountabilities seems to imply that which person holds which accountability at any given moment is subject to change. I’m not sure that was the intent here, but it does open up a host of potential issues when organizations start thinking people can seamlessly shift from one accountability to another within a Scrum Team. I think everyone would be better served to continue to think in terms of roles and the associated accountabilities on a Scrum Team. The more stability in who does what – or who has which set of accountabilities to use the current terminology – the better both for the Scrum Team and for the organization.

Product Owner

Of the three accountabilities, this is the one that saw the most significant changes in the 2020 Scrum Guide. The Product Owner is accountable for maximizing the business value of the Scrum Team’s work and for effectively managing the Product Backlog, the latter consisting of (this appears on page 5):

  • 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.

Okay, all good so far. Unfortunately, the Product Owner may do this work personally or delegate it to others, all the while remaining accountable for the results. I would never advocate for a Product Owner to do everything all the time, but delegating significant parts of the Product Owner’s work can very easily devolve into the dreaded “proxy Product Owner” situation in which accountability breaks down and decision making authority is diluted. In my view, the Product Owner should be doing most of this work, with perhaps the exception of creating Product Backlog Items, which can clearly be the result of input from many different quarters.

Sharing One Product Owner Across Multiple Scrum Teams

I mentioned in Part 2 of this series that I would be returning to this topic so here we are. Just by way of a refresher, the 2020 Scrum Guide states the following on page 5:

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.

Sharing the Product Goal and Product Backlog across multiple Scrum Teams makes perfect sense. However, where I disagree strongly is with the assertion that the Product Owner is tightly coupled to the product and only loosely coupled to any particular Scrum Team (to use an object-oriented programming metaphor). In my view this is a significant problem. In fact, in my experience this type of Product Owner overloading is among the most common single points of failure in Scrum implementations. A much better approach is to ensure that each Scrum Team has a fully formed Product Owner and, in a multiple-Team setting, there is a Chief Product Owner who takes on the strategic view of the product. Following the 2020 Scrum Guide on this point leads directly to the emergence of proxy Product Owners on each Scrum Team, that is, an individual who has neither the accountability nor the authority to fulfill the Product Owner role yet is expected to do the same work. Nothing good can come of this so my advice is to avoid using this approach at all costs. Follow the one Product Owner-per-Team with a Chief Product Owner model instead.

Developers (Instead of Development Team)

This is a refreshing simplification. Instead of a team-within-a-team, we now have Developers as a constituent part of the Scrum Team, tying in with the new emphasis on the entire Scrum Team being accountable for creating a valuable, useful product increment every Sprint (page 5).

The accountabilities of the Developers have also been distilled down to planning each Sprint by creating a Sprint Backlog, building quality into the product by adhering to the Definition of Done, adapting their plan each day to take into account that reality really doesn’t care about our plans, and engaging in mutual accountability.

The number of Developers on a Scrum Team is no longer specified, but implied by the overall limit of 10 members of each Scrum Team, which translates into no more than eight Developers, with a conscious bias toward smaller Team sizes to enhance responsiveness and reduce decision-making overhead.

Scrum Master

The Scrum Master accountabilities have also been distilled down and simplified, though not as dramatically as those of the Developers. The Scrum Master is accountable for “establishing Scrum as defined in the Scrum Guide” (page 6). That is much more forceful language than previously used. The Scrum Master is also now charged with being a “true leader” instead of specifically calling out the practice of servant-leadership as in the 2017 edition. The only issue I have with this formulation is the lack of a clear definition of “true leader.” You will need to explore the nature and practice of leadership to be able to answer this call adequately.

Otherwise, the Scrum Master is charged with being of service to the Product Owner, Developers, and organization much as before with just a couple of notable revisions. First, the Scrum Master is accountable for ensuring that the Scrum Events are positive, productive, and do not exceed the timebox. This is much more forceful than the 2017 version which simply stated that the Scrum Master should facilitate the Scrum Events if needed or requested.

Two final clarifications of the Scrum Master accountabilities: First, Scrum Masters are now required to ensure that impediments to the Scrum Team’s progress are removed, rather than laying it all on the Scrum Master to remove all such impediments, which was never organizationally realistic and in many ways contradictory with the Scrum Master’s defined role in the organization, i.e., not having management authority.

The second clarification of note covers helping the Product Owner engage in effective stakeholder collaboration as needed or requested and helping break down barriers between stakeholders and the Scrum Team. These are common-sense changes that provide additional clarity and support for the Scrum Master’s daily work.

That’s it for this installment. I hope you find these observations relevant and helpful in your Scrum practice.

Next up, a review of the revised definitions of the Scrum Events.

Some Thoughts on Virtual Scrum Teams

I’m interrupting my series on the 2020 Scrum Guide to examine a topic we’ve all been immersed in since March of last year – you remember last year, 2020, the year that just wouldn’t end.

A recent article published on the BBC offered some interesting, and to Scrum Team members, not surprising analysis of virtual teams. First of all, it turns out that teams already working well together in-person adapted pretty much seamlessly to working from home. The reasons behind this outcome are essentially that an established, high-performing team already contained knowledge of the work styles and personalities of all of its members. Established teams also have built psychological safety into their interactions, which makes the transition to dispersed, virtual teamwork smooth. The regular cadence of Scrum Events ensures that every member of a Scrum Team stays connected and engaged. Keeping the Team’s video meeting space active throughout the day allows teammates to collaborate and communicate in real time much like they did when they were working in a physically co-located workspace.

The only issue established teams experienced was the loss of chance encounters with people external to their team. Ironically, it turns out that to keep that kind of cross-pollination going we need to schedule “random” encounter time to replace the hallway or coffee break conversations that happen organically in a co-located office setting. The upshot is it takes a little more effort but really isn’t a big deal. Using your go-to virtual team tool, just set up an open breakout room where people can drop in as the mood strikes. When you see someone in the “virtual coffee” breakout room you want to chat up, just pop in and go. No big deal.

What About Setting Up a New Dispersed Team?

Setting up a new team in a dispersed setting, while not impossible, is much more difficult and time consuming than simply moving an established team to a virtual communication platform. We humans do still interact more effectively when physically present with each other. Given that we won’t be doing that again on any kind of scale for a good long while yet, waiting around to set up a new team really isn’t an option.

So what can you do to help a new, dispersed team get moving? This is where that regular cadence of Scrum Events comes heavily into play. Since each Event has both a goal and a time box, newly formed dispersed teams have good a great opportunity to score a continuing series of small yet satisfying wins. Even holding an effective Daily Scrum using virtual tools inside the 15-minute time box produces a satisfying sense of accomplishment to kick off the day.

You will, in your role as Scrum Master or Scrum Coach need more than the Scrum Events to help a new team get off the ground. Leverage the Scrum Values to build an effective team working agreement right out of the gate. Use pairing to build familiarity with individual work styles, competence in the product development domain, and trust between individuals. Make sure that pairs of teammates rotate regularly, twice daily at least, to move quickly toward building a real team. Also make sure management gives the new team space to grow into their new form of work. That means relaxing or removing entirely the pressure to generate some preconceived output every Sprint. On the other hand, make sure you set up your team to score small output wins early and often during every Sprint. And when the wheels come off, as they inevitably will, make sure to treat the experience as a learning opportunity rather than some massive downer that blows up the team before it even has a chance to get started.

All for now. Stay safe and Scrum on!

We now return to our regularly scheduled programming with the next installment of my review of the 2020 Scrum Guide….