Photo by Aaron Burden on Unsplash

Expanding the Scope of Scrum

The Agile movement was motivated by a desire to improve the outcomes of software development projects. Before Agile, traditional project management techniques that work well for projects with well understood requirements, like construction projects, were being used for software projects with vague and changing requirements. Using waterfall project management was resulting in massive cost overruns and the delivery of unsuitable software products. This resulted in customers and delivery teams blaming each other and wasn’t good for the software industry in general.

Agile and Scrum is an approach, or framework designed for projects with uncertain requirements. There are many other project types beyond software projects that have this issue of uncertain requirements. The Scrum Guide 2020 is simplified and less prescriptive, making it easier to apply to other project types.

For example, the three questions have been removed from the Daily Scrum. The 3 question agenda being:

• What have you accomplished since last scrum?
• What do you plan on accomplishing before next scrum?
• What blockers or impediments are you encountering?

Of course this agenda can still be used by teams, but it is no longer mentioned in the Scrum Guide.

Scrum is all about team based delivery and I’ve seen daily scrums that feel like status meetings where each team member answers the 3 questions as inviduals and not as team members. “I got my thing done, so I’m doing my part.”, instead of “here is how I am contributing to the team’s goal”. I’ve also seen situations where team members aren’t really paying attention to what each other is doing, going through the agenda robotically.

The daily scrum is really a team meeting, not a meeting of individuals. It is where the team forms the plan for that day. The agenda really should be - As a team what are we going to accomplish before next scrum, and how does each team member want to contribute to that accomplishment.

Sprint Goal and Definition of Done

There are a couple of concepts to cover here, namely artifacts and commitments. I expect this addition to the guide will grow over time, and I think the new commitment model is important to understand.

Scrum Artifacts and Commitments

Straight from the the Scrum Guide, the scrum artifacts and commitments are:

So commitment has returned, but the commitment is to a goal, not to the delivery of specific work items. This allows for some flexilibility and keeps a focus for the team. Ken Schwaber and Jeff Sutherlans are working hard to ensure that Managers, Customers and Delivery Team Members work together and don’t use the Scrum framework as a divider. Scrum was created to enhance cooperation with all stakeholders.

The 2020 Scrum Guide also addresses self organizing teams and a dangerous misinterpretation of this idea where developers were using self organization as an excuse to miss commitments, to “do what they want”. Self organization means the team is responsible for figuring out how to achieve a goal. The team decides on and designs the solution, figures out what needs to be done to implement and who will take on the work items. There is no task master, there is no one person in charge of the work.

However, the team can’t change the goals, the self management power does not extend to the determination of outcomes, this is the Product Owner’s realm. The team commits to the goals. This commitment balances the self organized team and keeps them accountable to the Product Owner and to the end product.

Scrum Master Leadership

The Scrum Master’s leadership role is reinforced. The Scrum Master is a servant leader, both a servant to the team as well as a leader. As a servant the Scrum Master helps the team by removing impediments, protecting the sprint goal from scope creep, and facilitating the Scrum framework ceremonies. As a leader, the Scrum Master watches out for the commitements the team has made and pushes for increased discipline and agile principles. The Scrum Master also help ensure the spirit of cooperation across all stakeholders.

Product Goal

I’m glad to see the formalization of goals in the 2020 Scrum Guide. Most importantly, the product goal. The Product Backlog is described as representing the product goal. I like the idea of creating a product vision statement against which backlog items are measured for suitability and priority. Higher priority increments described by User Stories or Feature Hypotheses (even better) are prioritized by how much they bring the current iteration of the product to the final goal.

Other Resources

InfoQ has a transcript of an interview with Ken Schwaber and Jeff Sutherland on the 2020 Scrum Guide Changes.

Review the 2020 Scrum Guide for all the details.