Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
3 replies Latest Post - ‏2011-01-17T19:08:45Z by jruehlin
BobPalank
BobPalank
6 Posts
ACCEPTED ANSWER

Pinned topic OpenUP Team Size Guidance

‏2010-11-06T12:50:59Z |
"OpenUP is a process for small, co-located teams. It can be used as-is but, if your team has significantly different characteristics, the process should be modified or extended to address those needs."

Does small mean a project size of under 20 team members for a duration of less than 25 months?

In applying OpenUP, can User Stories be used instead of Use Cases ?

It seems scenarios are not defined. Are they ever not used?

Bob
Updated on 2011-01-17T19:08:45Z at 2011-01-17T19:08:45Z by jruehlin
  • ScottAmbler
    ScottAmbler
    158 Posts
    ACCEPTED ANSWER

    Re: OpenUP Team Size Guidance

    ‏2010-11-10T15:25:30Z  in response to BobPalank
    Size is in the eye of the beholder. Best definition that I ever saw for large team size was 20% bigger than what you've been successful at. So, one person might consider a team of 10 people to be large but another person consider it quite small.

    In my survey where I examined the effects of team size on success rates, see http://www.ambysoft.com/surveys/stateOfITUnion201007.html , I used the following definitions: small was 1-10, medium was 11 to 25 and large was 26 or more.

    • Scott
  • BruceMacIsaac
    BruceMacIsaac
    19 Posts
    ACCEPTED ANSWER

    Re: OpenUP Team Size Guidance

    ‏2010-12-06T22:30:12Z  in response to BobPalank
    In applying OpenUP, user stories can definitely be used in place of use cases.
    In fact, the latest Rational Method Composer practices library includes a practice for story-driven development, which can be used as an alternative to use cases.
    Rational Method Composer customers can be download the latest library here:
    http://www.ibm.com/support/docview.wss?rs=2360&uid=swg24028417

    Bruce MacIsaac
    Manager Rational Method Composer Practices/RUP/OpenUP
  • jruehlin
    jruehlin
    12 Posts
    ACCEPTED ANSWER

    Re: OpenUP Team Size Guidance

    ‏2011-01-17T19:08:45Z  in response to BobPalank
    The size of a "small" team was a big debate we had when writing OpenUP. There's a lot of variation of opinion, and we never agreed on a firm number. In my research on team sizes, I came to the conclusion that a small team was 5 or fewer people. Six people, even experienced people, are bigger than a small team.

    This is mostly due to the communication overhead required by members of a team. After 5 people, the overhead starts to grow asymptotically. I haven't found any research on what happens to a team at this point, but it's a good bet that something different starts to occur! Every person added to a team after the 5th person raises the communication overhead significantly and in a non-linear way. It's likely that after 5 people, the nature of how people communicate need to change because they can no longer scale the techniques they used when they were a smaller team.

    Many Agile techniques depend on teams that can take advantage of lower communication overhead. This includes things like creating fewer artifacts. You can get away with this for a while, but since you can't communicate with 8 people as efficiently as you can 3, you need to have formalized artifacts and reviews when teams get bigger. And "bigger" happens quickly.

    There's also the issue of team members "hiding out" versus taking responsibility for the team. Research indicates that a team size of 3 is ideal for maximizing the amount of work done (because people can't hide out) by each individual. Performance per team member goes down as more members are added after that.

    So I wound up with 5 being the largest sized team that can be considered small. 3 or 4 is better. In my experience, OpenUP out-of-the-box will work best for small teams defined in this way. Of course, it can be scaled to larger teams by adopting other practices or customizing OpenUP practices.

    • Jim

    Jim Ruehlin, IBM Rational Software
    Jazz Jumpstart Team, Processes and Practices
    www.jazzpractices.blogspot.com
    EPF Committer
    jruehlin@us.ibm.com