The managers role within agile – part 1: along came an agile process

When an organisation attempts to adopt agile practices with their focus on team responsibility and self management a question you normally hear is so what does a manager do in the agile world?

Just recently this seems to have been a hot topic with many blog posts and articles published on the web about this very subject so I thought it worthwhile to put my thoughts down.

Before we had agile

It is worthwhile taking the time to look back to before we had agile concepts/processes and to remind ourselves what a manager has traditionally done so that we can better understand their role in today's agile environment.

So lets look at what a manager would be expected to have responsibility for:

1. Interfacing between the team and the rest of the organisation
2. Managing work available for the team
3. Overcome issues stopping the team from working (impediments)
4. Handling team administration (KPI’s etc)
5. Technical expert
6. People management

We can see that the managers role is multi-facetted, one moment they are  handling who does what work, then needing to ensure KPI’s and statistics are up to date, then meeting with the business to discuss forthcoming work for the team, finding the resolution to a technical problem the team have and finally dealing with any people issues (poor performance, frustration at lack of career progress, etc).

Another key point to remember at this point is that in the traditional environment the focus is on the manager to deliver not the team; it is the manager that will be put directly under pressure and dependent upon the organisation they may or may not be able to alter deadlines/milestones on a project, or what is to be delivered, if struggling to keep to a project schedule.

When you look at it like this it is a lot for any one person to try and take on especially if the manager hasn’t been given any specific training in how to manage and not forgetting that they have most likely been promoted from a technical role that has nothing to do with management.

Given all of the above you can see how the Command & Control management style is popular, the person doing the managing needs to be able to tell the people they had responsibility for/authority over to do what needed to be done so that they themselves can move on to the next task that they needed to accomplish.

Then came agile

Agile processes such as Scrum, XP, DSDM, etc came about because of the way that software development was managed.

The main difference in an agile process to your traditional process is changing the focus from the manager to the team, it becomes the team that is responsible for delivering the work but it is also the team that is able to decide what work they are able to do (pull based working). This in itself is a huge leap forward as the team is looking to create sustainable delivery to enable better planning and scheduling of work.

In edition to this new roles appeared to do the work that had previously been handled only by the manager spreading the responsibility amongst more people.  Some people at this point say ‘but surely that would cause chaos, no one person is aware of everything that is happening’ but in the agile world lots of people know what is happening: the team, the ScrumMaster, the product owner and in fact anybody that wants to know what's going on should simply be able to look at the team board.

This reliance on a single person is one of the fundamental weakness of traditional management and in extreme cases creating a single point of failure where if the manager is not around/available the team may not be able to do/continue work as they need a decision from the manager before continuing.

So what roles having been added? Taking scrum as an example we have 3 new roles:

1. Customer – the person that ultimately wants the work
2. Product Owner – the person that liaises with the Customer to determine what is required and then is responsible for working with the team to schedule the work to be done.
3. ScrumMaster – the person that looks after the process for getting work done, handles process admin for the team such as KPIs like velocity.

These roles separate and specialise responsibilities always with the aim of supporting the team to ensure that the work is available for the team to pull in.

If we go back to our list of manager responsibilities we can which role within agile handles that particular responsibility:

1. Interfacing between the team and the rest of the organisation – Team
2. Managing work available for the team – Product Owner with Customer
3. Overcome issues stopping the team from working (impediments) - ScrumMaster
4. Handling team administration (KPIs etc) – ScrumMaster
5. Technical expert - Team
6. People management - ?

These are fairly sweeping generalisations but illustrate that in agile the load has been spread across different people, making things more robust (no single point of failure) and allowing people to focus on what their responsibility is help ‘feed’ the team with work and to ensure that the team has sufficient work to do.

From our list the only item we haven’t attributed to a new role is the people management aspect of the managers role which in most part agile processes haven’t touched as they are more concerned with getting the work done.

Next time…

In this post I’ve outlined what a manager has traditionally done and how agile processes have affected the role, in the next post I’ll go into what being a manager entails in an agile environment.