Why Self-Organizing Teams Are so Important
TLDR: No one likes having to keep their migraine medication handy at all times.
Join the DZone community and get the full member experience.Join For Free
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.
You may also like: The Importance of Agile Leaders
Yes, I realize this is a mouthful.
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.
Self-Organizing Teams for the Win
Luckily, the solution is actually rather easy: Make the management of this complexity as close to the work as possible, which 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.
Best of Both Worlds
Cross-functional teams are ones that 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-organizing 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 one or two 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 nine 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 seven plus or minus two 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, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.