Production-Ready Iterations

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. So says the first principle of the Agile Manifesto. Software development teams aspire to be able to produce increments of production-ready code in every iteration, where ‘production-ready’ may mean something like: 100% unit tested, 100% feature tested, 100% system/performance/stress tested end-to-end in a production-like environment, with zero open bugs and no incremental technical debt. And of it course goes without saying that the new increment is just not technical plumbing, but provides ‘value’ to an actual user of the product. This represents an ambitious goal for most development teams, one whose realization may be measured in years, not months, or sadly, may never be achieved.

Scrum’s Inspect and Adapt framework enables teams to evolve, iteration-by-iteration, towards any desired level of capability. The specific practices, methods and tools needed by any individual team in order to accomplish any required outcomes are the result of using the framework to continuously improve, and the time it takes a team to establish a set of practices that support their desired level of agility will depend entirely upon how rigorously the framework is embraced.

Scrum is intended to be used as a framework, not a prescription (“there is no methodology” says Sutherland), and The Guide studiously avoids all references to techniques, methodologies, tools or tactics. In particular, there is no mention of “user stories”, and the authors instead use the generic term “backlog items” for the work of a scrum team. This is indeed a perfect abstraction since it sets up scrum as a framework for almost any endeavor, not only for software development. The authors define scrum as: “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value”. And that, “specific tactics for using the scrum framework vary and are described elsewhere.” I might put it differently and say that specific tactics, practices, methods and tools should be evolved by teams in a way that best fits their circumstances and supports achievement of their desired outcomes. Hence, nowhere in the Scrum Guide will you find any reference to User Stories, TDD, BDD, test automation, or continuous integration. These are considered to be tactics, which may or may not work in all situations, or may in some circumstances simply be irrelevant, and hence have been appropriately omitted. The 13-page Scrum Guide is devoid of practices, methods or tools, and is instead devoted to defining a framework comprising 3 roles, 4 events and 3 artifacts. The intention is that scrum teams use this basic framework to evolve and improve, iteration by iteration,  a set of practices and methods that works best for them and whatever they are trying to accomplish.

Here is an annotated version of the generic Scrum diagram that emphasizes using Inspect & Adapt with metrics and data in order to arrive at a set of practices and methods that supports the team’s objectives:

At the conclusion of each sprint scrum teams should be asking: How well did we execute on our goals? And: What is holding us back? Each sprint has 2 sets of outputs:

• A potentially releasable new increment of the product. The new increment is subject to inspection and adaptation via the sprint review event in which stakeholders are presented with a demonstration of the new capabilities delivered and have the opportunity to provide feedback and recommend changes. This is how development teams and users continuously collaborate to develop great products.
• New learning acquired by the team via the sprint retrospective event. During this event the team will reflect on how well their practices, both engineering and working agreements,  have served the goal of delivering production-ready functionality per the plan derived at the sprint planning event. The team will then make adjustments or adaptations to their working practices and methods in order to move closer to their overall goals for delivery capability.

Adopting Scrum is about forming teams, building backlogs, and regularly producing increments of working software. Anything that gets in the way of any part of this is an impediment.

Data-Driven Improvement

Improvement in a team’s agility evolves via the process of inspection and adaptation. Effective improvement must be data-driven and teams must be able to quantify their objectives so that progress towards them can be measured and evaluated. At the outset we stated that the generic goal of any aspiring agile team was alignment with the first principle of the manifesto. Some have argued that the first principle is the core one, and that all of the others serve to support it. How do we measure how effective we are at value delivery? The following chart is frequently used to illustrate the fundamental difference between traditional software development and an agile one where value is delivered with every iteration and accumulates until the the team has sufficient to justify a release to the market. In the waterfall approach, no real value is releasable until the very end of the project. Further, apart from process deliverables, like documents, there is no objective way to measure progress throughout the project.

Value delivery could me measured by simply counting done features per iteration. (For even more granularity count the associated story points by rolling up completed user stories to the feature level):

From an Inspect & Adapt perspective, we would want to understand what factors influence the slope of the delivery rate, identify sources of waste and impediments, and continuously seek opportunities for improvement. Once major impediments have been addressed, further increases in delivery rate can be achieved by adding more capacity, that is, more delivery teams.

A second useful metric is the team’s predictability, that is, their ability to plan a sprint and then achieve most of what they planned to deliver. This could be measured by looking at planned versus actual velocity.

A reasonable goal might be to consistently deliver 80% of what is in the sprint plan, and this could be reflected in a control chart like the one below.

Typical problems impacting this metric include backlog items not being sufficiently refined (INVEST), stories that are too big, lack of clarity on acceptance criteria, or lack of regression test automation in place.

One of the first things an agile team must do is establish a definition of done that makes clear what they must do to get backlog items to a releasable state. Failure to get items from the backlog to an accepted done state makes it impossible to establish a velocity. All project progress, and a team’s velocity,  should be based on working tested software, and the absence of an accurate velocity makes it impossible to measure progress (or do any kind of planning). Progress based on partially done work is an illusion. Operating without fully done product increments means that a team is accumulating an unestimated, indeterminate backlog of work that will eventually need to be addressed.

Both of these metrics are fairly simple to collect and taken together can help a team improve continuously on value delivery effectiveness. The ability to produce a potentially deployable product increment as the output of each iteration is a non-trivial objective for any team, and may take a considerable amount of time and investment in things like automation and continuous integration. Nonetheless, scrum provides a solid framework through its inspect and adapt mechanisms that enables teams to continuously improve and build on their capabilities.

Summary

• A fundamental agility goal for any delivery organization or individual team is to evolve the capability of producing deployable increments of new functionality as the output of every iteration.
• This capability may take a considerable amount of time to develop, but can be achieved by diligent application of scrum’s inspect and adapt framework.
• Convergence on such a goal can be  accomplished more effectively by use of metrics to quantify gaps between actual delivery performance and desired outcomes.