Agile Zone is brought to you in partnership with:

Sean McHugh is a Scrum Master at Axosoft who works with customers who are new to the scrum methodology. He also helps customer's who are experienced with scrum, but are beginning to implement a software solution for their scrum teams. He shares some of his thoughts and experiences at Sean is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Why self-organized teams are so important

  • submit to reddit
It's a situation that I run into with new Scrum teams all the time.

Their work is complicated you see, there's all of these dependencies for every backlog item to be implemented and each task needs somebody with a special skill and we have to schedule how each person with the correct skill will finish each task in a certain order so I need some way of planning all of this and managing it within each sprint.

Before you know it, there's gantt charts up on the walls and people are calling other people "resources". This is the reason why I keep my migraine medication handy at all times.

The problem here is that the very first assertion made here is absolutely true. Implementing a new feature in a complex system is complicated and there are certainly more factors involved than any one person can manage effectively.

Luckily the solution is actually rather easy. Make the management of this complexity as close to the work as possible, this actually means removing the project manager and allowing the team to decide for themselves how the work should be done.

Now almost as soon as you start doing this you'll begin to find impediments to the team getting their work done. The most major of these is that many new features and bugs need more than just a single person to complete them, at the very least you'll need somebody to code it and somebody else to test it but you may also need someone to modify a database or code a UI or design graphics or write up a help file.

To be clear, I actually don't agree with the approach of classifying developers by specific competencies. I feel like a developer should be able to code something into an application from beginning to end regardless of which part of the app needs to be modified.

This makes development much easier, a complex feature may be developed by a single person and the only reason another person may be needed is for testing or pair programming.

I do realize that this is not always possible in every organization so I invite you to the middle ground: the self-organized cross functional team.

Cross functional means that the team as a whole includes everyone needed to implement any backlog item from beginning to end, including testing. This means that the team will consist of UI designers, Backend Developers, Database Administrators if needed and definitely testers.

Self-organized means that the team decides as a group how to implement those backlog items. This means that if a feature was started by Joe the UI developer but he needs something changed by Jim the DBA then all he needs to do is tell Jim to make that change when he gets a chance, no complex scheduling needed just individuals and their interactions getting things done.

Now in order for this to work you need a lot of collaboration between team members. Please note that this does not mean that the developers spend more time shooting emails back and forth, it means that they spend more time actually interacting. Preferably with real face to face communication.

In many cases a lot of this collaborative talk will be done during the daily standup as developers chat about what they're planning for the day and their impediments, as a Scrum Master you'll want to allow enough of this during the standup for them to plan out who they'll team up with to complete their work but not so much that it makes the standup longer than it should be.

Get used to the phrase "You two should be able to work out the details after the standup, let's keep moving". Also, try to keep the team from planning their individual plans more than 1 or 2 days ahead of time, any more than that and plans become hazy.

You may also consider a couple other options for increasing collaboration (and therefore the team's ability to self-organize) by removing the cubicles and allowing the team to work in a single room with no walls separating them. This way if a developer needs somebody else for a particular change or task they can simply ask them without having to visit their individual office or cube.

When doing this (or when deciding on teams in general) keep in mind your individual team sizes, a team larger than say 9 people will begin to find it difficult to communicate as a group effectively and you'll actually begin to hinder collaboration rather than help it. The ideal team size is 7 plus or minus 2 and the same should hold true for your team rooms.

Finally, it never hurts to encourage the team members to become cross functional as a whole. Introduce the team to pair programming. It's up to them to adopt it or not or to modify it into something that fits their own team culture but the more they can see of code outside of their own specialty then the easier it will be for their team to take on complex work.
Published at DZone with permission of Sean Mchugh, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Timo Lihtinen replied on Wed, 2012/03/14 - 1:32pm

Self Organized teams are a a panacea for many companies. It's nearly impossible to reach this status for the project team. Teams have to go through lots of conflicts, especially if they consist of more than 5 resources, before reaching this level.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.