top of page

Can we not measure Servant Leaders' success?

Updated: Dec 31, 2020

A fresh morning, a cup of hot tea (coffee is not my cup of tea!), and a conversation with like-minded people can be a fantastic start to a day. That is how one of my days started.

I was talking to two Scrum Masters on the other side of the globe. Exchanged greetings, learned wellbeing of each other, we talked about Agile practices and the latest learnings. Since it is the start of Q4, we also discussed upcoming year-end reviews and the success of the Servant Leader’s team in general.

The striking unanswered question in that discussion was – how to measure the success of Servant Leaders? My brain started working on this question from the moment I dropped the call. Finding myself restless, I ended up writing the below notes. These are my thoughts, influenced by my experience, past readings, and training/meetups I attended.


No matter what role we look at, a human tendency tries to tag the success with outputs that are measured by metrics. Servant leadership is a job that cannot be measured by simple metrics or by measuring outputs. The servant leadership role is more outcome-based in nature.

Good thing that the industry values agility, agile-practices, and respect the agile professionals. But there is still a high level of ambiguity in measuring the success of the agile process backbones - the servant leaders. There are 'managers' reviewing the servant leaders' performance in companies, many not knowing how to evaluate the success of the servant leadership role.

You may look at process improvement measures, cycle times at team or program level, team's maturity and understanding with agility, etc. but you run the risk of falling into the trap of measuring the process instead of looking at the outcomes that result from your Scrum Master's involvement in the process.

Scrum Master is involved everywhere and yet, nowhere.

If the program is in the transformation phase, you will have KPIs to tag to servant leaders. Examples being

  • The number of training sessions conducted for the group for various roles.

  • Monitoring and assessing agile knowledge in a particular area.

  • Analyzing and implementing cadence and ceremonies.

  • Help POs refine the backlog with the teams and manage the priorities.

  • Physically running the ceremonies for team/s and the program.

  • Answers the questions and queries raised by the transforming team/s.

... etc.

But as soon as the program is transformed into agile, we still need the Scrum Masters, and it gets tough to fit their role’s success within the output criteria.

In the usual situation, Scrum Masters coach the teams, the POs, and others with best understood agile practices. SMs help teams find the most viable solution to respond in specific scenarios. They keep reminding people of processes, practices, and principles. They facilitate (not drive) most communications and ceremonies.

It may also happen that in a particular environment, there are several people within the construct never been tagged or visited by the Scrum Master, and the very reason could be that those people are doing such an awesome job that there is no need for reminders by the Scrum Master. But the Scrum Master must be too fortunate to have many such people in one group/team/program. That only seldom happens.

The Scrum Master may also feel that they are not doing anything valuable for a certain period. They are only facilitating ceremonies and not getting into impediment resolution, conflict management, process improvement, training, coaching to team, PO, and others, or sending the reminders out. That is fine. This situation could potentially be an outcome of their fantastic job in the past. The team is functioning very well and self-servicing in given situations. No one should question the slack achieved by the Scrum Master with their great work. On the other hand, the Scrum Master is supposed to utilize this slack time to sharpen their skills, meet people, and understand potential opportunities/needs of the future. They can read books, attend meetups/conferences, meet other Scrum Masters to learn/share the practices. And, certainly, continuously monitor and care for the team/s. Since the Scrum Master job is involved with humans (the human who are interacting with other humans as well as artificial systems), there will be some dysfunction over time. And then the Scrum Master will get some challenges to get into action.

In simple words, a great Scrum Master makes sure that their team does not need a scrum master.

A great Scrum Master brings the team to an invulnerable maturity level. And this is very hard to measure by a set of metrics.

Once the Scrum Master does not require much to do for the team, they can focus higher on the organization. There is always something to improve.

As a Servant leader itself, their reviewer or one providing feedback for the servant leader’s performance, we may not have a concrete set of KPIs for the role, but few questions can be asked to realize the success (or failure):

  • Is the team functioning well?

  • Is the team elevated in agile maturity over time?

  • What process improvements or industry best practices are implemented and monitored by the Scrum Master.

  • How are we following up on action items from the team and program level retrospectives?

  • Was the scrum master available when the team needed them the most?

  • What did the Servant Leader do to improve their soft skills and enhance the knowledge horizon? (coaching relentless improvement, led by example.)

Above all, a Servant Leader's success is relevant to the team’s success and tightly coupled with the team's culture and maturity.


Working on this article helped me overcome the quest for an answer to the question that disturbed me for hours. I feel energetic understanding that I have enough pointers to discuss with my reviewer at the end of the year. I am eager to share my findings with my fellow scrum masters and seek their comments and inputs.

If you also have thoughts and comments, please post it below.

Recent Posts

See All


bottom of page