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.