One of the key tenets of agile development is self-organizing teams. The more code-focused flavor of agile exemplified by XP doesn’t explicitly call this out. However, the more management-focused family of methods exemplified by Scrum makes this a key focus. (I owe the code-focused vs management-focused distinction to Steve McConnell, Earl Beede and the other folks at Construx Software.)
How an Ideal Scrum Works
In an ideal scrum, participants don’t tell the scrum manager about their tasks or their blockers. Instead, they tell each other. They reach into the backlog and choose their own tasks and defects to work on, rather receive work assignments from the manager. Some scrum managers ostentatiously turn their backs on the group to make this point as clear as possible.
Experimenting with Self-Organizing Teams
I’m working with a team in the late stages of a project we’ve consciously tried to run as an “agile” project. We have not been too dogmatic about the label. We’ve tried to use fixed-length iterations, story-point estimation, priority-based work scheduling, and a daily scrum meeting. The overall experience, I think, has been positive, and I’ll report on some of the practices in more detail in other posts. But I’ve been ruminating since the beginning on the self-organizing teams aspect.
Removing the Leader’s Presence
Initially, we tried to stick to the self-organizing theory. At the very beginning, after the first couple scrum calls, I polled the group for how they thought the calls were going. My team members informed me that the calls where the client’s project manager and I had been absent had gone better. Points on the board for open team communication! To determine why, I dialed into the next few calls with the listen-only passcode, figuratively turning my back on the group (but keeping an open IM line).
Leader in Moderation Mode
After a while, I started to join the calls as a participant but limited my role to moderator. I just polled everyone in the group for their completed tasks, those in the queue, and their blockers. Since we completed all scrums by conference call, it helped to have someone prod people to go next and give their report. (That said, you can also ask each person to “call on” the next person after giving their report. We might have done better to adopt that.)
Adapting Under Pressure
We stuck with this fairly low-management self-organizing teams approach for a while, but before too long the project began to come under pressure. The project was a brand new technology for us (risk!), and the schedule had been established, not quite by fiat, but by negotiation. It was based more on “what the client will accept” than on a bottom-up estimate. (We had this in hand and argued for adding another month to the schedule but didn’t receive approval — risk!). Predictably, we were behind on each iteration. Kudos to incremental development for highlighting the shortfalls early — but it does increase the stress on the team.
Returning to Full Leadership
As the work built up, and the defects began to roll in, and as we slid slowly (never catastrophically) behind, I began to feel more and more pressure to “drive.” I never flat-out told team members what to do, but I began to be more and more forward with my suggestions. There were times when my ideas were not the right ones, and all the way through, team members spoke out in the scrum if they saw a better approach. For example, I might try to push a task to someone, but they might reply that “Tom should take that task, it’s dependent on the work he’s doing.” Or, someone might have better information on a task’s priority nott reflected in our task tracking system yet.
Adding Perspective
I also, as the work built, felt a need to present a forest-rather-than-trees perspective on the existing backlog. During the few weeks of very “flat” or self-organizing team scrums early on we sometimes lost a sense of urgency and priority. Everyone could show up, say what they’d done, what they needed to do, and what their blockers were. They felt like they were keeping up and everything was running smoothly.
Unfortunately, a week later, after five or six of these even-keeled scrums, we’re 60% of the way through the iteration and have only burned down 35-40% of the story points. The team recognized this apparent lack of progress when it happened and felt simultaneously sheepish at the appearance of being stalled. Everyone got defensive that the tracking method somehow wasn’t giving them credit for everything they were doing. I, therefore, found it felt necessary, toward the end of iterations, to prod the team toward working in ways that would lead to a higher closure rate.
Did We Fail at Agile Self-Organizing Teams?
I’m not sure we failed to self-organize or that I seized the reins in a way I shouldn’t have. Because our team is distributed, the developers kept an IM chat room open all day. I’ve been able to see a very high level of ownership, cooperation, and problem-solving in the chat. I’ve seen some of the more experienced developers direct the work of those with less experience. Whether prodded by me or not, the team has generally made good choices about their work.
Self-Organizing Team Requirements
Based on our scrum experiences so far, I’d suggest that self-organization does not happen automatically. One of the biggest qualifiers lies in disparities in experience and character among team members. Some team members, due perhaps to greater experience with tools or platforms or deeper programming experience or skill in general, are going to have better ideas. This may sound elitist, but if so, so be it: it’s important, here as an in any endeavor, that skill and experience be given their due.
In an ideal team, more experienced members will mentor less experienced ones without being “told” to do so. Less experienced members will accept that instruction without letting ego get in the way. There’s no question this happened in our group, without any impetus from me.
Self-organizing teams don’t make everyone’s ideas equal. More skilled or experienced team members should stil be assertive about the value of their ideas. There’s an equally important flip side, though. Everyone, “junior,” “senior,” or otherwise, can offer unique insight into the project. There’s no one on the team who’s been solely a “leader” or solely a “follower,” though some have adopted those roles more often, some less so. Everyone has taken the lead on various things at one time or another.
A Mild Critique of the Dogma
Google for “agile self-organization,” and you can easily find posts and documents that summarize the prevailing views. Let’s look at a few typical statements.
The Manager’s Role
Teams and individuals organize themselves around the work. Managers no longer have the authority to tell people how to do their jobs.
Well, one question is, where’s the emphasis in that last sentence? Managers no longer have the authority? Managers no longer have the authority? No longer have the authority to tell?
I guess I come back to this: except in circumstances so rare they hardly bear mention in a discussion of general principles, teams will be characterized by disparities in experience and skill. It’s both desirable and necessary in those cases for greater experience to get its due. The ideas of those with deeper knowledge to be accorded the weight that’s due them.
Then let’s consider the “scrum master” (the perspective from which I write). Ideally, you choose for that role a person of significant skill and experience. The good ideas don’t come only from people labeled “managers.” They are not adopted based on “authority” and are not promulgated by “telling to.” All true. But in many teams, you can expect to see a certain disparity in the distribution of actionable ideas (to put it understatedly).
I don’t think is the sign that one is not “doing agile right.” Noone should shy away from expressing their sense of what should happen, regardless of how often they speak up in the scrum. As to our scrum master, choose someone who frequently proposes and argues for actionable, “best” ideas.
Strict Self-Organization
Again, as is often the case with semi-straw-person language, we see some strong words. “No one orders.” Hopefully, any highly-functioning team contains a minimum of ordering as such and a maximum of compelling argument and persuasion. I know of relatively few successful managers whose standard M.O. is “giving orders.”
Let’s take up the next sentence: “…for work that they see needs doing …” Agile argues persuasively that the people doing the work are most familiar with the work. At one level, that’s self-evidently true. However, the same close focus that makes an individual team member the master of their current work bucket makes it less likely that they’re equally intimate with the overall status of the project. They will likely benefit from having the bigger picture in focus. (Of course, if a team needs a person, i.e. a scrum manager, to provide the larger focus, it could be that there are deficiencies in their information radiators. I’ll need to think that one over.)
I found the above two quotes on agileadvice.com.
Successful Scrum Managers
So what does a scrum manager need to do to adequately support a self-organizing team?
- Don’t abdicate. You’re here to help the team focus, to remind them of priorities, and if necessary, to redirect their efforts. Don’t let the mantra of self-organization prevent you from speaking up if you feel the team needs to take a different course.
- Bring the forest. You must ensure the individual choices and directions adopted by the team add up to a coherent assault on the central project problems. Submit your conclusions and recommendations to the team as provisional. Invite their comments, but don’t shy away about what you think needs to happen.
- Give everyone a voice. You may have an unusual project staffed with a group of equally experienced, equally assertive people who all speak the same native language and are unperturbed by any gender or culture issues. However, most likely you’ll encounter at least some disparity in people’s willingness to speak up or pitch in. Try to help make sure everyone reaches their potential. Make sure the most experienced or adept can contribute their best ideas and work. At the same time, anyone “under-contributing” should understand their full participation is desirable and necessary.
Interestingly, as I look over those points, they could apply equally well to the job description for an effective meeting facilitator, in any subject area. Further, they are items that every team member would do well to take to heart and practice.
What do you think? Did I miss any crucial points? What has worked well for your agile self-organizing teams?
Links
- John Scumniotales has some good thoughts on what makes for a strong agile team lead.
- Agile proponent James Highsmith argues for replacing the term “self-organizing teams” with Light-Touch Leadership.
- The Running Agile blog aggregates a number of useful links on this subject.
