Our Blog Excerpts Savings Contact

logo

Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features
Features       Excerpts       Interviews

 

iDH Sign-Up


Get Our e-News
Delivered by FeedBurner

Agility and Largeness

by Jutta Eckstein

Adapted from Chapter 1 of Agile Software Development in the Large. Reprinted by permission. All rights reserved. See below for copyright notice.

Agile processes promise to react flexibly to continuously changing requirements. That is why agile processes are currently treated as a panacea for successful software development. However, agile processes are almost always recommended for small projects and small teams only—bad news for those large teams that have to deal with speedy requirements changes.

The Importance of Communication

Software engineers tend to question the feasibility of agile software development in the large, not only because most agile processes claim to work mainly for small teams, but also because most of the projects that fail are large. The reason most (large) projects fail is a lack of communication: among teammates, between team and manager, between team and customer, and so on.

Communication is one of the focal points of agile processes. But can effective communication ever be established successfully for large teams? The popular opinion is that it can't, leading to the idea that if you have a hundred people on a development team and get rid of all but the top twenty or (preferably) fewer, the chances for project success will rise significantly.

However, you can't generally avoid large projects. Sometimes, you will face constraints that force you to run a large project with a large team. For instance, some projects have such a large scope that it is not possible to realize it with a small team in the defined time frame.

If you want to take advantage of agile processes, several questions arise: Are agile processes able to scale? That is, Can they be amplified in order to support large projects? And, moreover, are they able to support large projects? And what kind of problems occur when an enterprise decides to use an agile process for a large, perhaps even mission-critical, project? My book tries to answer these and many questions relating to agile software development. Here, though, I discuss some aspects of what I mean by large projects.

The Dimensions of Largeness

In my experience, I have found that a project can be considered large in many dimensions. For example, the money, scope, amount of people, and risks involved can be large. These different "dimensions" of largeness are mostly interrelated. Some dimensions exist—scope and people—as a first-order consequence of the requirements and constraints. Others are derived from these first-order dimensions.

You can definitely run a large-scope project with a small team. But large-scope projects are almost always developed by a large team—especially in large companies.

Typically, if a project is large in terms of people, all its other dimensions are probably just as large. For example, you will hardly ever find a large team working on a project with a narrow scope, a schedule of only three months, or a budget of only a few hundred thousand dollars. The project itself might not carry any extraordinary risk, but scaling all the project's dimensions implies a risk of its own. For instance, if a lot of money is involved, there is a high risk that a lot of money will be lost. Or, if the time frame is extremely large, the risk that the project will never be finished at all increases.

The Impact of Largeness

Of course, large is not a well-defined magnitude, and neither is the largeness of a team. Will a team be considered large if it contains 2, 10, 100, 1,000, or even more people? And what impact does every additional order of magnitude in staff number have on the process? For example, let's look at its influence on communication:

  • 2 people and more: If a project is developed by only one person, that person should have the big picture of the project in mind. He or she knows the whole system in terms of code and design. As soon as another person is added to the project, these two people will have to communicate with each other. Communication is the only thing that will enable both developers to understand what is going on and to further coordinate their efforts. For example, it would be annoying if they both worked on the same programming task unknowingly, only to find out once they began to integrate the code.
  • 10 people or more: With teams of this size, you have to start coordinating members' efforts and their communication. You have to explicitly establish communication channels in order to discuss topics with the whole group.
  • 100 people or more: Even if you have an open-plan office available, teams of this size will not fit in a single room. Therefore, across the entire team, you have to strategically foster the kind of "natural" communication that would take place inside a single room.
  • 1,000 people or more: Chances are high that this team will not only be distributed over several rooms, but also over several buildings, perhaps over several locations. Consequently, the people on the team are unlikely to know all their teammates.

This example shows not only that large is relative, but also that scaling can lead to different consequences.

Detecting the Agile Process for Scaling

A large team is typically split into many smaller teams. Because a lot has been written elsewhere about agile processes in small teams, I do not focus on the processes these subteams are using. Instead, I concentrate on the process that brings them all together and enables them—despite the large number of people—to work together with agility. Therefore, rather than focus on every aspect of agile processes, I concentrate only on those that work differently in large projects developed by large teams.

 

AddThis Social Bookmark Button

 

 

 


COPYRIGHT NOTICE: This excerpt from Agile Software Development in the Large: Diving Into the Deep [ISBN:0-932633-57-9] appears by permission of Dorset House Publishing. Copyright © 2004 by Jutta Eckstein . All rights reserved. See http://www.dorsethouse.com/books/agile.html. The material contained in this file may be shared for noncommercial purposes only, nonexclusively, provided that this Copyright Notice always appears with it. This material may not be combined with advertisements, online or in print, without explicit permission from Dorset House Publishing. For copies of the printed book or for permissions, contact Dorset House Publishing, 1-800-342-6657, 212-620-4053, http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.

 

 

 
  DORSET HOUSE PUBLISHING CO., INC.
New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044
Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal