Agile Leadership – 2
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 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 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. I suspect that subtle signals of leadership are being given and received within the team. Perhaps different people are acting as the leader in different domains and at different times of the day. (But then… what does leadership really mean?)
There are teams that 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.
In Scrum, some will say that the Product Owner is the leader. He or she decides the team’s priorities by selecting Product Backlog items for the Sprint and 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 in 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 mwan not sheepish followers, but 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 a 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.
The team should probably define norms about how the various team members will lead. 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.
When the chips are down, on the day when things look the 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 allows personal issues to be discussed, and then gets the team back on track?
My experience is this leadership can come from many types of people. It all depends on the people involved.
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.”)