Accepting change is hard. Getting other people to change is even harder. The hardest of all is getting change to last. Often, transformation efforts last only as long as the change agents are around; teams revert back to their old behaviors when they leave. This has a lot to do with confidence and buy-in. Change is usually rushed, and forced by “experts” who use phrases like “trust me” or “this is industry standard”. With a rushed process, it is easy for people to resist change, thinking that the change does not apply to their culture, problem or domain. But with some extra time, commitment, relationship building, and empathy, lasting change is possible.
I knew a team who brought consultants in while they rebuilt their e-commerce site. For the whole rewrite, consultants, employees and contractors worked side-by-side. The consultants taught agile practices while they helped deliver the project. It was a resounding success. Six months after the consulting money dried up and everybody rolled off, they asked my team to asses the situation. Their team had doubled in size but was struggling to keep up with the work. We discovered that as soon as the consultants left, they team reverted to their old processes and practices. Somehow, even after launching a successful project, they had not internalized the changes and were struggling again.
I was once brought into a pretty complicated consulting engagement. The client team had been struggling to keep up with basic maintenance of a legacy codebase and had very little chance of implementing some required new functionality on time. They hired a management consulting firm to manage the project and update their processes to get back on track. A process change was not enough, so the firm brought my team in to double the number of developers for a combined deliver-and-transform engagement. The firm decided to reconfigure the workspace, add new developers, mandate a change to an agile process, and roll out the new schedule all on the same Monday. They called it “shock and awe”. Fast forward a year. We delivered on time, but it cost the client half their team in attrition, extra money in budget overruns, and too many nights and weekends. And three months later, when we were all gone, they were back to waterfall.
So far, I am painting a pretty bleak picture of successful change. These failed attempts taught me some important lessons. All of these failures have a few things in common: First, they were rushed. Second, the people impacted did not believe in the value of the change. Third, it was assumed that “industry standard” practices would work in each case, without assessing the practicality of applying the new process to the team. I now believe that lasting change happens in three phases:
1. Prove it: The expert takes a hands-on approach and executes the new process.
2. Teach it: The expert pairs with or coaches the team on the process.
3. Hand it off: The expert backs off but provides advice and answers questions
Rush or skip any phase and your change will only last as long as you are there to force it, but if you make it to the end of phase 3, you should have a team that is fully bought-in, believing in the change, and skilled enough in the new practice to keep it around.
Phase 1: Prove it
The first phase of change is both the most important, and also the most often skipped or ignored. This phase has two main objectives: first, tune the process to the particular team, situation and local conditions, and second, start to build confidence in the change.
Learning about a new team, application, and organization can take some time. Adapting a process to that team may require a few iterations. Frequently, these adaptations are done while trying to teach the process to the team. While failure is part of learning, seeing the expert fail is not confidence-inspiring. It is better at this point to err on the side of a bit of opacity, revealing the process to the team when it is clear that it will be successful.
At the same time, getting input from the team is essential to success. Use this time to build trust and start laying out the case for making a change. Get input on pain points and frustrations and make sure that the new process addresses these, even if some are tangential to the main change. The more that you can relate the work you are doing to the team on the ground, the easier the next two phases will be.
Once you have what appears to be a working process, pressure test it. Put it in action for an short time, maybe an iteration or small project. Make it clear to the team that if it does not work they are free to return to their previous process. If your change is really valuable, the value will be demonstrated and the team will want to keep it. In the best case, the team will be excited and ask you to move to phase 2. In the worst, you fail fast, admit that the change needs refinement, and try again.
Phase 2: Teach it
Once the change process has been refined and tested, it is time to pass on ownership of the change. This phase is often where change starts, but without the benefits of the refinement and trust built in Phase 1. In this phase, one or more team members should be selected to learn and champion the change. Using what you learned of the team in Phase 1, choose champions that are engaged and open-minded. Spend time teaching them the process and time paring with them on the tasks and practices that they will need to do in the future. Avoid doing all of the work for them, but do not put too much pressure on them to get it right the first time through.
This phase should last as long as it takes for the champions to be comfortable and fully bought in on the change. Stay open to input and feel free to refine the process to match the evolving skills and comfort level of the team. As you progress, the champions should need you less and less. This opens the opportunity to create additional champions or transition to Phase 3.
Phase 3: Hand it off
By this point, the champions should not only be familiar with the new process, they should be evangelizing it to their teammates. When this begins, it is time for you to extract yourself from the process and take a purely advisory role. Inevitably, new situations will develop, and the team will need you to advise them on how the process evolves. Make sure to let the champions resolve as much as they can but keep the confidence of the team up. Small failures are unavoidable and healthy, as long as they do not snowball into large failures that will shake the team’s faith in the change.
Take an opportunity during this phase to step back and assess what will happen when you have moved on to something new. Will this team maintain the new process? Do they believe in the value of the change? Are they engaged or simply going through the motions? The answers to these will be the difference between a temporary change and a lasting transformation.
Epilogue
I have been refining this article for almost a year now, and in the first few drafts I did not have a positive story to reinforce this as a viable method for bringing lasting change. I can now report that I have had the chance to get through Phase 3 on one significant occasion, and have a few other change efforts in Phase 2 today.
My most successful change took place with a small development team that I worked on for a few months. They had struggled for some time to delivery a complex (and complicated) piece of software. I helped refine their user story authoring and workflow management processes. I started by writing the first batch of stories before recruiting a champion. I spent a few iterations with him, at first doing most of the writing but ultimately transitioning to reviewing the stories that he wrote. By the end of the project, I was merely relaying conversations that I had with the product owner and the stories were written and executed by the team with little attention from me. I left the team at the conclusion of the project, but kept up with some of the team members. They applied what they learned to their next few contracts and continued to deliver on time and under budget.
Kevin Hickey's Blog 