The purpose of Scrum is to deliver Increments of releasable functionality [1]. So at each Sprint Review, a “Done” Increment is required to make transparent the progress made by the team. Releasing it opens the gate to market validation to Inspect and Adapt based on market feedback (i.e. actual use). The only feedback that counts is the actual use of our Product. All else is just hypothesis or worse, assumption. While having no remaining work left to do provides development Transparency. This means our ideas & plans of future work are not impeded by hidden loose ends and we are not building up Technical Debt [2].
Many ‘Scrum’ teams struggle to deliver a releasable Increment
Recently I found myself discussing the difference between ‘done’ and releasable’ with some fellow trainers and Scrum enthusiasts, and I blogged about that in ‘Done vs releasable’. In Scrum there is no doubt that a releasable increment is required, yet in the world at large many teams using Scrum (self reported) are struggling to create releasable Increments in their Sprints. I am confident that most actually don’t and never have. Some teams because they don’t have all the skills needed (for instance release expertise), some teams because they don’t have the mandate in their organization to actually perform all the steps needed. How can we use the Definition of Done to help us improve and what is the best way to move forward? How do we reach that necessary state of Scrum where we have a releasable Increment each Sprint to truly validate our assumptions of both Business Value (how well satisfy a customer need) and Technical Quality (how well is our solution built).
Scrum Teams that lack certain skills needed for the releasable Increment
For example, starting up a new team or starting on a new area or product with an existing team, where certain Security tests are needed for every release to pass regulatory law. We currently do not have the expertise and/or skills to do this (well enough) within our team. And without passing these Security test criteria, the Increment is not allowed to be released to the market. The bottom line is that the Development Team has insufficient skills to create a releasable Increment (without outside help).
How to solve the lack of skills needed to release an Increment as a Development Team
Regardless of your role: take it to the team! NEVER attack a complex problem alone. Discuss the problem in a Sprint Retrospective or another suitable moment. Earlier is better. Let the team explore what the problem is and how to potentially improve. Sometimes it is hard to get a grasp and know how to attack this problem. If you are unsure how to approach this, try organizing a competency matrix workshop [3] with current and target states of the skills and competencies needed to create a releasable Increment. Make sure to include overall team aggregates to stress the team responsibility, and if non Development Team members have skills that we need, maybe create a column on a separate sheet to indicate its external nature. Let the team suggest how to get the Development Team’s skills to a sufficient coverage. Also discuss what, if any, temporary solutions we can try. As a team, aim for the best first step you can take. So it you cannot fix the problem in one Sprint – for example by learning the skill needed or adding a person with the needed skill to the team – aim for the first best step: collaborating closely with a colleague that does have the skills and ensuring skill transfer by pairing and creating a (dependent) releasable Increment that way. Or, slightly less preferable, collaborate closely with a person with the right skills to get the Increment in a releasable state as soon as possible after. The essence is to keep on working on this Impediment until you can as a team autonomously create and deliver a releasable Increment each Sprint.
Scrum Teams that lack the mandate for certain process steps to create a releasable Increment
For example a team that is not allowed to install new releases to the production environment in their company. For example teams and organizations that are just getting started with agility, where Scrum often is a local initiative. Those organizations are often not ready (yet) for completely tearing down the Silo’s they’ve erected over their past years of growth and internal specialization. And sometimes even companies who have been trying Scrum for a few years still have an official structure of Silo’s and separation of responsibilities needed to release an Increment to the market. The bottom line is that the Development Team has insufficient mandate to create a releasable Increment (without outside action and/or authority).
How to solve the lack of mandate needed to create a releasable Increment as a Development team
Again, take it to the team! Discuss the problem in a Sprint Retrospective or another suitable moment. Earlier is better. Let the team explore what the problem is and how to potentially improve. Sometimes it is hard to get a grasp and know how to attack this problem. If you are unsure how to approach this, you can use an adapted version of the Team Competency Matrix, where the team additionally explores what they feel they are able to do but are not allowed yet. With these insights, find ways to collaborate more closely with those who are actually allowed and try to make the process smoother. In the mean time, work with Stakeholders to create awareness of the downsides of not having the full transparency of a releasable Increment each Sprint (miscommunication, quality, wait times, inefficiencies, etc). Thus hopefully creating movement towards more responsibilities and strengthening the Development Team’s mandate to do all the work needed for a Releasable Increment. Be aware, attempting to change the structure of a process or organization is very hard, since every structure has evolved to keep itself in place. But keep raising Transparency of the problems to the right Stakeholders [4] (those with power & interest [5] preferably) and you should be able to get there.
Conclusion
In this post I’ve addressed the need for a releasable Increment, hopefully giving more insight into why this is essential to Scrum. Others have written about this topic in way more depth and I encourage you to deepen your Scrumderstanding by diving into the topic deeper, for instance the Scummerfall antipatterns [6] or the Empiricism saga (Transparency [7], Inspect, Adapt). However, knowing what is needed and why is not enough to start improving. Therefore I’ve described two common scenarios of not being able to create a releasable Increment, and common examples and approaches to start improving. Notice that while teams that do not create a releasable Increment each Sprint are in fact not doing Scrum, they can benefit greatly of the Scrum Framework on their path to Scrum. There is a lot to be gained by using Scrum’s rules as a target and its empirical process control to support continuous improvement towards getting real, rapid market feedback.
Do you want to get to better grips with concepts like the releasable Increment, Empiricism, Roles & responsibilities in Scrum? These and other essential insights, PLUS practical options to complement and strengthen Scrum & agility are on the Learning Backlog of Scrum.org & Prowareness training. Find all my Scrum.org classes on my profile and browse Agileacademy.nl for the complete Prowarenss training catalog (mostly Dutch, some courses available in English). Please reach out to me for in-house customized programs!
References
- [1] Done is at the heart of Scrum – Gunther Verheyen – scrum.org
- [2] Technical Debt – Martin Fowler – Bliki
- [3] Team Competency Matrix – Management 3.0
- [4] Stakeholder Mapping workshop – Matthew Weprin – uxdict.io
- [5] Getting Stakeholder Engagement Right (by using a stakeholder map) – Roman Pichler
- [6] We Don’t Deliver a Done Increment Every Sprint – Willem-Jan Ageling – Serious Scrum
- [7] Empiricism: Transparency – Sjoerd Jozef Nijland – Serious Scrum
2 thoughts to “The Purpose of Scrum is rarely realized – a path to better feedback”
Thanks for sharing your great insights Sjoerd. Hits the nail on the head. And thanks for the reference to my article!
I was just browsing the Scrumguide revisions as listed here: https://www.mitchlacey.com/resources/official-scrum-guide-current-and-past-versions
Interesting advice on not being able to get Releasable Done in the first published scrum guide (although also somewhat dated, so read/use at your own peril):
“TIP: 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 undone 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 6 pieces of “done” and 4 pieces of “undone.” If the Team finishes a Product Backlog item of 6 units of work (the Team is estimating based on what it knows how to “do”), 4 units are 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.”