Where are all the managers in Agile?

The heart of agile is described in the few words of the Agile Manifesto and its accompanying principles; the dominant agile framework is Scrum and its derivatives. Yet, amongst those core references, one word is conspicuous by its absence. 

Manager; Agile doesn’t talk about managers or management.

This causes considerable confusion for organisations adopting agile or attempting an agile transformation. Management is so embedded in modern business practices that its omission from agile approaches must surely be some sort of mistake. Yet it isn’t. It’s very deliberate.

So, what should organisations do?

They could trust that the authors of the manifesto and Scrum guides knew what they were talking about, and set up teams without manager roles or explicit management functions. But in practice, many will already have manager jobs and corporate expectations of management activities that need to be done.

Often, organisations swing the other way – they correct this oversight by adding in management jobs and giving those managers responsibilities (often taking them from the Scrum Master or Product Owner). Or they seek out an agile framework or approach that does include management more explicitly (like SAFe or Agile PM).

Finding the right balance

A better approach is to look for the right balance – allowing agile teams to perform at their best, while still meeting essential business needs.

This means distinguishing between necessary management and unnecessary management.

In an ideal agile team, anything that needs to be done to deliver value to the customer is the responsibility of the development team. They are self-organising and have all the necessary skills, experience and authority between them. If there are contracts to manage, people to communicate to, money to account for or people to train, then that’s just as much their job as writing code or building systems.

However, that can be a hard thing to achieve. Not everyone wants to do all those other jobs, and not everyone is particularly good at them. So, expecting the agile team to do it often doesn’t work, and those ‘management’ tasks are neglected or done poorly. To address this, many organisations put managers in or around agile teams: Project Managers, Team Leads, Development managers, and Delivery Managers. 

This can be an excellent solution to manage the things that are essential to the delivery of value to the customer, but which the agile team can’t or won’t do well. Things like tracking and managing budgets, contracts and perhaps some stakeholder communications or business change activities. These are necessary management activities.

The problem comes when those people try to manage other things – especially the goals, the people and the work. These are unnecessary things.

This is because whole team accountability is a core agile principle. Agile teams are accountable for those things themselves, and if they aren’t, good leaders and coaches will help them get there. Trying to manage these from outside disempowers the team, removing responsibility, breaking their direct connection to the business goals and making it too easy for them to just focus on the tasks rather than delivering value. 

If teams don’t need the unnecessary things managed for them, why is it so common?

One reason is that those strictly necessary things aren’t always enough to make a full-time job, or challenging enough to make the job the right grade for the people displaced from a previous development approach. Another is the misplaced assumption that technical people don’t make good managers. But it’s also because the desire to manage these elements is a natural state – people are used to classical management, where managers tell you what to work on, how you should do it and then check up on you. That’s why even the presence of another person with ‘manager’ in their job title can be enough of a nudge to cause teams to abdicate their responsibilities to that person. 

In order to counter this, identify the things that really must be managed from outside the team and decide how best to achieve them. For many of the others, leadership and strategic alignment will be required instead of ‘managing’ them.

Some other tips include:

• Start by assuming the team is accountable for everything, and nothing needs external ‘management’;
• Don’t use the word ‘Manager’ in job titles – it leads to an expectation of being managed;
• Consider using a service model for some management. Purchase services (eg financial, commercial) from an external supplier or project management office.
• For things that require dedicated effort (such as stakeholder communications or business change activities), consider bringing specialists into the team;
• Make line managers responsible for coaching and developing their staff, not tasking them;
• Focus architects and system engineers on architectural and technical leadership and coherence, not approving work or specifying approaches.

By doing this, you can provide an environment where the team can be accountable for the value and the way they do it, but be supported and enabled by experts and leaders around them. 

Enjoyed this article? Read Simon’s follow-up article ‘Where did you get that hat?‘ to find out about how leaders and managers need different approaches to create empowerment and autonomy in their Agile teams.