Learning to Self-organize
The concept of self-organizing teams is one of the most important—and often misunderstood—foundations of successful software development. In my experience, newbie agile teams struggle to learn how to self-organize. We’re used to having some manager come tell us what the problem is and what we should do to solve it. In a self-organizing team, we use retrospectives to identify our biggest impediments and think of small experiments to chip away at our problems.
Self-organization doesn’t mean the team doesn’t need leadership. There are some problems that require intervention by a manager. For example, if a team member refuses to go along with the practices the team members have agreed to adopt, and the team is unable to influence this person’s behavior over time, then a manager should step in.
We need the right people on our team, and tough decisions may be required if someone just doesn’t fit.
I started my own agile career working on teams that adopted Extreme Programming (XP). We followed the XP values and principles, using all of the XP practices with the help of our team XP coach.
When I joined my first Scrum team in 2003, I found that a truly self-organized team was something a bit different. In the early stages of our agile transition, we had so many problems that we barely knew where to start. So, we started by deciding on our commitment to quality: We’d deliver the best software product that we possibly could. We looked around to see what practices had been shown to improve quality and started learning them.
In our first year as an agile team, we sometimes felt stuck. Our manager suggested that we figure out our one biggest obstacle. What one thing could we do that would help us move forward?
On one occasion, we decided that our biggest issues involved our database and that we should hire a DBA to help. We usually used big visible charts to help us focus on a particular issue and the experiment we were trying to overcome it. For example, when we committed to having a stable build by two days before the end of the sprint, we put big countdown numbers on our task board—e.g., “3 days until we must have a stable build.”
Teams need plenty of slack time to learn how to self-organize. They need management support to be free to experiment, fail, and learn, so they can innovate. They require a manager who knows when to step in and help. They must spend years together so they can jell as a team, developing the level of trust that allows a diversity of viewpoints, healthy debates, and the ability to pull together to meet big challenges head on.
The investment in self-organizing is huge—but so are the returns. Take time to learn how your team can self-organize.
