The managers role within agile – part 2: the agile manager

In my first post I outlined what a manager did in a traditional environment and how agile processes changed that.  Now I’m going to outline how the role has changed and the responsibilities a manager has when an agile process has been implemented.

What do I do?

When an organisation begins to try and implement an agile process it is most often the managers that worry the most about what their role will be once the new roles and responsibilities have been explained, this maybe acerbated by the organisation getting excited about the self-managing team and saying that there is no need for managers.

The actual role a manager plays will very much depend upon the organisation that they work for and the amount of agile adoption that the organisation wishes to achieve.  Frequently an organisation will simply replace existing project management processes with agile processes but as I mentioned in the previous post this isn’t all a manager does.

Just to recap the responsibilities that I identified a manager as having, and the scrum roles that take on those responsibilities are:

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 - ?

So in a new agile environment we can say with a fair amount of confidence that in most organisations the manager will still have responsibility for people management, the exact nature of this may change slightly but is likely to fall to the manager.

There are some organisations that do give the people management to the team so that they are completely self managing but I believe that it depends on the organisation, most larger organisations are setup with
HR departments/processes that have to be followed outside of processes for work an exception to this is somewhere like Google where annual reviews have been done away with completely

The Facilitator

People management is not the only responsibility that the manager will have, within agile a managers role is best described as a facilitator - helping the organisation, but more importantly the team, adopt and use agile processes and practices.

Although the manager may have had a lot of their previous responsibility moved to other roles the task of helping adopt agile is not a small one Henrik Kniberg in his presentation The Manager’s Role in Scrum says that the manager can be ‘the best catalyst or the worst impediment’ showing their importance in the adoption of agile practices.

As a facilitator the manager should be focused on helping the team get the work done and doing whatever is needed by the team to allow them to complete the work, in my earlier post Scrum Pain Points & Resolution - Management I listed of some of the tasks a manager may undertake as a facilitator some of which I’m going to expand on below plus a couple of extra behaviours.

Communicator

In larger organisations where steering committees et al are the norm then the manager may be the person that will be communicating with these committees or simply senior management.

It is vitally important that a manager in this position is engaged and believes in the process of adopting agile practices, if the manager is not engaged it will be apparent to the other people that  the manager talks to and can lead to difficulties for the team as the agile practices may well be questioned.

The manager needs to be an evangelist going to the rest of the organisation and telling them how good agile is and why they should be doing it – this isn’t spin this is just explaining how the system works and showing how the team is delivering as a result.

Servant-Leader

To work successfully in an agile process the manager needs to take a leaf out of the ScrumMasters book and become servant-leader to the team, this can be a very big hurdle for a lot of managers who have been used to Command & Control (C2) as suddenly they aren’t the one who is making the decisions.

I believe more than any other reason that it is managers who have difficulty doing this that causes the most problems for a team trying to move to agile working. 

This can of course be exacerbated by more senior management continuing to try and work in the way they always have, C2,  leaving the manager stuck in the middle. A succinct example of this can be found in  Manager 2.0: The Role of the Manager in Scrum with the tale of Francis a manager who tries to be agile but with pressures from his manager Simon reverts to C2 practices.

Trust

There are frequently problems in agile adoptions simply because a manager will not ‘let go’ and trust the team to do what is needed,  depending upon the type of manager this can either be the hardest thing in the world or business as normal.  Even in C2 type organisations you have managers that trust their team and leave them to be fairly autonomous and there are managers that don’t trust their team and micromanage them.

An agile team is built on trust – team members trust one another to deliver the work to the standard that is expected, the team trust the Product Owner to ensure the backlog is prioritised correctly, etc  and the manager needs to trust that the team is doing the right thing and this links to taking up a servant-leader type role.

If the trust is lost for whatever reason then it can take a lot of time (and effort) to rebuild this trust.  The biggest problem in lose of trust is it can be the start of a slippery slope back towards C2 and you will most likely see the morale of the team drop as you head down that slope.

Trust the team will do what is necessary, yes they make mistakes but through the retrospective process you should see them address the failures and come out with actions to prevent those failures in the future.

Sara Ford a program manager for Microsoft has a very good blog post around this subject How I Learned to Program Manage an Agile Team after 6 years of Waterfall

Support

For a fledging agile team it is crucial that the manager support them, the team may have no experience with agile processes and practices and therefore will need the manager to help them while they get to grips with what it is they need to do. If somebody questions the way work is now being done the manager must defend the team, if they don’t the agile adoption could be in jeopardy as it is likely that the team will be told how to do the work most likely reverting back to old non-agile practices e.g. TDD is taking too long so stop doing it and test once you’ve completed the development.

For a more experienced team that has being doing agile for a while and is comfortable with the practices and processes the support will be different, its then all about helping the ScrumMaster to remove impediments, working with the Product Owner(s) to help them with their backlogs, etc.  This is still very important to the team as it frees them from resolving issues that takes time away from their primary activity which is should be developing software.

Summary

Over the two posts I’ve outlined the differences between the traditional managers role and the managers role within an agile process and specifically in this post I’ve elaborated on some of what I see as the key tasks and behaviours of a manager working with an agile team.

Hopefully you can see a manager is very far from redundant in an agile process but that the same time the role is completely different from a traditional management environment and that a manager needs to change their behaviour to be able to help the team to succeed.

Resources

I’ve not managed to find many online articles specifically about managers in agile but I recommend looking at The Manager’s Role in Scrum by Henrik Kniberg and The Agile Manager by Roman Pichler both of which are slide decks from presentations that they have given on this subject. The one article I have found which is referenced in many different places is Manager 2.0: The Role of the Manager in Scrum by Pete Deemer, I mentioned this in the section under servant-leader but linked to the InfoQ article rather than the pdf as this second link does.

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.