This series on leadership arises from a talk by Mary Poppendieck on Agile Leadership. See our earlier post.
Now let’s consider leadership in Scrum. In theory. And then later, in practice.
We are reminded of Yogi Berra’s quote: “In theory there is no difference between theory and practice. In practice, there is.” (A nod to Nancy Van Schooenderwoert.)
Some in Scrum will say that there is no leader on a Scrum team; everyone self-organizes themselves and things emerge. (See the High Moon video, here.) In a very healthy and capable team one can imagine that things might seem that way, but we rather doubt that is the truth. Or at least, not the whole truth. We suspect that subtle signals of leadership are being given and received within the team. (And then we fall back to…what does leadership really mean??)
We also have had teams that, well, demand a “leader” if not a boss, to guide them in (or perhaps even tell them) what to do. In theory this is not good, but there you are sometimes.
Some in Scrum will say that the Product Owner is the leader. She decides the team’s priorities by choosing the Product Backlog items to be worked now and by deciding when they are done. Thus, she is the leader. Or at least a leader.
Others might say the ScrumMaster is the leader or a leader. He is not command and control (as stated in the book), but with his Jedi magic, he is nonetheless in effect leading the team toward higher productivity. Clearly it is an important role, since the ScrumMaster’s main job is to manage, and see that action is taken on, the top items on the Impediments List. The role is not a mere process coach for a few Sprints or an MC for meetings.
My own view is that Scrum does not really specify leadership. And that this is a good thing.
First, we need to remind ourselves that there is a whole range of essential things about which Scrum remains silent, expecting the team members to add the appropriate things needed to get the job done in their specific situation. I think leadership falls in this category also.
This is good, because no one-size-fits-all set of answers actually works in all situations. It is good because not all teams require the same dimensions of leadership, and not all teams have capable leaders in the correct roles. This is also partly because not all teams have good followers. (By which we mean not sheepish followers, but those people who can see good leadership and support it.)
Let me remind you (although some may already have inferred this) that when I talk about leadership I tend to mean that group of things relating to vision (purpose, meaning, value), inspiration, and people skills.
Another important area (sometimes included in leadership) is to have the right person make the important decisions. To me, who the right person is must be determined decision-by-decision (or area-by-area). The right person to have the last say on the business value of a story is probably not the same person who should say whether some java code is written well enough.
So, the team should probably define norms about how the various team members will lead. And I would recommend some flexibility in that definition. My bias is that everyone on the team is responsible for leadership in one area or in some way.
Here is the crux, in my view. When the chips are down, on that day when things look worst, who carries the heart of the team? Who encourages that team to stick to it? Who comes up with that one useful, inspiring idea? Who won’t let the team fail? Who let’s the personal issues get discussed, but then gets the team back on track?
My experience is that this leadership can come from many types of people. It all depends on the people involved.
Although we have no simple answers, the team still needs leadership. (Dang, again we are missing that Agile Cookbook chapter that people can follow and check off to see whether they have a good “leader”.)