The Scrum Master is
responsible for ensuring that the Scrum Team adheres to Scrum values, practices, and rules
. The Scrum Master helps the Scrum Team and the organization adopt Scrum. The Scrum Master teaches the Scrum Team by coaching and by leading it to be more
productive and produce higher quality products. The Scrum Master helps the Scrum Team understand and use self-
organization and cross-functionality. The Scrum Master also helps the Scrum Team do its best in an organizational environment that may not yet be optimized for complex product development. When the Scrum Master helps make these changes, this is called “removing impediments.”
The Scrum Master's role is one of a servant-leader
for the Scrum Team.
Note in particular the use of the term servant leader.
That's a lot of churn for a key role (Scrum defines only three roles), and it has changed again. As of this writing, the Scrum Guide says that the Scrum Master role is responsible for the following:
Coaching the Development Team in self-organization and cross-functionality
Helping the Development Team to create high-value products
Removing impediments to the Development Team's progress
Facilitating Scrum events as requested or needed
Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood
It says other things as well, but this is the part we want to focus on, because it pertains to leadership. It basically says that a Scrum Master is a kind of facilitator, impediment remover, and advocate for Scrum. However, the second bullet is extremely ambiguous: “Helping the Development Team to create high-value products.” That could mean anything! It could mean that the Scrum Master rolls up their sleeves and writes code. So that one tells us nothing, and we shall ignore it.
One thing to note about all of these definitions of the Scrum Master role is that it is focused on a single team. Team leadership is one of many levels of leadership in an organization, and so the Scrum Master role cannot be assumed to be a model for leadership at other levels of an organization.
Another thing to note is that it is very inward-focused: it is about helping the team. The outward-focused elements are the ones that pertain to advocacy for Scrum, such as “Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.”
A major function of the Scrum Master role is to remove impediments for their team. What does it take to do that? Generally, it means that the Scrum Master must meet with other stakeholders in the organization and persuade them to make changes to how they operate. Anyone who has ever worked in a large organization knows that getting people's attention usually requires that you have some kind of “standing.” Your standing can come from being responsible for something, from having authority over something, or from a reputation of respect that precedes you. If you don't have standing, people don't pay much attention to what you want; they have urgent priorities and too little time.
A Scrum Master's standing is that they represent a team, and the team is responsible for delivering something. But a Scrum Master is severely handicapped because they cannot make an agreement on the team's behalf. Negotiating with someone usually requires that if they agree to do something, then you agree to do something that they want in return. A Scrum Master cannot do that: their only tool of persuasion is that their team needs it, and that is all.
In other words, a Scrum Master lacks any kind of authority, except that they can prescribe that the team must adhere to Scrum. Their lack of authority makes them unable to make promises or deals on their team's behalf.
We also saw that the Scrum Master role is entirely focused on a team—a single team. In a large organization, there are many other contexts in which leadership is needed. As Peter Drucker said in his book The Practice of Management, an organization needs an “outside person,” an “inside person,” and a “person of action.” Drucker was describing different styles of leadership.
Leadership is a complex and nuanced issue. We find that the Agile community over-emphasizes self-organization and, in doing so, over-simplifies leadership, often dismissing the need for any kind of explicit leadership, as if good leadership always emerges from a team on its own. In fact, we feel that leadership is the central issue that needs to be understood well and not over-simplified. With good leadership, everything else follows.
We also do not believe that there is a way to perform “leadership by numbers”; that is, there is no organization design or process that can sidestep the need for good leadership. People have tried to do that: to prescribe processes that avoid the need for authority. However, what happens is that individuals attain influence, and thereby de facto authority, and one is back to having individual leaders again.
The problem of needing good leadership will not go away. It must be met head-on. The Agile movement has dismissed explicit leadership: the manifesto's stated preference for a self-organizing team was taken to mean that explicit authority is not needed. Yet to form a team in the first place, one needs authority. We will delve more into this topic in Chapters 3 through 5.
The Scale Problem
From the beginning, Agile ideas were expressed in terms of “the team,” implying that there is one team working on one product. A one-team product occurs frequently, but multiteam products are just as common, if not more so.
Could it be that Agile methods only work for a single team? Maybe Agile methods worked well, not because the methods were good but because they were commonly applied for the easy case: one team. We do not believe that, but it is a valid challenge.
There is also the case of multiple teams but a single monolithic product. In the early days of Agile, most software products were monolithic; that is, they consisted of a small number of very large bodies of code. A typical architecture was a web application, which consisted of a user interface web page, a web server, and an application server.
That kind of architecture could become pretty complex, and there were frameworks for breaking up the application into pieces on the server. The most well-known examples were the Enterprise JavaBean architecture and the web service architecture, and these patterns were often used together. Still, the number of runtime components was generally a handful at most.
Contrast that with today. A typical architecture at, say, a large bank, is that the company's digital platform will consist of tens or hundreds of products, each supported by hundreds of distinct microservices, and all these microservices interact in various ways in real time by sending messages or calling each other. There are often hundreds of development teams working on these many moving parts, which together constitute an integrated product ecosystem.
In his Forbes article “The End of Agile,” Kurt Cagle wrote this:
Scale problems only show up once you've built the system out almost completely and attempt to make it work under more extreme conditions…This becomes even more of an issue when developers have to integrate their efforts with other developers, especially for those components developed at the same time.2
The complexities of scale are what make the scale issue perhaps the most important technical issue today. It is also an issue that strongly overlaps with the issue of how leadership should scale:
