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!
adamprescott.net 
I have always loathed the way we handle stand ups. They should be quick, with each person taking less than a minute on their turn. Did you accomplish what you wanted to yesterday? What are you doing today? Do you forsee any roadblocks?
Instead, the majority of developers wish to go into full details what occurred the prior day and taking 5-10 minutes just to explain the prior day, then another 5 on what they hope to get done that day. Its one thing to say, “I had an issue yesterday, basic details are this, if someone would meet with me after this meeting, I would appreciate it.”
This is ok if you have a small team of 3-5 people, but some of the teams are 10+ and standups take 30 minutes.
Sounds like you are on the right track and I hope it works 🙂
We’re going to try it out next sprint. Our team is 12 people now. We keep it under 15 minutes, but most people just check-out until it’s their turn; the value of the standup is really lost.
With the virtual teams, groups of 3-4 will have their own standups. The individuals in the group should be focusing their effort toward a common goal, so what happened yesterday and what’s happening today becomes relevant. That’s the plan/hope, at least.
I probably won’t have a good feel for how it’s going until mid-to-late January–once we’ve had a chance to get past the holidays and through a few sprints.