An Agile Approach to Change Management
Many organizations are reluctant to introduce new tools or technologies, or even to update existing ones. The reason is often framed in terms of risk management. But while change brings risk, not changing can also have consequences.
A colleague once described a reluctance to explore and experiment with new tools as “not risk-averse, but risk-stupid.” Agile teams already have the tools to manage the risk of change: testing and experiments.
Having a good suite of automated tests is what enables agile code, because you can’t feel comfortable making changes if you can’t quickly identify whether the change affected behavior in an unexpected way. But even if you have a good suite of tests—which not all teams do—you are unlikely to have a comprehensive suite of tests. Sometimes gaps in test coverage are the result of poor planning or execution, but even teams that have a good testing discipline won’t and can’t test every aspect of all their code.
Incomplete test coverage is inevitable. Tests add overhead, and exhaustive testing can add time to the build and delivery process, which in itself can make your delivery less agile. There may be things that you opted not to test because it seemed overly expensive. You may also simply not have anticipated some test scenarios. Testing can help you identify when a change causes a problem with something you expected might be risky, but good test coverage is not a guarantee, especially against the risks you are not aware of.
A mindset of doing experiments can help you mitigate the gaps in risk identification that your existing testing does not identify. The key point about an experiment is that you acknowledge that the technology you are evaluating is subject to change. Rather than feeling committed to making a system work when you discover a problem, you start prepared with a strategy to undo your change.
Developers do this every day with task-level commits to our version management system. For large-scale work, this can be something as simple as deploying you application with a new version of a framework on a small number of (intensively monitored) servers and being prepared to roll back quickly. For more complex technology decisions, such as the introduction of a new language into your development tool set, you can start with a small, realistic project with acceptance criteria for what the new language will bring, areas to evaluate, and a plan for implementing the project with conventional tools.
Change can be scary, and it can be risky, and it’s important to recognize the difference between the two. Fear paralyzes you and leaves you open to the risks that happen when you do not change. Risk can be mitigated through testing and experiments. Being open to change by having an experimental mindset can help you identify the difference between fear and risk and allow you to address change rationally.
