A while back I blogged on Drive.  I’ve been meaning to revisit each theme with some observations but I’m only getting round to the first one now.

In Drive, autonomy surrounds the what, when, how and who of your working environment.  In order to get high productivity, you need to allow people do the work in the way that they want to do it.

The focus on drive is on individual motivation.  Does this also equate to team motivation – or do these two compete on some levels?

Individual Autonomy

Individual autonomy seems obvious.  If I have the freedom to do what I want, when I want to, however I want to then I will hopefully be motivated to do it well.  If I also get to choose who I do it with (or don’t do it with) this makes me happy.

The downside of autonomy is that without purpose it may lead to not being motivated on the goals of the organisation but potentially more on the personal goals of the individual.  That lack of focus may cause friction in an organisation and potentially a backlash against giving people autonomy – simply because if we reduce the autonomy we reduce the waste of doing the wrong thing.

The solution is clear – find purpose and enthuse people with mastery over their work.  Without that there is risk that the autonomy means that I feel okay to be unproductive when I don’t have the motivation and drive that I need.

Team Autonomy

Scrum teams should be largely autonomous.  That is what self-organisation is all about.  But some of what makes a team potentially contradicts the individual’s autonomy.  Is this a contradiction?  Or do we just widen the scope and focus on the team as the individual?


A Scrum team gets to choose what it works on – by pulling from the backlog – and how much it works on – by limiting the number of stories in the sprint.  Obviously the constraints are limited to what is on the backlog.  This ensures the focus is on the organisation’s goals while limiting the autonomy over what.

A Scrum team also gets to determine retrospective actions that it takes into a sprint.  This allows the team some choice as to what to work on – alongside the constraint of the backlog.

Individuals in the team get to choose what to work on – though preferably the next highest priority story on the board.  The tasks within the story are not allocated so team members may choose what to work on – as long as it contributes to the completion of the story.


I suspect most collocated Scrum teams don’t get as much say over when they do the work.  The goal of collocation is to enable the team to work as a cohesive unit.  The individuals usually get less of an option of doing 24 hours of solid work and taking the next 2 working days off – as they need to decide to do that as a team.  The “when” is determined by the working agreements of the team.

Everyone should be working during the time of the stand-up – or come up with a working agreement of how else to deal with that.  The same would occur with sprint planning, reviews and retrospectives.  These activities are team activities that the team can decide when to do them as a group.  The individual has to work with what the team decides.

Activities like pairing also reduce the autonomy of when an individual can work as they need to work with their pair at the same time – otherwise it isn’t pairing 🙂

Individual autonomy around when to do the work can contradict the team’s need for when the team needs to work together.  This can be solved with working agreements, but those working agreements are team decided artefacts so clearly there is compromise and the autonomy of the individual may take more of a back seat to the autonomy of the team.


A scrum team is always responsible for how the work gets done.  This is clear.  The only conflict that can exist is when individuals have differences of opinion on how the work should get done in the team.  But this is more a general team dysfunction than an autonomy issue.


Clearly a Scrum team doesn’t get to decide who they work with on a daily basis.  They are a team and should be working together.  If there is a team dysfunction then the team make-up may change to resolve the issue.  The general concept of teams disbanding and swarming into teams on the fly to solve problems isn’t a goal of Scrum.  Scrum promotes team cohesion by having the goal of not changing the team make-up.  So the individual has less choice over who they work with on a daily basis.

However the individuals do get a choice over who to pair with and who to help and work closely with.  But the goal of a team would for all individuals to be comfortable in doing this with all the other team members.

There are mechanisms that can be put into place to increase a team’s autonomy around whom they work with.  If they are involved with the hiring process – either with interviews or meeting the candidates – they can make active choices about the people they work with.  I have read an article around teams allowed to make the choice to request a team member to leave via a voting mechanism – a kind of Scrum Survivor.  It is also possible that over the longer term you might want to allow teams to disband and reform when a project is coming to an end to increase the autonomy of who the individuals work with.  That does come with the risk redoing the forming / storming / norming / performing cycle.  But it could be interesting to see the outcome.

Team autonomy

Clearly teams can be autonomous – and should be in Scrum.  Some of what a team is does however conflict a little with individual autonomy.  Find the right team members and this won’t be a problem.  Find the wrong ones and there may be conflict instead of the necessary compromise to make any team awesomely motivated and driven.

On a personal note

In the organisations that I’ve worked I’ve generally had a good amount of autonomy.  And with that I’ve felt a high level of responsibility.

I have found that often the what is relatively high level and the how has lots of freedom.  The who is always constrained by the organisation’s operational abilities – such as how they are allocating people – to clients or to projects that are internal.  In internal development on a project or product there is generally a higher degree of mobility between projects – as it is all accounting – but if there is a single product there may be a smaller degree of mobility across different types of work.  In outsource coding organisations there is often a higher mobility in different types of work (given the constraints of work coming to an end) but less mobility simply when you want to move.

When you work is always determined by the organisation’s culture.  If you need to log hours that influences the when as well as work becomes accounting based and not outcomes based.  My experience of the organisations I have worked with the when has always been good – other than any after-hours support that may occur in a given organisation.

Is autonomy important?

Autonomy is a key ingredient.  But when the other ingredients are missing – particularly purpose – then autonomy can become a double edged sword – providing productivity but also reducing it when the focus is in another direction other than the direction the organisation needs to move.

Scrum teams do not contradict individual autonomy.  The autonomy of the team should be respected.  Individuals should compromise with the team in order to ensure they retain sufficient autonomy while ensuring the team is a cohesive working unit that is greater than the sum of the individuals.

4 comments on “Autonomy

  1. Aslam Khan says:

    Hi Patrick

    I’d be keen to see a matrix of “autonomy characteristics” (like that above) against a list of specific teams, and then tick off the intersections to see team “maturity” or which properties are most common.

    I’m being quite a sceptic here but with Scrum teams that I’ve worked with, the extreme minority even have autonomy of choice (what, and who).

    — Aslam

    • patrickvine says:

      Hi Aslam,

      That would be an interesting matrix indeed. We’d need to work out what factors show that they team has any power over the what, who, etc. But once you have that you could possibly ask probing questions in a similar way as Scrum Sense’s agile maturity questionairre (I’m not sure that is what they call it… but that thing that Marius used at many org in the US/Canada :>) Something to think on.

      I would agree that most Scrum teams have little to no autonomy over who. The only thing they can do anything about with respect to the who is within the team which I’m not sure is the point. Or if there are integration points – working with another team. For instance most organisations assemble a team – they don’t ask the team to self form. The team usually doesn’t actually get to fire the PO, SM or other team members. If you did – there might be far more autonomy over whom.

      In terms of the what – my experience is that the backlog comes from the PO and usually stuff that isn’t front and center is ignored. This is great focus but ignores the realities of things that need doing to make sure you don’t make a ball of mud or would help you to move faster. I suspect this also is a maturity thing. There is another blog post in this as I’ve seen it many times in terms of backlog being one thing while expections being another – of course we need to do the scalability or other old issues but it can’t go on the backlog to plan it…

      My initial question for myself when writing this post was can a team acheive that to start of with. I think that possibly they can – within limits. But in my experience the vast majority don’t.


  2. […] Pink’s book Drive are autonomy, mastery and purpose.  I’ve previously blogged on autonomy.  This time around I wanted to throw some thoughts about around Purpose – in a Scrum team, […]

  3. […] been meaning to come back to this topic for a while – closing the loop on Daniel Pink’s Autonomy, Mastery and Purpose theme from his book Drive.  Now that I’m doing it I’ve realised that I […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s