Dr. Dobb's Journal - June 2008 - (Page 52)

d06ambler_p3as 4/11/08 11:34 AM Page 52 The Agile Edge by Scott W. Ambler Has Agile Peaked? Let’s look at the numbers 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. edge 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” . 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 knowlLength 4 weeks No iterations Table 1: Iteration length. 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. 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 2008 3.1% 9.2% 32.8% 16.7% 22.8% 10.3% 5.6% 2007 5% 17% 32.6% 12.5% 21.0 % 9.6% 1.4% 52 Dr. Dobb’s Journal l www.ddj.com l June 2008 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - June 2008

Dr. Dobb's Journal - June 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries There Must Be Contest Conversations Building a Test Harness for RTOS QT and Windows CE Software to Hardware Parallelization Performance Portable C++ Effective Concurrency The Agile Edge Swaine's Flames

Dr. Dobb's Journal - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.