Better Taste, Fewer Calories: My Take on the 2020 Scrum Guide
As a fitting means of commemorating 25 years of Scrum, an update to the Scrum Guide was released today, November 18, 2020, via a launch event, hosted by Jeff Sutherland and Ken Schwaber (of course!), joined by numerous other people who care a lot about Scrum.
My purpose in writing this post is not to provide a detailed account of everything that has changed since the last update to the Scrum Guide (in 2017). I have no doubt that plenty of other people will do that. What I do seek to accomplish here is to point out a subset of the differences that I find most compelling, based on hearing about them, and reading the actual changes, on the day that they were announced to the public. Among the things that have not changed are the Scrum Pillars, which are shown below.
To start with the most obvious difference, the updated Guide is considerably shorter than its predecessor (the updated version is 13 pages long; the previous version was 19 pages). The big difference, insofar as making the updated Guide that much shorter, is that the 2020 version is considerably less prescriptive than its predecessor was.
Here is a summary of the differences that I’m going to cover in more detail, and how I think those differences are significant:
- Areas of Accountability
- Commitments
- Farewell to the Three Questions
- Self-Management
- Leaders Who Serve
Areas of Accountability
One of the aspects of Scrum that I have long found most vexing in the past was what were formerly called the “Scrum Roles.” The intention behind articulating the three Roles (Product Owner, Scrum Master, Development Team) as was the case in previous versions of the Scrum Guide, in my judgement, includes:
- Separation of concerns between the duties of the Product Owner and the Scrum Master
- Non-separation of concerns between the duties of the members of the Development Team (that is to say, having this single Role helped deemphasize formal role definitions, while emphasizing the team concept)
One of the reasons that the former Scrum Role definitions could be problematic was that they often got tangled up with job titles. Especially in medium to large organizations, a great deal of significance, and also authority, is associated with certain job titles. In the end, consternation about roles and role definitions often became a distraction for teams.
What’s in place now in the Revised Guide, instead of three Scrum Roles, are three areas of accountability, which together constitute a Scrum Team:
· Product Owner
· Scrum Master
· Developer
The fact there is now a Developer (area of accountability), in place of the former Development Team (role), is significant in numerous ways, especially when it comes to creating a sense of inclusiveness. As it says in the opening section, titled the Purpose of the Scrum Guide:
We use the word “developers” in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included.
The intention behind the change was certainly to make Scrum feel less intimidating/more inviting to individuals and teams that are doing work other than software development. (It’s important to acknowledge here that some practitioners would have preferred to have kept Scrum pure, inside of the castle walls of software development. Whether Scrum “should” be used for non-technical work is not a hill that I’m prepared to die on; )
To sum up, the switch from Scrum roles to Scrum areas of accountability is a welcome change in my mind, because it helps place even greater focus on getting the job done, that is, being accountable for outcomes, as a team
As the updated Guide says in the section about Developers:
The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:
- 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.
Commitments
Another significant change in the Guide is the introduction of a Product Goal. There has always been a tacit understanding that it’s important for Scrum teams to articulate a high level vision or goal (what some people might call a North Star). And, many teams have adopted techniques to help them articulate a Product Goal, such as Inception (introduced by Jonathan Rasmusson in the book The Agile Samurai). Nonetheless, it’s significant that the need for a Product Goal is now formally articulated in the Guide, and I think it helps solidify the importance for the team to be able to succinctly articulate what they seek to achieve, ideally including a measure that helps them be able to demonstrate that they did in fact achieve the Product Goal.
The Product Goal is in fact one of three Commitments in the Guide, corresponding with the three Artifacts (boldface mine):
- 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
Moving on to the Sprint Goal, taking the step of calling it a commitment helps solidify and clarify something important, adding more separation from some language that was included in the Scrum Guide several versions ago. Specifically, in part because of that earlier Scrum Guide language, many Agile practitioners have been in the habit of thinking of the Sprint Commitment as a particular set of user stories, or Product Backlog Items (PBIs), that the team indicated they could finish during the Sprint. The unfortunate consequence of that usage of the term Sprint Commitment was that it placed a huge amount of focus on finishing every single one of the user stories that were “committed to;” so woe be to you if you were on a team that said you’d finish 25 user stories, but you “only” finished less than 25 of those. As a consequence, whether or not a team accomplished its Sprint Goal would often get far less attention than the perceived “failure” to meet the Sprint Commitment (I wrote about manifestations of this particular anti-pattern in 2017). In summary, making the Sprint Goal the commitment places the emphasis where it belongs, on achieving a particular business outcome — not on hitting a target Velocity.
Now let’s talk about the Definition of Done (DoD). In previous versions of the Guide, it was easy to get the impression that even though the Definition of Done was part of Scrum, the way that it was articulated made it feel a bit like a “bolt-on;” as in, here’s something (else) that’s important that you need to pay attention to. Articulating the DoD as the commitment at the Increment level gives the DoD added heft, it seems to me, in that it sends a stronger signal to the team, and to stakeholders, that the team takes seriously the importance of delivering a working solution that is free of quality problems and meets a baseline set of expectations.
Farewell to the Three Questions
One of the things I disliked the most in previous versions of the Guide was what practitioners have often referred to as the “three questions,” which were intended to provide a template for a set of questions to be answered by each team member during a Daily Scrum. The three questions tended to be variations on: 1. What have I done since the last time we Scrummed?; 2. What do I intend to do between now and the next time we Scrum?; 3. What’s slowing me down or stopping me from getting <important thing> done?
Aside from the fact that the old language about the 3 questions felt overly prescriptive in older versions of the Guide (and gradually became less prescriptive which each update), it also had a tendency to push the conversation in the direction of status reporting. I see the primary purpose of the Daily Scrum as an opportunity to check for alignment and obstacles, as in: are we still focusing on the most important work, to help us achieve the Sprint Goal?; and is there anything we need to address right away that could jeopardize the Sprint Goal?
To paraphrase what Jeff Sutherland said during the Webinar where they formally introduced the 2020 Scrum Guide, the most important question that needs to be answered by team members during a Daily Scrum is “Why isn’t the most important story currently in our Sprint Backlog not finished yet, and what do we need to do to finish it?” The modified language about the Daily Scrum in the Guide reads as follows:
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.
Self-Management
Another notable change in the Guide is the replacement of the term “self-organizing” with “self-managing.” It’s important to pause for a moment and remember that “the best architectures, requirements, and designs emerge from self-organizing teams” is one of the 12 principles in the Agile Manifesto. So why this change to “self-managing teams?”
It seems to me that this change is to a great extent about accountability, and accountability is an area of greater emphasis in the revised Guide, as noted earlier in this post. I can recall many teams that I’ve worked with, and I’m sure many Agile practitioners can say the same, where teams could easily take the idea of self-organization too far, where they might choose to believe that it granted them a blank check to take a “Wild, Wild, West” approach to the work that they were doing. To be clear, I’m not saying that teams should not experiment, in the spirit of continuous improvement — they most definitely should be empowered to innovate and to find better ways of working. There is a difference, though, between running experiments and evaluating the outcomes from those experiments, vis-à-vis doing essentially whatever you feel like doing.
Leaders Who Serve
One of the hallmarks of previous versions of the Guide was to refer to Scrum Masters as Servant Leaders. As anyone who has been involved in an interview for a Scrum Master or Agile Coach position over the past decade or so can likely confirm, it’s likely that somebody will ask the candidate to describe what Servant Leadership means to them, and how they’ve modeled it. Don’t get me wrong — — I think Servant Leadership can and does have positive connotations. (For another perspective on Servant Leadership, see my blog post Roberto Clemente and Servant Leadership.)
An important side effect of the term Servant Leadership being used so often, however, is that its meaning has gotten diluted, and it tends to diverge in practice from what was originally intended when it was included in past versions of the Scrum Guide. Consider these behaviors which I’ve seen all too often, which some people might believe constitute signs of a Scrum Master acting as a Servant Leader, but which tend to be problematic in part because Scrum Masters are so often expected to concurrently work with multiple teams, and also because being an effective Scrum Master has very little to do with any of these things:
- Acting as notetaker-in-chief (taking notes is fine, but for many conversations, it’s difficult to be an effective facilitator while trying to record what is being said at the same time)
- Being the only person on the team who schedules team meetings (it’s common practice for Scrum Masters to schedule all of the Scrum Events, for instance, but that doesn’t mean they have to schedule ALL team meetings)
- Being the person on the team who’s expected to arrange snacks or beverages (back in the day when there were lots of collocated teams, that is ; )
In the updated Scrum Guide, the new language is “leaders who serve.” On its face, that change might appear so slight that it’s not meaningful. It seems to me that the significance of the term “leaders who serve” is to put leadership front and center. Let’s be careful not to make the mistake where leadership is somehow interpreted as providing direction (the infamous “command and control” style of working). What’s asked of the Scrum Master is more of a quiet form of leadership, often wearing different hats to suit different occasions.
Below is the link to the Webinar that I listened to as I was formulating my thoughts about what’s different in the 2020 Scrum Guide. I encourage you to watch it, because there are insights provided that cannot simply be gleaned by doing a “diff” between the 2017 version of the Guide and the 2020 version.
