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.