Wednesday, September 25, 2013

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.

No comments:

Post a Comment