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.

3 More Questions to Ask During Stand-ups

Most everyone is familiar with the three traditional Scrum questions answered during the daily stand-up as presented in the 2016 Scrum Guide by Sutherland and Schwaber:

  1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
  2. What will I do today to help the Development Team meet the Sprint Goal?
  3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The purpose of the daily stand-up is for the Development Team to review the previous day’s plan and then arrive at a plan for the next 24-hours. In most cases, the Development Team can do this pretty well. The daily stand-up is a straight forward and simple meeting that focuses on the sprint goal but what could be done different to enhance the team’s daily goals and daily commitments, commitments which the Development Team will hold themselves accountable for.

To help focus the Development Team on the day’s planned delivered value, “What will I do today to help the Development Team meet the Sprint Goal?”, it is helpful to expand this into 3 questions before taking about today’s plan:

2.1 What is the customer value you’ll deliver at the end of today?

2.2 Is there something you can show the Product Owner today?

2.3 Is there something you can do to help get the most important story done today?

Now these three questions are not simply the fantasy of the Scrum Master but are arrived at jointly with the Development Team. Each of the above questions have their roots in team retrospectives and, in the beginning, the team wanted the Scrum Master to ask them. It’s very important that the team agree to any enhancements to the daily stand-up. For teams still early in their Agile journey, these questions will probably not seem unreasonable. However, for more mature Agile teams, there definitely needs to be a strong motivation to adopt them. In my particular circumstances, the Scrum Team was very mature and each of these 3 questions addressed a very specific problem the team recognized.

2.1.  What is the customer value you’ll deliver at the end of today?

When the question is asked, the team provides an answer in terms of acceptance criteria/tests that would pass at the end of the day that currently fail.

I started asking this question of the Development Team several years ago when it was brought up during a retrospective that during the daily stand-up, the team was focusing on the technical aspects of the work more than the customer problem they were actually meant to be solving. It wasn’t that the technical stuff wasn’t important, it is, but we wanted the team to keep some focus on what why and who they’re doing the work for. During the retrospective, the Product Owner said he was unclear of the progress of the user story, specifically the progress of the user story from a value perspective. More focus on the acceptance criteria and tests was a natural way to convey progress on value completed. The Product Owner was happy and the Development Team added the acceptance tests results as part of their daily planning.

This question provides an additional opportunity to further communications and collaboration between the Development Team and Product Owner. This is achieved by tying the customer, the acceptance criteria, and the solution together as a daily goal, a measure of value delivered each day.

2.2.  Is there something you can show the Product Owner today?

This question sprang from the Developments Team’s observation that some work was being rejected by the Product Owner, especially user interface work, too late in the sprint to correct it. The problem was the team was waiting until the story was complete before showing it to the Product Owner. This usually resulted in a new user story being written and added for the next sprint.

During the retrospective, the team recognized that some user stories and the intended value were being missed during the sprint because of the delay in showing progress to the Product Owner. The Development Team and Product Owner quickly saw that viewing incremental progress was the answer but the Development Team needed to alter how they broke down the work into tasks to facilitate this. It was breaking down the work differently that was the real challenge for the team as it required some work to be done that would ultimately be thrown away. This was the occasional stub or driver code to get some display components looking ‘right’.

This question provides an excellent opportunity to further collaboration between the Development Team and Product Owner. It serves to help focus on what ‘done’ means for a particular user story and helps reduce rework through a more collaborative approach to solving a problem. It can also make for a better product faster as the Development Team and Product Owner make any adjustments as a story progresses.

2.3.  Is there something you can do to help get the most important story done today?

This question got its start while 4 teams were working the same backlog and it was observed that new stories were being started while higher priority stories were still in progress sometimes with a large number of tasks in ‘To Do’. Although this question came from a Large-Scale Scrum (LeSS) implementation, it scales down nicely to a single team working a single product backlog.

What the Development Team was trying to improve during a retrospective was their ability to swarm until done. When I was developing, I would prefer to work it alone, without outside help whether I could use it or not. The Development Team saw that this mindset tended to slow down getting stuff done and suggested that the question be asked during the stand-up to heighten awareness that getting to ‘done’ was important. The way it eventuated was tasks still in ‘To Do’ for the higher priority stories were picked up. It also helped in identifying tasks that needed further breaking down.

The question provided additional visibility to getting stuff done rather than getting stuff in progress. Getting work done quicker gives the Product Owner maximum flexibility in releasing or A/B testing of new features. Unfortunately, companies sometimes look at 6 developers and wonder out loud why there aren’t 6 stories in progress.


After having the Scrum Master ask the 3 additional questions at the start, the Development Team began using the questions in context to their plan for the day and the questions themselves weren’t asked after a time. These 3 questions helped the team find the deeper meaning to the question, “What will I do today to help the Development Team meet the Sprint Goal?”

Please drop me a line and let me know what you think and your results if you give this a try.

New Scrum Master: Problems to solve in your first days

In the previous two posts. First day as Scrum Master and Second day as Scrum Master, I talked about you as a new Scrum Master to a team and some steps you can take to ease yourself into the team’s world. The first post talked about a group meeting with all team members including Product Owner. That meeting set up some introductions and gave you some clues as to how the team interacts and possibly some team dynamics. You followed that up with some one-on-one talks with each member of the team. In this post I’ll talk about interpreting the results of your one-on-one discussions with the team members.

Once you’ve finished your talks with the team it’s time to pull all the information together and begin planning your actions. The problems mentioned by the Product Owner, developers, testers, BA’s, UXD, and others on the team will likely fall into several categories. What’s listed below can be used as a guide but doesn’t take the place of your own analysis based on your unique set of circumstances.

Team’s ability to self-organize and be cross-functional

One Team, One Goal.

One Team, One Goal.

This will be by far the most common area of weakness based on the many discussions I’ve had.  The clue to this will be problems brought up by the team that they can clearly solve themselves but they’ll need your help. Some comments might include:

  • “Requirements are poorly written”,
  • “Working on things before we know what to do e.g. UX Designs incomplete”,
  • “Too many hand-offs”, and
  • “Definition of Ready and Definition of Done missing”.

I’ll look into the first comment, “Requirements are poorly written” in some detail. When the Scrum Development Team say this, I’m thinking there’s both a communication issue and possibly some role based barriers in place. The comment given by the Development Team makes me think they’re not feeling completely responsible for making sure the user stories are backed with heaps of conversation. Both communication and not feeling it’s their job can be resolved through well facilitated grooming sessions. The team can become better at self-organizing by tackling head-on the issue of shared understanding of the customer problem documented in user stories. The team can also build their cross-functional capabilities through greater contributions to the user story including the acceptance criteria. For a developer whose experience may be waterfall and where the sole contribution of the developer was code, helping to write the requirements can be a new and possibly frightening turn of events. You as Scrum Master are there to help facilitate this transformation.

Business or company culture as impediments

We do it that way because that's the way we do it.

We do it that way because that’s the way we do it.

Problems or issues cited by the team that fall into this category might include:

  • “Too many sign-offs and approvals (Designs)”,
  • “Little interaction between test and other departments”,
  • “Business emergencies and no way to stop them”, and
  • “Fixed end date regardless of start date”

It’s clear the company culture is not controlled by the development team but they can have an influence. The comments above could make you think the company is a top down Command & Control shop and you’d be right. One thing I’ve seen in this kind of environment is nothing is written down, it’s all done based on memories of past practices. One way to begin affecting this culture is to document how current work is done paying specific attention to the time it all takes. The Scrum Master and team can do this documenting of existing process and then present an alternative process with the now documented benefits and savings. As Scrum Master, you should also seek out and secure executive support or at least, a powerful mid-level manager who can support change. Without support, you’re chances of success are severely limited as I’ve recently learned first hand.

Technical challenges or knowledge gaps that are impediments

Thomas Edison - Incandescent light bulb

Thomas Edison – Incandescent light bulb

This is something I usually note as a result of listening to the development team but it’s rare that the team will directly say something with the exception of how testing is done. What I commonly see is a team hampered due to:

  • Specialist on team that can’t assist in other technical areas
  • Test treated as a separate group or sub-team
  • Testing always done at the end of sprint

These fall under a team being cross-functional but to get there will require specific training and strong guidance from the Scrum Master.  I once had a team with one tester doing all the testing. I suggested that the developers help out with the testing to speed it up and relieve the pressure on the sole tester. Luckily there wasn’t a rope handy as I’m sure the developers would have hung me then and there for speaking such blasphemy. One developer suggested to the managers that they needed to hire more testers. The managers, GM of Product and GM of R&D both told the developers that hiring wasn’t an option and that they would need to better support test. Once the management support was established, I was able to help get the developers to run acceptance and system tests. Baby steps. It was the opening needed to begin the longer term goal of spreading a little knowledge throughout the development team. When I left that company, the Scrum Teams did all the UX, testing, and infrastructure work themselves whereas in the beginning, each of these areas had specialist teams doing this work.

How this helps

After my first days and weeks with the team, I continued doing one-on-one talks with all the developers and Product Owners, noting what changes they felt had occurred in the previous month or two, how exactly these changes affected them, what further changes they wanted to see, and what makes them happy to come to work. I often find myself listening to the team chatter but asking the team to tell me their struggles and their delights helps me focus better on serving them. That’s my role as Scrum Master, to serve the team.

I welcome your thoughts and comments.