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 classes. Find all my Scrum.org classes on my profile. 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