Agile Scales: The Evidence You’ve Been Looking For

The goal of this article is to summarize some of the evidence that I’ve been gathering over the past few years via IT research 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

The fundamental points are:

It appears that organizations are applying agile techniques at scale;
It appears that some are succeeding at doing so;
It appears that organizations are in fact dealing with many 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:

Lifecycle scope. Mainstream agile processes tend to focus on construction but disciplined agile teams recognize that they must consider the full agile delivery lifecycle 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 effectively.
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.
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 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 Surveywhich 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 occur 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.