Or “Why is it a problem when Stories slip to the next Iteration?”
Successful lean-agile implementations have a number of common patterns that ensure we improve our ability to deliver value in comparison to more traditional approaches. One of the most underestimated ideas is the focus on delivering running, tested features on a cadence (iteration, sprint), which are then demonstrated to stakeholders for feedback. This type of thinking starts with the Agile Manifesto (“Working software is the primary measure of progress”) and is typically supported by a number of lean-agile practices:
Cadence: A regular cadence for delivery, typically as iterations (or sprints)
Definition of Done (DoD): A known quality standard for delivery, which usually takes the idea that a team has finished work to include not just the coding, but also documentation, testings, integration testing, etc.
Value orientation: A focus on delivering value to customers / stakeholders.
Self-discipline: The need for self-discipline - maintain a professional standard where you take personal responsibility not to cut corners
What are the benefits of working this way, especially when you compare to more traditional approaches to implementation? When we focus on delivering running, tested features (to a known quality standard and on a cadence) we:
Improve forecasting. Rather than forecasting based on, for example, whether we have completed a design document, we can base our forecasts based on delivering something real and use that historical data to better understand how the total delivery will go.
Increase predictability. Because we are delivering something real, on a cadence, we improve overall predictability of our efforts.
Decrease risk. Since we are seeing real, working systems we have a objective understanding of what we have. There is no risk associated with what we have delivered.
Decrease the cost of change. Because we are showing real working systems, we find problems earlier when they are still cheap to fix.
Reduce variation from the expected goal. As we see real working systems we can course correct rather than simply continuing based on our current understanding of the plan.
Improve decision making. We have data to determine pivot, persevere, or stop decisions because we can see real, working systems.
Improve chances we are building the right thing. As we show real working systems to our customers they are able to provide real feedback on the work so they end up with something they want at the end of the project, not what they thought they wanted at the beginning of the project.
Improve the changes we are building something right - to the internal quality standard. We get in the habit of building things to a known quality standard. We leverage tools like the “definition of done” (which offers a more complete view of what it means to be done) and demonstrations of software (e.g. System Demo, Sprint Review).
Can stop the efforts when we find something else more valuable to do. We have a system that works. We can stop and still have a system that works.
Isolate release decision from implementation. Since we know the system is in a state where it is “done” we can make the decision to release functionality at any time it makes business sense.
Increase engagement from customers and stakeholders. People are naturally able to respond better to a working system than something like a “design document” - “I’ll know it when I see it” - and are simply more engaged when working on real working systems.
Reduce the number of assumptions we make. Instead of building long term plans based on assumptions, we test assumptions early. This is increasingly important as we deal with increasing complexity of our systems.
Can capitalize the work earlier. Since we are producing working systems, we can more easily capitalize the work, potentially improve organizational financials.
Reduce waste. We worry less about what has happened in the past - you can change history anyway - and only worry about decisions that effect upcoming work.
All in all, a pretty good return for a pretty simple idea. This is not to say that doing this is easy. Most organizations do not have systems or processes in place which support and leverage these ideas even when they think they are working in a lean-agile way. But the benefits above show that investing in this space makes a lot of sense.
And if you have not figured out good business reasons to do DevOps, this might be a start (note: DevOps provides a lot more benefits than this) as successful DevOps take this idea one step further to deploying and releasing on a cadence.