I'm aware that the Rational Unified Process (RUP) scales depending on the team and project. I'm also aware of the general outlines provided in The Mythical Man-Month by Fred Brooks regarding team size and structure. However, is there a particular team size in which RUP begins to break down in effectiveness?
A:
I don't know RUP very good but I don't think it is different to other approaches in team size. I find the maximum team size is more or less some constant value. A team size of 7 +/- 2 is always good. If it would go over 9 I would think about splitting.
Norbert Hartl
2009-05-17 14:56:58
A:
I think that should be "RUP claims to scale". YMMV.
What process explicitly says it does NOT scale? Every one that I read about makes the claim.
Scalability has a great deal more to do with the team and its makeup than the process you use.
duffymo
2009-05-17 15:31:06
Scrum teams can't scale - a team of more than 10 people won't work and you are supposed to make multiple, smaller Scrum teams. That's an example of a team that can't scale.
Thomas Owens
2009-05-17 16:34:11
@duffymo: OPEN/Metis (www.openmetis.com) explicitly says that it is aimed to small and medium projects. It will not scale above mid-sized teams. Of course, that kind of honesty is not always present in commercial products.
CesarGon
2010-10-02 19:12:08
@CesarGon - I agree with your point about honesty being rare. These days I think that process is immaterial and teams make the difference. A bad team won't be saved by any process; a good team can make anything "work".
duffymo
2010-10-02 19:34:08
@duffymo: Indeed. However, most of the time we're stuck with average teams rather than brilliant or pathetic ones. And a good process may make a difference there.
CesarGon
2010-10-02 19:40:01
I"m not sure I agree. "Stuck with average teams" - normal distributions say that 68% of all values are within +/- one standard deviation of the norm. Every developer imagines that they and their team are in the right tail of the distribution. You make it sound like an average team is so terrible. I'd say let's figure out how to move the whole distribution to the right so even the left tail individuals and teams are very good. The truth is that neither you, me, nor any process has a great way to measure productivity.
duffymo
2010-10-02 19:43:00
I agree with you; we cannot measure people issues successfully, and I don't think that an average team is terrible. My point was that having a good method can help when you can't afford brilliant developers. And by "can help" I don't mean that it will save your ass from disaster if your team is really bad. I mean that it can make a decent difference if everybody is good enough.
CesarGon
2010-10-03 16:41:14
A:
There is an amusing thesis by Jared Phillips "Team-RUP: An Agent-Based Simulation Study of Team Behavior In Software Development Organizations" that gets into that kind of issues. Recommended: http://etd.auburn.edu/etd/handle/10415/497
CesarGon
2009-11-25 08:43:40
What's your connection with this thesis? Do you have a relationship of some kind to be promoting it? Or is amusement sufficient? Personally, I think RUP and all its variants are failures. The inventors keep trying to sell that snake oil, but it's not taking.
duffymo
2010-10-03 17:49:02
No, I have no connection whatsoever with the work, and I do not intend to promote it beyond the mere interest that it may have as a piece of academic work. I recommend it to the OP as a means to learn about the problem that he mentions in his question, namely team size issues when using RUP. On your comment about RUP being a failure, I quite agree with you if you define failure in terms of technical faithfulness; a great deal of my careeer has been devoted to finding alternatives to RUP. Howevever, if you define failure in terms of money-making, then RUP may have been quite successful!
CesarGon
2010-10-03 21:17:48