Agile software development becomes lean development and lean startups, and sometimes the folks who grew up in software development transition into organizational change. They bring with them ideas from software development and information technology in general to attempt to make organizational change easier. That’s what Lean Change Management: Innovative Practices for Managing Organizational Change is. It’s a guide to organizational change management from someone who grew up in software development and agile approaches.
Satir Change Model
Jason Little views change from the lens of the Virginia Satir model, which is the model he was introduced to organizational change with. The model consists of a status quo (called the late status quo) interrupted by a foreign element, which is met with resistance and chaos, until a transforming idea allows for integration and a new status quo. The model grew from Satir’s work with helping individuals change.
Little recounts his introduction as being elected as the person who resisted the change and was eventually persuaded to move to the new status quo by some crafty people who were trying to make the new status quo a reality – and who knew that Jason was a fan of Johanna Rothman, who was teaching next door and kindly came over to help Jason change.
Starting the Change
Little is clear that the change process doesn’t start on some magical date that you’ve plugged into your project management software. Your attempts to manage the change start when people begin to mumble about the change and wonder what it means to them. If change is about managing the human aspects of change, then the idea that it becomes relevant when people begin to worry makes a great deal of sense.
The Mojito Method
Little explains that his approach to change management is based on Jurgen Appelo’s Mojito Method. The short of this method is that you mix ideas from multiple industries and disciplines into something that is uniquely your own but is based on sound working practices. The approach is what many would recommend for creativity and innovation. (See Creative Confidence, The Innovator’s DNA, and Design Thinking for more on mixing ideas.)
In Little’s case, he leans on his software development background.
Lean Change Cycle
Little explains the approach to organizational change management as an extension of agile and lean principles. Things like iterate fast, create minimum viable products, and learn are at the core of the approach. He uses an iterative process like Deming’s PDCA/PDSA cycle. However, in his cycle, it starts with insights, which create options, which lead to experiments that lead to more insights. The experiments themselves can be broken into preparing, introducing, and reviewing.
The general idea is to start the process and keep iterating, and therefore learning, until you reach the success that you desire.
Little introduces another technique brought to the agile community by Stefan Haas. The culture hacking process consists of three components: the crack, the hack, and hacking zone. They are as follows:
- The Crack – The dysfunction of the organization that feels uncomfortable.
- The Hack – The action that you take to amplify the discomfort of the crack.
The Hacking Zone – The degree of danger that your hack exposes you to as follows:
- Green – Safe. These hacks aren’t a threat to you or anyone else.
- Blue – Risky. These hacks aren’t likely to get you in serious trouble but might.
- Red – Dangerous. These hacks will most certainly upset people. The question is whether they’ll fire you, label you a rogue, or accept the change.
I’ve learned through my study of learning that sometimes there’s a degree of desirable difficulty and the necessity to make it intentionally difficult to the learner – but that the difficulty must be in a very narrow band. Culture hacking seeks to make the appropriate level of discomfort overt. (See The Adult Learner and Efficiency in Learning for more on how to make learning more effective.)
At the heart of Little’s recommendations lies one of the fundamental perspectives of agile. While traditional software development and organizational change believed that you can script every move, agile believes that the kinds of problems being worked are inherently too complex to be resolved by one group doing all the planning. Agile works from the premise that everyone is a part of finding the solution, because allowing everyone to solve their own problems may lead to sub-optimal solutions for the individual instance but ultimately will result in better overall outcomes.
Said differently, agile assumes that uncertainty can’t be removed, and therefore it’s more important to adapt to the uncertainty than to try to plan around it. The Soviet system of Leninist Marxism didn’t work, because central planning wasn’t efficient enough to compete with the energy produced by capitalism.
If you’re uncertain about whether you’re ready for a change, maybe you can approach your uncertainty with Lean Change Management.