The Scrum Guide – 2020
Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
© 2020 Ken Schwaber and Jeff Sutherland
Commentary
As we have seen in the previous chapters, every word and sentence in the Guide is there for a reason. The End Note is not an exception, it delivers a strong and important message.
Adopting Agile practices requires a change of paradigm from large corporate organizations and a change of attitude from their people. Many large organizations still fail to understand the true goals of Agile and Scrum. Instead of considering organizational agility, they think of it as a way of managing developers. A decade ago the situation was even worse: Organizations wanted to implement Scrum (following the trend) but were not ready to accept the underlying agile principles. For instance, they failed to empower their product owners and trust their teams with self-organization. Many of them were afraid to stop project managers and team leaders from micro-managing individuals. Few of them were ready to build product backlogs instead of writing heavy-weight upfront specifications. For these reasons, the authors of the Guide rightfully warn the public that implementing just certain elements of Scrum is a partially Agile approach for solution delivery, but hardly Scrum.
On the other hand, every organization can take its own path, make its own experiments and learn from them. They can choose any tools, techniques, and practices that best suit their situation. No authority scrutinizes whether Scrum terms and conditions are met, and no policies are enforced.
Scrum in the Organization
There are different scaled frameworks incorporating Scrum, some of the best-known are:
- Nexus is a creation of Scrum.org. It is ideal for implementing large products with the involvement of multiple Scrum Teams.
- LeSS is a creation of LeSS Works and has a very similar scope to Nexus.
- SAFe, or the Scaled Agile Framework is for enterprise-wide adoption of Agile. Scrum Teams may be part of it.
- Spotify-Model is the nickname of the scaled agile solution that evolved at Spotify. It connects the teams and team members through guilds, tribes and branches.
The Scrum Guide – 2017
End Note
Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
©2017 Ken Schwaber and Jeff Sutherland.
The Scrum Guide – 2010
FINAL THOUGHTS
Some organizations are incapable of building a complete increment within one Sprint. They may not yet have the automated testing infrastructure to complete all of the testing. In this case, two categories are created for each increment: the “done” work and the “undone” work. The “undone” work is the portion of each increment that will have to be completed at a later time. The Product Owner knows exactly what he or she is inspecting at the end of the Sprint because the increment meets the definition of “done” and the Product Owner understands the definition. “Undone” work is added to a Product Backlog item named “undone work” so it accumulates and correctly reflects on the Release Burndown graph. This technique creates transparency in progress toward a release. The inspect and adapt in the Sprint Review is as accurate as this transparency.
For instance, if a Team is not able to do performance, regression, stability, security, and integration testing for each Product Backlog item, the proportion of this work to the work that can be done (analysis, design, refactoring, programming, documentation, unit and user testing) is calculated. Let’s say that this proportion is six pieces of “done” and four pieces on “undone.” If the Team finishes a Product Backlog item of six units of work (the Team is estimating based on what it knows how to “do”), four is added to the “undone work” Product Backlog item when they are finished.
Sprint by Sprint, the “undone” work of each increment is accumulated and must be addressed prior to releasing the product. This work is accumulated linearly although it actually has some sort of exponential accumulation that is dependent on each organization’s characteristics. Release Sprints are added to the end of any release to complete this “undone” work. The number of Sprints is unpredictable to the degree that the accumulation of “undone” work is not linear.
© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved