The Agile Manifesto Principles: Self-Organizing Teams

The best architectures, requirements, and designs emerge from self-organizing teams.

The cultures that are trying to adopt agile are usually command-and-control, because most organizations are. This means that there’s a boss who tells their subordinates what to do, and then those subordinates tell their subordinates what to do.

Agile attempts to flip that script upside down. While command-and-control is a top-down approach, agile promotes self-organizing teams, where teams organize from the bottom up. People at the ground level, actually doing the work, usually have the best ideas on how to get things done the best way, because, well, they’re actually doing the work.

This doesn’t mean there are no rules; this isn’t the wild wild west. Most agile methodologies actually have stricter rules and everyone can see whether you follow the rules you set or not. However, the big shift in responsibility is that agile allows the team to set the rules themselves. You don’t have to use the same processes handed down by the organization or the same processes as the team in the next department. Self-organizing agile teams have the flexibility to figure out what works best for their team.

Each team works differently. Some teams will want to split work one way and another team will want to split it up a different way. Some teams will have someone who shines in one area, and they’ll share the rest of the responsibilities with the rest of the team. Other teams won’t have someone who is really strong in one area, so they’ll all share all the responsibilities. Or they’ll all have specialities. That’s the point. The team gets to decide what works best for the team.

While self-organizing teams get to decide how to organize themselves, there is still oversight, and there are still responsibilities. Someone, in some organizations that’s a product owner, is going to tell you what has to get done, what they need. The teams responsibility is to determine how they’ll deliver the requirements.

Product owner = what
Self-organizing team = how

Making the transition from command-and-control to self-organizing teams will differ from team to team, but one thing to keep in mind is that self-organization is an ongoing process. When team members leave, you’ll have to adapt. When new team members join, you’ll have to adapt. When things aren’t working as well as you think they should, you’ll have to adapt.

Like all agile processes, communication is key and by holding regular retrospectives about the actual self-organization of your team, you can strive for continuous improvement.

Remember, every team’s self-organization will be different, so challenge your team to figure out how you best work together. Then work together to self-organize.

I’d love to continue the conversation with you in the #agile channel on the TechWell Hub.