Channels ▼
RSS

Supersize Me


March, 2006: 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.

Scaling Agile Processes

The following strategies enable large teams to remain agile.

  1. Organize your large team into several small, colocated subteams.
  2. Model your high-level requirements and architecture early in the project.
  3. Deliver working software regularly.
  4. Coordinate via daily stand-up meetings, not status reports.
  5. Collaborate, collaborate, collaborate.
  6. Hire good people.
  7. Adopt common philosophies and guidance.

—SA



Agile in the Large

Useful techniques for scaling agile to large project teams

  • Agile Software Development in the Large: Diving Into the Deep (Dorset House Publishing, 2004). Jutta Eckstein's book focuses on ways to scale agile approaches to large projects. It's a great resource for anyone trying to scale his software development process.
  • "Scaling Agile Methods: Ten Top Issues and Lessons Learned" by Donald J. Reifer, Frank Maurer and Hakan Erdogmus summarizes the findings of a February 2003 workshop held in Calgary, Canada on scaling agile methods (http://can.cpsc.ucalgary.ca/ws2003/ScalingAgile%20V1_1_.pdf).
  • Agile Model Driven Development (AMDD) is described in detail at http://www.agilemodeling .com/essays/amdd.htm.
  • My essay, "Agile Architectural Modeling" describes an agile approach to architecture. Find it at http://www.agilemodeling.com/essays/agileArchitecture.htm.
  • "How Can Enterprise Professionals by Agile?" (www.agilemodeling.com/essays/enter priseAgility.htm) overviews strategies that enable enterprise architects, operational database administrators, program managers and others to work effectively with agile project teams.
  • My "Agile Enterprise Architecture" article (http://www.agiledata.org/essays/enterpriseArchitecture.html) argues that enterprise architects can and should work in an agile manner, and describes techniques for doing exactly that.

—SA




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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video