Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Amr Elssamadisy on Jul 24, 2007
Using Agile methods with large teams is a reality - the old Agile = Small Team equation is no longer valid. Nonetheless, team size is still an issue. How important is team size and what, if anything, should we do about it?
An interesting discussion started on the ScrumDevelopmentList when one member suggested that team size should be anywhere between half a dozen to two dozen:
split the team - depending on the source, the recommended size seems to vary between half a dozen and two dozen team members.
Huh? In Scrum the recommended team size is 7 plus or minus 2. Isn't this a Scrum forum?
A conversation ensued regarding the definition of Scrum and team size. When the dust started to settle, Roy Morien commented and asked:
No direct answers have been given yet on ScrumDevelopmentList, but Tom Scott blogged about a presentation given by Dave Thomas at Spa 2007 that touches on this subject:Scrum overcomes these problems to a considerable extent with it's emphasis, at least philosophically, on regular, but short, meetings, on collaborative actions, on 'information radiators' etc. But Scrum itself cannot fully overcome the problem of big teams. This matter goes back decades ... James Martin over 10 years ago talked about "SWAT" Teams (Specialists with Advanced Tools, if I recall correctly), which were of limited size ... 5 or 7 or so, but the emphasis on small, for effectiveness.
What seems to me to be a more rewarding and informative discussion is about the ability of agile methods, and agile project management methods, to 'scale up' to large teams, and large projects. Or, probably more to the point, the best team sizes, and the possibility of multiple teams, and the problems of multiple teams, if and when using agile methods.
So ... straight question(s) ... what is the optimal team size (regardless of any prescription by Scrum officianados)? Is Scrum able to scale up to be used by larger teams? How can Scrum principles and practices be applied in a multiple team environment? AND is there any research, experience, or anecdotal evidence and publications to support the answers?
The answer? [to the question How can small teams can deliver big projects?] Divide the big project into small independent projects. Nothing too shocking about that. But there is still a question about how to organise the work and structure the project. Earlier in the year I attended Spa 2007 where Dave Thomas outlined one approach.
The objective is to let projects have freedom to create the solutions to specific problems but to coordinate activity between projects. The approach is to structure the work into four phases:
And, Pascal Pratmarty on his blog wrote about the Inefficiencies and large teams:
When is it profitable for a team to grow? Do we really need big teams to handle big projects?
I deplore the fact that so many people measure the importance of a software project by the sole size of the team working on it.
Many members certainly imply more brainpower potential, but also a greater difficulty to realize this potential. Actually, I notice two common pitfalls for crowded teams, namely miscommunication and lack of motivation.
There is consensus that small teams are much more efficient and productive than large teams. But larger teams are still being used to cut more code because small teams lack the capacity to produce as much code - or do they?s
Learning to be a Good Product Owner: Foundation Skills
Technical Debt and Design Death
The approach is to structure the work into four phases:
Envisioning;
Definition;
Development and;
Release.
Haven't I seen a four phased approach before? IMHO, large projects require more of a UP approach. The larger your project gets, the more difficult it gets for small teams to see the big picture. Therefore a well (not necessarily over-) documented process is indispensible.
This is a trick question, asked by a department that had already hired programmers and assigned budget, and decided to go Agile after the fact.
The real question is: we have x high-value stories, initially estimated at y and the client needs this part of the project done by z. We need how many teams for the next 3 iterations?
The issue is that you can do this work two ways: throw everyone at it, and suffer massive ineffectiveness as a large team chews up time and energy trying to find ways to communicate; or start small, grow your teams as the requirements start to get fleshed out, and see if you can really do it with half the people.
Because, we've all seen it happen: 100 people start working, they spend weeks/months getting up to speed, and then everything changes... oops, we only need half this software, suddenly!
The problem is: this would leave a bunch of skilled developers sitting idle, and once grabbed up by other departments (if they have budget) they're not likely to be coming back... something needs to change in the way we staff development work. Part of the problem is the traditional perception of the word "Project" imo.
Splitting developers into smaller teams will only get you so far. You also need to manage the overhead at the project management level, and there things like Technical Debt, code quality and your architecture start to play an increasingly important role as projects come to a close.
In my opinion, regarless of your methodologies large teams don't scale. In fact, the usual problems become much bigger and in the end unmanageable.
Customers are certainly to blame for big team sizes. Many customers want huge applications and want everything together, instead of building things incrementally.
If you're thinking about a co-located team, you can fit eight developers (four pairs) around a rectangular table, and have the property that no pair is farther away from any other than diagonally across the table, in earshot of each other. If you add a fifth pair, one of the pairs is going to have to sit somewhere where there'll be another pair between them and their farther-away teammates, which prevents them from easily asking questions... or from overhearing a conversation between pairing partners and chiming in.
I've heard Werner Vogels, Amazon’s CTO, talk about their approach and I understand that they limit their project teams to 8-10 people. If they can eat more than two pizzas, it’s too large.
I'm a (dirty, rotten, etc...) consultant. I can't really go into a company and tell them "you know, you should really get rid of 90 out of the 100 people you've got - just leave me with the best and we'll get things done better, faster, cheaper...". (I've tried - didn't work.)
It seems that:
1) once a team is big, then it is stuck,
2) once a company gets used to ultra-large teams (250+) it is an epidemic,
3) I'm not really willing to bet my life that 10 people can do the work of 100, let alone 250...
IMHO, large projects require more of a UP approach.
Why?
a) the inception phase? (aka analysis/design paralysis)
b) the elaboration phase? (aka BDUF architecture not pulled by requirements)
c) construction? (aka follow the elaboration phase and build more)
d) transition? (testing/deployment? shoulda done it earlier)
Having fun with the UP - or is it now the 'Agile' UP ? ;)
IMHO, large projects require more of a UP approach.
Why?
a) the inception phase? (aka analysis/design paralysis)
b) the elaboration phase? (aka BDUF architecture not pulled by requirements)
c) construction? (aka follow the elaboration phase and build more)
d) transition? (testing/deployment? shoulda done it earlier)
Having fun with the UP - or is it now the 'Agile' UP ? ;)
I think you're mixing up UP with traditional waterfall. Even -well practiced- UP starts testing as early as possible, so it's not something you postpone to transition. Even in inception test automation can be taken care of. Don't forget that UP is just as iterative as agile methods.
Inception and elaboration are not only about analysis, design and architecture. It's all about finding out with a small (you might call it a two pizza or whatever) team whether it's feasable or not to bring in your 100 person team in construction and elaboration. You can however argue as a consultant that your customer isn't waiting for you to decide whether or not you will be needing the 100 persons that are already hired.
To come back on what you'd like to call 'Agile' UP: I consider software engineering in general as a set of - let's say - 10 best practices. If every methodology - beit UP, Lean, SCRUM ... - takes 5 to 7 of these best practices and puts them in its box, you will surely see some overlap. E.g. iterative development, continuous integration, test driven development.
So on a day to day basis, there's not that much difference. In the end we all have to deliver a product.
I love it!! :-D
One approach might be to convince them to create smaller sub-projects, so each project has fewer people to deal with and less communication overhead?
A good friend of mine had his children at pretty well the same time I had mine. Once when our kids were quite young, we were comparing our respective backpacks full of support gear. I noticed that the bag he was carrying was considerably smaller than mine, with a proportionally lower weight!
He explained that his philosophy when buying a bag was to figure out what was the smallest bag possible that he could get away with, and then he bought the next smallest one.
In my experience, this philosophy applies to team size as well, at least at the beginning of a development effort. Determine the smallest possible team size and then (assuming that it isn't 1), subtract one from it. Only increase the size of the team when there is absolutely no other option.
The mistake that I have seen made many times is to assume that a project or development effort requires a large team. Even if the end product is large, that doesn't necessarily equate to having a large team to build it.
Dave Rooney
Mayford Technologies
I've seen standups with 20 to 30 people in places where "7 plus or minus 2" was seen as a naive suggestion.
It just doesn't accomplish what it's supposed to. "7 + or - 2" comes from psychology - it's the number of things the average person can hold in their head at once (I'm paraphrasing). Yes, everyone speaks. But it's impossible to remember and synthesize all the information given. Also, people tend to give less meaningful information because the meeting is just too long otherwise. What actually happens is several logical teams gather in one huge circle, and people listen to the news from the people actually related to their own work (their "logical" team). All that's gained is the SM is split across too many people, too many problems to solve. The team can no longer hear one another becuase their space is either too big or subdivided.
Large teams, of necessity, compromise many other agile practices and principles. Team size is not an independent variable at all.
The classic answer, I believe, is: learn to write small, independent stories, and realize the importance of adequate Scrum Master coverage. Then you can split teams and still deliver the work.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
12 comments
Watch Thread Reply