Evidence that Agile Software Development Scales
Home  |  Contact Us  |  Licensing  |  Announcements  |  Downloads  |  Site Map

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 topics: What does it mean to scale agile? Agile and team size Agile and geographical distribution Agile and regulatory compliance Agile and technical complexity Agile and organizational complexity

The fundamental points are:

1. It appears that organizations are applying agile techniques at scale;
2. It appears that some are succeeding at doing so;
3. It appears that organizations are in fact dealing with many scaling factors when it comes to agile, not just team size.

1. What Does it Mean to Scale Agile?

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 size.  Agile scaling factors include:

1. 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.
2. Team size. Running a project team of 10 people is different than running a team of 100 or a team of 1000. 
3. Geographical distribution. The greater the distribution of team members the greater the difficulty for working together effectively.
4. 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 regulations.
5. Organizational distribution. A team of people from several divisions, or several organizations, faces greater complexity than teams which are homogenous.
6. Technical complexity. Working with legacy data, with legacy code, or with multiple technologies increases the challenges faced by a project team. 
7. 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.
8. Enterprise disciplines.  The desire to address cross-system enterprise disciplines, such as enterprise architecture, 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.

2. Agile and Team Size

Figure 1 summarizes results from the 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 situation).

Figure 1. Average size of agile teams.

3. Agile and Geographic Distribution

Figure 2 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 2008 Project Success Survey how the project success rate decreases as your team becomes more geographically distributed (near located in Figure 3 is the 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 2. Agile software development and geographical distribution.

Figure 3. Success rates by paradigm and distribution level.

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

4. Agile and Regulatory Compliance

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

Industry regulations typically require greater levels of documentation, greater levels of traceability, proof that you performed certain tasks, separation of some agile testing techniques, and so on.  This clearly increases the complexity of the situation that your agile delivery teams find themselves in.

5. Agile and Technical Complexity

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.

When you're building brand new, "greenfield systems", using modern technologies and a relatively homogeneous platform it's fairly easy to succeed.  But when technical complexities rear their ugly head you find that you often need to change the way that you work.  This can make it difficult to scale agile to meet the needs of your entire IT organization, not just the teams in relatively straightforward problem spaces.

6. Agile and Organizational Complexity

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.

7. Summary

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.

8. Recommended Resources