Free Project Management Software

One of the most important aspects of agile project management is the ability for teams to self-organize. But as Damon Poole writes in this post (http://agile.dzone.com/articles/the-use-self-managing-teams-ou), understanding exactly what that means can be a little difficult to say. Poole is committed to digging up some answers and to do so, he’s looking outside of agile and will report back with future posts on this topic.

From my own experience working in agile environments, the concept of self-organization has always been pretty clear (and its benefits have been just as clear). Because most agile frameworks or methodologies divide responsibilities through well-defined roles, there has never been any confusion. That is, the team is responsible for completing the work it agrees to in a given iteration and, therefore, must work together to determine how it will be completed. Poole wonders if this means that individual team members decide what tasks to tackle in addition to how and when. I think that self-organization entails all of those decisions. However, it’s important to point out that these decisions aren’t made independently by individual members of the team. It’s the team that self-organizes. Thus each member weighs in and, collectively, a consensus is reached. The benefits of this approach are obvious. It allows the team to take on more ownership of the work, thereby increasing their investment in its success. Managers, on the other hand, are relieved of their “babysitting” duties. Instead, they can focus on big picture concerns, such as release planning and prioritizing outstanding work.

How would you expand this definition of “self-organization”? Do you think Poole is making it more complicated than it really is or is he on to something? And do any of you have experience with self-organization outside of a dev team?

There’s quite a debate going on in the agile community over Jim Shore’s “The Decline and Fall of Agile” blog post. If you missed it, Mike Bria’s “Adopting the Whole Enchilada” over at InfoQ (http://www.infoq.com/news/2009/02/whole-enchilada-and-context) will catch you up to speed, from the original post to the heated posts it’s inspired. At issue in Shore’s original article is how agile could die out if organizations continue to simply “say” they’re practicing agile, without actually walking the walk. For the most part, the agile elite have come out in droves to agree with and elaborate upon his position. Martin Fowler posits that agile methodologies often give short shrift to the technical side of things. Industrial Logic and IXP founder Joshua Kerievsky suggests the problem is how organizations adopt agile, stressing that companies should become completely agile from the get-go. And Ron Jeffries puts the whole discussion in perspective, explaining that agile processes aren’t to blame, but the organizations that insist certain aspects of agile won’t work there.

For those of you who have been following this, what’s your take? Are agile’s shortcomings inherent to the methodology? (I don’t think so.) Or is it the “context”—i.e. the organizational milieu—that’s to blame? I’d love to hear your thoughts in the comment section.