Agile Servant Leadership and the Manager


In the 1950’s and 60’s, Taiichi Ohno, following W. Edwards Deming’s ideas, built what became the successful Toyota Product System (TPS). In part, the success of TPS was using workers to improve the system of processes and procedures. TPS ensures people are sufficiently empowered to make the necessary changes for improvement.

Deming’s 14 principles for management suggests the manager’s role is to provide support and remove barriers impeding the team. Both W. Edwards Deming and Taiichi Ohno saw change as vital to increased productivity. Agile and Scrum have their roots in these Lean Manufacturing concepts and practices.

Most businesses have structures in place where managers are given responsibilities to meet production and delivery goals. Agile attempts to give teams the responsibility for meeting production and delivery goals. Managers are still needed to run the business but their relationship changes from one of control to one of helping and serving the team, to become Servant Leaders.

Servant Leadership was coined by Robert Greenleaf in 1970 and is defined as “The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first.”

Servant Leadership and how the traditional manager can begin their transformation to Servant Leader starts with a single request for help.

An Example of How Servant Leadership Fits In

Team Lead, I have a problem

Assume a team member in a new Agile Team asks a traditional Command & Control Team Lead for help. What you’d see is the manager quickly assess the situation and tell the team member what they need to do. In a C&C environment, this is the quickest way to get the team member moving forward again. The team member’s happy because their immediate problem is solved. The Team Leader’s happy because he’s keeping the project moving in the right direction. The business managers are happy because a potential impediment has been removed. So, if everyone’s happy, why would we need to change? Unless you’re looking to have different outcomes, there’s really no reason to change.

But lots of businesses want to continually improve.

Using Agile to improve

When the team member first had the problem, they didn’t rely on teammates, they went directly to the expert, the Team Lead. From Tuckman’s stages of team development, the Agile team is still Forming. The desired outcome in the Forming stage includes things like:

  • gaining an understanding of the team’s purpose,
  • determining how the team will be organized and who will be responsible for what,
  • discovering what resources will be available for the team to use, and
  • developing general team rules.

When the expert provides the answer to the team member, they address none of these objectives of team building. The manager provides the means to progress but the team is not better off for it. The team member doesn’t improve as a person. They don’t learn any new ways of thinking or new approaches to problem solving. In fact, the team member learned the manager is the problem solver, not themselves. Although the team member would probably be able to solve an identical problem in the future, he might struggle with even a slightly different problem.

The manager can also help Agile team members to understand the power of the team. Had the team member approached the team with the problem, they may may of found a solution. There’s a study, “Groups Perform Better than the Best Individuals at Solving Complex Problems“, illustrating that groups solve problems better and faster than individuals. The team’s collective experiences and differing points of view would most likely have found a way. The Scrum Team is the model of diversity whose makeup often consists of user experience designers, coders, testers, a product owner, and business analysis.

The traditional manager is following a C&C technique, providing little or no decision-making authority to the team. Let’s look at the same situation but through the lens of a Servant Leader. The Servant Leader would be empowering, nurturing, and supportive of the team despite the extra time it will take. The Servant Leader will help solve problems through mentoring and empowering the team to make decisions. Teaching the team how to think through problems for themselves is the measure of success. The manager as Servant Leader can help team members break down problems by showing them the techniques the manager himself uses. This gives the “environment and support” to the team to grow and improve.

Enter Agile Principles

The twelve Agile Principles form a set of guiding concepts that support teams implementing Agile within their projects. Marc Bless wrote an excellent analysis of each of the twelve principles but we’ll focus on principle number 5,

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

When a project manager, line manager, or Team Lead puts themselves into the position of authority, they’re not actually giving the team the “environment and support” they need to become leaders. And if managers feel an obligation to ‘tell’ the team how to do their work, there’s little “trust[ing] them to get the job done.”

Decision Making

A while ago I was asked by an Agile Team to help them improve using Scrum and the Agile Principles. This Team included a Team Lead, responsible for evaluating team members, doing salary reviews, and guiding their careers. Additionally, the Team Lead did development work: design and code. I wasn’t with the team for long before I recognized the Team Lead made all the decisions. When I asked him if the team members could make more decisions the response was, “they’re not ready.”

This rather straight forward answer can reveal a concern the manager has about losing power. Agile and Scrum deliberately moves power and control to the Scrum Team, the people most likely to have the knowledge and resources necessary to make the right decisions. However, for someone to gain, this often means someone needs to give up and this sets up a conflict within the manager that is difficult, sometimes impossible, to overcome.

If the manager or Team Lead cannot give up power, cannot control their ego, and cannot see their team as bigger than themselves then it’s very unlikely any substantial change toward Servant Leadership will occur. If on the other hand, the manager or Team Lead is able to put the interests of the team ahead of their own then there’s a good chance sustainable change will happen. This was the topic of a talk given at Scrum AustraliaThe Journey to Servant Leadership, describing exactly how this change occurred. What started out as a coaching effort toward better Scrum turned out to be the transformation of the Team Lead into a Servant Leader and was documented in this presentation.

Steps to empower the team and give them a safe environment

Managers, as Servant Leaders, build regions of safety for the Teams to operate in and lets the team know specifically where the boundaries are. Even better, the Servant Leader works with the team to set these boundaries. For example, a development manager might say what parts of the architecture can’t be changed without a review. He might also be specific on what parts the team can change on their own. This could apply to tools and 3rd party software components. Management might set goals as boundaries, for example, a 85% accuracy rate on all sprint planning commitments or a 65% accuracy of release planning estimations. I worked with a team once where they had a definition of ready where the goal was only 1 in 10 stories could have surprises impacting a sprint outcome. Boundaries, rules by any other name, are great for using as retrospective triggers. If a team was unable to complete 85% of the work they committed to in a sprint, the team would do root cause analysis to figure out what happened.

The next thing for the Servant Leader to do is give the team the power to make decisions within the established rules. In the talk, The Journey to Servant Leadership, the manager described how when asked for his opinion, he threw the question back at them, “what would you do?” He ensured a decision was made but he empowered the team to make it. Over time, the team grew confident in their decision-making capabilities, relying less and less on the Team Lead. The Servant Leader asks questions and uses these questions to help the team find their own way.


The manager as Servant Leader is a crucial step in building a sustainable Agile workplace. If the management team is willing to build self-organizing teams, spend time training team members about problem solving in their domain, build a safe environment through the introduction of boundaries, to trust the team to make their own decisions within those boundaries, and finally, to see themselves as the support mechanism for the team, the business is likely to excel and achieve greater things.

Further Reading

Mary Poppendieck’s article, “Train-Wreck Management“, very nicely ties together the birth of a hierarchical management style, the recognition by W. Edwards Deming that the ‘system’ was most often the problem stifling productivity, and Taiichi Ohno who championed continuous improvement and Lean Manufacturing techniques.

I welcome your comments and feedback.

Author: Robert Boyd

I'm a CSP (Certified Scrum Professional), CSM (Certified ScrumMaster), and CSPO (Certified Scrum Product Owner). For 30 years I've been streamlining processes and systems. I've introduced agile methodologies to software and product management departments, resulting in a 300 percent increase in feature deliveries.

Leave a Reply

Your email address will not be published.