The Scrum guide has been updated to better reflect what Scrum is and clear up misconceptions about it. Scrum can be used for building software products, and it can be applied to many other areas outside of software as well. Scrum is a framework based on empiricism for continuous improvement; it supports inspection and adaption daily and throughout the process. Having a potentially shippable product increment at least every Sprint or more often is a key element of Scrum.
The new updates to the Scrum guide were announced and discussed in a webinar with Ken Schwaber and Jeff Sutherland, authors of the Scrum Guide, and co-creators of Scrum. InfoQ interviewed them.
InfoQ: What are the major updates to the Scrum guide?
Ken Schwaber: There are five main changes to The Scrum Guide: a greater definition on the uses of Scrum, a more refined definition of the role of Scrum Master, clearer understanding of the Daily Scrum as a vehicle for inspection and adaption to ensure progress toward the Sprint Goal, the establishment of a maximum length to time boxing and updating the Sprint Backlog to include feedback from the Sprint Retrospectives. That said, all of these changes serve the same purpose, which is to clear up misconceptions about Scrum.
Jeff Sutherland: All updates to the Scrum Guide were recommended by the Scrum Community to make the wording of the guide clearer and more helpful to Scrum Masters. I was particularly concerned that some "Scrummerfall" practitioners were claiming that the Scrum Guide did not say they had to improve. We have changed the wording at the beginning of the guide to make it crystal clear that Scrum is a continuous improvement process and at the end of the guide we require that at least one process improvement identified in the Retrospective be put in the Sprint Backlog as a top priority story in the next sprint.
A Lean expert pointed out to me in a Scrum class that you need to use Scrum to make Scrum better- you need the emphasis. The retrospective is only effective if you act on the process improvements you identify in the retrospective meeting. I applied it and saw an immediate increase in velocity.
InfoQ: What are the misconceptions that exist around Scrum?
Sutherland: Many people are calling themselves Agile and they cannot deliver a shippable product increment at the end of a sprint or more often. This is inconsistent with the Scrum Guide and with the second value in the Agile Manifesto. This inability to inspect and adapt causes high risk and extensive delays - I call this Scrummerfall: People who say they are doing Scrum but it has all the symptoms of Waterfall. In 2005 I published a paper on "The Future of Scrum" which described PatientKeeper, one of the first companies to move toward continuous deployment. Since then continuous deployment has become the norm for good companies rather than the exception. However, there are still teams out there that think it is OK not to deliver anything in a Sprint.
Schwaber: One of the biggest misconceptions about Scrum is that it is only used for building software functionality. Scrum is actually much more flexible than many think and applicable to many areas outside of software development. Scrum is now widely used for products, services, and the management of the parent organization and when the words "develop" and "development" are used in the Scrum Guide, they refer to any kind of complex work.
Another big one is that people using Scrum to develop systems should always know from Scrum what to do. We’ve said before that Scrum is only a framework for building complex products. It is very simple. Using it to turn your particular complexity into a working useful product is very, very hard. As is all complex work. These updates should help clear many of these misconceptions up.
InfoQ: Inspect and adapt is one of the pillars of agile. How does Scrum support this?
Schwaber: Scrum is based on aspects of Lean thinking and Empirical process control. Empirical process control relies on regular inspection and adaptation of transparent artifacts to support decision making. Scrum has had inspect, adapt and transparency built into all of its events and artifacts since the early 1990’s. Agile is a word devised by the people who developed the Agile Manifesto at Snowbird in 2001. The only direct outputs were the values and principles of the Agile Manifesto. Inspect and adapt may be important to agile/Agile, but certainly are not the only way to be agile.
Sutherland: Every event in Scrum is for inspecting and adapting from the Daily Scrum to the Sprint Review and Retrospective. Failure to able to inspect and adapt by having a shippable increment of product at the end of the Sprint or more often breaks Scrum and causes major dysfunction.
InfoQ: How can teams use the Daily Scrum as a vehicle for inspection and adaption?
Sutherland: Scrum is inspection and adaption. Every event is inspection and adaption. Sprint planning is inspecting the top of the backlog and making sure it is ready for the Sprint. Daily meeting is inspecting what you’ve been doing yesterday and fixing it today. Sprint review is inspecting the product at the end of the Sprint and changing the backlog based on stakeholder feedback. And so on.
Schwaber: In the Daily Scrum, the Development Team works together to use that time to inspect their progress toward their Sprint Goal and adjust their plans accordingly. Here is the verbatim from the Scrum Guide:
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based.
InfoQ: How do you expect the changes in the Scrum Guide to impact teams that are working with Scrum?
Schwaber: The Scrum framework has been successfully used for more than 20 years, and users have built an impressive community of support. Those who have internalized principles, values and mechanisms of Scrum and learned from their experiences are already as successful as they could ever be – these changes will not impact these users that much. The changes have a larger impact for those only now seeking to understand Scrum, to ensure they have the best possible overview at their fingertips.
Sutherland: Our hope is that it will allow teams to do Scrum better with corresponding better results.
