Modeling an Enterprise Agile Transformation With a Transformation Canvas

In previous posts I've talked about how to complete a change model as expressed by a Change Canvas. The focus of these posts have been on using the canvas to define Minimum Viable Changes, and also how validate those changes using the Validated Change Lifecycle; first through discussion, then by checking behavior, and finally by checking performance.

I've also discussed how to use the Validated Change Lifecycle to order the kind of actions and experiments we want to execute in order to de-risk our change program.

The type of change that we have been talking about so far, has been at the team or department level. However, we can also use the Change Canvas on a very different scale, to support planning for large-scale organizational transformations. When using a Change Canvas this way, we call it a Transformation Canvas. The Transformation Canvas can help senior executives who are looking to rewrite the Cultural DNA be any of their entire organization, and want to execute large-scale change across the enterprise.

Why Do We Need a Transformation Canvas?
as a quick review of how lean change work so far, change agent can work with a group or cohort of change recipients to execute a set of improvements experiments as a Minimum Viable Change.


A Change Canvas is used to reflect all the components of the minimum viable change, and that canvas is then validated first through discussion, then by checking behavior, and finally by checking performance.
 
Change agents can de risk and maximize learning for a change by moving Minimum Viable Changes through the validated change lifecycle.

As a change program scales out, multiple change agents may work on multiple Minimum Viable Changes can in parallel, effecting numerous changes on an organization.

Different change agents will come up with different solutions to the unique problems of the change recipients they are working with. This can be considered a good thing, different groups of change recipients will often require different solutions that match their context.

However, taken to the extreme, executing different changes in different parts of the organization can result in a solution that doesn't make sense or work very well as a whole.

Different lean and agile methods place emphasis on different things, and even may contradict each other in the advice they give. Without care change recipients and other chain stakeholders can become confused.

Change Agents working on an organizational transformation, one where a larger number of Minimum Viable Changes will be introduced to the organization, should spend some time on planning and modeling what a transformation can look like from the perspective of the entire organization. Just like a Minimum Viable Change, elements that make up the model for a transformation level change can be thought of as assumptions that can validated through experimentation.

An organizational transformation model can be used to ground and otherwise constrain the various minimum viable changes that pass through an organization. When a change agent begins work on a new minimum viable change the first point of reference is the organization organizational transformation model. Does the minimum viable change fit within the overall objectives of the organizational transformation?


A Transformation Canvas Models the Elements of an Enterprise/Organizational Transformation
Just like a Change Canvas can be used to model the elements of a Minimum Viable Change, a change canvas can also be used to model the elements of an organizational transformation. We call this type of Change Canvas a Transformation Canvas.

The main difference between a Transformation Canvas and our previously discussed Change Canvas is one of scope, a Change Canvas used to model an MVC is concerned with improving the lives of a particular segment of change recipients within an organization.

A Transformation Canvas is used to model the concerns of either the entire organization or very large subset of an organization undergoing a transformation.

A Transformation Canvas can be validated through the implementation of one or more Minimum Viable Changes.

When using the Transformation Canvas this way, you're asking change agents to take part in a two tier, hierarchical planning process.
At the top layer an organizational Transformation Canvas is designed, and a suggested set of Minimum Viable Changes are prioritized using a Kanban style backlog.
As change agents become ready to work on new Minimum Viable Changes, Change Canvases are defined and validated through improvements experiments.

Using this approach feedback trickles from the lowest level, learning from Improvements Experiments impact the validity of elements on the MVC Change Canvas, and changes to various MVC Change Canvases impact the Transformation Canvas, and thus cause change to the transformation.

Shown below is an example of the transformation canvas. It's very similar to a regular change Canvas only larger, content is also geared towards discussing an entire transformation.
.



Read More Lean Change - Chapter 5: Using a Transformation Canvas for Enterprise Change

1. Understanding Why We Need an Organizational Transformation Canvas
2. Applying the Change Canvas to Transformations
3. Mitigating Change Risk through Traversing the Canvas
4. Prioritizing Different Minimum Viable Changes Based on Risks on the Organizational Transformation Canvas

Validated Change Lifecycle State 3: Validate Adoption

When entering the Validate Adoption State of the Validated Change Lifecycle, we are now ready to validate the change by measuring what people actually do, and how they actually behave. During the previous two states of the validated change lifecycle, validation occurred through discussion. Change agents would test the change canvas by measuring how change recipients reacted to different sections of the canvas.


It's important to note that during this state, measurement and validation is still largely qualitative. While we can use numbers to measure how well people are improving in new methods and techniques, experience and judgment will still play the largest role in validating any assumptions behind the change model.





The primary purpose of the validate adoption state is to determine if change recipients are able to adopt new behaviors, techniques, and working culture related to lean and agile technics. It's important to focus on adoption first, and give people chances to get used to new methods before focusing on looking at performance or other business outcomes.


One of the first things a change agent should do during this state is to work with change recipients to come up with a backlog of improvement experiments. These improvement experiments should be designed to validate that specific actions taken by the change agent will result in improved capability and adoption of specific agile techniques.

Good improvement experiments will also be validated against a specific success criteria listed on the change canvas.


Our team has had good success using simple agile and lean capability models, tracking a number of capability dimensions for particular set of change recipients. Improvement experiments can be designed by creating a hypothesis that Outlines how a set of change activities will result in improvement on some dimension of the capability model.

It is extremely important that change recipients take an ownership role in measuring the effectiveness of a particular improvement experiments, change agents should act as facilitators, and almost never interfere with the teams self-evaluation.


It is also crucial to make sure that teams do not feel like they are being judged or evaluated by any type of external authority, the use of capability models is especially prone to misuse by management. Teams need to feel safe to learn at their own pace, and not get into capability competition with other teams. The point is to make sure that we can validate assumptions behind how much effort is required to help teams adopt new techniques, and to collaboratively adjust any of these expectations if they turn out to be false.


Again our experience tells us that understanding the relationship between the commitment required for change recipients to truly adopt new techniques is extremely hard. This effort is often vastly underestimated, and is usually the source of the first pivot required to realign an agile change program.



 

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

1. Validated Change Lifecycle Using Kotter, Leanstartup and Kanban
2. State 1: Agree on the Urgency of Change
3. State 2: Negotiate the Change
4. State 3: Validate Adoption
5. State 4: Verify Performance
6. Realizing a Change Canvas through the Validated Change Lifecycle
7. Instantiating the Lifecycle Effectively Using Information Radiators

 

Presenting the Complete Lean Change Method

Transforming your organization to agile is hard. Too many lean and agile change initiatives fail

Many traditional "Big C Consulting" change management methods rely on upfront design, fixed plans, and disruptive overhauls that result in change resistance and can decrease organizational performance. Many organizations have challenges in getting existing agile improvement methods, such as Kanban and Scrum, to work as prescribed.

A Startup Is a Really Good Metaphor for Agile Change Initiatives

Lean Change is a change management method that provides change agents with a dynamic planning and execution framework. Lean Change is based on the metaphor that any agile change initiative can be thought of as a startup. Borrowing many principles and techniques from the Lean Startup method, change agents are able to keep the change plan and model relevant by incorporating the latest learnings obtained from on the ground adoption.

Lean Change integrates the "Kotter 8 steps of change" with validated learning to provide change agents with a systematic approach to mitigating common risks encountered during agile/lean transformation; including resistance to change, correctness of change, and sustainability of change.










All aspects of the Lean Change method are designed to be cocreative, enabling change agents, change recipients and other change stakeholders to negotiate their way through a communally owned solution. All change participants learn their way to a successful change outcome.

Lean Change Is Now Ready As a Consumable Method

I have posted a large number of articles around Lean Change,  all of these articles tie together in an overall story that I hope to publish one-day. I have put together a quick table of contents, hyperlinking to the relevant articles where they exist. As always please feel free to provide some feedback.

Chapter 1: the Case for Lean Change

1. Why Today's Technology Organizations Need to Change
2. Challenges with Current Organizational Change Methods
3. Presenting the Lean Change Method

Chapter 2: Getting Started with the Change Canvas 

1. a Short History of the Canvas 
2. the Change Canvas in Action-a Story of Danny the Developer
3. Using a Canvas to Represent a Minimum Viable Change 
4. Guidelines and Practices When Using the Change Canvas

Chapter 3: Advanced Change Canvas Topics

1. Using Plug-Ins to Explore the Urgency and Change Recipient Sections
2. Using Plug-Ins to Explore the Vision and Target State Sections
3. Using Plug-Ins to Explore the Actions and Success Criteria Sections
4. Using Plug-Ins to Explore the Benefits and Commitment Sections
5. Using Plug-Ins to Explore the Communications Section
6. a Catalog of Reusable Agile Change Patterns

Chapter 4: the Validated Change Lifecycle

1. Validated Change Lifecycle Using Kotter, Leanstartup and Kanban
2. State 1: Agree on the Urgency of Change
3. State 2: Negotiate the Change
4. State 3: Validate Adoption
5. State 4: Verify Performance
6. Realizing a Change Canvas through the Validated Change Lifecycle
7. Instantiating the Lifecycle Effectively Using Information Radiators

Chapter 5: Walking through the Validated Change Lifecycle with a Comprehensive Example

1. State 1: Agree on the Urgency of Change
2. State 2: Negotiate the Change
3. State 3: Validated Adoption
4. State 4: Verify Performance

Chapter 6: Using a Transformation Canvas for Enterprise Change

1. Understanding Why We Need an Organizational Transformation Canvas
2. Applying the Change Canvas to Transformations
3. Mitigating Change Risk through Traversing the Canvas
4. Prioritizing Different Minimum Viable Changes Based on Risks on the Organizational Transformation Canvas

Chapter 7: a Cadence Model for Workshops, Meetings and Review Sessions When Running Lean Change at Scale

1. Overall Cadence Model
2. Change Agent Daily Standup
3. Change Recipients Improvement Update
4. Stakeholder/Sponsor Update
5. Change Agent Planning
6. MVC Canvas Refresh
7. Transformation Canvas Refresh
8. MVC Backlog Replenishment
9. Metrics Update

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

1. Validated Change Lifecycle Using Kotter, Leanstartup and Kanban
2. State 1: Agree on the Urgency of Change
3. State 2: Negotiate the Change
4. State 3: Validate Adoption
5. State 4: Verify Performance
6. Realizing a Change Canvas through the Validated Change Lifecycle
7. Instantiating the Lifecycle Effectively Using Information Radiators

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

1. Validated Change Lifecycle Using Kotter, Leanstartup and Kanban
2. State 1: Agree on the Urgency of Change
3. State 2: Negotiate the Change
4. State 3: Validate Adoption
5. State 4: Verify Performance
6. Realizing a Change Canvas through the Validated Change Lifecycle
7. Instantiating the Lifecycle Effectively Using Information Radiators