The Power of Small Experiments

Change can be scary. Change at work is particularly threatening. After all, most of us spend more time working that doing any other single thing. Even a potentially good change, one that promises a better future, is risky. The better future might not pan out. It might be worse than the status quo. It’s that risk that makes talking someone into accepting a change so ineffective.

To gain acceptance of a proposed change, stop trying to persuade on the merits of the change. Very few changes have to be permanent, so you don’t need to convince people to accept the change forever. Instead, look at ways you can remove the risk, ways to make the change undo-able. Frame your change as an experiment that can be rolled back if it doesn’t work. Set a date to evaluate the results and make a decision whether to continue with the change or roll back. And then stick to that plan, even if the change is going overwhelmingly well. It’ll remind people that you’re trustworthy and that when you propose an experiment you really mean it—you’re not just being sneaky.

When you consider how long to make an experiment, remember that it can take 21 or more repetitions for a new practice to become a habit. Think about the learning curve associated with your change. Try to make the experiment longer than that initial learning, habit-building period.

Scrum’s sprints and retrospectives give you a nice built-in cycle for experiments. It’s easy to propose trying something for 1, 2, or 3 sprints, to be reevaluated in the corresponding retrospective. Want to adopt TDD or pair programming? Want to move QA people into your team? It doesn’t have to be permanent. Just try it for a few sprints. Maybe measure cycle time or defects while you do it. If it doesn’t work for, you can always go back to what you’re doing today. It’s just an experiment.