Statement 1: Agile development works better for smaller teams and is more difficult for larger teams, e.g. refactoring can be done only for small systems and great developers.
a. Do you have experiences or data that confirm or refute this statement? (Briefly explain) b. Can you refine the statement based on your experience (e.g., XP works better for smaller teams but scrum does not, agile works better for teams of size 8 or less, agile works just as well for larger teams as long as the system domain is well understood)?
The appropriateness of agile methodologies depends on more than just size.
Gary Pollice - Some agile techniques are better suited for small teams.
Some agile techniques clearly work better for small teams. XP for instance, was designed for teams of around 10 or less. One of the problems is that, as Allistair Cockburn says: “agile is a point of view,” and the way people will use the word agile is quite loose. The principles and practices on the Agile Alliance Web site provide, in my opinion, one way of approaching what I think of as agility. I do not believe it is a definition of agile.
Size is but one of many factors that will determine when your process may be more agile. In this case, I think of agile as one that minimizes process overhead, favoring the use of tacit knowledge transfer over explicitly documenting knowledge and decisions. Other factors are geographical distribution of the team (the whole team, not just developers), externally imposed regulations, risk, and many others.
My experience has been that you need to find the “sweet spot” as Boehm talks about for the process and the project. I would say that the context in which you work directly affects the amount of agility, or plan-driven aspects of the process you apply. I have seen small teams of five that have to have a rigid process because they work in life-critical software applications, and teams of 30 or more that use many loosely coupled practices to deliver software regularly on a monthly release schedule.
Evidence for use by small teams.
Frank Maurer
We have some empirical data from an industrial case study that shows that agile practices seem to work well for small teams (summary is attached as position statement). We do not know yet how scalable the practices are. The team use collaborative ownership, pair programming (mostly), test-first programming (partially) and lightweight planning practices. The customer was closely working with the team (initially) and later on call. A paper on our results is available and under review.
Evidence for use by large teams.
Scott Ambler: Agile modeling has worked for teams of up to 40 developers.
Most of my experience applying agile methods has been with smaller teams although I have worked on projects with up to 40 developers who were taking an Agile Modeling approach.
Erdogmus & Martin: XP should work for teams of more than 7 pairs.
During our training course, the size of the development team was 14 in the first week and 12 in the second, 7 of which were newcomers who got integrated into existing team mainly through the hands-on project. Nobody did XP hands-on before and the experience level of the participants varied largely. Except for one pair, nobody had worked together before. It worked surprisingly well considering that the length of the iterations and scope of tasks were artificially small, thus increasing the communication overhead relative to iteration size, and the mid-project turnover was drastic. It seems like communication is the overriding factor that limits team size. With 6 to 7 pairs, yes chaos reigned for a while, especially at the beginning of each iteration, but the team coped by coming up with novel strategies on the fly. This leads us to believe that for an experienced team in a real project and in the ideal physical environment, team sizes of greater than 7 pairs should be feasible. However, we have no idea what the absolute upper limit is.
Tim Mackinnon: Evidence for large teams that work (and small ones that don't).
I can both confirm and refute. I have worked for 3 years in a small team (8-12 people) that was created to build a product using strictly XP development practices. We noticed that when our team was split into two parts, one part being the core (more skilled) technology team and the second being the perceived secondary application assembly team, that the second team had much more difficulties achieving their goals and ran into much more difficulties with the practices. The second team had slightly less skilled people, however when we joined to form one larger team we overcame these problems. (Note: all developers were hired by pairing with existing team members during their interview, and an aptitude for XP was required. The technical skill level ranged from fresh graduates to 7+ year veterans). My belief is that it is more a question of discipline and culture than skill and size. On these lines, I have also worked for a much larger development team (at OTI) which was an early adopter of many agile practices and which was highly successful with a size of about 50-80 developers distributed across the world (in teams ranging from 30 to 12 to 5). This company was noted as being composed of great developers however the discipline of those developers was again a common theme.
Randy Miller:
I have experience that refutes this statement. Specifically, we have large FDD teams and medium XP teams. The idea that agile processes work only for small teams is completely false. Creating software with large teams requires a different kind of skill (like embedded software).
Don Wells: Agile methods have worked for teams of up to 150 developers.
I have mostly done agile methods with small teams to date. In that context I don't see any reason why agile methods should not scale larger with proper management. The largest team I have been with was 150 people. [More detail on this team is below.]
Scale-up strategies:
Scott Ambler: Agile methodologies can scale up by adopting a "team of teams" approach.
Larger teams can adopt agile techniques if they choose to do so. They must rethink their approach to development and organize themselves in such a way as to take advantage of agile techniques. The most common approach is to break the larger effort up into smaller ones.
Peter Hantos: Agile methodologies can scale up, but published practices do not address this issue yet.
The team-size issue is misrepresented in the discussions. In my opinion skill, communication and comprehension limits will determine the optimal team size. In response to scope increase, teams of teams would have to be created, instead of a knee-jerk increase of the team size (and the eventual stop at 50 or whatever the number de jour is…). Agile methodologies (published practices…) do not really address this issue.
Refactoring is misrepresented as well. Refactoring works well for a single person, or the agile "pair". It might involve the complete, repeated restructuring of their own design and code. If the need for change goes beyond the boundaries of their own code, then basically a need has arisen for refactoring the architecture, involving interfaces, maybe middleware and possibly many other modules.
Agile development can be chosen for smaller scope projects, to be implemented by smaller teams. The currently used and published agile methodologies do not provide the right tools for achieving agility in teams working on larger scope projects.
Ken Schwaber: Agile methods have agile scaling mechanisms.
[Statement 1] is a misunderstanding that arises from agile processes using small teams to maximize self-organizing capabilities. Just like all methodologies, Agile has numerous techniques for scaling these small teams.
Don Wells: Agile methods scale if used with agile management.
The largest team I have been with was 150 people. That team was divided into smaller groups each with it's own methodology. All the groups used an ad hoc method to deliver rapidly. The problem with that project was coordination between groups was very difficult. The different groups produced both software and hardware. Many groups produced products that were to be tightly integrated into another group's output. My group solved many of the coordination problems by quickly building a few software tools to take everyone's products and check for integration issues. In many cases it saved us from enormous problems later. There was an instance when a problem threatened to put the project way behind schedule. Within hours our agile team produced an alternate schedule that took into account the new constraints and still deliver on time. So to answer the question, if you want a large team to go agile you must go all the way and shed any obsolete concepts you might have about coordinating large teams and develop your own agile coordination mechanism. New methods need new management.
c. Can you cite any publications that directly address this statement? (Give citations)
Scott Ambler, Agile Architectural Modeling. www.agilemodeling.com/essays/agileArchitecture.htm
(Contributed by Scott Ambler)
A
Practical Guide to XP (Prentice Hall, 2002)
(Contributed by Randy
Miller)
d. What are the implications if this statement is true? How should we change development practices to address this problem?
Scott Ambler:
Why is this a problem? The vast majority of project teams are actually this size anyway, and not everyone needs to be following agile methodologies. The Enterprise Unified Process (EUP), www.ronin-intl.com/publications/unifiedProcess.html is one option.
Tim Mackinnon:
I would hire the best developers you can and try and break teams into smaller sizes if possible. Ensure a mixed range of skills with a good ratio of highly skilled to less skilled developers. Ensure all team members exhibit a tendency to agile discipline.
Frank Maurer:
Adopt agile methods for small teams.
Gary Pollice:
To me, the implication is this: just as we tell software developers that they need to have a technical toolkit, for example, good O-O techniques, knowledge of patterns, and so on, we need to develop a process-oriented toolkit of practices and patterns and learn how to apply common sense to implementing them on different types of projects.
Ken Schwaber:
That we should stop saying that it isn't true.
Don Wells: