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

Thoughts on the 2020 Scrum Guide – Part 2: The Scrum Team

Last time I examined changes to the 2020 Scrum Guide in the areas of Scrum definition, theory, and values. This time, I’m taking on the new, and in many ways improved, definition of the Scrum Team.

Definition of the Scrum Team

The 2017 Scrum Guide defined a Scrum Team as self-organizing, cross-functional, and consisting of a Product Owner, Scrum Master, and Development Team. The first major change here is the removal of the term “Development Team” and its replacement with the designation “Developers.” The 2020 definition of the Scrum Team appears on page 5 and is worth quoting here:

“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.”

There is a lot going on in just these few words. First, the much-needed clarification that Developers do not form a sub-team within the larger Scrum Team. The concept of a Development Team within a Scrum Team created no end of confusion and I am glad to see that awkward usage replaced with the much more straightforward designation of “Developers” as members of a Scrum Team.

The authors also clarify that a Scrum Team consists of exactly one Scrum Master, exactly one Product Owner, and the aforementioned Developers. They then go on to muddy the waters around the Product Owner, but more on that later. Importantly, the 2020 definition of a Scrum Team specifically rules out sub-teams and hierarchies within a Scrum Team. The relationship between members of a Scrum Team is strictly peer-to-peer, even though each of the “roles” (oh boy, this is a problem, but again more on this later), has its own areas of accountability.

Finally, the new definition makes it crystal clear what the purpose of a Scrum Team is: a cohesive set of professionals focused on delivering a clear objective, in this case an artifact new to Scrum, the Product Goal. More on the Product Goal when I get to artifacts in a later post.

From Self-organizing to Self-managing

Although it may not seem significant at first glance, this is a major change in the definition of the Scrum Team. The old definition of a Scrum Team as self-organizing gave the Team the authority to decide how to do the work and who would do the work without external interference. The new definition enhances the autonomy and authority of the Scrum Team by designating the Team as self-managing, rather than self-organizing. So what does self-managing mean? Just this, the Scrum team decides internally not only who and how, but also what to work on. This means that the Scrum Team has complete authority over what they collectively choose to deliver each Sprint in order to achieve the Product Goal in the best way possible.

Scrum Team Accountability

The rest of this section in the 2020 Scrum Guide (again, on page 5) describes in more detail the size of the Scrum Team – 10 or fewer people with a bias toward smaller Teams to enhance communication and productivity. If a Scrum Team becomes too large, whether exceeding the limit of 10 or not, the 2020 Scrum Guide recommends reorganizing into multiple smaller, cohesive Scrum Teams that share the same Product Goal, Product Backlog, and – here’s the big problem – Product Owner. I’ll dive into why having multiple Scrum Teams sharing the same Product Owner is a fraught proposition when I cover the Product Owner in a later post. For now, be aware that this is a significant source of major dysfunction in organizations using Scrum, so until we can dive into this topic in more detail, suffice it to say I recommend that you avoid sharing an individual Product Owner across multiple Scrum Teams at all cost.

Okay, back to the accountability of the Scrum Team. The Scrum Team is accountable for all product-related activities, including collaborating with stakeholders, validating that what was built was the right thing, ongoing operations and maintenance of the product, experimentation, R & D, and all other aspects of product development, delivery, maintenance, and enhancement. The organization is obligated to provide the Scrum Team with full authority to manage their work, including working at a sustainable pace to enhance focus and consistency.

Not only is the Scrum Team accountable for the long-term development, delivery, and health of the product, the Team is also accountable for creating a valuable, useful product increment every Sprint. This combination of long-term and short-term accountability helps the Team stay focused on the big picture while not losing sight of the details.

These are excellent clarifications of the product-level accountabilities of a Scrum Team and will, I hope, end forever the notion that a Scrum Team is only dedicated to a technological component layer or development of new features only. This new emphasis on end-to-end product accountability is a breath of fresh air in the Scrum Guide and removes several areas of significant potential dysfunction from the conversation about Scrum.

That’s all for this time. Next up, describing the specific accountabilities within a Scrum Team: Scrum Master, Product Owner, and Developers.

Thoughts on the 2020 Scrum Guide – Part 1: Definition, Theory, Values

With the release of a newly revised Scrum Guide ( I’d like to identify some of the key changes since the last release in 2017 and offer my thoughts on the changes that strike me as significant. Rather than writing the whole thing up in one probably quite long post, I decided to break it up into as many separate posts as needed to cover each thematic area in smaller, more easily digestible bites.

I’ve organized this journey through the 2020 Scrum Guide chronologically, covering topics in the order in which they appear in the new Guide. Fortunately, the Scrum Guide is organized thematically in general, which makes a chronological approach both convenient and effective. So, without further ado, here we go….

Scrum Definition and Theory

These introductory sections have not changed substantially in the new Guide, but there are some differences and clarifications of note. First off, the definition of Scrum on page 3 dives right into the major responsibilities of the Scrum Master in fostering an organizational environment in which the Scrum Team can successfully deliver value while collaborating with stakeholders to inspect and adapt every Sprint. This does not represent a substantive change from the previous Scrum Guide, but does state very clearly that the Scrum Master is a critical player in the organization’s success. I think (here’s my first interpretation) that placing the Scrum Master right up front as one of the keys to success using Scrum is both appropriate and clears up any confusion around the necessity of having a full-time, dedicated Scrum Master to serve each Scrum Team.

The Scrum Definition section wraps up with this extremely meaningful statement: “Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.” This means that everything within the organization is subject to change and improvement, management structures included. This refreshingly powerful statement makes clear that it’s not just the people doing the work who may need to change, management also must be accountable for improvement and change.

The brief section on Scrum Theory on page 3 now calls out that Scrum is based not only in Empirical Process Control and its three pillars of Transparency, Inspection, and Adaptation, but also Lean thinking with its emphasis on reducing waste and focusing on essentials. This is an important acknowledgement of the importance of Lean thinking in Scrum. Lean thinking was always implicit in Scrum practices, but not called out explicitly in the Scrum Guide. The remainder of this section describes how Scrum applies Transparency, Inspection, and Adaptation to enable Lean thinking.

Scrum Values

As with the 2017 edition, the 2020 Scrum Guide specifically calls out the five Scrum Values: Commitment, Focus, Openness, Respect, and Courage. The definitions of the Scrum Values now focus more on how individuals come together as a team to achieve shared goals and build trust. I am especially gratified to see the emphasis on building trust both within the Scrum Team and between the Scrum Team and its stakeholders. I have long advocated that trust is critical to success so this is, in my opinion, an excellent addition to the formal philosophy and practice of Scrum.

That’s it for this installment. Next time we will examine the substantial changes to the definition of the Scrum Team and its players.

Imagining a Post-COVID-19 World

It’s probably a bit premature to go there, but imagining what Scrum will look like post COVID-19 seems unlikely to do any harm. So here goes – a little glimpse into a very hazy crystal ball.

No Return to Normal

One thing seems certain – there will be no return to the 2019 version of “normal” regardless. COVID-19 has produced massive disruptions in business and patterns of work as well as virtually every other aspect of life. That disruption is almost certainly going to continue through 2021 and well into 2022. The first problem is stopping the spread of the virus through widespread vaccination. Here in the USA, achieving the necessary level of vaccination will be a major challenge, meaning here we could experience virus-induced disruption for several more years. The upshot is, following a prolonged period of disruption, new patterns of life and work will emerge that may bear little resemblance to the patterns of 2019.

The Office is History

Organizations have already begun to scale back their physical workspaces – offices – as the pandemic took on all the characteristics of a long-term issue. Organizations have also invested in infrastructure and software to enhance the effectiveness of the new virtual, dispersed workforce. Those trends are both almost certain to continue after the immediate effects of the pandemic have subsided. Office space emptied and leases lapsed or terminated are indicators of a long-term approach, not a short-term adaptation. So keep that Zoom shirt handy for the long run.

Business Travel Will Never be the Same

And that’s a good thing. So much of business travel under the old paradigm was both unnecessary and frivolous. I once sat on a plane next to a man who was returning to Denver from London where he had been for a one-hour meeting in the airport. Unbelievable. Communication technology has matured under the intense pressure of the pandemic and is now so ingrained in our collective thinking that business travel for anything other than absolutely necessary face-to-face in-person work is difficult to imagine.

What Else?

There will be other new patterns of life and work as a result of COVID-19. What exactly those new patterns will be and how they will affect us is a big unknown. In a few years, we may look back on 2019 with the same sense of nostalgia and bewilderment that previous generations looked back at the world of 1912 from the perspective of the Cold War. The main thing is to be aware, be adaptable, and give yourself and others a full measure of grace.

Why Scrum Matters Now More Than Ever

As we near then end of 2020, it seems like a good time to explore why Scrum matters more than ever in this year of pandemic-forced changes to our workplaces and work patterns.

Scrum Keeps Us Connected

With its collaborative, team-based structure, Scrum has kept us connected and productive during a time of unprecedented and absolutely vital social isolation. Continuous engagement with teammates ensures that no member of a Scrum Team is left feeling unconnected. Using the array of communication and collaborative work tools available to us, Scrum Teams have, after an initial period of adjustment beginning back in March, continued to work much as before the pandemic struck. While my sample is clearly anecdotal rather than statistical, most of the people I interact with in classes say they prefer the new way of working – no commuting, no office distractions to accommodate, and far fewer extraneous demands on their work time.

Scrum Works for Dispersed Teams

This had been a topic of discussion for many years before the pandemic put to bed any misgivings. It turns out that the previous standard advice – keep dispersion to the same time zone if at all possible and never try to disperse a Scrum Team across more than a two-hour time zone difference – was sound as borne out by the vast experience of essentially all Scrum Teams worldwide suddenly being compelled to work remotely. What has come as a surprise is just how seamlessly the members of Scrum Teams were able to adapt from working physically in-person to working in a virtually connected environment. Most of the people I’ve interacted with this year have stated unequivocally that their team’s work has improved in the new dispersed world. Most people have also stated that their team connections and their individual contributions are now more satisfying than in the pre-COVID-19 world. It turns out Scrum not only works for dispersed teams, it is probably the best way currently known to organize a dispersed workplace.

Scrum Supports a Healthy Work-Life Balance

One of the complaints I read from newly dispersed employees is that their organizations expect them to be online 24/7. Only by violating several Agile Values and Principles as well as a collection of Scrum rules could an organization do this to a Scrum Team. Indeed, again based on my anecdotal sample of conversations with people in training classes, my experience indicates that working from home as a member of a Scrum Team has enhanced further a healthy balance between work and the life that is both made possible by work and makes work worth doing. Work and life are not mutually exclusive – or at least they should not be – but are different aspects of what makes up a full, rich life. Working on a Scrum Team helps us find the right balance between these two major aspects of life. The pandemic has, in many ways, helped us focus on what’s important in life and what we can do without. Excessive work at the expense of other parts of life is inimical both to Agile Values and Principles and the practice of Scrum and is clearly one of those things we can do without.

All for now. Stay safe, stay healthy, and Scrum on!

Why You Don’t (and Can’t) Have a Full-time ScrumMaster

Among the most common impediments facing teams and organizations when they are attempting to adopt Scrum is the lack of a full-time ScrumMaster, Product Owner, Team Members in general, and Team Members with testing expertise in particular. The most unexpected thing about this situation is that the degree to which people are not available (or allowed) to play full-time on one Scrum Team is directly proportional to the size of the organization: the larger the company, the less likely it is that full-time commitment to a single Scrum Team will happen.

I’ve been noticing this effect for several years, through training and coaching in organizations of all sizes, from single-team startups to gigantic companies with thousands of people and potentially hundreds of Scrum Teams. Smaller companies in general find it both logical and perfectly sensible to allow – in fact to insist – that everyone focuses on a single role, committing to the organization and to their teammates a single-minded devotion to performing that role at the highest possible level.

The outcome is always a happy one. People love being able to throw themselves into a productive, valuable, purposeful role that creates the best possible product for the company’s customers. Engaging with others to achieve shared goals, both long-term and short-term, also offers tremendous individual satisfaction and generates powerful intrinsic motivation. Being in a position to help make everyone else better through teamwork and commitment is a powerful aspect of Scrum done well.

Bigger Really Isn’t Better

And then there is the other case. Giant companies typically spread their people across at least two or more so-called Scrum Teams. There is no possibility of commitment, focus, or building the essentials of teamwork. Even worse, with their attention constantly divided and distracted, these individuals never get to experience the intrinsic motivation that is one of the most powerful side-effects of working in a real Scrum environment.

One more time, for emphasis: the larger the company the less likely it is that people will be allowed to play on a single Scrum Team full-time, in any role. This situation begs the question: why would small companies, with very limited resources (primarily money) be better at adopting and using Scrum effectively than large companies whose financial resources are effectively infinite in comparison?


Follow the Money

A recent study* published by William Lazonick, professor of economics at the University of Massachusetts-Lowell, pinpoints the root cause of the problem at the system level. Large companies are chronically understaffed because investment of current profits in the future of the company – a key tenet of capitalism – has been replaced by the theory and practice of Maximizing Shareholder Value, or MSV, which demands that companies return not only all of their profits but also much of their cash-on-hand to the shareholders rather than investing in the company’s future products and productive capabilities. The primary engine of this new business philosophy, which emerged from the US competitiveness crisis of the 1980s, is the stock buyback, followed by the more traditional stock dividends.


Professor Lazonick demonstrates, with publicly available financial data from corporate SEC filings, that many of the largest multinational companies’ stock buybacks and dividends actually exceeded corporate net income for the decade 2004-2013. This includes some of the biggest names in technology: IBM, Intel, Microsoft, Cisco Systems, and Hewlett-Packard. What this means is that these and many other companies spent more than they made in profits over the course of that decade just on stock buybacks and cash dividends to shareholders. Even more startling, many of these companies incurred debt, by selling corporate bonds, to finance their share buybacks. The inevitable result is that companies had nothing left over to invest in future products and future productive capacity.

Cash Out or Invest in Innovation?

Innovation doesn’t just happen: it requires significant investments both in the exploration of new products and technologies and in the people who can carry out those explorations. It requires investments in things that may not provide and instantaneous return, such as within the current fiscal quarter. It also demands that people be allowed to apply focus and commitment to their work every day. Innovation also generally demands that people be allowed to work in stable, cross-functional teams, in an environment that encourages experimentation and can tolerate the occasional failed experiment.


So why can’t you have a full-time ScrumMaster, Product Owner, and dedicated cross-functional Team Members? If you work for a large company, the answer lies in what happens to the profits. Is your company on Lazonick’s list? If so, you know the answer.

* William Lazonick, “Stock buybacks: From retain-and- reinvest to downsize-and-distribute.” Brookings Institute, Center for Effective Public Management at Brookings, April 2015. William Lazonick is a professor of economics at the University of Massachusetts-Lowell, where he directs the Center for Industrial Competitiveness. He is co-founder and president of The Academic-Industry Research Network.