Check out my article on Agile Organizational Design Principles over at the Agile By Design Blog.


Also feel free to have a look at my latest book on Agile Organizational Design, still at work in progress, but there is a lot of material fleshed out already.

New Site

In case anyone still comes here looking for my posts, check out agilebydesign.com. It's the site being used to represent the new company that I have co-founded along with a couple of my old crew from Deloitte LEAN.

Think Visually When Building an Agile Enterprise Change Plan

A picture is definitely worth 1000 words when trying to articulate the true north for an organization undergoing massive change. 

Here are some examples of how someone with even a modicum of artistic skills (i.e. me) to use visual thinking to increase the chance that people in the organization will notice, and even provide feedback on your change plan.


Here is an atypical, if somewhat generic example of an agile transformation plan using a simpler canvas format, you can see a lot of visual metaphors used to represent the different parts of the canvas. 

A Transformation Canvas laid out to support a linear narrative

The format of this canvas is quite different than the ones I have previously shown on my blog and my book. The sections follow a simpler, more straightforward path daily typically seen a lot of canvases including ones that I previously designed.


I like this canvas format as it allows somebody new to the canvas to look at the content in a linear narrative by simply following the canvas horizontally or vertically. I've tried to organize the canvas the following almost Connextra style storytelling approach, For each column of the canvas could be followed according to the following format:
where each column of the canvas could be followed according to the following format:

We want to achieve <vision>

through <target options>  

which will produce <benefits>

that are validated through <success criteria>

and enabled through <change personas>

who are motivated to change because of <urgency>

which will inspire <action>

Here's another example of a transformation canvas template that I've also been experimenting with, in this case the format is less linear, and elements are grouped together according to how closely related they are to each other.

Including specific instructions and samples for each section

In this template, I've tried to provide some guidance around how to fill each section, so that change agents and change participants alike can use structured language to distill the really important points of each section. I've also used some visual narratives to show examples for each section.


Below is an example using this template.

Taking visual thinking to its extreme, I decided to place an immense, wall sized visualization of a transformation canvas in the most public place I could find in my client's organization (no I didn't ask for permission first). This caused people to actually stop, and take a look at what was being planned for the organization, Given the several thousand people impacted, wanted to explore all options when it came to socializing the transformation model.

Graffiti-ing up our client's wall with a transformation canvas

It certainly was a lot of fun (and a lot of work!) creating visualizations for each canvas element. Drop me a line if you want any of these templates, I'm happy to share.

Lean Product Development Part 1

Recently, I've been helping some clients apply lean startup inspired concepts to their work. I'm a big believer that a lot of the concepts made famous by lean startup, such as validated learning, minimum viable products, continuous innovation, etc. are widely applicable outside of the startup world.

I have been using two lean startup inspired tools that I have designed with help from a couple of clients, the Product Canvas, and the Product Experimental Design Factory. I have attached a short video which provides an overview of each of these tools.

Here are some screenshots of the canvas and factory respectively. 

Stay tuned, I'll be releasing another video with a real example shortly.

Shift the Focus of Learning Depending on Where You Are in Your Agile Transformation

When looking at the catalog of agile change patterns together, they form a pattern language that helps you focus, where you're learning should be depending on the progress your organization is made in adopting agile.

When starting to adopt agile or lean in your organization it makes the most sense to focus change on enabling Quick Wins. Rather than trying to validate whether you have the exact right set of target options for your exact context, focus on helping a small portion of the organization adopt a set of lightweight agile methods like Kanban or Scrum. This will identify major obstacles to change, some examples of these obstacles include an uninvolved executive, inattentive business owners, overly specialized organizational structure, or extremely poor morale. With quick wins you are -trying to determine if the organization is ready to adopt "any" amount of agile. And if not, what are the major obstacles, and countermeasures that can be put in place.

Once learning increases through a successive of quick wins set of quick Win, you can start experimenting with introducing a more fulsome representation of your candidate target state. Introducing a Kernel Pilot involves introducing the set of organizational target state options representing the vision for the overall enterprise. This can include a number of agile methods, changes to organizational structure, and modifications to roles and responsibilities. While this change is bigger than the Quick Win, the focus here is still on learning. Focus has now changed from learning about resistance to learning about whether assumptions behind the solution is correct.

As one or more kernel pilot's are introduced into the organization, the change initiative switches from piloting to adopting. A change based on the Kernel Adoption pattern is focused on introducing the future state using successive, rolling waves. As we uncover more and more understanding of how the organization accepts change, and what approach is ideal for the organizational context, we can gradually switch learning from "what" is the target state, to "how" we can best facilitate adoption. This can be a subtle, and permeable distinction. The main point here is that it is okay to spend more time working with people and really understanding what's getting in the way of facilitating learning when starting down the road. At some point, we want to understand how to scale out our efforts to support a sustainable change plan.

Changes based on the Self-Serve pattern is another step in this direction. At this point, we should have enough understanding about what works in the organization, where we can standardize, where we can't. We should also understand what parts of our target state are relatively stable, and which parts continue to change rapidly. This allows us to start figuring out how to publish our knowledge in a way that the organization can consume on their own with minimal support from agile coaches are agile consultants. Many change management consultants recommend starting with defining some type of delivery model and method publishing it out, and getting adoption going. It's really only at this point, but I found it useful to get thoughts around "how" the organization is meant to work. At this point in the transformation, a lot of learning has taken place based on on the ground adoption, we now want to switch our learning to understand how we can push change out to the edges of the organization, supporting it in a way that creates a self learning environment.

Changes based on the Capability Modernization pattern are really about cementing the change and ingraining it into the supporting structures of the organization. New specializations and competencies are modeled as appropriate using a combination of career ladders, capability models, job specifications, and incentives. Functions like Human Resources, Finance, and even Legal play a role, making sure that employees are on board, educated, and compensated according to the new "normal (if there is such a thing as normal for an agile organization).

For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking

Toronto Agile Tour 2013 Session

I'll be presenting at #att13 this year. Well not so much presenting as running a workshop. I'll be joined with a team of both peers and clients of mine  to help workshop attendees build a change canvas. The idea is to work with anyone coming to the workshop to help map out an agile change using the canvas.

If you are part of an agile change, or want to get one started come to the workshop and will help you put a change model together. Here is a video describing the workshop below.

For more check out the Lean Change Method: ManagingAgile Transformation with Kanban, Kotter, and Lean Startup Thinking
 

Updating Your Canvas Based on Your Improvement Experiments

At some point you will want to take the time to update the Change Canvas to reflect any new learning that resulted from the Improvement Experiment. This could include rebalancing benefits and commitments, desired target options, or any other component on the canvas.
I recommend setting an explicit Kanban style policy concerning when to take the time to update the Change Canvas. Options include whenever an experiment is finished, or on a set cadence, perhaps biweekly or monthly.
I often run a session with change participants to annotate the canvas for correctness, again using green, yellow, and red markers for portions of the change model that are believed to be correct, partially correct, and completely incorrect. Participants may also annotate the canvas with a statement that describes "why" a certain assumption is not turning out to be true.

The Change Canvas can then be updated to reflect the latest understanding and newest learning. This can include looking at the existing Improvement Experiment backlog and re-factoring it to consider the new information added to the Change Canvas.

Performing a Change Pivot

When a large number of experiments do not meet expectations, then it is time to consider a change pivot. A change pivot involves wholesale modifications to the Change Canvas, and underlying change model. When executing a change pivot, one key aspect of the change model is altered, while keeping another aspect intact. Examples of a change pivot include:
1. Choosing a different set of change participants
2. Selecting a different set of methods, tools or techniques to adopt
3. Switching up actions and tactics, perhaps going from light touch to high touch or vice versa
4. Scaling back benefits to better reflect time commitments that your change participants can make

For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking .

Writing Good Improvement Experiments

A good improvement experiment can take many forms, I design my Improvement Experiments so that they contain the following key items:
1. Explicit activity or action
2. The roles and/or people being affected by the change
3. An outcome or effect as perceived by the people be impacted by the change
4. A constraint, such as a number of sessions, or a time. Where the experiment expires

Change agents should feel free to experiment with the exact format of an Improvement Experiment ticket, I tend to work with the following format:
-an action- -with/for- - a specific change participant- -will result in- -an outcome- -within some constraint-
an example could be:
"co-facilitated story mapping sessions with the business analysts and business subject matter experts will result in them feeling that they can effectively determine solution scope and structure after 3 supported sessions"
The activity is an explicit action that the change agent is going to execute in collaboration with change participants.
The specific change participant is simply the one or more of the change participants listed on the canvas that will be participating in the Improvement Experiment.
The outcome is the expected results, this can be in the form of improved capability, improved performance, or some other benefit. It's a good practice to write the outcome from the perspective of the change participants, how they perceive improvement is taking place (or not).
The constraint can be expressed in the form of a time period, i.e. "after two weeks" or a number of instances of a certain activity, i.e. "after three sessions". A constraint can also be specified as the occurrence of a specific event, iwhen the emergency defect occurs".
It's important to phrase validation from the perspective of the change participants, rather than using language that specifies achievement of some goal in a generic way. For example:
"developers will become TDD ninjas after three weeks of coding dojo's" isn't as good as "developers will indicate their mastery of TDD after three coding dojo's".
We want to structure our outcomes like this because it helps to enforce the idea that all validation of an Improvement experiment has to come from the change participant. It's not enough for a change agent to evaluate the impact of an improvement on change participants. Embedding language that hypothesizes how a change participant will indicate his reaction to a change encourages this mindset.

The nature of the experiment will vary depending on where a Minimum Viable Change is within the lifecycle. Here are some examples of improvement experiments that could be part of each of the 4 states within the validated chief lifecycle:

· the online team can identify enough problem statements to provide a clear case for the adoption of agile technical practices after 3 facilitated workshops (agree on urgency)
· the portal technology group can articulate and contextualize a more agile working model after 1 week of brainstorming (negotiate change)
· analysts who are part of the International Teller Program Will tell me that they can  perform agile style story analysis after 2 weeks of coaching (validated adoption)
· including developers in detail story analysis will reduce defects by 50% after one month (verify performance)
Regardless of whether you use the rest of the method in its entirety, running an agile adoption or transformation as a set of improvement experiments helps to reframe a change agent activity is something that can be put under constant scrutiny, helping the change agent examine his tactics, and possibly changing his strategy if necessary.
For more check he Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking

Improvement Experiments In Action - Continuing Our Story of Danny the Developer

In order to show how Improvement Experiments can be used, Let's continue following Danny as he works with his team to Improve delivery performance.

Filling the Backlog

After a couple of planning sessions Danny and his team come up with a set of Improvement Experiments That they feel will result in executing on their change model. The group then prioritizes these Improvement Experiments into various two-week blocks.
They take care to put no more than 3 Improvement Experiments in each block, as the team feels that this is the maximum amount of change the team could absorb every two weeks.

Preparing New Improvement Experiment

When December 1rst rolls around, tickets can start moving into the Next column, signifying that new improvement items should be started. Note that only two tickets are moved as this is the current Wip limit being set by the team.
The team then decides to move the value stream mapping session into the Prepare state.

As tickets are moved through the prepare state the first thing we do is rewrite the ticket so that it supports the notion of testability. Each test should validate the assumptions behind the change, represented in one or more sections of the Change Canvas.
In this instance Danny and the team rewrite the value stream mapping Improvement Experiment so that it says "value stream mapping sessions will allow change participants to reveal urgencies after 3 sessions ".

As an Improvement Experiment is moved into the Prepare column, it is rewritten using this experimental format. The change agent then does all the necessary preparation work to get the improvement ready. Examples include preparing for workshops, developing training guides, scheduling sessions, sending out communications, etc.
In Danny's case he works with a new, external, agile consultant recently brought to the engagement. They work together to prepare workshop material, book rooms, and coordinate everybody's schedule to make sure that they are able to run three workshops dedicated to reviewing and suggesting some fixes using the value stream mapping process.
 

Introducing the Experiment

Once this Improvement Experiment has been prepared, it can now be moved to the Introduce column, this is a signal that the team is now actively running sessions, trying out new techniques, etc., and potentially even benefits from the improvement items. This benefit could be in the form of validation of change assumptions, or actual realization of benefits on the change canvas.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
The Improvement Experiment continues until either the experiment has proven true or false, or the constraint has elapsed.
In Danny's case, the value stream mapping Improvement Experiment is moved into the Learn column after three sessions have been completed.

 

Learning from the Experiment

At this point the experiment is moved to the Learn column, and evaluated for success.
It is important for change agents not to fall into the trap of evaluating experiments on their own, ultimately it is the change participant who needs to make the call about whether an Improvement Experiment is successful or not. In our experience Improvement Experiments do not always simply pass or fail, for this reason we have used A three outcome approach. Success, fail, and partial success. (and tagged with, green, red, or orange markers)
As various Improvement Experiments are passed through the Learn column, the canvas can be evaluated for correctness. Failed experiments are to be expected, and will indicate a need to modify certain sections of the canvas.
If we continue to follow Danny's progress, we can see that the value stream mapping experiment was successful in that he was able to come up with a good set of urgencies with his change participants. Unfortunately, Danny was not able to collaborate with his team to come up with a target options model based on a big A-Agile solution. This latter Improvement Experiment is telling Danny that he needs to rethink what the solution is going to look like if it's going to be of value to his change participants.

Typically as one Improvement Experiment is being prepared, introduced, and evaluated, other Improvement Experiments are being pulled through the Improvement Experiment Kanban based on the capacity limits. Here is a snapshot of the entire Improvement Experiment Kanban.

Breaking up a change model represented on the canvas into a set of Improvement Experiments and then managing them using a Kanban system provides the team with real-time insight on how the change effort is progressing, much like a Kanban system can help software delivery teams provide insight on how a software project is progressing.
For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking

Validate Your Agile Change with an Improvement Experiment Kanban

In various recent posts I have talked about how a Minimum Viable Change as small as it can be. An MVC also has to be viable.

For a change to be viable, we need to continually validate the different aspects of that change. This validation can be achieved by implementing our change using a discrete set of Improvement Experiments. As each Improvement Experiment is introduced to change participants, the experiment is evaluated, providing insight into the validity of the change model represented on the canvas.
One way to manage Improvement Experiments is to track them using an Improvement Kanban System. The Improvement Kanban tracks the progress of Improvement Experiments as they are introduced to change participants. Each MVC typically has its own separate Improvement Kanban board. Frequently, the Improvement Kanban is placed directly under the Change Canvas that is used to represent the MVC in question.
 
 

Different columns represent different states within the improvement lifecycle. As Improvement Experiments complete a particular state they move from left to right across the Improvement Experiment Kanban.
The left side of the Kanban represent items that have not yet started, basically an improvement backlog. It is recommended to use a regularly reoccurring cadence to schedule replenishment of Improvement Experiments. In this case each column represents a two-week interval in the future. What this would mean is that every two weeks the change agent and change participants would meet and start on the Improvement Experiments within the appropriate column. Depending on the number of improvement items and a timeline of the change, a later/optional column could also be placed to the very left, signifying improvement items that may be "stretch" goals.

The right side of the Kanban represents items that are currently in progress, and follow a simple prepare, introduce, and learn lifecycle.

The numbers on top of each column is known as a work in process limit, or WIP limit for short. This number represents a recommended limit to how many tickets should be in a particular state at a time. This "inventory leveling" is a feature of Kanban that helps ensure that value flows quickly through a system and an individual work ticket does not spend too much time waiting around in one particular state.
Below is a real-life example of a MVC Change Canvas along with an Improvement Experiment Kanban below it.
.
For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking

A Change Canvas Action Cheat Sheet

Here is a quick cheat sheet I put together to help people when trying to navigate a Change Canvas. Enjoy!

For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking

Using Kanban to Manage the Flow of Agile Change

Kanban, as described by David J. Anderson's book "Kanban: Successful Evolutionary Change for Your Business", is an ideal method to manage both continuous operation and continues improvement for all kinds of knowledge work systems. Kanban is a lean inspired management method that helps knowledge workers continually improve work performance through a combination of visualization, just-in-time value creation, and focus on flow. Kanban is an excellent method to help manage and improve the operations of an agile change initiative.
Kanban is a core concept to the Lean Change method. Kanban is used in the following ways:
1. to track and manage both minimum viable changes and improvement experiments on various kanban boards
2. as a means of providing quantifiable validation of improvement experiments and the underlying change during the verify performance stage of the Validated Change Lifecycle.
3. As an alternative change management method that can take over from the method once the organization achieves sufficient maturity to operate in a continuous improvement mindset

Both Minimum Viable Changes and Improvement Experiments Are Managed Visually Using Kanban Systems

A focal premise of the Lean Change method is that Kanban is used to manage the flow of change, taking advantage of visual, just-in-time techniques. The Lean Change method uses various Kanban boards to define and visualize how change progresses through the organization, helping change agents get into a state of change "flow".
A Validated Change Kanban is used to track individual Minimum Viable Changes as they pass through the Validated Change Lifecycle. This allows teams of change agents to coordinate and collaborate during a change initiative, taking advantage of Kanban features such as visualization, explicit policies, standups, and limiting the amount of change in progress.

An Improvement Experiment Kanban is used to track Improvement Experiments for each Minimum Viable Change. As an MVC passes through each state in the Validated Change Lifecycle, various portions of the change are validated using one or more Improvement Experiments. Each MVC typically has its own dedicated Improvement Experiment Kanban, placed right next to, or right below, the Change Canvas used to describe the Minimum Viable Change.

Changes Eventually Need to Be Measured in Terms of Improved Performance, Kanban Provides an Excellent Set of Techniques to Do so

I've already talked previously around how Improvement Experiments are used to validate different aspects of a Minimum Viable Change. As change participants gain experience in lean and agile methods, they start to evaluate Improvement Experiments against performance metrics. Because of its origins within lean, Kanban provides mousedown 20 a rich set of metrics such as leadtime, throughput, and failure intake that can be analyzed using statistical process control or cumulative flow diagrams.

Making this concept real, when a Minimum Viable Change passes through the Verify Performance state, Improvement Experiments can then be evaluated to see if one or more kanban inspired metrics improve. An example of an improvement experiment implemented during the verify performance page could be conducting developer reviews of unfinished requirements documentation on a weekly basis will reduce UAT defect density by at least 30% after one month.

Once the Organization Achieves Sufficient Maturity, Kanban Can Take over As the Change Management Method

Kanban is described as a change management method in its own right, by David J. Anderson and others in the LeanKanban community. This change management approach borrows many techniques and ideas from lead and other bodies of knowledge to enable a viral, and evolutionary change management approach designed to help organizations gradually become more agile over time.

Kanban is designed to provide a gradual way for technology knowledge workers to improve. Knowledge workers start by mapping out their existing delivery process and visualizing this process using a Kanban system, typically manifested as a Kanban card wall.

A combination of methods are used to enable a grassroots, continuous improvement mindset, that in some conditions can virally spread across the organization. These techniques include explicit and visual policies that govern how work is conducted, limiting work in process to enable flow, connecting value delivery through frequent regularly scheduled cadences, and allocating work across visually colored classes of service.
So why not just use Kanban by itself and forget about the Lean Change entirely? It's been my experience that the Kanban method, used in isolation, is not always sufficient to help organizations transform to a more agile state. In some circumstances, helping clients adopt the Kanban method has resulted in amazing performance improvements. In other cases I've seen people attempting to use the method never quite grokking the continuous improvement mindset. Even more unfortunate were the cases where teams were doing well, but management did not adequately support changes being suggested by people who adopted the Kanban method, causing those people to eventually become disgruntled, and abandon the change effort. I have personally experienced a number of Kanban-based agile adoption that stalled because of a lack of patience, existing expertise, or direction.


The Lean Change method enhances Kanban to provide the aspects of a managed change initiative that can help organizations receive the guidance and support they need to be get started with Kanban, or some other continuous improvement method. Eventually, the goal of any agile or lean change initiative is to reduce the need any for an official "managed" change. We want to move from a transformative change mindset to an incremental, evolutionary change mindset. The sign of a true healthy, agile organization is one where improvement is continuous, and driven from employees doing the work.
In A nutshell, Kanban is an ideal method to supports the organization's efforts to continually adapt and improve. Lean Change is there to help with explicit change planning and change coordination when required, whether that change is larger or smaller. Kanban can take over when and where continuous improvement is more appropriate.
Think of Lean Change as a mechanism to make some of the more overt changes required to prepare an organization for Kanban. As change participants get used to working in a lean and agile context, they can start using Kanban to continually improve at their own pace, independent of any "managed change" effort.
For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking .