Many companies would like to do a better job at developing software — better quality, better delivery times, better cost / benefit. Here’s the problem, getting better means changing and change is hard.
It’s widely perceived that most of us are resistant to change. I’m not convinced of that. I think most people, including me, are resistant to being changed. Most of us want some control over, or at least input into, the change process. We resent forcible change.
Going from a legacy waterfall approach for software development toward an agile approach like Scrum, Kanban, Lean or XP involves lots of changes. As soon as the team hears about agile development, they’ll start searching the web for more information. Inevitably, they’ll read some things they like and some things they don’t. They’ll focus on the latter and so it begins — the resistance.
Resistance is difficult to overcome. You’re best approach is to do everything you can to prevent the resistance from building in the first place. How do you do that?
- Get everyone involved in the initiative to define a new, agile approach to software development. Make changes that make sense.
- Have a senior executive lead the change effort. That person needs to be actively involved not just available to help.
- Focus on values and principles first. Best practices can wait. Everyone needs to understand the reasons for change and the vision behind them.
- Emphasize that the path toward the new approach is not well-defined. It will evolve with time. Let the team determine the pace of change.
- Don’t send everyone to agile training at the beginning of the process. Training in what exactly? There needs to be some structure and definition in place before training can begin.
After getting started, use retrospectives as the primary vehicle to drive change. Retrospectives work because they involve the entire team in assessing what’s working and what’s not. Never stop changing. Make it the way business gets done.