After reading this, I saw that there seems to be a lot of disagreement over how agile teams should be structured within a group of developers with varying ability (aka almost all teams). Should all the best developers be put on their own teams and be given the highest priority work? This will pretty much ensure that the most important tasks will get done. At the same time, you are then left with the "less than perfect" teams elsewhere racking up technical debt, even if it is only on low priority tasks. On the other hand, evenly distributed teams could have the benefit of making your lagging developers a bit better, but has the potential to demotivate your heaviest hitters. Also, if you mix in a bunch of good design patterns with a bunch of terrible anti-patterns, you can really end up with something that might as well be a bunch of anti-patterns. All teams have their strong coders and their not so strong coders, so how should this be dealt with?
-
Seems like this: programmers.stackexchange.com/questions/76890/….– S.LottJun 1, 2011 at 13:41
-
@Lott Similar, but that is referring to keeping an overly dominant developer in check if I remember correctly.– Morgan HerlockerJun 1, 2011 at 14:00
-
2Most decent character systems let you redistribute talent points periodically.– FrustratedWithFormsDesignerJun 1, 2011 at 15:00
-
1Sorry, too much Mass Effect 2 (and other games) these days. :P– FrustratedWithFormsDesignerJun 1, 2011 at 15:00
7 Answers
There are some known risks with A-Teams, but if the dynamics are right then I think yes, I'd put my strongest people on the most important projects along with the junior developer(s) with the most potential. For your lower priority projects you need a good team leader if at all possible to keep them from going to far off the rails. Technical debt is going to happen no matter what. Not all technical debt is equal; the cost/liability of technical debt is in proportion to the business value of the project in the first place, so while your lower priority projects may have more warts the cost of those is probably still much less than significant problems on your high priority projects would be.
I remember when I was at uni one of our professors telling us an anecdote about team structures (I had a look for the paper he was talking about just now but I can't seem to find it).
Basically, the story went as follows:
A group of programmers were split into groups based on ability, with the worst x programmers being grouped together, the next x grouped together, etc., and the very best ones grouped together.
They were all assigned the same task, and given a set timeframe in which to complete it.
At the end of the timeframe the organisers looked at the solutions to the tasks, and they, to their surprise, discovered that the best performing solution came from the team made up of average people. In contrast, the team made up of the A* programmers made one of the worst solutions because they spent all their time arguing about what was the best solution.
If you need a team that's going to get stuff done get a bunch of average guys and a dominant guy who can lead, was the conclusion of the study (If I remember correctly), otherwise the more dominant members will spend more time fighting than getting stuff done!
-
1Yes this is one of the primary A-Team problems but concluding that it universally applies to all teams based on this study would be a mistake.– JeremyJun 1, 2011 at 15:14
-
Agreed: not everyone is the same, nor will equivalent groups have the same dynamics, but it's a good anecdote nonetheless!– Ed JamesJun 1, 2011 at 15:26
-
1Well, put a bunch of devs together that all write only path-finding algorithms and this is what you get... Jun 1, 2011 at 21:04
-
lol - you can't find the paper most likely because the professor just made the story up on the spot. ;-) Jun 1, 2011 at 23:19
-
The vast majority of inexperienced developers may not be able to come up with robust, elegant designs on their own, but they can recognize and understand it when they see one. If they can't, then they usually lack either the aptitude or the preparation to have been hired in the first place.
There are also some more experienced developers who are capable of understanding very complex software designs, but lack the discretion to know when something simpler would be better.
In my experience you usually only have permanent problems with mixed teams if they contain unprepared members, needlessly complex members, or both. Otherwise, if your team has issues they can usually be fixed with better communication or assigning appropriate roles.
-
I can only assume from your first paragraph that you don't work in an environment where the demand for developers exceeds the supply. Many of us do. :-) Jun 1, 2011 at 21:15
Grouping best people to single team can look like a great short term solution but it is failure in long term scope and it has additional costs. For example my company prefers when people learning from their more skilled colleagues instead of paying for trainings. If you separate best people they will not be able to transfer knowledge to less skilled people. In short term your best teams can perform well but because of lacking knowledge transfers the number of skilled people will not increase. It is much better to have less performed team at the beginning and increase performance over all teams as people become more skilled.
Moreover what happens if skilled people decide to leave? Who will take their projects?
Another point is that team should be composed from people with different skill sets. You will always have easy tasks (and boring tasks) which are too expensive to be done by the most senior developers.
Those that can't teach, do...
I think there are more factors to consider.
You will get the most value by distributing those that can teach as team leads. They can teach the other members of the team and help elevate the quality of their work.
Not all senior programmers will make good leads. That ability to communicate information is a skill in and of itself. This skill is not something that develops through programming experience. It develops through teaching and explaining.
-
I agree but in the same time you can learn from the code written by other developers. If senior developers are not part of your team you cannot learn from them this way. Jun 2, 2011 at 15:01
-
@Ladislav Mrnka: I'm not saying that you shouldn't distribute senior developers throughout different teams. The ability to learn from code will vary. This also assumes devs will take the time to learn from code which many do not. Jun 2, 2011 at 15:39
Assigning an 'A' team, has two significant issues. First is compatibility. Having teams that get along and work well together is far more important then their "ability". Now this may be two "high" skill programmers, two "low" skill programmers, or a mix. The fact they can work well together means they will be more productive.
The second issue deals with growth. Two "low" skill programmers will not learn much from each other, besides bad habits. Likewise two "high" skilled programmers will not learn much from each other. However mixing "low" and high" skill levels will help improve the abilities of the "low" skill. They also will improve the abilities of the "high" skilled. How? trying to teach a subject will quickly find your weak points in that subject. I don't considered a skill "mastered" until you can teach it to someone else.
From the other side of the coin, I think it makes sense to keep teams which can "keep up" with each other. Your A-Team type programmers don't want to wait on the B-Team types to get their bits done. Your B-Team types might be intimated by the A-Team style workflow.
