Friday, February 1, 2008

Self organizing teams - quo vadis?

I have a team of 5 developers and 2 functional analysts and we use mostly an agile approach to developing software. Coming from a non-agile environment, I had to get used to the concept of letting the team make decisions, including those involving self righting. I instantly recognized some of the benefits. First and foremost - the dream of any project manager, I didn't have to tell everybody what to do all the time. One of the pitfalls of managing project is trying to do too much and by doing so, curtailing the natural lines of communication between project participants. Developers did not expect me to tell them how to communicate with each other or with the functional analysts. If we hit a bump in the road or communication was not efficient, we would discuss it at the iteration post mortem meetings and right it for next time.
However, lately I have been nagged by a side effect. There have been several instances lately where the team took decisions that should have been brought up to my attention. An example is making a decision to refactor code instead of picking up new functionality off of the product backlog. This put the overall schedule and our commitments to the client organization and their board of directors at risk.
The moral is that self organizing teams is a great thing to do if it can be kept under control. Multidimensional communication should still include the PM and the role of the PM as the gatekeeper on scope, schedule and cost should still be recognized. There is a delicate balance to be striken between micromanaging that strangles team initiative and an absolute 'hands off' approach where the project manager is rendered powerless by the voice of the crowd.

No comments: