My team has a decade of experience applying self-organizing teams and pair-programming to reduce wasted productivity in an enterprise banking application.
The Benefits
No Technical Lead
Our self-organizing practices eliminate the need for a technical lead who assigns and follows up on work. No work is assigned to any individual.
Individual Empowerment
Developers are free to remove pain points as needed, so most have a strong sense of ownership. Team members feel empowered to champion for broad changes to the codebase.
Few Meetings
Without the need for significant process or oversight, the team has very few meetings a week. In a survey of the last several months, the average team member had less than three hours of meetings a week.
How does this work?
As amazing as it all sounds, what prevents this process from falling into anarchy? How has this been working for us for over ten years with very little oversight? The team has completely changed three times (roughly a 3.6 year average turnaround) so it can’t only be about “the right people”.
Self-Correction While Maintaining Trust
The author of Reinventing Organizations talks about the concept of “self-correction” that allows self-organizing teams to adapt without writing a thick rule-book of policies. Healthy, self-organizing teams build a simple system that self-corrects instead of adding new policies when trust is abused. Rather than trying to design the perfect rule-book, they let individuals grow into trusted, intelligent agents who are expected to learn and improve.
The author suggests that three things are needed for self-correcting teams:
- A shared understanding of what’s healthy
- Information
- A forum for conversation to trigger self-corrective action
Our Process
Our process has several examples of self-correction, and several places we are still sorting out how to best self-correct. We currently apply these democratically-elected practices:
- Full-time pair-programming on all production code
- No work is assigned to any individual or pair
- Any pair can make any technical decision
- Pairs are shuffled randomly twice a day
- Everyone participates in a five-minute status update twice a day
- Weekly “retrospective” is held to reflect and make changes
Example: Any pair can make any technical decision
Consider the practice that “any pair can make any technical decision.” The information comes when the pairs switch every half-day. Bob and Sally might think designing the module one way is a good idea in the morning, but Sally and Jane might see things with a fresh perspective in the afternoon. The information spreads organically every four hours as a fresh set of eyes gets to see the work. The forum for self-corrective action happens when the new pair discusses the previous session’s decisions.
If a pair makes a technical decision that isn’t ideal, the next pair will have the opportunity to choose to continue down that path or adjust the code to a better solution. To prevent significant rework, we meet once a week for under an hour to chat about the upcoming week’s features and get a rough idea of the direction the team wants to go.
In practice, rework happens only occasionally as everyone strives to produce the best designs they can. No one wants to see their work undone because of a missed requirement or poor design, which prompts a healthy desire to do one’s best.
Example: Work Isn’t Assigned
Work isn’t assigned to pairs or individuals. The shared understanding is that the most valuable thing for the business is for pairs to work through the priority queue of enhancements and technical debt. We promote information with a twice daily status update of what each pair accomplished. We have a retrospective forum once a week to discuss what is healthy and prompt self-corrective action.
In practice, pairs rarely “go rogue”. Only occasionally in the last few years has it happened, and the issues have been resolved through the weekly retrospective. A recent example comes from a pair who semi-secretly stayed on an interesting feature for over a week instead of rotating as agreed. Several other team-members felt like they’d missed out on getting to build it and brought up their feelings in the weekly forum. It turned out there was a legitimate benefit to the pair’s decision to stay on the feature for so long. The conclusion was the pair would’ve gotten a lot more support if they’d been upfront with the team with what they saw and their decision to stay on the project for longer than usual.
Some simple communication would’ve saved everyone some hassle
Rather than adding a new policy to the rule-book, the whole team got a reminder on two great lessons. First, nothing is as simple as it seems. Second, a pinch of communication prevents a pound of hassle.
Application (No, you don’t need to do pair-programming fulltime!)
Self-correction and self-organization is on a continuum. The more your team grows to self-correct, the more benefits you gain.
Not every team should have the same practices for self-correction. Our specific practices of pair-programming, rotating, and pair-empowerment are not magic: they are just good examples of applied self-correction. We have found pair-programming and pair switching to work well for us, but there are infinite ways to grow a system that self-corrects.
“Trust, but verify.” - Russian proverb
Self-correcting practices allow individuals to perform at their best with fewer rule books, fewer meetings, fewer bottlenecks, and less oversight. Individuals are trusted to perform their best, and the team is provided with a way to discuss improvements. A self-correcting team will find individuals empowered to improve the business in incredible ways.
