The goal of this article is to summarize some of the evidence that I've
been gathering over the past few years via
IT surveys which shows that
people are applying agile and lean techniques at scale. Much of
the evidence currently shows that people are doing this, and some of the
evidence shows that they're succeeding at doing this (the evidence
gathering is an ongoing effort, but things are looking good). This article covers the following
The fundamental points are:
The answer to this question depends on the context. When
you limit the scope of the question to team size then it's a fairly
straightforward question to answer. But, when the scope of the question
focuses on how to scale agile to meet the needs of your entire IT organization,
warts and all, the answer is a bit different. When this is your scope it's
clear that there is more to scaling agile software development than just team
Agile scaling factors include:
It appears that organizations are applying agile techniques
It appears that some are succeeding at doing so;
It appears that organizations are in fact dealing with many
scaling factors when it comes to agile, not just team size.
Life cycle scope. Mainstream agile processes tend to
focus on construction but disciplined agile teams recognize that they must
consider the full
agile delivery life cycle if they are to succeed. In short, the
first step to scaling agile strategies is to ensure that you have a full
end-to-end view of what it takes to successfully deliver a solution, from
project inception all the way to delivery into production.
Team size. Running a project team of 10 people is
different than running a team of 100 or a team of 1000.
Geographical distribution. The greater the
distribution of team members the greater the difficulty for working together
Regulatory compliance. Teams in regulatory compliance
situations, such as having to conform to HIPPA or FDA regulations, face
greater complexity than team which do not have to conform to such
Organizational distribution. A team of people from
several divisions, or several organizations, faces greater complexity than
teams which are homogenous.
Technical complexity. Working with legacy data, with
legacy code, or with multiple technologies increases the challenges faced by
a project team.
Organizational complexity. Dealing with
corporate politics, trying to get people with different visions as to how to
proceed with development, or working with people still transitioning to
agile from waterfall techniques are examples of organizational complexity
which increases the challenge faced by an agile delivery team.
Enterprise disciplines. The desire to address
cross-system enterprise disciplines, such as
strategic reuse, or
people management (to name a few), includes the complexity faced by
agile delivery teams. As you've learned at this site it is possible to
take an agile approach to enterprise issues, but it necessitates more mature
ways of working by agile delivery teams.
Figure 1. Average size of agile teams.
|Figure 1 summarizes results from
2009 Agile Practices Survey which asked about agile team size. Although the
majority of agile teams are 20 people or less, some organizations do in fact
have fairly large agile teams. Team size increases communication and organizational risks on
agile delivery teams, is often an indication of both
technical complexity and
organizational complexity (the more
complex the situation, often the larger the team required to address that
Figure 2. Agile software development and
summarizes results of a question from the
2009 Agile Practices Survey asking about agile and geographical
distribution. Apparently, only a minority of agile teams are co-located,
with the rest exhibiting some form of geographical distribution. More
importantly, Figure 3
summarizes the results of several questions from the
Project Success Survey how the project success rate decreases as your team
becomes more geographically distributed (near located in Figure 3
combination of Same Building and Within Driving distance in Figure 2).
It's interesting to note that some organizations are in fact succeeding even
when their agile teams are very distributed.
Figure 3. Success rates by paradigm and distribution
Geographical distribution increases the communication risks
faced by your agile delivery team, which in turn decreases your success rate,
requiring you to adopt your process accordingly to hopefully address those
Figure 4 shares
results from the
2009 Agile Practices Survey which shows that one third of agile teams are
working in regulatory environments.
Figure 4. Agile software development and regulatory
Industry regulations typically require greater levels of
documentation, greater levels of traceability, proof that you performed certain
tasks, separation of some
testing techniques, and so on. This clearly increases the complexity
of the situation that your agile delivery teams find themselves in.
Figure 5 summarizes results from the
2009 Agile Project Initiation Survey which shows that the majority of agile
teams are working with legacy assets, either
legacy systems or
legacy data, in some way. This is one kind of technical complexity
which agile teams may need to deal with (others include integration of
heterogeneous platforms and intrinsically difficult technologies).Figure 5. Agile development and legacy assets.
Figure 6 summarizes results from the
2009 Agile Practices Survey showing that a some agile teams are following a
CMMI-compliant process. This is one indication that some agile teams face
organizational complexities, in this case it is common that the pro-CMMI culture
clashes with the pro-agile culture at first until they come to a strategy for
working together, which can be an aspect of scaling agile.
Figure 6. Agile software development and CMMI.
It is clear that many agile teams face a variety of scaling
factors. These scaling factors introduce complexities which the team must
overcome. This article will be updated as more scaling-oriented evidence
comes in from the various IT Surveys
which I run. I hope that this article has been of help to you.