One of the key tenets of agile development is often described as self-organization. This isn’t explicitly called out as much in the more code- focused flavor of agile exemplified by XP, but it’s a key focus of the more management-focused family of methods exempified by Scrum (I owe the code-focused vs management-focused distinction to Steve McConnell, Earl Beede and the other folks at Construx Software).
In an ideal scrum, we’re told, the participants don’t tell the scrum manager what they’re working on and what their blockers are — they tell each other. They reach into the backlog and choose their own tasks and defects to work on, rather than being assigned work by the manager. Some scrum managers, we’re told, ostentatiously turn their backs on the group to make this point as clear as possible (but surely there are other, undesirable, implications of that gesture as well?)
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 whole self-organization thing.
Initially we tried to stick to the self-organizing theory. Well, at the VERY beginning, after the first couple scrum calls (and they were conference calls, more on that elsewhere), I polled the group for how they thought the calls were going, and was forthrightly told that the calls where I and the client-side PM had been absent for some reason had gone better. Points on the board for open team communication! So for the next few calls, I joined, but (ostentatiously?) dialed in with the listen-only passcode, figuratively turning my back on the group (but keeping an open IM line).
After a while, I started to join with the I-can-talk passcode again, but I tried to limit my role to moderator, just polling everyone in the group for what they had done, what they were going to do, and what blockers they had. Since the scrums were all done by conference call, as mentioned (we had team members in three North American and one Indian time zone), it helped to have someone prod people to go next and give their report. (That said, there’s a conference call practice I’ve seen elsewhere for this, where each person is responsible for “calling on” the next person after they give their report, and we might have done better to adopt that).
We stuck with this fairly low-management approach for a while, I’d say, 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, and was based more on “what the client will accept” than on a bottom-up estimate (which we had in hand, and which argued for adding another month to the schedule — 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.
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 suggestions as to what to do. There were times when my ideas were not the right ones, and all the way through, I did find that team members spoke out in the scrum if they saw a better approach. 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, that wasn’t reflected in our task tracking system yet.
I also, as the work built, felt a need to present a forest-rather-than-trees perspective on the existing backlog. One of the things I felt happened during the few weeks of very “flat” or self-organizing scrums early on was that 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, and feel like they were keeping up. Everything feels like it’s running smoothly. But a week later, after five or six of these even-keeled scrums, guess what, 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, and defensive that the tracking method somehow wasn’t giving them credit for everything they were doing. So I 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.
I’m not sure that all of this means that we failed to self-organize, or that I seized the reins in a way I shouldn’t have. Because the team is distributed, the developers kept an IM chat room open all day, and 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 what to work on.
Based on our scrum experiences so far, I’d suggest that self-organization is not something that happens automatically. One of the biggest qualifiers, I think, 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. And 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. I think the point I’m making here is that self-organization does not mean that everyone’s ideas are created equal, or that more skilled or experienced team members should avoid being assertive about the value of their ideas. There’s an equally important flip side, though, which is that everyone, “junior”, “senior” or otherwise, is capable of offering unique insight into the project, and needs to be treated as such. I think that this, too, has characterized our 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. But everyone has taken the lead on various things at one time or another.
Google for “agile self-organization” and you can easily find posts and documents that summarize the prevailing views in this area. Let’s look at a few typical statements.
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, and for 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). I think ideally you choose for that role a person of significant skill and experience. So OK, the good ideas don’t come only from people labeled “managers”. And they are not adopted based on “authority.” And they 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,” and I don’t think anyone should shy away from expressing their sense of what should happen, regardless of whether they’ve already spoken nine times in the scrum. And as to our scrum master, once again, I’d expect them to be chosen in such a way that one would find them frequently proposing and arguing for actionable, “best” ideas.
No one orders a team or an individual to do specific work. The team members volunteer for work that they see needs doing…
Again, as is often the case with semi-straw-person language, we see some strong words. “No one orders.” Well, 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,” but let’s leave that aside and 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. But 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 brought quickly into focus for them, so that they don’t need to focus at two distinct scales at once. (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.)
The above two quotes were taken from http://www.agileadvice.com/archives/2005/12/agile_work_uses_2.html.
So what does a scrum manager need to do? My opinions:
- 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. It’s your job (it’s everyone’s, but especially yours) to make sure that the individual choices and directions adopted by the team as they go about their work add up to a coherent assault on the central problems posed by the project. Submit your conclusions and recommendations to the team as provisional, by all means, and invite their comments, but don’t shy away from being clear about what you think needs to happen.
- Make sure everyone has a voice. Unless your project is unusual enough to be 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, you’re likely to encounter at least some disparity in people’s willingness to speak up or pitch in. So try to help make sure that everyone reaches their potential. Make sure the most experienced or adept are able to contribute in a fashion that takes full account of the contributions they have to offer. At the same time make sure that anyone who may be “under-contributing” understands that 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.