Supersize Me

Software Development
Agile software processes such as Extreme Programming (XP) and Agile MSF (Microsoft Solutions Framework) are often applied to project teams of 10 or fewer people; as a result, many practitioners believe that agile development is applicable only to small teams. Luckily, 70 percent of all software development teams are of this size, so it's not such a bad market niche. However, many people have asked me if agile techniques can scale to larger project teams, and the answer is a resounding yes.

Size is in the eye of the beholder—for some people a team of eight is huge; for others a team of 50 is small. A large project, for our purposes, is one that is 20 percent or more larger than what you're used to—although for the sake of this column, let's get specific: A team of 15 people or more will be considered large.

The good news? Agile methods have been successful with large teams. The first Feature Driven Development (FDD) project was 50 people, and the second 150. XP, in conjunction with Scrum, has been successfully used on teams of 50, and I've heard stories of teams of 100. In 2002, Ron Crocker developed an agile process called Grizzly at Motorola for a project team of more than 200 people. It's clear that agile scales.

Are You Sure?

Let's assume that you have a team of 40 people and you want to take an agile approach. The first question to ask is whether you need that many people. I once saw a team of 80 people doing the work of 10 to 20—the other 60 to 70 people were writing useless documentation and attending meetings. At XP 2002, Jim Johnson of the Standish Group told a story about two organizations that had virtually identical requirements and environments. One had decided that a team of four to five people could complete a project in less than a year, whereas the other decided that a team of 70 could do it over several years. Both organizations were right, the first one delivering the system for less than a million dollars, and the second one for over $100 million. Johnson's pricey point? A project team's size is often determined by management expectations, not by the actual nature of the problem being addressed.

You scale agile methods exactly the same way that you scale traditional ones: divide and conquer. Fundamentally, there's no such thing as a 200-person project team; even the biggest behemoth comprises many subprojects. Each subteam should follow an agile process appropriate for its situation and then interface with the other teams and any coordinating or support bodies in an agile manner. For example, four subteams might take an XP-based approach, two subteams might adopt the Agile Unified Process (AUP), and the operational database administrators (DBAs) might follow the Agile Data (AD) method. Scrum could also be used to provide the "management glue" that holds everything together.

For agility in the large to succeed, team members must share the same philo-sophical mindset and follow common standards and guidelines. You'll run into trouble when people take different approaches or work to different standards. For example, if your operational DBAs insist on working in a serial manner, they're facing a serious cultural impedance mismatch with the agile developers. This clash will likely result in significant strife, putting the overall effort at risk. Worse yet, the agile teams may go ahead and do the database work that they require in secret and then simply block the operational DBAs—the database schema will probably suffer, and any work that the operational DBAs do will be a sheer waste.

You Need to Model

The various subteams must work toward a common goal and a common architecture, each focusing on a portion of the overall system. The complete team must agree on the scope of what they're building and how they'll do it. With an Agile Model Driven Development (AMDD) approach, you do a little bit of modeling up front to identify your system's scope and potential architecture, and then model the details in a just-in-time (JIT) manner during construction iterations. On a typical project, you'll spend the first week or two developing these initial models.

On small agile projects, your initial requirements model might be a stack of index cards and a few whiteboard sketches of the business processes that your system will support, as well as your conceptual/domain model. Your architecture model would consist of several sketches addressing the system's technical aspects and optionally a list of critical design decisions. Larger teams do the same, but take their models one step further. The individual requirements should be summarized with a digital list, easily maintained in a simple spreadsheet or database, indicating the subteam that they've been assigned to. This list can later be enhanced with basic management information such as the estimation/ actual effort, the priority and the assigned iteration. The sketches should be captured digitally, either as a snapshot of the hand-drawn sketch or transcribed into a drawing tool such as Visio or a modeling tool such as Rational Software Architect (RSA).

Large agile teams take an interface-driven approach to architecture, in which they define in detail the interfaces to the various subsystems/components early in the project. Once the interfaces to the various subsystems are agreed upon, they can be assigned to individual subteams for parallel development. Any changes to the interfaces are suitably negotiated with the other subteams.

Because project stakeholders are typically more varied for large projects, disagreements as to the requirements do arise. Choose from among several strategies for modifying your approach to working with stakeholders. First, you could adopt Scrum's Product Owner concept and make one stakeholder responsible for eliciting and prioritizing requirements fairly from all other stakeholders. Second, you could add an agile business analyst (see www.agile modeling.com/essays/businessAna lysts.htm) to your team to manage the overall requirements effort. Third, you could simply work with several stakeholders: Each would be seen as the expert in a given subject, and would be responsible for working effectively with their counterparts.

Scrums of Scrums of Scrums of ...

Agile teams often conduct a 15-minute daily stand-up meeting called a scrum, in which each team member shares his current status by answering three questions: What did you do yesterday, what are you going to do today, and what challenges are you facing. This approach works well for small teams of fewer than 10 people, but, as you can imagine, it's a wash for larger teams because of the time it takes for the entire crew to provide their status reports. How to handle the hordes? Hold a "scrum of scrums" to support intra-team coordination. Each subteam holds its daily scrum, and then one member from the subteam attends an intra-team meeting. This strategy can be applied recursively as needed. In this way, everyone on the team knows what everyone within their immediate work group is doing, and information is easily shared among subteams, all without the need for status report writing.

Finally, the easiest way to scale agile techniques is to hire good people. By paying 20 percent more, you often find that you've hired someone twice as productive. It's been estimated that the best developers are almost 25 times as productive as the worst developers. You get what you pay for, and a team of 20 above-average developers can clean the clocks of a team of 100 below-average developers.

As Agile As You Can

Agile approaches work for large teams, even when people are distributed across several sites. Collaboration and communication are still critical to your success, as is developing working software on a regular basis. To scale agile you need to do some modeling up front (but remain agile doing so), organize your large team into a collection of smaller ones, and coordinate the teams effectively. Large teams are simply not as nimble as the small fry, and so aren't able to respond to change as quickly. Although you'll probably need to lower your expectations a bit, you can still be as agile as possible for your situation.

Scott W. Ambler is a Canada-based software process improvement (SPI) consultant, mentor and trainer with Ambysoft Inc. He's written several books and is a regular speaker at software conferences worldwide.