|
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.
|
