How much autonomy should an agile team have?

The Creation of Adam — Michelangelo

I’ve been asked (and have asked) this question many times in the past. I’ve received (and given) various different answers at different points in time, none of which I have found satisfactory.

But recently, after working with two teams that for once, seem to “get it” (if you’re wondering “get what?”, please read this), I’ve boiled the answer down to this:

An agile team should be given as much autonomy as possible without compromising on the following:

1. The team must meet their objectives and key results.
2. The team must produce work that can be maintained by future teams.
3. The team must make the status of their work transparent to the entire organization at all times.

If a team can consistently demonstrate that they can meet all three of the above criteria, then you get out of their way and let them work. Your only touch point with the team should be at the beginning of a sprint (to set expectations) and at the end of the sprint (to check if expectations were met).

If the team is still maturing, and is not yet able to consistently demonstrate the above three criteria, then you find a middle ground. If their gap is technical, you fill that. If their gap is delivery related, you fill that. You can fill the gap either…