We know that Scrum teams are a fundamental building block of the Agile approach. They are where the core work gets done to deliver the remit of the Product Owner. The guiding principle behind the Scrum team is that they are self-organizing teams. However, this does not mean that there is no need for managers in the organisation.
What is needed is the right behaviours and manager role in Agile in the right place, at the right time.
How Does a Manager’s Role Differ in:
Vertical vs horizontal management
Managing in an organisation that is fundamentally based on self-organising principles is not easy. This is particularly true if the managers have learnt their management practices and behaviours in a more traditional top-down command and control hierarchy and are used to waterfall planning. Waterfall teams follow the vertical structure of the organization. Scheduling and performance management is often “top-down,” meaning that managers set the pace and the schedule.
In an Agile environment, however, the team is self-organizing. It sets its own schedule based on priorities from the product owner and the available capacity and velocity of the team. The team follows the horizontal flow of the work down the value stream.
Command vs influence approaches of leadership
Managers and leaders have a number of critical roles in organisations deploying an Agile approach. These include setting product and service directions, making resourcing decisions, integrating across teams, and helping team members with their continuous professional development. However, where traditional management relies on top-down direct and a ‘command’ approach, management in an Agile environment relies much more on influence and trust. A command culture will hinder a team’s ability to develop self-organizing skills, which are at the heart of the value Agile brings to an organization.
Moving away from managing by control can be difficult for some managers, and learning to trust and influence can take time. However, the change in behaviour lets the manager delegate decisions to the team, freeing them to concentrate on the longer-term issues and strategy, as well as allowing them to focus on eliminating organizational barriers obstacles to the success of the Scrum teams, this in turn helps the team be more productive.
Managing work vs management as a role
When implementing an Agile approach and Scrum teams, companies are understandably hesitant to let go of the familiar management roles they’ve depended on for years. They will see this as a foundation of past success. Therefore, it is critical to remember that management is work while being a manager is a role. The activity of management will continue to exist. The question to answer is where does this work get done, and in which role?
It is easy to fall into the trap of seeing management as work that must be vertical in order to align with the function area of the team members, such as Design, Quality, Engineering, Marketing, Finance, and so on. However, in an organisation or unit that has an Agile approach, management needs to be horizontal. The manager role in Agile will need to change fundamentally, recognising that much of what has been seen as a first-level manager’s role has now been ‘devolved’ to the scrum team.
Scrum Managers vs development managers
In an Agile environment, Scrum managers and development managers are positioned between senior leadership and individual scrum teams. They work to optimize teams and individuals to deliver the best quality output that meets the unit’s goals. At the highest level, the Scrum master focuses on helping the team build velocity, whilst the Development managers focus on building and developing the team members’ skills.
| Traditional Management | The Overlap |
Agile management |
| Evaluating | Assess and deliver development needs |
Coaching |
| Controlling | Trusting | |
| Top Down Command leadership | Servant leadership | |
| Failure is embarrassing, fear of failure | Feel responsible for team performance |
Failure is a learning opportunity |
| Blame the team | Support and advocate for the team | |
| Report obstacles upwards | Remove obstacles |
Most waterfall teams are manager-centric. They look to managers to set priorities, track progress, and evaluate performance. By contrast, agile teams are self-organizing teams that own their roadmap and delivery. To make this work for larger organizations, scrum managers and development managers must work together to build an agile culture throughout the organization and act as a buffer between teams and C-level management.
Therefore, focus the scrum master on the team’s adoption and implementation of Agile ways of working. Focus the development manager on hiring the right individuals, mentoring existing team members, and ensuring that there is a culture of continuous learning in every team. Both roles by working together will foster effective high-velocity agile teams.
| Scrum Master | Development manager |
| Coordinates most of the inputs and outputs required by the team.Co-ordinate across teams | Give feedback |
| Agile coach | Professional coach & mentor |
| Drives the agile ceremonies (Sprint kick-offs, sprint reviews, etc.) and sprint planning | Choose when to intervene and when to let the team struggle and learn. |
| Integrates new recruits into the team | Initial onboarding of new recruits |
| Optimises the velocity of the team | Ask questions and vetting assumptions during estimation (Never change timelines or scope) |
When do issues arise?
With the role of Scrum managers and Development managers clear, with senior leaders driving the vision and strategic direction of the organization or unit, and with self-organizing scrum teams doing the core work to deliver the remit set by their Product Owner role, what is left to do?
In reality, not a great deal! The manager role in Agile is to ‘stay in their lane’ and help make efficiency and productivity a reality, maximizing the teams’ ability to deliver value. Agile managers do this through anticipating what their teams are going to need.
In practice, problems arise for three fundamental reasons:
- The managers step beyond their role boundary and start doing work that belongs to another role, often the work of the scrum team.
- Scrum managers don’t give enough time and attention to their glue/co-ordination role across teams. In larger projects with more than one product stream the Product Owners don’t give enough time and attention to their glue/co-ordination role across product streams.
- Under pressure, managers revert to traditional top down waterfall behaviours.
Putting in effort upfront to determine what work goes into which role boundary, and then using this framework to design the managers’ jobs in relation to the work of the scrum teams will pay dividends as implementation begins.
Peter Turgoose is a Senior Consultant at ON THE MARK, a global organisation design consulting firm and leader in collaborative business transformation with offices in the US and UK. He is a Chartered Occupational Psychologist with over 30 years of experience in applying behavioural psychology for business.
Contact ON THE MARK
Peter, This distinction between scrum master and development manager is helpful, but could be expanded a bit more. First, there is also the “organisation designer and objective setter”. This person decides whether an Scrum team is the right organisational solution for the objective at hand, decides which functions will be represented in the scrum team and sets the mission for the scrum team. Second, there is a development manager for each function represented on the scrum team. You give the impression that there is only one development manager for the whole team.
Thank you for the article. It helped me clarify my own thinking. Andrew Campbell
Hi Peter, thanks for this article. The topic of “what does the manager do in Agile/Scrum” is a great topic to write on. I resonate with these characteristics and I agree with Andrew’s note on the topic as well. But, I’d also say that the characteristics that you cite aren’t particular to Agile, in that any delivery structure benefits from a coaching, trusting, servant leadership model.
I think that much of what is discussed about managers in Agile comes from a perspective of trying to “protect a development team from bad managers.” I get it. From my experience in technical management, there appears to be a lot of bad technical managers. Of course, this is hard to discuss from my perspective, due to a lack of objectivity, because I am a technical manager. But, maybe it makes sense to understand why there are poor leadership practices by many technical managers.
1) About every 5 years, the number of software developers doubles. This means that at any point in time, 50% of all software developers have less than 5 years of experience. With this growth comes a need to manage these folks.
2) Given that most technical managers come from the ranks of software developers, the characteristics of what makes a great software developer and what makes a great manager are decidedly different. But the need for managers is great, so we get a lot of technically skilled, low experience, managers.
3) In organizations without a lot of other technical managers, there is little in the way of mentorship or leadership development for these new technical managers. Through Plato (I’m a Plato mentor), I have mentored 25 technical managers in the past year or so. None of these managers had taken even an intro leadership course or read an intro leadership book. Many of these folks have been managing groups for years…
4) Many organizations still believe that managers need to be coders. I believe this is an incredibly short sighted move, but I see this a lot. If managers are continually pushed to stay very technical, they are not going to value learning leadership concepts that will help them as leaders.
It’s no wonder we have “bad technical managers”! I believe that we have so many bad managers because they don’t know what they don’t know. I offer my version of Hanlon’s Razor, “Never attribute to malice that which can be adequately explained by ignorance.”
Getting more mentorship for new technical managers is I believe the best way of not perpetuating this problem. Platohq.com is a good place for folks to go. I also take on pro bono mentorship myself through WinningTack.
Thanks,
Dave
Hi Peter, I agree with most of your points, especially on the development manager’s supporting role. However, the image you draw of the Scrum Master with “Coordinates most of the inputs and outputs required by the team. Co-ordinate across teams”, “Drives the agile ceremonies…”, “Integrates new recruits into the team” and “Optimises the velocity of the team” is in my opinion an obstacle to the team’s self-organization. I’d prefer that the Scrum Master helps the team initially (and later on if there are impediments) to deal with those things by themselves. Here some suggestions:
“Coordinates most of the inputs and outputs required by the team. Co-ordinate across teams” —> “What”-Inputs are handled by the Product Owner. “What”-Outputs are dealt with in the Sprint Review (feedback). The “how“ between different Development Teams that work on the same product could be coordinated via e.g. Scrum of Scrums and/or a community of practice. The Scrum Master could support the team by setting up those structures and then get out of the way.
“Integrates new recruits into the team” —> Maybe aside from the Scrum theory that needs some explanation, in my experience teams can do that on their own. But the Scrum Master could support the team to come up with some kind of onboarding guide, wiki page or checklist.
“Drives the agile ceremonies…”, “Optimises the velocity of the team” —> Maybe it’s just the wording. But it should be the Scrum Master’s guiding principle to help the team doing that on their own. A Scrum Master should aim on making her- or himself redundant (even if she or he never completely is).
Just my two cents. Overall, it’s a great article. Keep up the good work!