Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Seems like this: programmers.stackexchange.com/questions/76890/…. –  S.Lott Jun 1 '11 at 13:41
    
@Lott Similar, but that is referring to keeping an overly dominant developer in check if I remember correctly. –  Morgan Herlocker Jun 1 '11 at 14:00
2  
Most decent character systems let you redistribute talent points periodically. –  FrustratedWithFormsDesigner Jun 1 '11 at 15:00
1  
Sorry, too much Mass Effect 2 (and other games) these days. :P –  FrustratedWithFormsDesigner Jun 1 '11 at 15:00

7 Answers 7

up vote 11 down vote accepted

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.

share|improve this answer
    
+1 for relating technical debt to business value. –  Macke Jun 1 '11 at 14:26

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!

share|improve this answer
1  
Yes 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. –  Jeremy Jun 1 '11 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 Woodcock Jun 1 '11 at 15:26
1  
Well, put a bunch of devs together that all write only path-finding algorithms and this is what you get... –  Steve Evers Jun 1 '11 at 21:04
    
lol - you can't find the paper most likely because the professor just made the story up on the spot. ;-) –  Steven A. Lowe Jun 1 '11 at 23:19
    
That wouldn't surprise me :D –  Ed Woodcock Jun 2 '11 at 8:31

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.

share|improve this answer
    
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. :-) –  Carson63000 Jun 1 '11 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.

share|improve this answer

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.

share|improve this answer
    
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. –  Ladislav Mrnka Jun 2 '11 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. –  dietbuddha Jun 2 '11 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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.