Servant Leadership - It’s Not What Scrum Says It Is

Leadership is almost always essential for any endeavor involving many people.

Many among the Agile movement believe that leadership must exclusively emerge from within a team--that it must not be imposed (although many also question that axiom). Their belief stems from an absolutist interpretation of the eleventh principle of the Agile Manifesto, which is a brilliant yet imperfect document. It states,

The best architectures, requirements, and designs emerge from self-organizing teams.

I would argue that this statement is not true--the Manifesto provides no evidence for it. In fact, there is a mountain of evidence to the contrary, yet many Agilists just accept each of the Manifesto’s principles as doctrine that is beyond question.

Let me make it clear that I am an advocate for Agile ideas, and was an early adopter. In 2000 my own company where I was CTO adopted eXtreme Programming. In 2005 I wrote a very thick textbook about how one could approach the design of enterprise systems in an Agile manner, focusing on team learning and patterns instead of big up front designs, signoffs and controls. Over the past decade I have helped more than ten organizations become more Agile, mainly through showing them Agile and DevOps approaches. A case study in which I converted a waterfall team into a true DevOps team in two months is here.

But I don’t swallow dogmatic ideas outright: I scrutinize them and test them if I can. What I have found is that extreme ideas usually do not work in most situations, even if the extreme idea has a kernel of truth in it. What usually works is a moderate version of the extreme idea.

But back to the dilemma of what leadership means in the Agile community. The most popular methodology that claims to embrace the principles of the Agile Manifesto, Scrum--although a strong case can be made that Scrum is not Agile at all--defines an anemic model for leadership: the “Scrum Master” role.

(Note: There are too many articles about why Scrum is not true to Agile to even begin to reference them. The articles and posts that I pay most attention to are the ones by programmers--the people who actually do the work. Their view tends to be quite different from the view of most Scrum Masters. Here is an example. Here is another. Here is another.)

The Scrum methodology is defined by the Scrum Guide, in which the Scrum Master role is defined and explained; but the Scrum Guide’s definition of the Scrum Master role has changed vastly and frequently over the years, so one would be right to view it with skepticism.

Except that so many Scrum devotees--it would not be too inaccurate to call them acolytes--treat the Scrum Guide as something definitive. They way they refer to it, it is almost as if they view it as something biblical and perfect.

Yet the reality is that Scrum is contradictory and unfit for purpose, except for a narrow range of very simple cases like small startups. It is unfit in so many ways, from the fact that it only defines a target state without any consideration of how to get there; that it focuses on a single team when most products require more than one team (that’s why they later had to invent “Enterprise Scrum”); that it does not account for the very real need of specialists for complex products--e.g., data scientists--; that the generalist view of the team members actually treats them as commodities; that its theory of a feature team cannot handle today’s deep stacks; that the sprint time-box cannot efficiently accommodate the extremely powerful method known as Behavior-Driven Development, which is inherently a workflow; and so many other things--it would take many pages--a whole book actually--to explain all of the problems of Scrum in the real world of digital product development, so I will focus on the point of this article, which is leadership, and the Scrum Guide’s Scrum Master role.

Consider that the Scrum Guide currently (as of June 27, 2020) says, “The Scrum Master is a servant-leader for the Scrum Team.” (It did not always say that--they have added, removed, and added back the word “leader” over the years.)

Except that the way that it then describes the role is clearly not servant leadership!--at least, not as that style of leadership is described in numerous books on leadership, including those that focus entirely on servant leadership (such as this one).

Servant leadership is leadership; it carries with it accountability and authority, just as many other forms of leadership. What is different between a servant leader and an autocratic leader is not in how their role is defined or scoped, but in how they perform their role.

A servant leader acts in a supportive way, rather than a demanding way. But a servant leader is still a leader.

Yet nowhere in the Scrum Guide does it mention that the Scrum Master has any authority or accountability. Defined as it is, the role is really just a facilitator and mentor. Facilitation and mentorship are aspects of leadership, but in an organization that has lots of teams, teams need real leaders to represent them and to advocate for them, as well as to develop them so that they can start to lead themselves.

And accountability is important; because a whole team cannot be accountable: that creates a tragedy of the commons, in which no one is accountable.

What Is Missing Without Real Leadership

The Scrum Guide lists some wonderful things for what a Scrum Master should do, such as,

• Coaching the Development Team in self-organization and cross-functionality
• Helping the Development Team to create high-value products

The second one is more than a little bit nebulous--in fact, the way it reads, it sounds as if the Scrum Master is supposed to write some of the software code!--but the first one is clear that a Scrum Master should provide mentorship to help the team to learn how to organize itself.

But this seems more than a little bit like hand waving to me. There is so, so much that goes into mentoring a team. First and foremost, mentoring a team is about mentoring individuals. One does not only mentor a whole team: one must mentor each of the people within the team. That is how you mentor effectively.

In Dr. Marta Wilson’s fantastic book, Leaders in Motion, she writes,

“Good relationship skills include awareness of others’ feelings, needs, and concerns. That’s the only way to win hearts and to work from the heart.”

One of the things that I dislike about the open office arrangement that is commonly used for Agile teams is that it is so cumbersome to talk to anyone alone; yet talking to individuals alone is--I think--a core element of relationship building and mentoring.

Many years ago I worked for a project manager named Carl who was the best team lead I have ever had. He was a natural servant leader--it was just how he was. Each morning he would go to each person’s office and sit down and say, “How’s it going?” and after a little chit-chat, he would say, “So what are you working on today?”

So far it sounds like a Scrum standup between just two people; but then he would ask, “So how will that work?”

He wanted to talk through what I was working on, and he was a good listener. After listening and asking questions, he would often get up and draw something on the whiteboard--each office had one--and then he might make a suggestion, but emphasize that it was only that. He’d then say it was nice talking and leave, on to the next office.

This sounds compartmentalized, but it was not at all. We kept our doors open--unless we needed to focus--and we were popping in and out of each other’s office all the time; plus, for much of each project we had a standing one hour design focused meeting each afternoon, in which we would talk through problems people were having. They were well attended, but attendance was optional. Once things were well underway and the code was solid, we stopped those design meetings until we needed them again.

Carl’s office was also a frequent place where we would go to discuss things: “Let’s see what Carl thinks”, where we would use his gigantic whiteboard, and he would participate, never dominating, but never hesitating to offer his own ideas. We all knew that we would talk things through logically and the best idea would win.

We all trusted Carl. He cared about us. He had our back. Sometimes he made a decision: that was his job, and he was accountable, but we trusted him and so we wanted him to make a decision when he had to. He never micromanaged us or forced us to work in a certain way, but sometimes he had to be the decider about something that affected all of us. On the other hand, he was a natural organizer and at the start of a project he set things in motion rapidly--and we wanted that. And he did so transparently, with discussion, and always open to alternatives, so in the process he was showing us all how to organize things and creating new leaders in the process.

Carl also never thought that he was smarter than everyone else, or that he knew more. He was smart, and he knew alot. He had a PhD in linguistics and had worked for twenty years at the Defense Language Institute in Monterey California, but then decided to enter the computer field, and to train himself he created one of every major kind of program: he wrote a database manager, he wrote an operating system, he wrote a compiler, and he wrote several other kinds of program as well. He had no formal training in programming or computer science.

So he was smart, but we had various tech leads on the team, including two computer language experts (we wrote compilers), and Carl treated everyone’s ideas as equally worth consideration. Everyone was respected.

Carl often had to advocate for the team. There were often pressures from management and from technology partners to change things or change schedules, and Carl represented us in those very difficult discussions, often flying off to Texas or New York. We felt confident in him, because we knew that he understood the technical issues as well as the business issues, and--as I said before--he had our backs. This is why it is important to have a true team lead who understands the whole range of issues--not just certain kinds of issues.

He was not the technical expert, but he was deeply interested in every issue, and if it was something he did not know, he made it his business to learn about it.

We not only trusted Carl, but he came to trust us. I say “came to” because real trust is earned: it is not automatic. That is something that the Agile community does not appreciate. It is one thing to give someone a chance to do something beyond their proven ability, with supervision, so that they will learn or prove themselves at a new skill; it is another thing to blindly trust the team and hope for the best, rationalizing that by thinking that if they fail, they will learn from their failure: that is a good way to allow a catastrophe to happen that could put the entire company out of business.

Carl knew what we were each capable of because he took time to get to know each of us as individuals and how we worked. Over time, he was able to put people in leadership roles (on one project he put me in charge of the test automation), because he knew what they could handle. That’s how you mentor people: by getting to know them as individuals.

Leadership is paramount. Leadership is what it is all about. The Agile movement rejected traditional leadership in the form of the autocratic boss who comes in and bosses everyone around, and then blames them when things go wrong. But throwing out leadership entirely is not a solution. Leadership is necessary: the right kind of leadership.

The primary challenge that any organization has is how to encourage and nurture a culture of the right kind of leadership.