Lean Transformation

Friday, August 30, 2013

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.

Read the Rest of Lean Change - Chapter 4: the Validated Change Lifecycle

The Validated Change Lifecycle State 2: Negotiate the Change Solution

Once you have connected a set of problem/urgencies with a set of change recipients
who want to form a guiding team your Minimum Viable Change is ready to move into State 2: Negotiate Change of the Validated Change Lifecycle , you are ready to start working on the actual change solution.

Change agents typically focus first on is the vision, target state, and potentially some qualitative benefits. A change agent can take a quick stab at the sections and then refine them through one or more workshops with the potential guiding team, or he can choose to work with a complete blank slate.

Once the sections are reasonably fleshed out, the change agent and the guiding team can work on taking a stab at coming up with a supporting set of change actions that will realize the target state, as well as start working on the commitments required to complete the suggested change actions.

As the canvas starts to take shape, attention can then shift to establishing a set of success criteria that will define what the success of the change looks like.

This suggested approach to completing the various sections of the canvas is not set in stone, in reality the conversation between change agents and change recipients will result in the canvas being traversed in a variety of sequences.

It is important to note that this process is also highly iterative, discussion in one section of the canvas will result in refinements in other sections of the canvas and vice versa.

A potential change can result in process change, organizational structure change, and will usually result in a change in techniques and methods being employed by employees within the organization.

Regardless, it is important to leverage storytelling techniques that are semiformal in nature to help visualize what the potential change will look like.

It is important to note that many Minimum Viable Changes will stall and potentially be abandoned at this point in the process. While this might seem like a waste it is better to take this opportunity to abandon a potential change before expending significant effort in attempting to adopt new methods and tools.

For the most part the process of trying to agree on urgency, and negotiate should be considered a relatively lightweight process that can be completed in a couple of weeks, with only a couple of days of actual effort required from any individual change agent.

In order for a Minimum Viable Change to pass through the "negotiate change" state, a target state and vision must be agreed by the potential guiding team. It is much more preferable for the solution to be cocreated with this potential guiding team. Critically, change recipients need to step up to any time commitments specified within the canvas, looking at the relationship between actions and benefits as a kind of contract between change recipients, the change agent, and other change stakeholders.

As mentioned previously the label of the minimum viable change ticket may change to reflect any updates to the canvas.

Read the Rest of Lean Change - Chapter 4: the Validated Change Lifecycle

The Validated Change Lifecycle State 1: Agree on the Urgency of Change

The first state within the Validated Change Lifecycle that a Minimum Viable Change passes through is the Agree on Urgency state.

In this state focus on connecting a set of problems/urgency with a group of change recipients who care enough to participate in a potential change. The process of connecting problems to a potential guiding theme is an iterative process.

Change agents will interview various potential change recipients to examine their pain and problems, and see if they can come up with a form a guiding team to act as change champions for the suggested change.

As problems are identified, potential change recipients can be evaluated informally based on their ability to participate in coming up with solutions and countermeasures.

Ideal change champions will be ones who demonstrate experience in actually fixing problems and trying to come up with the solutions in the past. Our experience is that many organizations have employees who have practiced what we call "guerrilla agile", adopting one or more methods and practices without necessarily having organizational authority to do so, agile change agents should seek these people lie within the organization and target them for the first wave of change champions who can form a guiding team.

When a minimum viable change is in the Agree on Urgency state, change agents want to focus on identifying a set of problems that can go into the urgency section, and more importantly connecting those problems to a set of potential change recipients who feel that urgency enough to act as a guiding team, one that will help co-create and co-execute the potential change.

It's perfectly normal for the identifying label of the minimum viable change to be modified as it goes through the lifecycle. The beginning of the process the suggested change may have a very generic title, such as "implement agile methods with a specific team". As more information is understood about the potential change stakeholders will be and what the problems are, the title can reflect an agreed-upon vision.

The minimum viable change will be ready to enter the "negotiate change" state once the change agent has found a set of change recipients who are willing to commit to co-defining a change solution.

Read the Rest of Lean Change - Chapter 4: the Validated Change Lifecycle

Realizing the Change Canvas Through the Validated Change Lifecycle

As change agents and change recipients take a Minimum Viable Change through the Validated Change Lifecycle different sections of the Change Canvas become validated through a number of different methods.

In this post I'll provide a summary of how our team has been typically validating the canvas depending on where it is within the lifecycle.

It is common for a change agent to create a draft canvas as soon as he feels that a change would be a benefit to one or more change recipient groups.

Upon entering the Agree on Urgency state the change agent may put a little more thought into the urgency and change recipient sections to prepare for initial conversations with stakeholders. Remaining portions of the Change Canvas will often only contained cursory notes or initial guesses as to what the contents would be.

As a Minimum viable change passes through the Agree on Urgency state the Urgency and Change Recipient sections of the canvas are validated through discussion with one or more change recipients. It is typical for the Targets, Vision and potentially other sections of the canvas to be given further consideration as a result of these discussions.

When the Minimum Viable Change passes through the Negotiate Change state the change recipients and change agent discuss how the Vision and Target State sections could address the various problems stated in the Urgency section.

Work then progresses on agreeing on a set of Action Items, Commitments and Benefits. After the majority of the canvas is completed, Success Criteria can be defined for the Change Canvas.

When the Minimum Viable Change passes into the Validate Adoption state, a backlog of Improvement Experiments are created. Each of these Improvement Experiments are responsible for validating that the actions listed in the Actions section will help change recipients move towards the Success Criteria defined boundary in the Change Canvas.

As improvement items are moved through the improvement lifecycle of Prepare, Adopt and Learn, various portions of the canvas are validated from a behavioral perspective. Can change recipients successfully use the new methods?

Once the Minimum Viable Change moves into the Verify Performance state Improvement Experiments are now executed, but this time improvement items are evaluated from the context of improved performance. Again as improvement items are moved through the Prepare, Adopt, and Learn lifecycle the Change Canvas is evaluated for correctness, this time from the perspective of performance. Can change recipients operate in a more effective manner because of the suggested change?

Read the Rest of Lean Change - Chapter 4: the Validated Change Lifecycle

Accelerate Change Learning through the Validated Change Life Cycle; leveraging Kotter, Kanban, and Lean Startup

During previous posts I've discussed how change agents can collaborate with change recipients to negotiate their way to a successful change solution.

I've also discussed how a change canvas can be refined so that the change is minimal, as well as subjecting it to explicit experimentation to ensure that it is viable. This allows us to incorporate the concept of validated learning .

During this post I'll continue to build upon these previous topics, going over the Validated Change Lifecycle. The validated change lifecycle provides a path for minimum viable changes to be developed and validated in a way that maximizes feedback and learning.

Why Do We Need a Validated Change Lifecycle?

Change initiatives face a multitude of risks all of which can derail any chance of a positive outcome.

Using the Validated Change Lifecycle risks and assumptions that tend to impact change initiatives first can be dealt with earlier. Other risks and assumptions that impact change initiatives later can be deferred until it makes the most sense.

Change agents who elect to follow the lifecycle are able to learn faster about whether a particular change is viable. The idea is to provide feedback with less effort, so that a decision around whether to pivot or pursue or abandon can be made earlier.

As described in previous posts, validating a change requires subjecting the assumptions contained within a Change Canvas to experimentation. Each assumption can be expressed as a hypothesis, which is then tested for correctness. The Validated Change Lifecycle provides guidance to determine which assumptions to validate first, based on the severity of the risk inherent in the assumption.

An Overview of Key Risks Faced by Agile and Lean (or Any) Change Initiatives
Perhaps the most significant risk of any change engagement is one of resistance. Changes that seemingly make the most sense to everybody involved can still face significant and/or passive resistance when change agents try to execute these changes. Organizations and the people that are employed in those organizations possess very robust antibodies that are able to resist any challenge to the status quo regardless of implied benefits.

Even when organizations and people within them have a genuine desire and willingness to try out new methods and techniques such as agile or lean, there's still a question of sustainability. Many Change initiatives start with a bang, and then fizzle out over time. Change recipients become burned out trying to adapt to the new models and new methods of working and change programs become only partially completed. Many Change plan simply did not come to fruition because he not adequately assess how much commitment the organization can actually contribute to the change.

Finally, even when resistance has been adequately dealt with, and the pace of change is sustainable, any upfront change plan may simply specify the wrong solution. If you remember from the beginning of this course we discussed how detailed planning and upfront design is Not suitable for developing products in highly uncertain and variable markets. This is especially true when trying to define a change management solution that changes the way people behave and work within an organization. Change agents expecting any predefined change solution to survive completely intact throughout the lifecycle of the change initiative is facing certain disappointment.

The Validated Change Lifecycle Is Inspired by the Kotter "Eight Steps of Change" Model
John Kotter, in this text "the heart of change" describes an eight step change lifecycle. John describes a number of case studies showing how change agents work within an organization to enact significant change following these steps.

Step number one is establishing a sense of urgency, insightfully, John believes that most people are at least subconsciously aware of what is wrong with an organization and so starting with a target state or vision is the wrong way to go. Instead, successful change agents should focus on establishing a sense of urgency within the organization.

A good outcome from establishing a sense of urgency is finding enough concerned people within the organization who are willing to form a guiding team that is willing to tackle the sense of urgency being felt.

The guiding team then works on a change vision, a "true North" that can help guide the activities of this change.

Subsequently, the guiding team works on communicating as necessary to establish by across all change stakeholders and others impacted by the change

Executives, sponsors and stakeholders are all responsible for empowering action so that the guiding team can make the changes necessary to realize the vision

It is critical that the guiding team structure their change management effort so that they receive wins in the short-term, and not structure their change management activities so that benefits are loaded

The team, and its sponsors and stakeholders have to be careful to approach change in a sustainable way, and not giving up partway through

After the organization receives tangible benefits, effort switches to making sure that change sticks, and becomes a cemented part of the organizational culture

You may have noticed that much of the language and ideas contained within these eight steps are reflected on our change canvas. In fact most of these steps more or less a line to one of the change canvas components

What this means is that each section within the canvas contains assumptions which when validated will mitigate specific risks

When a minimum viable change is broken up into specific experiments each of these experiments can be designed to validate a specific subset of the canvas. Ordering these experiments according to a change management lifecycle allows us to mitigate change risk in the most optimal order.

The validated change lifecycle provides explicit acceptance criteria to determine when a change can move through for specific states
The validated change lifecycle adapts Kotter eight steps of change, into four specific Lifecycle States. This lifecycle was also inspired by Ash Maurya's Lean Startup Product Development Lifecycle described in his book Running Lean.

Minimum viable changes are both defined and validated according to a specific sequence by passing through the lifecycle.

The first state is About Agreeing on the Urgency of why the change needs to take place. Change agents focus their effort on establishing a sense of urgency and connecting that urgency with a set of change recipients who are willing to form a guiding team. This guiding team acts as a set of teams champions for the potential change.

In the second state change agents work with the identified guiding team and change champions to Negotiate the Change solution, develop a vision for the change as well as the target state. The important part here is that is that the solution is cocreated by both the change recipients (s) and change agents

Once the change model has been agreed upon the change is Validated from an Adoption perspective. The key question be answered here is can change recipients effectively change their behavior and improve their expertise in specific methods and skills?

As new skills are acquired, change recipients will start demonstrating new behaviors and new methods. Focus can then switch to whether the change is verifying performance improvement, we want to ensure that the change is resulting in the right business benefits relative to the commitments required to execute the change.

Instantiating the Lifecycle through a Validated Change Kanban
You may remember that in a previous post we talked about extending a Change Canvas by placing a Kanban system below it to track the lifecycle of specific improvement experiments.

A Kanban system can also be used to visualize the state of Minimum Viable Changes progressing through the validated change lifecycle. As each MVC satisfies the criteria necessary for it to be considered complete within a certain state, it can pass from one column to the next on the validated change Kanban.

Specific acceptance criteria and completion criteria for each state can be marked as a simple work policy under each column within a Kanban system.

This covers my (not so short) overview of the validated change lifecycle, up next I'll provide details on each state within the validated change lifecycle.

Chapter 3: Advanced Change Canvas Topics