Skip to main content

Evolution of the Agile Manager

June 12, 2017

How will the role of the Manager change in an Agile organisation?
This is a question that keeps every Manager busy when they start their Agile journey.
In this blog I describe the pattern of a changing management style. The behaviour is based on my observations when coaching the Agile Manager.

The Pattern of an Agile Manager

A crucial part of an Agile transition is the mindset and acting of the Manager.
Many Managers have a hard time changing. Not because they don’t want to change, but mostly because the world around them isn’t ready for it.
Agile Managers need teams to self-organise. Especially when it comes to operational, detailed, day to day activities. Daily, operational work is too complex to be involved in every detail.
However, self-organisation doesn’t just happen overnight!
Agile Managers need to create an environment where people\teams organise themselves. Traditional management roles will evolve into leadership roles.
The pattern below describes 5 stages. In every stage the Manager changes behaviour and lets go of an old behaviour.

Expected Benefits of an Agile Manager












Each of the stages has a relation to the maturity-level of the Scrum team. An Agile Manager cannot grow when the Scrum Master, Product Owner, and Developers are not growing along.

The Director

The Director










The Director wants to be in control. He has a highly directive management style and tells people what to do; sometimes, even how to do it. The Director compares a Scrum Team with a factory or an execution-machine.
The organisation is a top-down hierarchy. Plans are made at the top of the hierarchy. The Director makes sure that people below in the hierarchy (Product Owners included) focus on execution.

The Director gives people individual targets to ensure efficiency, quality, and responsibility for the outcome.
Profit and shareholder happiness are the main measurements of progress. Teams commit to time, scope, and budget to make sure plans are executed.
Directors in a transition to the next stage have difficulties, since:

  • The whole organisation is so used to this management style that it is very hard to change it.
  • Targets are still efficiency\shareholder driven.
  • People in (Scrum) teams are not used to self-management (although they might be open to it).
  • Teams aren’t stable enough to continuously learn and become self-management.

The Influencer

The Influencer









Being a Director in a world with uncertainty and change is stressful. At some point, he needs to delegate stuff to people he can trust. That’s the moment where Directors become Influencers. A Manager needs some maturity from the Scrum Masters, Product Owners, and Developers to make that shift.
The Influencer still has a need for control. He still makes the top-down plan and then tries to get buy-in on these plans.
Once he has buy-in, he delegates the less critical tasks. In this way the Influencer can focus on escalations and high important\long term decision making:

  • The Influencer delegates Planning execution to the Product Owner.
  • Product Owners have to provide frequent progress reports.
  • The Influencer imposes improvements on Scrum Masters by providing guidelines on processes and tools.
  • The Influencer ensures quality by setting up predefined standards for the teams.
  • He challenges teams to increase their velocity.
  • He adds extra resources if this is not possible.

As a result of delegating work, people will start to feel responsible for some of the work. The Influencer creates more room for self-management, but people still struggle to get in control.

The Facilitator

The Facilitator










When Scrum Masters succeed in building good teams, standards and responsibility grow. An Influencer needs this to feel comfortable enough to delegate more work and responsibilities. Influencers turn into Facilitators when this happens.
The focus of the Facilitator shifts from staying in control\ensuring compliance towards keeping employees and customers happy.
The Facilitator takes strategic decisions, but leaves the details to consensus and mutual agreement:

  • Planning decisions are an agreement between Product Owners, stakeholders and himself.
  • Product Owners become the spokesmen to customers and stakeholders.
  • He tracks progress by frequently visiting Sprint Reviews.
  • In Sprint Reviews he participates as a stakeholder or helps stakeholders to make the right decisions.
  • He provides the boundary conditions for teams to set up their own quality-practices.
  • He uses velocity as an indicator for fixing issues instead of enforcing it to the team.

The directive management style of the Facilitator management has changed into a supportive approach.
People feel responsible and in control. They now want full control over their work.

The Advisor

The Advisor










Once the Facilitator dares to let go of critical decision making he becomes an Advisor.
In this stage he only gives advice. Decisions are made by the people doing the work:

  • Scrum Masters decide on the processes, tools and improvements to be made.
  • The Advisor consults or helps the Scrum Master in solving difficult problems.
  • Product Owners decide on product planning & stakeholder management. The Advisor has no need to be in between.
  • Instead, he facilitates interaction between Product Owners, Stakeholders, and Developers.
  • Developers are responsible for the quality and how they do their work (using the Definition of Done).
  • The Advisor facilitates the Developer to get the resources for building high-quality products.

There is a big overlap in the work of a Scrum Master and an Advisor. While the Scrum Master is focussed on coaching the teams, Advisors coach the Scrum Masters and\or Product Owners.
Once in a while, the Advisor inquires if decisions do not lead to issues. He is still responsible for budgeting but leaves the decision making with the people doing the work.

The Servant Leader

The Servant Leader










Mature Scrum teams feel ownership for the full value chain. The Servant Leader feels safe enough to hand over full control to these teams. Instead, he has a holarchical view of the organisation, while teams continuously improve on their own level in the holarchy.
This is what real self-management looks like:

  • Developers are responsible for product quality.
  • The Servant Leader randomly samples if customers are satisfied with the quality.
  • Product Owners are responsible for budgets, profit, and loss of their product.
  • Scrum Masters are responsible for the continuous improvement of the team and the organisation.
  • The Servant Leader facilitates entrepreneurship for every employee.
  • He makes sure everyone in the organisation has focus on creating customer value.
  • He focuses on capturing opportunities, solving problems, and getting results.

The Servant Leader provides guidance, possibilities, and resources for new\unexperienced people to grow as a professional.
The major responsibility of the Servant Leader is to prevent the environment from re-creating old paradigms. Employees need enough room for experimenting with the values in the Agile manifesto.

Tips for the Agile Manager

Traditional Managers have a hard time becoming Agile leaders since many organisations still run on old, top-down, directive paradigms.
A Servant Leader stands out by breaking through these political power-hierarchies.
A few tips if you are planning to walk this path yourself:

  • If you work in an organisation that is still based on these old paradigms, make sure that you are supported by ‘someone above’.
  • It is often easier to become a Servant Leader in a small organisation. If your organisation grows, make sure that new employees also become Servant Leaders.
  • Focus on growing people....You can't do this alone! You need Product Owners, Scrum Masters and Developers to grow with you.

Curious on how a Scrum Master grows? Have a look at this blog: Evolution of the Scrum Master
Curious on how a Product Owner grows? Have a look at this blog: Evolution of the Product Owner
Curious on how a Developer grows? Have a look at this blog: Evolution of the Development Team

Looking for more reads\background information on this topic:

What did you think about this post?