Can self-managed teams really work?

Though Scrum's call for "self-managed teams" might sound like a bit much, it's less radical than it appears

Dear Bob: ...

My company is starting use Scrum to manage our development projects. The general concept makes sense, as it really helps communication and allows for the most important work to be addressed in relatively short cycles.

[ Also on InfoWorld: "Mixed teams don't have to be dysfunctional -- but they certainly can be" | Get sage advice on IT careers and management from Bob Lewis in InfoWorld's Advice Line newsletter. ]

One part of Scrum that I do not fully understand is that the team doing the actual work is supposed to be self-managed, self-organized, and cross-functional. That idea looks great in books, but self-managed teams seem to be something that has only been successful in the eyes of writers like Tom Peters.

I understand that the peer pressure of a Scrum environment almost forces developers to stay on task, but how do you feel about teams in a Scrum environment trying to organize and manage themselves? Many IT shops that I have worked in seem to succeed due to visionary leaders who understand how to manage and develop a variety of skills and talents.

- Confused Chicken

Dear Cluckmeister ...

Having both led and participated in self-managed work teams, I share your skepticism. Among the less-often-mentioned disadvantages is that self-organization takes time and energy away from doing the actual work.

Personal opinion: While I agree with Scrum's thought leaders that traditional project management techniques need modification for Scrum to work effectively (the reason "project manager" changes to "ScrumMaster" and "business sponsor" changes to "product owner"), I don't agree that full migration to self-management is required or even desirable.

As a practical matter, I suspect the issue won't even come up. In the Scrum environment, self-management ends up meaning that:

  • Team members are responsible for estimating the difficulty of each backlog item added to the sprint.
  • Team members get to horse-trade specific backlog assignments instead of being assigned by the project manager.
  • All team members work in a shared work area instead of in separate cubicles.
  • The balance between peer pressure and project manager oversight as tools for ensuring work gets done places more emphasis on the former and less on the latter than in traditional projects.

None of this really means self-management. It's how modern business leaders of all stripes ought to operate when leading teams.

Except, of course, for the shared work area. These take getting used to. They have the advantage of facilitating shared problem solving and informal communication. They also have the advantage of reducing the number of non-project-related interruptions, compared to what employees typically experience in their cubicles.

They have the disadvantage of making heads-down concentration more difficult, specifically because they encourage informal communication among team members.

All in all, I recommend them for this sort of highly collaborative development, recognizing that they do represent a trade-off and not an unmixed blessing.

As for the importance of a visionary leader: I'd say this is more important a layer or two above the Scrum teams. Even in traditional projects, I don't look to the project manager for vision. Vision should have happened long before the project manager got involved.

Project managers are the ones to make sure the vision turns into reality -- an entirely different kettle of poultry.

- Bob


Copyright © 2009 IDG Communications, Inc.