Is XP good for big teams

Question

How does a team of say 50 work on an XP project?

I would assume that the project would need to be divided in to multiple modules before all these people can start working on anything.. but this may be against XP practices (BUFD)

Also if many people start implementing user stories at the same time, won't there be duplication (same class would written by more than 1 person)... or say some data access functionality is need by every story in the 1st iteration.. are each developer supposed to write the data access and merge later on.. I am little confused..

Answer 1

If you want to use an XP style of development, you need to break them down into teams of probably about 4-5.

Each team would be responsible for different feature sets in different parts of the application, for example one team would be responsible for the data layer, another on the business layer, another on the communication layer, and additional teams on the user interface.

Cross programming teams on top of the same functionality is going to be difficult, that is why I recommended the break-up into logical areas of the software.

I personally have seen extremely agile methods employed in large development environments, they work, but you have to segregate the teams so they can work independently with communication streams to the other teams for integration.

Answer 2

The title of this question indicates that you are open to considering alternative methodologies yet the first sentence from the description indicates that you are not.

Breaking the big team up into many small teams, all handling different functionality, is most probably a good idea no matter what methodology you use.

Do you have 50 coders or 50 people total? If the latter, then does that 50 include software architects, information architects, graphic designers, interaction designers, managers, quality assurance engineers, subject matter experts? What percentages of each role are on the team?

Also, what percentage of your coders have junior experience?

If a significant percentage of that 50 are coders, then do consider breaking up the team into smaller teams both horizontally and vertically. Horizontal partitioning becomes even more compelling if your solutions must be highly scalable.

Few people mention this now but one of the original components of XP was pair programming which means one keyboard for every two coders. That makes XP really compelling if most of your coders are inexperienced.

Answer 3

First, remember that 3 women cannot ever produce a baby in 3 months; adding more women doesn't improve the rate of production.

50 people on a project smacks of throwing resources at a problem in the hope that somehow 9 women will produce a baby in a month.

However, since you're presumably stuck with 50 people, there are several things that have to be done.

1. You have to have a solid, working infrastructure so that everyone can develop incrementally. If the first release includes infrastructure, web servers, databases, failover, backups, SSO, and everything else, the first release will take a year and have no value to anyone (except developers).

   Therefore, a team of 4-5 has to get a solid, usable, extensible infrastructure up and running ASAP. Pick products, install, configure. Build QA/test and development environments. DO NOT BUILD PRODUCTION YET. You won't know enough. Conduct training by building something that will be thrown away.

   Or. Leverage an existing infrastructure that all 50 people know and are comfortable with.

2. You have to have a common, usable data environment. This includes your classes, your relational tables and your ORM. Someone needs to spike this technology and make sure all the pieces work. They will supply expertise to the other 35 or so developers.

   Therefore, a team of 4-5 needs to support shared data. Data is precious and you can't simply allow each team to define their own data as needed. XP is not anarchy.

3. You have to have a common, usable presentation layer. This includes your JSP or templates, your CSS's, your javascript and all that. Someone needs to spike this technology to make sure all the pieces work. They will supply expertise to the other 35 or so developers

4. You need a unit testing framework and nightly build. With 50 people, 10 (at least) must be doing QA of some kind or other.

5. Someone has to resolve operational issues. Startup, shutdown, backup, failover, upgrades, patches, upgrades and upgrades. You really have to understand upgrades (OS, components, your own shared layers, your own applications.) Upgrades are hard, and someone has to work out configuration management (what's running where) as well as source code control and the like. (Backups, log management, etc.)

What do we have?

• 5 infrastructure
• 5 database support
• 5 presentation support
• 5 deployment/operationalization
• 10 QA

If you have other layers (web services, for example) you may have other share-services teams.

You must have a QA leader, and an architectural leader who do nothing but coordinate and articulate a single, shared vision.

One architect. No second-guessing.

The other 20 people will be broken into 4 teams that somehow must coordinate among them selves and with the other layers. [4 is a large number. Bad things will happen because of overlaps and gaps.]

You'll have to break up the user stories into some priority scheme and locate the top 4 and farm them out to get worked on. After that, each team pulls the next available story when it finishes what it's working on.

Note that you MUST coordinate among all 9 teams on a daily basis to prevent redundant development or divergent project visions. I don't have any useful advice on how to keep 9 teams coordinated in a brisk, efficient way.

Answer 4

Note: XP is a set of agile engineering practices. It works best if combined with SCRUM which provides a set of project management practices.

No BUFD doesn't mean no design.

You can do enough initial design to understand the major pieces, and provide detail that you know. From there you can organize the teams given that 50 is to large. Teams of 12 to 20 (with each team having an IM, analyst, developers and testers in the ration of 1 analyst per 2 pairs and one tester per pair) are a good size.

With an initial design done on the whiteboard and discussed between the developers, you will avoid most duplication.

Given that story cards identify business functionality, the developers, during tasking will determine the work the cards entails and the pieces of the system that are touched (GUI?, Data Access Layer?, Database? etc.). Developers will discuss the design during tasking as they identify the detail. Once tasking is done, the work is known and the developers sign up for the work.

At this point the work is organized and can begin. Via pairing and and open work space for the team, issues can be discussed and questions answered as they are encountered.