Where is your comfort zone?
Everyone has (at least) one. It’s the place where you feel confident and comfortable. Once you’ve done something several times, you develop a comfort zone around it. That’s good — and bad.
The good part is that your comfort zone helps you develop a specialty. You get good at something and then you master it — all the while safe and in control within your comfort zone. You’re an expert when you’re in the zone. But eventually, it’s time to change.
That’s when your comfort zone becomes a liability. You get nervous about moving outside your zone. It feels uncomfortable and even unnatural. As the difference between what’s inside your comfort zone and what’s outside it grows, your stress level will too.
This reasoning applies to any business or software development process. Changing the way the team operates will push some or all of the team members outside their comfort zones. Making a major change to the process will push most people far beyond the limits of their comfort zones.
Examples of Major Development Process Changes
- Going from standard waterfall development to agile software development
- Moving from small-scale software projects to enterprise-scale projects
- Making major changes to technologies and tools (e.g. moving from .Net to Java)
- Evolving from centrally-controlled teams to self-organized ones
- Migrating from a document-centric approach to a working-software-centric one
You get the idea. Any of these situations will push the limits of the team’s comfort zone and create stress. If you want to succeed, you’ll need to work at expanding the team’s comfort zone. There are two fundamental ways to proceed.
Evolutionary Change
This involves making a few small changes, letting things settle down a little, then making a few more small changes, etc. Today’s “as-is” process evolves to tomorrow’s “to-be” process.
The approach makes sense though it carries a major risk factor. After a few change cycles, the team will have broadened its comfort zone and may feel that the newly evolved situation is “good enough”. If that happens, change will stop and the team will never achieve its envisioned potential
The way to avoid that premature ending is to lay out a change plan and communicate it early. Then keep reinforcing the plan each time new steps are taken so that everyone accepts the idea that more changes are coming.
The plan should not be too detailed. You want the flexibility to make adjustments as you go. You simply need enough detail for everyone to envision what the “to-be” environment will be like.
Revolutionary Change
Conversely, you can implement the “to-be” process immediately and deal with all the consequences up front. This is simpler in some ways because there are no interim states to worry about — one giant leap and you’re there.
The major risk with this approach lies in dealing with possible pandemonium. The “to-be” state could be chaotic at first and nerves could be frayed.
You may be tempted to analyze every possibility ahead of time and plan for every contingency. Clearly, you need to do some of that but I recommend placing more emphasis on communication and understanding.
Communicate what is being changed and why. Communicate that you expect problems. (To be clear: Don’t say that problems “may occur”. Say they “will occur”.)
Demonstrate understanding and compassion. When (not if) problems happen, don’t look for someone to blame. State that you expected the problem and you welcome it because everyone will learn and improve by solving problems.
The path you choose will depend on the scope and scale of the planned changes along with the risk tolerance of your company culture. Either way, stop agonizing and start changing.