The last Scrum Guide was published in 2017, and along with it, reinforcing that Scrum can and is used in different contexts beyond software. In 2020, the Scrum Guide now reinforces that stance to demonstrate that products and services, from wine production, medical clinics, finance and marketing, can all make use of Scrum’s focus on transparency, empiricism and self-management to get work done.
What's been removed?
Scrum is less prescriptive
Scrum is now focussed on being a minimally sufficient framework so that you can add practices on top to adapt it to your context of work – whether its software, consulting, physical hardware or product management in business as usual.
Importantly, it stresses that “rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.”
Scrum isn’t a “project management” methodology or framework
Scrum is now defined as a “lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems”.
No more servant leadership
The Scrum Master was often referred to as a “servant leader”. The intention is to reflect that the Scrum Master influences, not through being the team’s manager or a formal team lead with HR responsibilities, but through their expertise in Scrum.
The removal of “servant leader” helps to reinforce that the Scrum Masters are “true leaders who serve the Scrum Team and the larger organisation” by “enabling the Scrum Team to improve its practices, within the Scrum framework” (p6, Scrum Guide 2020).
Daily Scrum
Referred to by many as the “Stand-up Meeting”, the Daily Scrum’s 3 famous questions of “what did you do yesterday” and “what are you doing today” are gone.
This pattern for running the Daily Scrum turns every stand-up into a status report to the Scrum Master. The new Scrum Guide (2020) completely removes these questions, reinforcing that the purpose of the event is empiricism and the team’s job is to use whatever structure or technique they want to:
- Inspect its progress toward the Sprint Goal.
- Adapt the Sprint Backlog for transparency (as necessary).
- Adjust the upcoming planned work.
The emphasis here is important. The purpose isn’t for the team to align and collaborate. The purpose is all about empiricism, the outcome of which is:
- Improved focus.
- Improved self-management.
- Improved communications.
- Eliminating the need for other meetings.
What's changed?
One Team.
Scrum has now eliminated the concept of a separate team within a team because it often led to “proxy” or “us and them” behavior between the Product Owner and the Development Team. There is now just one Scrum Team focused on the same objective, with three different sets of accountabilities: Product Owner, Scrum Master, and Developers.
Development Team is now just “Developers”
“Developer” is the new term that defines the role of the people in the Scrum Team that are committed to creating an Increment each Sprint.
It’s critical to understand that Developer doesn’t mean “software developer” or “software engineer”. It’s the role of people in the Scrum Team who are doing the work to deliver the Increment. This means that the specific skills needed by the Developers are often broad and will vary with the domain of work, whether it’s marketing, HR, finance or software.
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 (Daily Scrum) toward the Sprint Goal.
- Holding each other accountable as professionals.
What's new?
Definition of a Product
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. Importantly, a product could be a service, a physical product.
This aligns Scrum more strongly to Product Management, where products are defined by how they are used by end-users/customers, not by its technical system components, the internal program that established it, or by its governance structure.
The Product Goal
The Product Backlog (one of the three artefacts in Scrum) now has a purpose – the Product Goal. Each Sprint should bring the product closer to the overall Product Goal.
“Commitment” is back! Each Scrum artefact has a commitment to value and quality.
Scrum’s artefacts represent work or value and are designed to maximise transparency of key information. Each artefact now contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
- Product Backlog: the Product Goal.
- Sprint Backlog: the Sprint Goal.
- Increment: the Definition of Done.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.
Self-Managing over Self-Organising
Previous Scrum Guides referred to Development Teams as self-organising, choosing who and how to do work. With more of a focus on the Scrum Team, the 2020 version emphasises a self-managing Scrum Team, choosing who, how, and what to work on.
Self-managing in this context can be described as the polar opposite of “command-and-control” management styles. This doesn’t mean, though, that managers aren’t necessary. Defining the rules and boundaries by which teams can make decisions, contributing to the Definition of Done so that good practice is adhered to, and improving the environment by addressing red tape, are all areas that managers are critical.
Sprint Planning: What, How and now Why
Sprint Planning now asks Scrum Teams to consider “why” in addition to “what” and “how”:
- Why is the Sprint valuable?
- What can be Done this Sprint?
- How will the chosen work get done?
The Product Owner proposes how the product could increase its value and utility in the Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. Importantly, the Sprint Goal must be finalised prior to the end of Sprint Planning.
The Sprint Goal isn’t, as a result “deliver these 10 items”. Sprint Goals are often thematically based, helping create focus for the whole Sprint, helping the choice of backlog items to achieve it, and supporting communications to stakeholders and end-users regarding the purpose of the Sprint.
Conclusions
Many of these changes to the Scrum framework reflect a growing use of Scrum outside of software and a stronger alignment with product management over project management. This can only serve to strengthen the use of Scrum in the marketplace as the framework of choice when organisations go agile. Hopefully, the improved simplicity, e.g. Daily Scrum questions, soften language around Product Backlog item attributes, soften language around Retrospective items in the Sprint Backlog, shortened Sprint cancellation section, and more, will help remove the myths and misconceptions about what is Scrum, how to make the most of it to improve time to market, ability to pivot and reduce costs, and how to stop turning agile teams into feature factories.
