Читать книгу Agile 2 - Adrian Lander - Страница 19

In the Agile community, the term leadership in the context of a team is often thought of in terms of the Scrum Master role, which is defined by the Scrum framework. There is also the Scrum Product Owner, who provides leadership with regard to the product vision and its feature set; and Scrum team members are expected to apply individual leadership when collaborating and organizing their collective work. Let's consider the Scrum Master role, which is the primary leadership role defined by Scrum pertaining to the work process of a development team.

The Scrum Guide's definition of the Scrum Master role has changed greatly over the years. In early 2007 the Scrum Guide said¹ that

the Scrum Master “is responsible for the Scrum process, for teaching it to everyone involved in the project, for implementing it so it fits within an organization's culture and still delivers the expected benefits, and for ensuring that everyone follows its rules and practices.”

In other words, back then, the authors of the Scrum Guide, Ken Schwaber and Jeff Sutherland, viewed the Scrum Master as mainly a master of ceremonies. The part about “implementing it so it fits within an organization's culture” is pretty ambiguous, but it sounds like it pertains to tailoring Scrum in some way.

Then in March 2007 they added three responsibilities to the role, which we paraphrase here:

 The ScrumMaster needs to know what tasks have been completed, what tasks have started, and any new tasks that have been discovered, and so on.

 The ScrumMaster needs to surface dependencies and blockers that are impediments to the Scrum team. These need to be prioritized and tracked.

 The ScrumMaster may notice personal problems or conflicts within the Scrum that need resolution. These need to be clarified by the ScrumMaster and be resolved by dialogue within the team, or the ScrumMaster may need help from management.

This adds some pretty specific process responsibilities, akin to task management, which is strange, because Agilists usually prefer stories over tasks. The reason is that a story is generally considered to be something that is defined in terms of its desired outcome, whereas a task is a prescriptive statement of what to do and therefore how to achieve the outcome. It is not that Agile teams never work on tasks, but if something can be expressed in terms of a desired outcome, that is preferred.

Then in 2009 they added (emphasis added here) the following:

The ScrumMaster is a facilitative team leader … . He must: Ensure that the team is fully functional and productive; Enable close cooperation across all roles and functions; Remove barriers; Shield the team from external interferences; and Ensure that the process is followed…

Then in 2010 they changed the role to be as follows:

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.