My Journey Towards Creating the Lean Change Method

The Lean Change method was developed primarily because my team and I needed some way  to manage the organizational transformations that we were running with our clients.  Over the last five years my focus has changed from running technology delivery  projects and programs to running advisory engagements. I had taken the knowledge that  our team had gained from executing large-scale agile projects and re-packaged it into  a service offering focused on helping clients adopt agile methods.

The good news is that I had early market success, especially in IT. Clearly many  organizations wanted to improve the way they were working, and were considering the  use of lean and/or agile as an enabler. Being completely transparent, many of these  early engagements had mixed results. While I am probably one of the harsher critics  of my own work, I was rarely satisfied with the outcomes of these organizational  transformations.

My early forays followed a traditional "big C consulting approach". This typically  meant performing enough analysis to come up with a target state for the future, and  developing a multiyear implementation roadmap. My team and I would typically stick  around for the first couple of phases of the change rollout.

It became immediately obvious to myself and my associates that the words "fixed  plan," and "organizational change" do not belong in the same sentence. We could  immediately see how many of our assumptions behind the target state model, and change  tactics used to realize that model, were incorrect the moment we started rolling  things out. But it was difficult for us to communicate our learnings to our clients,  too many of these folks were focused on tunneling their way through the plan, wanting  to get out of the other side. The result was a lot of dissatisfaction from people on  the ground, increased organizational dysfunction, and an overall decrease in delivery  performance for the organization.

As a side note, many of our agile adoption projects were based on helping clients  adopt scrum, this caused interesting challenges in an IT context. We encountered a  lot of delivery initiatives that could not easily lend themselves to the idea of  cross functional teams, where the majority of team members were dedicated to the work  of that team. Often technology delivery was based on the use of packaged software,  integration of legacy systems, large data conversion, etc. all which may challenge  you to get the value out of a pure scrum approach.

As I began to complement my agile knowledge with lean thinking, and specifically, the  Kanban method. Our team looked for clients who wanted help in adopting Kanban as a  means of improving the maturity of their organizations. In some cases, adopting the  Kanban method resulted in great performance gains for various clients, in other cases  people attempting to use the method never quite grokked 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 were  adopted the Kanban method, causing the people to eventually become disgruntled, and  abandon the change effort. It seemed that even something as lightweight as Kanban  required some aspects of managed change to ensure that folks received the guidance  and support they need to be successful.

In later change management initiatives our team once again elected to use a more  "managed change" approach, but this time, introducing change in small increments,  dubbed Minimum Viable Changes. In place of a static plan we used Kanban to manage the  change initiative. In lieu of a target state model, we defined a capability model  with suggested employee targets over time. We called this new approach "lean startup  4 change". Riffing on the concept that a change initiative can be thought of as a  startup, and can use practices made popular by the lean startup method.

In reality, this approach only borrowed a small amount of lean startup thinking, and  was really just a form of iterative change using just-in-time planning. There were a  lot of challenges with this approach, the biggest one being the disconnect between  change agents and change recipients. On the one hand, change agents were able to  effectively learn from the results of a previous change iteration, come up with anew  set of change tactics, roll the new change out, and incorporate more learning. On the  other hand, employees,managers, and other change stakeholders were not able to  effectively keep up. This constant modification of change had the effect of creating  massive confusion within the organization. Even worse, change was being pushed onto  within the organization, leading to change burnout.

Our challenges, highlighted a paradox in managing ambitious change efforts. On the  one hand a common strategy and vision is required to align everybody towards a common  goal post, and this common goal needs explicit management by executives, managers,  and other dedicated change agents. But managed change come with a number of potential  drawbacks, drawbacks which tend to severely derail the change effort.

Managed change programs tend to be directed from the outside in, as professional  change agents perform organizational analysis, draw up a blueprint for the future,  and rollout the change across the organization. Managed change also tends to be  directed from the top down, with executives expecting managers and staff to swallow  the change that has been dictated to them from on high. Finally, managed change also  tends to be rolled out in large batches, causing massive disruption, which is always  underestimated by those in charge. The result is change resistance, change fatigue,  and a change that often doesn't provide value in the context of real problems as they  are experienced by employees on the ground.

What I needed was a change management framework that would allow change agents to  model our change as a set of assumptions. The method would then allow me to take  those assumptions to mychange stakeholders so that they could validate (or more  likely invalidate) those assumptions. My change management framework needed to help  me validate proposed changes not only throughdiscussion, but also by testing how  people reacted and behaved once the change was deployed, and finally, by testing  whether that change was resulting in expected business outcomes, or onlymaking things  worse. I needed a change management method that would allow me to make organizational  change testable, providing insight to the entire organization around whether a change  was succeeding or not!

It was also equally important that any change management framework used insured that  the folks being asked to change had a say in what that change would look like. I  wanted my change recipients to be co-creators of any change initiative that they were  a part of!
 Digging deeper into Kotter, and how Lean Startup actually works provided inspiration  for this new method.

The Lean Change method is based on the principle that all suggested changes are  merely untested assumptions. Using a technique known as validated learning, we  introduce change their experimentation, pursuing correct assumptions, and letting go  of incorrect ones. The Lean Change method is also based on the principle that change  must be cocreated, following a process of negotiation and collaboration. Co-creation  must take place between the change agent (the person instigating the change) and the  change recipients (the people being asked to take part in a change) throughout the  entire lifecycle of the change program. Lean Change is at its best when it's hard to  distinguish between change agents and change recipients!

Check out more of the Lean Change method on this site or on my book, The Lean Change Method: Managing Agile Transformation through Kotter, Kanban and Lean Startup Thinking.

Take Part in the Lean Change Experiment, And Build a Change Canvas With Me

I'm hoping to enlist members the community in a little experiment relating to the Lean Change method.

Readers of this blog will be aware that I have been heads down over the last six months or so formalizing what I am calling the Lean Change method, with the book now published at https://leanpub.com/leanchangemethod/ , an index of all Lean Change articles can be found @ http://agileconsulting.blogspot.ca/2013/08/lean-change-table-of-contents.html

As a brief refresher, he Lean Change method brings lean thinking to the world of "managed change". The method adapts core concepts from the lean startup world, like the use of a planning canvas, delivering value through experimentation, and validated learning. It then integrates these concepts with the Kotter eight steps of change, and is operationalized using various Kanban systems. Finally once the right conditions are in place, the Kanban Method takes over as a continuous improvement technique.

I'm trying to see how useful The Change Canvas is to other folks who are trying to instigate change within an organization. I'd like to do this by working with anybody interested to:
1) I would conduct a canvas oriented change interview, going to each section of a change canvas to articulate an agile Orlean oriented change that you have been a part of, or are trying to plan. Given that this is a Kanban list, a Kanban adoption initiative would be especially relevant.
2) I will format the content into a change canvas and give that back to you
3) if you are happy with the result, support you as necessary so that you can post or otherwise comment on the experience in the community.

Of course if anybody Has any other quick or deep feedback that they would like to provide me on the method  and or the book, I would love to hear it!

Realizing a Minimum Viable Change Through the Validated Change Lifecycle; a Comprehensive Example Part 4 - Verify Performance

Performance Is Not Improving Close to What Is Expected
Charlie coaches the Product Owner to do some metric oriented root cause analysis, and shares this analysis with the rest of the team to get their thoughts. The bottom line is that while throughput and quality are improving, they are not receiving the magnitude of order improvements necessary to keep the backlog from growing at a rapid rate. There's simply too much demand coming into the system.


There Are Still A Lot Of Production Level Defects, but Code Quality Is High
Charlie thinks it's a good idea to take a closer look at the source of all of the failure intake coming into the system. Despite the team having adopted a better UAT, production level tickets continue to be a major source of demand for the team, consuming a lot of their effort. Having spent a good deal of time with this team, Charlie knows that their quality is actually quite good, and no longer believe that this is the source of production problems. Charlie marks this ticket within the Urgency section as yellow, meaning that more research is required.



Production Bugs Are Being Used to Capture Requirements

After a couple of facilitated workshop sessions where defects are analyzed, a number of common causes become clear. Many of the defects are actually uncaptured requirements. There appears to be a whole category of requirements that were not captured at the beginning of the project, and as a result the solution design needs to be re-factored to consider these features. The current practice in dealing with these requirements is for the operational experts to capture these missed requirements as production level defects, the team then attempts to fix the system in an ad hoc manner to meet these new requirements. No one is looking at these requirements from a holistic perspective, to determine overall impact on the system, or whether any reflector and is required. The result is the system never quite satisfies this category of requirements.


Story Mapping to the Rescue

Charlie discusses this with the application maintenance solution team and suggests that they bring back in another concept that was also retired from the change canvas, namely story analysis. If you remember, Charlie had removed this as a concept from the Target State along with other aspects of agile practices. His change recipients have felt at the time that this type of analysis was to heavyweight for maintenance type activities. Charlie suggests that they bring in a technique known as story mapping, as well as some other story analysis techniques such as playing poker, to help group defects into similar themes, and restructure them into one or more common user stories that can then be estimated, implemented and validated.

Charlie is now able to modify the Benefit section of the change canvas to have a much more modest improvement of throughput, as throughput is no longer the issue. Implementing these requirements now is, so with this in mind he adds a new Benefit; to reduce the gap between requirements and what has been implemented in the system. He wants to reduce this gap to one third of its existing size within three months.

Success criteria is likewise changed, throughput metrics are now much more modest. More critically, a new success criteria has been added that will measure the team's ability to analyze requirements and get them validated by the business at sufficient speed to reduce the backlog of unmet requirements. Initial suggestions are that if the team is able to process six story "themes" per month, then they will be at the right velocity.

Charlie also updates the Commitments to reflect both training as well as continued effort to perform this story analysis, something that will become a major responsibility for the solution analysts, as well as a commitment to the product owners well. Coaching has also grown to a full-time responsibility for Charlie, he's now helping on a number of different fronts but so far is getting good return on the time he spent with this team.

Charlie updates the Action section to reflect the new coaching that he will perform related to story mapping and estimating.

Charlie and the team agree that the Vision statement should now reflect how the team is working to evolve both the process and the underlying technology system to meet the needs of the business, both in terms of growing demand as well as correct functionality.



Once the canvas has been updated, Charlie introduces a new improvement experiment to validate these changes.



Check out the Rest of Lean Change - 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

Realizing a Minimum Viable Change Through the Validated Change Lifecycle; a Comprehensive Example Part 3 - Validate Adoption

Charlie feels that he has performed enough discovery with his change recipients to move his Minimum Viable Change into the Validate Adoption state. He populates his improvement experiment backlog with a set of tickets dedicated to understanding whether the application maintenance team can successfully adopt some of the process improvements and Kanban related practices described by the Target State.


Charlie Starts the Adoption Process, but Again Faces Passive Resistance

As Charlie works with the application maintenance team a common pattern begins to emerge. While there was reasonable participation in setting up the kanban system, and there is always some participation in the various kanban related meetings, a majority of change stakeholders either do not show up or are very disengaged from the process. No one is actively resisting Charlie's work, but neither are they showing very much initiative to do things on their own. Many change recipients are complaining that they have other activities to do, and that this change is taking too much of the time.


Charlie decides to reflect this information on his canvas. He's clearly not progressing towards his Success Criteria as fast as he would like, so he marks it yellow. Only a minority of change stakeholders consistently show up and or engage standouts and other kanban related meetings. An even smaller minority shows interest in actually modifying work policies are partaking in workshops necessary to set up and refine the Kanban systems. He marks the Success Criteria as yellow, i.e. partially correct as he is making some progress.

Charlie tries to work with managers to restructure all capability into a single dedicated team with employees who can provide full-time commitment, but is met with forceful resistance. It seems that there is too much point knowledge spread out across too many people, people that have other responsibilities, so he marks this part of the Target State as red.

Charlie still believe that there needs to be some concept of a fully focused, dedicated team, but at some restructuring is required to get it to work. He indicates this by marking the application maintenance team concept within the Change Recipient section as yellow. Currently not all change recipients are fully participating, nor are they learning all the skills promised, so he also marks the appropriate Commitment and Wins Benefits as being only partially correct as well.



Charlie and His Change Recipients Perform a Change Pivot
Charlie starts working with his change champions to get a better understanding of how work actually flows through the application maintenance team. These change champions have been showing enthusiasm and a genuine desire to improve performance. What is interesting is that these change champions are made up of a number of roles, there are operational experts, business analysts, and developers who are showing a mostly full-time commitment. A larger portion of these folks fall into the other other, less interested group.

Charlie collaborates with this change champions to design a simple value network diagram to try to get understanding of the different degrees of responsibility across these folks. It becomes clear that a subset of the application maintenance team are acting as a virtual team. A subset of operational experts understand the system from an end-to-end solution perspective, or have domain expertise in multiple lines of business. A subset of developers likewise understand how all the various systems work together from a solution and or integration perspective. Remaining operational experts and developers are either knowledgeable in one line of business or one specific system, and are really only needed on a part-time basis when a particular aspect of the solution needs to be changed or tested.

From Dedicated Team to Feature Team

Taking some inspiration from Kanban literature, Charlie looks at the concept known as a feature team. Charlie defines a core team, redefining the business analysts within this team as solution analysts, and redefining the developers within the team as solution developers. This team will be made up of dedicated, full-time individuals. The remaining operational experts and developers are placed in a pool, and are dynamically assembled into feature teams on an as needed basis. Charlie needs to work with the appropriate managers (development managers and LOB representatives) to make sure that enough capacity is set aside and some service-level agreements are put in place to ensure that these feature teams can be assembled fast enough to meet the to the needs of the core team.



As a part of designing the value network, Charlie and members of the core team update the change canvas to reflect the latest thinking. They starts with the Target State, adding the concept of a dedicated team supported by feature team.
He then updates the Change Recipient section of his canvas to show two different classes of Change Recipients, a dedicated solution team, and the just-in-time future team.

Likewise the Success Criteria are now much less ambitious, the dedicated is the only group that needs to have deep skills in of Kanban. The larger group needs needs to only be of work related policies to be able to follow them. The Commitment and Benefits section are likewise updated to reflect this new focus on the core solution team.

Charlie then puts in a new Action to help the team design this new type of kanban system and coach the solution team in operating it.



The Team Is Now Collaborating Better, Charlie Turns to Other Elements of the Change Model That Have Not yet Been Tested

With these new adjustments in place, adoption is going much smoother. Charlie places 2 new Improvement experiment into the backlog, one based on fixing the dysfunctional intake & prioritization mechanism, and another experiment dedicated to helping the team adopts some of the metric oriented root cause analysis capability that comes with the Kanban method.


Again, Charlie Faces the Evil of Passive Resistance

Charlie runs a number of facilitated prioritization sessions with LOB representatives who are responsible for establishing priority. He is shocked by how little progress he makes. His attempts to create queues and allocate them to different lines of business go nowhere. No one is willing to step up and say exactly how much capacity they need, Nor are any of these representatives willing to contradict anybody else. Charlie knows that most of these representatives are still going directly to the team, practicing backdoor politics to get their work done first.
Charlie is also unable to find any one person who really wants to own the role of analyzing metrics and getting the team into a state of quantifiable improvement based on data.
Charlie is unsure which part of this change model are incorrect, so he places yellow markers in the Urgency, Target State and Action section. He knows he needs to do some work here but is not sure exactly what.

The reality is that the Business LOB Representatives all have performance bonuses tied to getting their work completed by the end of the fiscal year. Interestingly, a very clear mandate from top executives have made it clear that these LOB representatives need to work with each other to make sure that all work gets done. This is led to a highly politicized climate, where backdoor dealing is the rule of the day.
Charlie adds this problem to the Urgency section.


Time to Reintroduce the Product Owner Role

Because of the divisive and fractured nature of the LOB group, Charlie suggests to one of the executive stakeholders that they look again at the Product Owner role, but this time he suggests that the person fulfilling this role is a senior executive, and that this person possesses the skills and factor to have some tough conversations with various business clients around what can and what cannot be done this year. Charlie is able to get agreement, as this concept was already currently being circulated within the executive group as a potential solution.

Charlie updates the Target State, to include the concept of a Product Owner. And likewise reflects this concept of a Product Owner in the Action, and Wins Benefits section. Charlie has upped his Commitment now to three days a week, as he will be spending a good deal of time coaching his executive on how to be a Product Owner on an agile team.

You may remember that the concept of a Product Owner was part of the original version of this Change Canvas, the idea was scrapped when the idea of an agile iterative team model went out to the window and we brought in Kanban instead. This is a completely normal part of the process, elements of a change model will be removed and then added back in based on new learnings. What Charlie has learned is that he needs to remain flexible and take concepts from different methods in different areas of thinking to come up with a solution that truly fits the needs of his change recipients.



Charlie runs a new improvement experiment for about a month, dedicated to taking an existing, senior Line of Business Representative, and coaching him to become a product owner for the entire solution. This person takes to the new role extremely well, and all early indications show that he is doing a fantastic job.

He also takes ownership of looking at performance metrics such as throughput in leadtime, and running periodic root cause analysis sessions to understand if performance is improving to keep up with the growing demand and improve customer satisfaction.








The change recipients are now showing the ability to successfully adopt new methods, as well as gather performance oriented metrics for the purpose of quantifiable improvement. Charlie is now ready to move the Minimum Viable Change into the final, Verify Performance state of the Validated Change Lifecycle.


Check out the Rest of Lean Change - 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

A Lean Change Comprehensive Example - Part 2 Negotiate The Change

Having validated the urgency and change participant section of the Change Canvas, Charlie is now ready to work with his identified change participants to co-create a change solution for the MVC.

Charlie Conducts a Workshop with the Change participants to Collaborate on a target options

Charlie prepares, then facilitate a workshop in the aim of working through different sections of the Canvas. Charlie hopes to come Up with a change solution.




Charlie suggests a more pragmatic set of changes this time around. Charlie present the idea of preserving the majority of the teams existing processes, but enhancing them with a better prioritization mechanism. He also suggests putting the Operational Experts in charge of UAT. Charlie would like to place both analysts and developers together into a cross functional work cell to perform the analysis function. Charlie still feel strongly that the application maintenance group would benefit from more full-time team members working in a dedicated cross functional nature, so he leaves that in the target options.

Charlie then suggests putting Kanban on top of this process in order to empower the team to improve their agility over time.

Charlie Faces Passive Resistance

During the first negotiate change workshop it becomes clear that many of the developers do not want to commit to any decisions that will significantly impact the way they work. Most of the technical folks are reluctant to agree (or disagree) with any of the suggested target options concepts.



Charlie Discovers Another Set of Change Stakeholders
After the workshop, one of the developers approaches Charlie. He lets Charlie know that the developers really belong to a number of different departments, segregated by system. These departments each have their own development manager. And it is hard for developers to agree to any changes to working methods without input and agreement from these development managers. Charlie adds these development managers as another set of secondary change stakeholders to the Change participant section of the Canvas. He then holds another workshop inviting these development managers, and is able to get reasonable consensus on his suggested approach.

Charlie Is Now Ready to Start Planning Adoption of His Suggested Target ghOptions

Charlie now prepares for, and then facilitates a change planning workshop with the intent of discussing what is required to realize this change.


Working with his change participants, Charlie updates the Action section of the Canvas to include Kanban set up and coaching. He also tries to secure commitment for the application maintenance team to take two days of Kanban training, and have all participants show up to all Kanban related sessions and meetings. Finally, he decides to update his own Commitment to two days a week as this group is larger than he had originally anticipated.

Charlie is hoping that all the listed change participants will Benefit from gaining deep Kanban expertise, he's also hoping that the team will be able to meet the continually growing demand, which would require a 100% improvement in throughput. While change participants are not entirely convinced that this is possible, they agree to defer to his enthusiasm. Defects also need to go down by an order of magnitude, given their huge rate, Charlie has put down a 200% reduction required. Again the team is not convinced but are willing to go with it for now.

Charlie also uses the planning session as an opportunity to discuss different Success Criteria. Given the team's relative inexperience with lean and agile methods, this is mostly an exercise in education and socialization. Charlie's change participant group consists of 53 members. In order for him to consider the change successful Charlie feels that a majority of these employees should be able to exhibit basic Kanban skills such as pulling work without being asked to, as well as follow other Kanban related work policies. He feels that a smaller but sizable portion should be able to create and implement new work policies. In terms of performance, throughput and quality need to eventually improve to the number listed in the benefits section. Charlie's gut tells him that this will take at least 10 months for these numbers to take effect.

Charlie Is Having Trouble Getting Everyone to Engage

Despite the fact that the workshops have gone reasonably well, Charlie marks his improvement experiment as only partially correct. Some participants in his workshop seemed to be disengaged from the process. He's becoming increasingly aware that a core group of change participants are working hard to understand concepts, and help co-create the solution. However a larger portion seems to be distracted, and even resentful that these numerous workshops are taking place.

Charlie Focuses on His Champions

Charlie decides to segregate his Change participants into two groups, those that are showing passion for the change, and actively engaging on shaping it, and those who are more disengaged and more passive to the process.



Charlie's holds a series of workshops with the selected change champions to carefully go through each section of the Change Canvas sharing supporting information when necessary, ensuring complete understanding, and gaining agreement that these change champions will be co-owners of the change.

For my next post, I'll talk about finally getting the change going with the validate adoption state.
For more check out the Lean Change Method: Managing Agile Transformation with Kanban, Kotter, and Lean Startup Thinking

A Lean Change Comprehensive Example - Part 1 Agree On the Urgency of Change

In the next several posts I'm going to provide an example of how the Lean Change method can be applied. I'll showcase the various techniques and practices in one integrated case study. This includes using the Change Canvas to represent a Minimum Viable Change, and using the Validated Change Lifecycle to define, validate, and finally re-factor a change plan based on the outcomes of a number of Improvement Experiments. Various methods and techniques that can be used to explore a Change Canvas, such as value stream mapping and value network design are also included in this example.

    

To begin we will showcase how a Minimum Viable Change passes through the Agree on Urgency state.

Charlie the Change Agent Has a Job to Do

Charlie is an agile coach whose responsibility is to help employees within his organization be more successful through the use of lean and agile methods and values. Charlie has been asked by the CIO of the organization to have a look at the application maintenance team. The maintenance team is responsible for supporting a complex, distributed solution that provides mission-critical functionality for the business. The team is having numerous challenges and business customers are starting to complain. Charlie is tasked with helping the application maintenance group improve their delivery performance.

Charlie marks down Some of His Thoughts on a Change Canvas

Charlie begins by taking a stab at putting together a Change Canvas to represent his first thoughts on what a MVC could look like. Charlie has worked for the organization for several years and has an idea of some of the problems that the application maintenance team is facing.

The application maintenance team is infamous for its reputation for poor collaboration both within the team and with its business customers. There is also a perception across the organization that the delivery is really slow, and leadtimes are incredibly long. Even when things are delivered, customers continue to complain about quality, and the defect rates of this group are amongst the highest within the organization. Charlie marks these challenges within the Urgency section of the canvas.
Charlie knows that both Business Analysts and developers are assigned to the application maintenance team, so quickly notes them in the Change participant section.

Charlie feels that a lack of "team culture" and bad practices are a major source of problems for the application maintenance group. Charlie feels that restructuring the group according to an "agile model", one that is co-located, and comprised of full-time dedicated members, will help to kickstart a more collaborative culture. Charlie also feels that the team will improve their capability to deliver through the adoption of agile style story analysis techniques, along with agile planning methods such as physical card walls. Charlie places these three concepts into the target options section of the Change Canvas. He likewise writes down a vision of an agile team in the Vision section.

Charlie quickly jots down his initial thoughts around Actions and Commitments, some upfront training, along with some occasional coaching, and various meetings. The one big commitment Charlie has placed is the need for a dedicated Product Owner, something that does not exist in this organization.

Charlie Then Validates His Thinking so Far

Charlie places two Improvement Experiments onto the Improvement Kanban system next to the Change Canvas for his MVC. He is hoping to be able to validate that his urgency and change participant sections are correct through a single workshop. He's also hoping to find somebody within either the application maintenance team or the business customer group who would be willing to play the Product Owner role. He doesn't want to spend more than one weeks searching for a candidate. He prepares some workshop material, schedules his workshop, and is ready to run the workshop to go over the Canvas.

Charlie moves his Improvement Experiments through the prepare column, and then into the introduce column. In parallel he also prepares a job description for the Product Owner, and starts scheduling meetings to see if he can find anybody interested in taking on this role. He likewise moves this ticket through prepare and then introduce.

Unfortunately, both of these improvement experiments turn out to have assumptions that are incorrect.

When speaking with the application maintenance team, he gets very little agreement that delivery times are actually slow. He can also only get partial agreement from some team members around the issues of poor quality and lack of collaboration. Workshop attendees also point out that he has not included everyone who is involved in the application maintenance effort.

Since Charlie has gotten both the urgency and change participant sections wrong, the rest of the Change Canvas is basically invalidated. Charlie needs to basically go back to the drawing board.

Charlie Conducts Some Deeper Analysis to Understand How the Application Maintenance Team Functions and What Their Problems Are

Charlie suggests to the application maintenance team that they spend more time understanding the current context of this team. He suggests running a number of value stream mapping sessions with the goal of coming up with a more accurate set of change participant and key problems within a two-week period.

Charlie prepares and schedules the workshop and then moves a new Improvement Experiment through the prepare and introduce states.

Charlie Is Now Ready To Take A Second Crack At The Canvas

After several sessions Charlie is able to come up with a reasonably accurate value stream map, outlining major activities including who is responsible for specific tasks.

He is able to get good agreement on specific challenges relating to each step within the process. The value stream map shows a number of these problems, ranging from:

· a nonexistent prioritization mechanism where diverse stakeholders (known as Line of Business Representatives) basically shout over each other to get resources, causing conflict in demand, and a lot of stop/start work

· a perception of ivory tower analysis causing the Business Analysts to be bypassed by Business LOB Reps.

· Developers are really system specialists, and work largely in silos, severely impacting quality down the road

· a UAT function that was not capturing quality problems, resulting in production bugs being unusually high

· the Business LOB Reps, who are tagged as having business subject matter expertise, have little real knowledge of the inner workings of the solution. The real knowledge is possessed by a diverse group of Operational Experts, the real users of the system. The Business LOB Reps. almost always delegate business-related questions to these Operational Experts.

Charlie is also able to get a good handle on which roles are impacted by these problems, taking time to speak with members from each of these departments to get their input.

Charlie now has a better handle on the makeup of the application maintenance group.

Charlie lists a core set of Change participants which include Business Analysts, developers, and the Operational Experts. He also adds the business representatives but puts them at the bottom of the section to indicate that they are secondary change stakeholders and not core members.

Rather than listing all the problems from the value stream map on the Change Canvas, he summarizes two major points in the Urgency section. First of all, the distributed nature of the team and unclear expectations around responsibilities is contributing to an environment of poor visibility and no understanding of who gets to make what decisions. Secondly, there is a growing demand of production related defects mainly because issues are not getting caught in UAT where they should be caught in the first place.

Charlie updates the Action section to reflect the team's desire to have more support than he initially estimated. He also updates the Commitment section to reflect the need for 1 day of coaching for the duration of this change.

With the Canvas updated, Charlie moved the we do /next value stream improvement experiment into the learn column, marking it as a success.

for my next post, I’ll discuss how Charlie works with this team to negotiate change 

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

Agile Transformation Cadence Model Activity 8: Update and Share Metrics

The Lean Change method can result in a variety of metrics, dashboards and charts which reflect a summary of how the transformation is progressing from a number of perspectives. We have found valuable to spend some time aggregating and analyzing this information to both communicate progress as well as generate new insight.
As change agents work with change recipient groups to complete various Minimum Viable Changes data will be generated from both an adoption as well as performance perspective.
Adoption information can be summarized both within and across change recipient scripts through the use of simple capability maps represented using spider charts.

Performance information can likewise be collected for particular change group or across multiple change groups where it makes sense. Performance metrics used will depend on the particular mixture of agile and lean methods selected.

Change agents work with change champions and other stakeholders to review this information, generating insight where appropriate, and communicating this out to stakeholders and other sponsors.
Where possible, we recommend placing this type of information into a well trafficked, public areas of the organization rather than bringing these charts and graphs to specific review sessions within meetings.

Read More Lean Change - Chapter 6: 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