Lean Transformation: The Validated Change Lifecycle State 4: Verifying Performance

When a Minimum Viable Change passes into the "Verify Performance State" Of the Validated Change Lifecycle, the focus shifts to validating that a change is delivering its expected business outcomes.

Like In the Validate Adoption state, the canvas is validated to ensure that change actions can be successfully executed, balancing commitments and benefits, helping all change stakeholders achieve the target state. Unlike the previous state, the change agent is not testing to see whether the changes are resulting in the acquisition of new behaviors, but rather that the change is actually improving delivery effectiveness.

When talking about any kind of agile or lean really change, improved business outcomes are often expressed in terms of improved performance. In order for a change agent to effectively measure performance, a number of things must be in place for the change recipient.
First of all, the team must have some type of lean or agile metrics gathering and reporting system. The team must have some experience in looking at metrics such as velocity or throughput, analyzing those metrics to look for potential impediments and problems, and at least a willingness or desire to run improvements based on these potential impediments.

Secondly, change recipient should be reliably using new techniques, comfortably using new methods and have developed new habits, and not be dependent on consultants or coaches. If the team is still struggling to adapt to new methods, it doesn't make much sense to start trying to evaluate the change canvas from a performance perspective.

Finally, before any performance-based experiments are executed it is recommended that the team is approaching some kind of stable performance baseline. What this means is that velocity and/or throughput exhibits some kind of predictability, and that the system of work has enough stability to support measurements based improvement.

There are many in the agile community that feel that software delivery work is too close to the edge of chaos to support any kind of quantitative improvement. There is certainly some merit to this opinion, and for some domains, it may make sense to have a minimum viable change completely skip the verify performance stage, the change plan can be considered "complete" after Validated adoption state is considered satisfied by all involved.

It has been our experience that many domains can experiment from a quantifiable experiment and improve loop. This type of quantifiable improvement is a cornerstone of the Kanban method. The loop starts by having a set of knowledge workers coming up with a suggested improvement and articulating it as an experiment using a hypothesis around what benefits the improvement will bring.
The improvement experiment is implemented with the change recipients, who then check to see if delivery performance has improved, stayed the same or gotten worse. Regardless of the results learning takes place, successful experiments become part of the team's delivery process, unsuccessful experiments prime the team to run a different experiment.

Change recipient and change agents attempting to adapt more classical agile methods can base improvement experiment hypotheses on a suggested change in velocity, and commitment accuracy.

Our experience in agile and lean transformation is to help teams adapt a mixture of classical agile methods along with more lean inspired methods such as Kanban.

Using lean metrics supports tracking and reporting on performance metrics that can cross the entire value stream. Lean Metrics that can be used as the basis for a quantifiable experiment include:

Leadtime - the overall time it takes to deliver a particular unit of value to an end customer. Leadtime typically takes into account all the way time that precedes delivery getting started and happens after delivery is completed. We tied can often be used to measure end-to-end project delivery, particular releases or even the delivery of independent user stories or features. When leadtime go down agility goes Up, quality tends to go up, and overall performance tends to improve.

Cycle time - is a lot like leadtime, but does not focus on the wait times before after delivery starts and ends. Cycle time is good for measuring process efficiently, and likely time we wanted to go down

Throughput is the number of business valued items that are completed over a particular period of time. Throughput is often measured as the number of user stories or features that pass through the delivery process in a given week or month or other period of time. Throughput is often a number that managers and executives care about the most.

Failure Load is the portion of work that we are building that represents value that we should've already delivered to the client because of previous work. Customer complaints, defects, and rework are all examples of failure load. The inverse of failure load is value load which represents the portion of work we are currently doing that to be generally considered a new and fresh business valued request.

Capacity Load is perhaps one of the most important metrics for any team attempting to use a lean inspired methods such as Kanban. Capacity load tracks how much work in process is in the system to hurt you workers in the system. Often represented as number of user stories or features in process per active worker. We want this number to go down, high numbers are a predictive indicator of long lead times, unpredictable throughput, and a high defect density and failure load.

As mentioned previously before a minimum viable change can pass into the verify performance stage, a change agent should have successfully helped a set of change recipient's adopt the tools and techniques and techniques necessary for them to become measurable. This is typically done through running on improvement during the validated options page of the lifecycle.

Once this improvement has been successfully adopted in the team and gain some experience in gathering, reporting and gaining insight from metrics, the team can start adapting the future improvement items so that the outcomes are reflected as a quantifiable improvement.