Has Agile Peaked?

Has agile peaked? Scott crunches the numbers to find out.


May 07, 2008
URL:http://www.drdobbs.com/architecture-and-design/has-agile-peaked/207600615

Scott is Practice Leader Agile Development for IBM Rational.


During the last week of February 2008, Dr. Dobb's ran a survey exploring the current adoption and success rates of agile software development techniques. We found that the adoption rate was the same as last year at 69 percent, that most agile teams had iterations of four weeks or less in length, and that agile teams had high rates of success. We also found that people believe that, on average, agile teams are producing greater levels of quality, are more productive, enjoy greater stakeholder satisfaction, and are doing so at lower costs than traditional teams.

Agile Adoption Rates

The title of this month's column is provocative for a reason: I was very surprised, and concerned, that the agile adoption rate appears to have flattened out. To be fair, I'm working from a three-year "trend" so there really isn't enough data to truly judge. In the 2006 agile adoption survey we found that there was a 65 percent agile adoption rate, in 2007 a 69 percent rate, and in 2008 69 percent again. To be fair we asked the question differently in 2006, so it could be argued that we shouldn't be comparing 2006 with the 2007/2008 adoption rates.

The good news is that the majority of organizations have adopted agile techniques and seem to be sticking with them. Only 18 percent of the people who indicated that their organizations have run one or more agile projects indicated that they were still in the pilot phase, implying that 82 percent are further along in the adoption process. My concern is that last year, 24 percent of the people who had indicated that their organizations hadn't yet tried agile approaches would likely do so sometime in the coming year, leading me to believe that we'd see a higher adoption rate. Granted, some new organizations may have adopted agile approaches in 2007 whereas some abandoned them, with a net gain of zero. This year, 15 percent of "No" respondents hope to do agile this year, so we'll have to wait and see.

I was curious about why the adoption rate seems to have peaked, so I crunched the numbers a bit. My first theory was that "stealth adoption" was occurring, something that I've seen in many organizations, where the developers were doing agile without the knowledge of senior management. But when I analyzed the adoption rates by role, I found that only 61.4 percent of developers thought they were doing Agile, whereas 78.2 percent of IT management thought so, the exact opposite of what I would've expected to see if stealth adoption was occurring. Based on these numbers, I suspect that developers and management have different criteria for what it means to be Agile, and that developers have set a higher bar for themselves. My fear is that management may be motivated to water agile down to earn their "agile gold star".

Iterations Are Short

Similar to last year, we found that the majority of respondents indicated that their iterations were between one and four weeks in length (see Table 1). It was interesting to see that the number of teams that aren't doing iterations appears to have increased, perhaps an indication that people are moving towards lean methods such as Kanban (more on Kanban in a future column).

My experience is that shorter is better than longer when it comes to iteration length because shorter iterations help to squeeze out low-value bureaucratic activities. For example, you can't tolerate a three-week review process when your iterations are only two weeks in length. Teams that are new to Agile often have iterations that are longer than four weeks in length, usually because they're still in the process of moving away from a serial/waterfall mindset and are struggling with the idea of producing working software in short time periods. They're often convinced that the requirements that they're trying to implement are so big that they require iterations of six weeks, eight weeks, or even longer. Having worked with project teams in numerous companies around the world, usually developing very complex software, I have never run into a large requirement that I couldn't disaggregate into much smaller ones. My observation is that teams always seem to find ways to break down their "three month requirements" into tasks that fit into eight-hour workdays. Granted, when team size increases, or when the team is distributed, it puts pressures on you to increase iteration length. For example, the Eclipse development team, several hundred people around the globe developing a complex system, has six-week long iterations.

Length 2008 2007
< 1 week 3.1% 5%
1 week 9.2% 17%
2 weeks 32.8% 32.6%
3 weeks 16.7% 12.5%
4 weeks 22.8% 21.0 %
> 4 weeks 10.3% 9.6%
No iterations 5.6% 1.4%

Table 1: Iteration length.

Small requirements are easier to estimate, implement, and validate than larger ones, but it's easy to lose track of the big picture if you're not careful. Although many agile teams create user stories, very small features that provide value to a stakeholder, they're also writing "epics" that are collections of related user stories. Some teams are writing lean/light use cases describing how one or more stakeholders will use the system. The most advanced teams are focusing on business scenarios, or "green threads," which involve usage of multiple systems to provide business value to stakeholders. These cross-system scenarios explore the true business processes of your stakeholders (few people sit down all day long and solely work with a single system), and thereby enable you to see the real "big picture" and hopefully avoid building yet another silo system.

Agile Scales

A small number of respondents indicated that they're succeeding with agile teams of over 200, and many others are trying Agile teams of 50 or more. People are clearly going beyond the small, colocated team approach described in many of the popular Agile writings. Within IBM, we've delivered products into the marketplace with agile teams of 200 people and have several agile programs of 500 or more people. My point, which I've iterated many times in this column, is that it is possible to scale Agile to meet the real-world needs of modern IT. Furthermore, my suspicion is that in the next few years, it will become clear that Agile scales better than traditional development approaches.

It's critical to recognize that there is more to scaling agile software development approaches than supporting large, distributed teams. For example, regulatory compliance is an important scaling factor for many teams, which complicates software development. Cultural challenges within your organization, such as supporting teams that don't work in an agile manner or legacy policies that don't reflect agile strategies, are also a risk at scale. Enterprise issues, such as enterprise architecture, strategic reuse, portfolio management, and IT governance become more apparent once you move beyond the pilot phase of agile adoption. Leveraging legacy assets, such as wrapping existing systems following a service-oriented architecture (SOA) strategy or fixing data-quality problems in production data sources via database refactoring, is an important scaling factor.

Adopting Agile is Very Low Risk

The survey asked about the success rate of Agile project teams in different scenarios. Colocated teams where everyone, including stakeholders, are in the same work area enjoyed an average success rate of 83 percent. Non-colocated teams where people are in different cubes, perhaps on different floors, or in different buildings, where they could easily get together physically if required, had a 72 percent average success rate. Projects where part of the team was at a significantly different location, such as offshoring situations, had a 60 percent average success rate. We asked about these three different scenarios to try to determine the risk premium associated with team distribution, and as you see it's fairly high—a 23 percent difference in success rates between co-location and being highly distributed. Overall survey respondents indicated that the average success rate for agile teams was 77 percent.

Organizations still in the pilot project phase had an 84 percent success rate when colocated, 72 percent when not colocated, 61 percent with highly distributed, and a 79 percent overall success rate. I was a bit surprised that the success rate for the Agile pilot projects was so high. Usually teams that are trying new techniques run into trouble and the project turns into a "learning experience" for the organization. Part of the high success rate is likely attributable to organizations choosing easier projects to pilot Agile techniques on. Also, better people usually staff pilot teams, so that would lead to a higher success rate.

We also wanted to get a feel for how effective agile teams are in practice, so we asked about productivity, quality, stakeholder satisfaction, and cost. Table 2 summarizes the results. As you can see, Agile teams are reporting significant improvements in productivity, quality, and stakeholder satisfaction, and reasonable improvements in cost. The interesting thing is that the upside of adopting agile approaches is fairly high, yet the downside is low. In short, becoming more agile appears to be low-risk decision for senior IT management.

Factor Improved No Change Worsened
Productivity 82% 13% 5%
Quality 77% 14% 9%
Stakeholder Satisfaction 78% 15% 7%
Cost 37% 40% 23%

Table 2: Effectiveness of agile teams.

The Laggards May Still Catch Up

We found that Agile software development strategies are being successfully adopted by the majority of organizations. Most organizations are moving beyond the pilot phase and are applying agile approaches on many project teams, and some are even applying agile at scale. Agile adoption may have peaked, or perhaps we're just seeing a lull before the "adoption laggards," as Geoffrey Moore likes to call them, finally decide to catch up to the rest of the marketplace.

As with previous surveys, the source data (without identifying information), the original questions as they were asked, and a set of summary slides are downloadable from www.ambysoft.com/surveys/. I invite you to analyze the results for yourself.

The Survey

We sent e-mail to our readership requesting that people fill out the survey and we had 642 responses. We had a wide range of respondents:

  • 54.8% indicated that they were developers
  • 29.4% were in management positions
  • 41.6% had between 10 and 20 years IT experience
  • 37.2% had more than 20 years IT experience
  • 71.0% were from North America
  • 17.0% were from Europe
  • 4.5% were from Asia
  • 34.9% worked in organizations of 100 people or less
  • 37.7% worked in organizations of 1000+ people

The experience levels indicate to me that the majority of people should have a reasonably good idea what is happening in their IT departments. There was also a good range of organization sizes represented. The only challenge was the over representation of North Americans, which has been an issue with previous surveys as well.

—S.W.A.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.