Autonomy in agile teams

Like everything in life, balance is key; just as it is for the autonomy of agile teams. A tightly restricted environment is stifling, but too much autonomy can be dangerous.

While we’ve got to be careful about making proclamations that apply to all teams in all cases, there are some general principles we can use to guide us on this topic.

Let’s establish the main point via an example

…the military

Many folks incorrectly believe that the military is a command and control organisation – which was often true throughout history, but is largely an outdated concept in modern times where they more typically:

• Provide soldiers with the skills (e.g. training) and tools (e.g. navigation aids, weapons, logistics, etc.) they need
• Have leaders set objectives and make their expectations clear
• Leave the operational groups (i.e. soldiers) to determine the best way of achieving said objective
• Within those groups, ensure folks understand the role they each play
• Provide them with rules to guide them (and ensure they are well understood)

Which is very much like how we describe mature agile teams – but sometimes the last point is misunderstood or neglected.

An aside

For more on modern militaries, see retired General Stanley McChrystal’s book on ‘Teams of Teams’, and David Marquet’s video, which both present a very different view of the modern military to that which many of us have formed – an incorrect perception that is often influenced by old war stories.

Autonomy

Anyway, the point is that while armies have autonomy, it’s not unbound; they need to follow the Rules of Engagement (RoE) that have been established within that operational area, the Geneva Convention, International War Crimes Legislation, etc. If these things didn’t exist, then there might be anarchy and disastrous consequences (often for civilians).

While usually not as consequential, the same is true for agile teams. Failing to follow standards, reference architecture, guidelines, policies, etc. can result in poor outcomes, and is often reflective of low levels of agile maturity. Often, when organisations labour under high technical debt, it’s because teams were too free in deciding how to deliver value to customers, and employed poor engineering practices (there's obviously commentary to be made about the role of education and training in this example).

On the flip-side, being too restrictive can hamper a team’s ability to deliver, and also compromise the outcome. To stick with the military example, many military failures throughout history were due to senior commanders (who were far from the fighting) telling soldiers at the front line exactly what they should be doing (micro managing). How could they possibly know how to best achieve an objective from their disconnected, isolated perspective?

In short, the optimal balance is somewhere in the middle – and you need to work out where that is for yourselves and your circumstances – this will often happen through trial and error.

Here’s another military example – a story that I became fascinated with upon hearing it several years ago; in Iraq, the Australian SAS (an exceptionally well trained Special Forces group) took an objective without casualties by having an Air Force jet fly overhead while breaking the sound barrier and scaring the defenders into surrendering. A very creative solution to a problem that was, quite possibly, the best outcome to a situation that would have otherwise resulted in many casualties. This demonstrates how, even when governed by rules, you can still have plenty of freedom to be creative.

Principles and practices

So, what does this mean for us? Consider providing guidance to your teams on the nature of autonomy when establishing and adopting your principles, and provide further clarity to folks around your specific practices.

For example, you may establish a principle that reads something like this:

‘Our teams are closest to the customer problem, therefore they best understand how to solve it’

Which provides a clear mandate for autonomy; but we don’t want it to be unbound, so it might be accompanied by another, such as:

‘Our teams consistently produce high quality work aimed at introducing zero technical debt over the longer term’

The second helps to balance autonomy with the quality / engineering imperative.

As these sorts of statements can sometimes be too abstract, consider elaborating and articulating these into a set of finer-grained guiding principles and practices. This will help folks understand what they mean ‘on the ground’ in their day-to-day activities. This is especially useful when you are driving clear culture change where more detailed principles can help folks understand what specific behaviours are consistent / inconsistent. Here’s an example from a few years back of how Spotify broke their high-level principles into something more meaningful.

Some of the other aspects you may want to consider in balancing out Autonomy may include:

• Technical standards (for all chapters, not just Developers)
• Architecture
• Relevant legislation (e.g. privacy)
• Company polices
• Anything else that’s relevant

Conclusion

It’s sensible to properly consider what autonomy means to your organisation and your teams – and refining this over time as you learn and mature (they will not / should not stay static, and change to reflect the stage of your journey).

Remember, that…

Too much control produces poor outcomes, but so too does too little