I’ve long been a believer of the idea that having only a single developer on a project is a recipe for disaster. First and foremost, you’ve got a code-red, emergency-level, bus factor of 1. (Very bad.) The next problem is that you have no buffer for the individual’s personal strengths and weaknesses. For example, if the assigned developer happens to test only base cases and doesn’t check any edge cases for abnormal behavior, the application quality is likely to reflect that.
I was the lone developer earlier in my career, and I didn’t like it. I wanted to be part of a team. I went from one extreme to the other, though, by joining one of the largest development teams in the company.
I soon grew to learn that very large teams have pretty much the same problems as teams-of-one. In my case, we had a team that was so large, nobody could keep track of what anybody else was doing. Or rather, nobody cared. It was too much. Sprint planning was–and continues to be–a challenge because team members can’t stay focused and engaged as we discuss 10 projects that aren’t related to them. Stand-ups are the same: give my update and zone-out for the rest. We were a big team, but we were a team of individuals. And with that came all the same lone-wolf issues. Specialized knowledge was retained by certain people. As new team members joined, they would be given their own projects. Everybody else would be too busy with their own projects and not available to give the amount of attention and detail required and warranted by a new teammate. And, perhaps most concerning of all, the quality of a customer’s project was largely dependent on which developer was assigned to work on it.
So how can this be fixed?
We’re in the process of restructuring the team into smaller, virtual teams. At the same time, we’re working on building and maintaining a true, prioritized backlog.
As we begin the transition, developers will bring their individual projects with them as they join the virtual team. Our prioritization effort included all of the currently active projects, so the teams are essentially pre-loaded with their own mini-backlogs. The teams will be responsible for reviewing these backlogs, re-estimating the amount of effort required to achieve project closure, and executing. Teams will be able to plan and hold themselves accountable. When the team backlog is clear, it’s time to get the next item from the greater-team’s backlog.
That’s the plan, at least. Making our big team more agile is something that I’ve been trying to focus on for the past year and a half. We’ve had some successes and some less-than-successes, but we’re committed to improving. I think this will be a welcomed change, and I’m optimistic that it will energize the team. Developers will be able to work closely with each other in a much more collaborative environment. At the same time, knowledge sharing will occur naturally, and individuals’ strengths and weaknesses will offset each other a bit.
To quote a former co-worker, “I’m feeling pretty jacked right now.” This is a change that I’m passionate about, and I really believe it’s going to help take my team to the next level. I’m sure I’ll post again with an update on our progress, but in the meantime, have you been through a similar experience? I’d love to hear lessons-learned, tips, or advice. Do share!
