Managing Agile Organizational Transformation: Learn how to manage agile adoption initiatives using the Lean Change method. The Lean Change method extends the Kotter change management lifecycle with high feedback, iterative planning practices based on validated learning and other techniques taken from Lean Startup.
Note: This is a transcription of a podcast. It has not gone through professional editing process and may contain grammatical errors or incorrect formatting
Related Podcast: Using Kanban, Kotter & Lean Startup Thinking
Transcription of Podcast
Joe Dager: Jeff started his career in the trenches of enterprise development, creating a software delivery joy through the use of things like patterns, Agile methods, and overall object-oriented goodness. In recent years, Jeff created the Deloitte Lean service offering, providing advisory, coaching, and change management services to IT departments and software focused businesses.
Jeff has built this capability within Deloitte to help organizations truly transform the way they operate their business. Over the last several years, Jeff has played a leadership role in some of the largest Kanban based enterprise transformations worldwide. Jeff recent captured some of this work in his new book called The Lean Change Method.
What was the motivation for putting together the Lean Change method?
Jeff Anderson: Thanks a lot Joe. Let me just provide a little bit of context- you’ve done an excellent job in describing what I do for a living. Over the last several years, I’ve been trying to help fairly conservative IT organizations, as well as conservative technology/software product organizations transform from traditional methods; command and control, highly specialized organizations, waterfall delivery to using more Agile methods, and using more Lean thinking. This is actually pretty complex and pretty hard thing to do. I think most Agile change agents out there will agree with me that too many Agile transformations are still unsuccessful; we’ve got some great value out of Agile, and a lot of organizations have received good benefits from using Agile and Lean thinking, but it’s still a really hard thing to do. It’s still really complex. 
You look out there, and the existing methods and tools used to conduct organizational transformations don’t actually lend themselves to the unpredictability of any type of organizational transformation; much less an organizational transformation trying to get an organization from traditional methods to new, modern and innovative techniques. Probably the most common method out there, unfortunately, is what I call the ‘Big C Consulting’ approach, where a whole lot of consults get hired by the executives within an organization. They spend a little bit of time analyzing the current state of that organization, and then they go, and they forklift one of the dozens of traditional models they’ve got in their catalogue of tool kits, put out an implementation road map, and watch as the change goes completely off the rails because of resistance, because of existing organizational cultural problems, because the change is just plain wrong.
On the other end, a lot of Agile transformations start with implementing some kind of Agile improvement technique “Scrum or Kanban” being an example. In this case what we end up doing is we try to find a place in the organization where we can adopt one or more of these improvement methods, try to adapt the context and hope things go well. In some cases, they go well, but in a lot of cases they still don’t, and we don’t actually know why. A lot of people say, “Scrum doesn’t match particular the context of a particular organization” and other people can say “Kanban just takes too long to be successful”. What my opinion is that if Agile transformation is going to happen in a reasonable time frame, it does require managed change. The change needs to be managed by the executives of the organization, by the managers of the organization, and it does require assistance sometimes from external consultants who have who have a lot of experiences in Agile and Lean, but we want to have managed change method that doesn’t lock us in an up-front plan, and into an up-front design.
I also wanted to make sure that I had a managed change method that wouldn’t disrespect the people being change. I wanted to make sure that what I call ‘change recipients’ of a change, which are the people that are actually being asked to do new things, I want to make sure my method enabled those people to be co-owners and co-creators of the change. So in a nut shell, the reason I made the “Lean Change Method” is I wanted a set of pragmatic tools for Agile change agents to be able to manage an Agile or Lean transformation in a way that would enable learning, quick changes in direction, and actually empower the change recipients to be co-creators and co-owners of that change.
Joe: What you’re saying is that you’re using a method to promote ownership as much as anything.
Jeff: The ownership is actually the key thing. One of the biggest strengths of the Kanban method is that it gives change recipients or everyday employees some tools to go and look at where their problems are, visualize those problems, get some data around those problems and come up with a solution. What I really want to do is extend the whole concept/philosophy of self-managed change, but have something that sits at a slightly higher direction, at a slightly higher level. So you can look at things at a strategic level, a holistic level, and at the entire organization level without giving up the ownership of everyday employees being owners of that change.
Joe: How does it coincide with typical Lean thinking? Is it similar to leader standard work and that type of process?
Jeff: What we try to do is inject Lean thinking into the world of managed change. Now there are lots of different kinds of Lean out there; what we specifically did is take inspiration from the Lean Startup method. One of the prime ideas behind the Lean Change Method is that a start-up is an excellent metaphor for a large-scale transformation; there’s a high amount of unpredictability; there’s a high amount of variation, and you need to learn your way through the success rather than plan your way through the success. So, we really actually take in a lot of the principles behind the Lean Startup method and apply them to Lean Change.
The first thing we did was look at the Lean Startup tools; Lean Startup is famous for taking the concept of a canvas-which is a kind of plan on a page and using it to collaborate on what are all the assumptions behind a highly uncertain business domain. So we’ve taken that and adapted that to the world of change management, creating what’s called a ‘Change Canvas’. Now in the start-up world you get feedback, and you get learning, but deploying and building the smallest possible product you can validate whether you’re heading in the right direction or not in terms of a viable product, and they call this-in the product world- a ‘minimum viable product’. In our world, we continued our shameless riffing-, and we have what’s called a ‘minimum viable change’. So in the Lean change world, what we want to do is say “we’ve got this Agile or Lean transformation going on, let’s make sure that we implement this change in the smallest possible increment that’s going to validate not only our change solution, but “are we employing the correct change tactics?”, and we call this the ‘minimum viable change’.
Joe: When you do that though, is that like a scenario? A smaller scenario type of thinking where you present it and you try it. You do the experiment, and you receive the feedback from it?
Jeff: Absolutely! What we do is we take our minimum viable change that’s articulated on a change canvas, and we start looking at what are all the assumptions behind this change canvas. We then create a set of improvement experiments that are designed to validate those assumptions. Now typically our improvement experiments are designed to test whether our change is resulting in changes, in behavior, and the acquisition or adoption of new methods, as well as acquisition of business outcomes and improvement of performance.
An example of an improvement experiment could be “imagine we’ve got a minimum viable change that’s all about helping a team adopts some Agile modeling methods, some collaborative brainstorming techniques, and we have an improvement experiment that says after a month of co-facilitation and coaching, our teams can independently do story mapping, class responsibility cards and definition of acceptance criteria on their own”, and that would be an improvement experiment.
Another one that’s more based on performance outcomes might be we’re going to actually take this set of people on a project, we’re going to merge them into a collocated team, and we’re going to see if the average lead time for a blocker goes down”. It’s interesting these improvement experiments can be done from a qualitative or behavioral perspective. They can also be done form a performance or business outcome perspective.
Joe: This really raises two questions with me, and the first one is that I see a lot of people believing that every iteration is good. Is that true? And how do you back up? Do some iterations fail?
Jeff: Well, if I look at an iteration being a change iteration, and kind of each minimum viable change can almost be thought of as that change iteration, you’re going to have a lot of failures at the beginning, and you’re supposed to. I think it’s Don Reinertsen that’s quoted in ‘Information Theory’ that says ‘optimal learning happens at a fifty percent failure rate’. The idea here is that with the Lean-change method you want to fail fast and fail cheap.
What typically happens is when change agents go, and they build their first canvas they do its using what we’re calling a ‘validated change life cycle’; it’s basically the customer development process adapted over to change management, and there’s this four state process which is designed to make sure that you can learn and fail as quickly as possible so you can pivot to the right change. In the first state, all you’re doing is looking at the portions of the canvas that deal with “Do I have the right set of change recipients who feel the urgency to change so much that they’ll become a set of change champions?”. So you’re really looking at the urgency and change recipient section of that canvas to try and find that right match. That’s a real quick problem; I mean a real quick thing to do, relative to coming up with a change target state. You’ll be iterating through all kinds of canvases, coming up with potential minimum viable changes, meeting those potential change recipients in the organization and saying “wow, I don’t want these guys to be my first adopters for an Agile transformation.” You’ll have a whole lot of what you call wasted minimum viable changes.
The next state is you’ll actually work with that guiding team, or those change champions to co-create or negotiate a change solution. Again, it’s interesting-this allows you to get through what I call a lot of passive resistance. A lot of the time change agents will think they’ve found that successful set of change champions, connected them with some urgency, and then really try to co-create a change solution with them. They realize that they’re just not involved; they’re not doing their homework; they’re not learning on their own to help create the change solution. That might seem like waste, but you’ve just learned an awful lot an awful lot quicker, and you’ll have a whole lot of failed minimum viable changes at that second state, as well. But it’s not really a failure; you’re learning where to try your first set of minimum viable changes, because you want to make sure that any large scale transformation starts with the eager adopters. Then you move on to the next state where you can validate that adoption is taking place, and finally you’ll move on to verifying that you’re getting good business outcomes or improvements in performance.
Joe: The second thing that you made me think about: Leadership changes in their role a rather than setting milestones and “this is how we’re going to go about change”- they’re getting visualization from your change to observe and coach. Is that how leadership fits into this?
Jeff: Leadership fits into this in a number of ways. The good thing with the Lean change method is we’re also making heavy use of Kanban to visualize the progress of our minimum viable changes as well as our improvement experiments, and then we use colors every time an improve experiment is correct, incorrect or partially correct we tag it with green or a yellow or red tag. Likewise, we periodically go through our minimum viable change canvases, and we go “you know what? Is this section completely wrong? The comments in this quadrant are wrong” and we start tagging those, as well. We can then have stand ups or weekly meetings in front of these artifacts and go “guys; our assumptions are incorrect, it’s time to update our canvases and update the backlog of minimum viable changes and update the back log of improvement experiments”.
We’re hoping that what we’ve done is created a change management method that’s making heavy use of information radiators so we can get the leadership more involved. If I can add one other point to ‘leadership’, there are various different kinds of minimum viable changes, and they’ll be directed against what we’re calling ‘change recipient segments’. An obvious example of a change recipient segment is a potential collocated cross functional team, but your change recipient segments could also be by level or functional specialization. We often have a minimum viable change that’s dedicated to managers and executives, used to different techniques like management 3.0, ‘Management to learn’, and other things that managers can do to help manage the system and build capability.
Joe: You used the term ‘canvas’ to explain and implement your change method. Why did you use a canvas? Is that just a buzz word? Or why not an A3?
Jeff: Absolutely! So the ‘canvas’ was made famous by Alex and Yves in their book ‘Business Model Generation’, and it was kind of like a tool for businesses to collaborate, iterate and prototype on how new, extremely innovative businesses could operate. It was then ported over to the Lean Startup world and made famous by Ash Maurya in his book ‘Running Lean’. That’s the ‘canvas’ that really inspired me. I like the Business Model Generation model as well but the Lean Canvas was really interesting to me because it talked about how to define a product in a highly uncertain market. When looking at this canvas, I noticed that there were a lot of parallels with the way start-ups co-create products with potential customers and the way change management needs to co-create change with their change recipients to create a transformation. So much so that I was able to take terms, and techniques from a change management life cycle made famous by John Kotter, known as “The 8 Steps of Change”, and match that up with the Lean Canvas to come up with something that I feel really reflects the way change management actually works.
If I contrast this to the A3, I think the real difference between the A3 and the Canvas, is that the Canvas is deliberately built to validate assumptions. You’ve got this whole notion that “my assumptions are going to be wrong until I test them”. I might need to make dramatic pivots and changes on this canvas as I go through the process. The A3 is really good technique for doing a lot of this, but it’s a little bit…it can be less visual, a little less compact, and it doesn’t have all the change management quadrant necessarily baked in. That being said; I’ve seen people use the Lean Change Method, and instead of using my canvas they went and used an A3, and then decomposed it with improvement experiments. This stuff is actually quite pluggable; you can use different pieces as you like
Joe: One of the things you talk about which I thought was unique in your book was cadence. How does cadence apply to change management?
Jeff: What’s interesting is that when we talk about cadence we’re really talking about a recurring heart beat for synchronization across various specialists. A lot of Agile methods talk about iterations, and having short iterations so you can make sure you get feedback back into the system. The idea is that the more you have, the more you can use that to regulate a process rather than having bureaucratic and overly cumbersome process definitions.
The interesting thing about Kanban and other types of Lean thinking is that they recommend that you take the concept of an iteration, and decouple the different points in the iteration. So for instance, an Agile team might say” we’re going to see what we’re going to do at the beginning of the week and then we’re going to release everything at the end of the week”. Whereas tools like Kanban say ”well why don’t we meet with the customer once a week to see what we’re going to do next, but because release is hard we’ll release once a month” and the cadences become independent of one another.
That idea can be scaled out to support any process, and in an Agile transformation there’s a lot of information going in every different direction; you’ve got to update your stakeholders, you’ve got to make sure all change recipients are kind of kept in the loop with their minimum viable changes, you’ve got to make sure that any metrics and dashboards and things are kind of shared across the organization, you’re going to have a back log of change that you’re going to want to keep fresh, and all this stuff is going in every different direction. So what we did is we came up with a cadence model where we have a suggested set of meetings, workshops, and sessions that provide advice on when to update certain Lean change artifacts. Now, that model’s really just a suggestion, and it’s taken from a case of one of the largest transformations that I was on. It might be overkill to use the number of meetings, and the number of workshops I suggested for a smaller transformation.
Joe: When we look at this, what type of companies can apply this? Do you know when a company isn’t ready for this? Is there something that’s obvious to you when you look at a company or start working with a company that they’re ready for change?
Jeff: My opinion differs from probably a lot of the Agile folks out there in that I don’t care if a company is ready for big A Agile or not. What I do care about is “can I use a mixture Lean and Agile methods and techniques to improve the way they’re delivering value now?” There is such a wide range of methods and techniques out there the answers almost always “yes” to some point. I’ve gone into some very probably conservative and dysfunctional organizations, and after a lot of effort we were able to get some level of visualization through Kanban, and some willingness to change policies and discuss policies across specializations, and that’s all we did. But that alone was a massive improvement over the way they were working before, and it’s opened up the door for them to consider some other improvements over time.
Some Agile transformation experts would say “well that you didn’t get that company to be Agile that must be a failure” and I really don’t look at it that way. When I look at Lean change, the great thing about the method is you can start really simple: you’re a team member; you’re frustrated about the way your team is delivering. You want to have an intelligent conversation around how to improve. Go and take a Change Canvas and slap it on the wall, have a discussion with your team about some potential changes you can make, and stop there. You can then step it up and say “I’m a program manager; I’ve have ten, twenty teams doing things. I’m going to go and ask them all to own their own change, and I’m going to start tracking that through the validated change life cycle, maybe using some improvement experiments, maybe not” and then finally you can take the notion of a change canvas and scale it out to what we call a transformation canvas. That is a lot like the minimum viable change canvas, but 4 times the size.
You want to get a whole lot of people in front of it to collaborate on it and use that to track an entire transformation. I think the answer really is that any technology company delivering new services and goods-they’re not in the operational world; they’re in the value creation world- they need to consider some mixture of Agile and Lean methods or they’re just going to become defunct, and they’re going to become obsolete. They can only stay in business using old methods and tools for so long.
Joe: If you were going to sum this up, what would you say is the key aspects of the Lean change method?
Jeff: There are two principles that we’ve tried to base Lean Change on. One is that while it’s a managed change method, it’s co-creative. So this principle of co-creative or negotiated change is principle to the method. It’s really important that change agents don’t build changes and then just deploy them out to the organization; they have to find their kind of either eager adopters or change champions, co-create their way through a successful change, and then goes on to the next set of change recipients and keep that process going.
The second principle is taken from the Lean start up world which is enabled through this co-creation which is the validated learning. Both the change agents, change recipients and change stakeholders have to understand the validity of their change by subjecting it to experimentation, creating a hypothesis, validating those hypothesis and being ready to pursue those change tactics if they’re working, modify them or not, or do a complete change pivot.
Joe: Jeff, when you developed this, is this your creation or did you have help?
Jeff: So Lean change was developed as a result of being on large scale Agile transformations, and actually trying to run them a little bit more effectively. It was co-created primarily by myself and fellow consultant Alexis Hui who iterated under a number of versions of the method. The method also has contributions from some of our clients who were working on some of these Agile transformations, and some key contributors include Jason Little, Andrew Annett and Bernadette Dario.
Joe: Where are the places that they could go to learn more?
Jeff: So right now the book is available on Lean Pub. It’s still in what I’ll call beta although it’s gone through a number of iterations, and I think in its current form it will be extremely useful to people who are interested in the change method, and that can be found on book Leanchangemethod.com. You can also go to my blog where I actually have a whole lot of articles talking about Lean Change and Agile, and you can find that on Leanchngemethod.com, as well.
Joe: I think you explain the Lean start-up so well. People don’t really understand the finer nuances of it.
Jeff: It’s kind of funny; when I first read about Lean Startup the big place that I missed was the validity in learning happens with co-creation with customers. Like you come out with the vision, and they tell you haven’t got the right problem, but it’s really them telling you what the problem statement is. It’s interesting; it’s ”go and extend my vision out onto the masses and see if I can iterate through the right set of customers or problem statements” and they’re telling it to you until you come up with the right one. So it’s a really interesting process.
Joe: Where do you see the Lean Change Method two years from now if you had to dream a little bit?
Jeff: Well right now what I’m trying to do is anyone who’s interested, I’m offering to do some free consulting to help them build their first canvas or start their first Lean Change Method. I really want to treat my early customers with the kind of support they need to help make this a valuable method. I’m hoping that two years from now, people will look at Lean change and say ”If I’m running a managed Agile transformation or an enterprise Lean technology transformation” a lot of them will be looking at least some aspect of Lean Change Method and using those tools. That would be great because that would mean other people are finding value in the same approaches that I find value in.
Joe: I find it very intriguing, and I thank you very much for being on the podcast today Jeff, you also can be found on LinkedIn I suppose under Jeff Anderson, and you’re in Toronto.
Jeff: You can find me on twitter at @ThomasJeffry and on LinkedIn under Jeff Anderson.
Joe: I would like to thank you very much again, and I look forward to hearing more about the Lean Change Method and even trying it out myself.
Jeff: Thanks very much Joe. I look forward very much to hearing your experience with it.
