Evidence that Agile Software Development Scales
|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:||
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 size. Agile scaling factors include:
|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.
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.
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.
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.
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.
This site owned by Ambysoft Inc.