Have you ever had trouble convincing your colleagues to adopt a new technology, agree to a change in process, or modify ways of working?
It may be worth considering whether your proposal would be more successful when reframed as an experiment.
Experimentation in agile teams
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
But there isn’t always a consensus on what or how to adjust. One way of moving on from these deadlocks is to define an experiment over an agreed timescale with well defined steps and success criteria.
It is very hard to argue against a reasonable case that takes the form: “Here’s what I think we should try, this is how long we should try it for, and this is what I think it will improve. Can we just give it a go? If it doesn’t work, we can stop doing it.”
Defining an experiment
The kick-off for most experiments need consist of no more than a quick chat amongst team members to agree its purpose and scope. This typically involves clarifying:
- What you want to try
- What the anticipated benefits are
- How long the experiment will run for
- What needs to happen to deem it a success
Once complete, it is important to review the outcome. Even if the result seems obvious to all involved, there may be useful feedback about how the experiment was framed, or how the same result could have been achieved with less impact for example. Regardless of whether it has met its success criteria or not, every experiment delivers value through what we learn.
Break it down until it is safe-to-fail
Ideally experiments should be framed such that they can be safely tested. ie. the consequences of the experiment failing should not adversely effect any business critical function. This isn’t necessarily easy or possible to achieve, but by curtailing your ambition and using techniques such as sampling, you should be able to reduce the risk to an acceptable level.
Handle more complex proposals with care
If you have something in mind that is likely to be controversial or have a major impact on the team, you may want to take a more cautious approach.
Discuss your thoughts with team members over time to get feedback without asking for any kind of commitment. Be prepared to be challenged and show that you are listening to your colleagues by compromising on the detail and working through the disputed aspects of the idea. When you feel you have enough support for the experiment, put it to the team.
Not every idea will be embraced by your teammates. However, if you find that even after a lot of discussion and compromise, very few suggestions are taken on, you may need to challenge the team to get back to basic agile principles. There may be genuine reasons for the team stagnating such as imminent deadlines or excessive workload, but a focussed retrospective should help surface the underlying problem. Look for support from a Scrum Master or Agile Coach if necessary.
Isn’t all kaizen experimentation?
Teams that excel at continuous improvement constantly evaluate the impact of changes they make. They wouldn’t hesitate to reverse a decision that has had a negative impact, or further explore one that has been successful. Looking for opportunities to reduce the risk of a change comes as second nature.
For those teams, there is no difference between the approach described here and any other change to process, way of working or the codebase itself. Why wouldn’t you treat all potential improvements in this way? Just take a look at how the GitHub Engineering Team approached a recent major refactor.
It all comes down to inspect and adapt
All we are really talking about here, is the ‘inspect and adapt’ cycle that most of us came across when we first started learning about agile practices. Except that for many teams, it gets lost somewhere along the way, and instead continuous improvement is simply thought of as that regular retrospective meeting where we roll out the usual complaints.
Instead, look to champion experiments, measure the changes you make, encourage others to test their ideas so that a habit develops within the group and experimentation becomes the norm. If you haven’t trialled an idea in this way yet, how about making that your first experiment?