And a Few Potential Non-Issues
I was surprised that there were several potential adoption accelerators explored by this survey that had no correlation either way with agile project success. One such strategy was having a group or center of excellence (CoE) to support adoption of Agile techniques within development teams. I've worked in several organizations that invested in an Agile CoE, including IBM, and in all cases, the Agile adoption effort went much more smoothly than in the organizations where this wasn't the case. An effective CoE helps teams share learning experiences, provides coaches, and (more importantly) provides experienced people to coach the coaches who work with the development teams. I'll write more on this in a future article.
Another issue we tackled was whether people were assigned to multiple project teams. When people split their time across several projects, their productivity fell due to the overhead of task switching. Although this was a common problem, the survey found that successful and challenged Agile teams were equally likely to be struggling with multiple project team assignments. It may be that IT professionals have become so jaded about this problem that we've come to accept it as the norm. This is clearly a hypothesis worth examining with a future survey.
We also explored the "two clocks" issue in which Agile teams are required to work with other non-Agile teams that are operating at a different cadence. There are two variants of this problem. The first is when an Agile team is supported by a non-Agile enterprise team, such as the data administration group or an enterprise architecture group (yes, it's possible for both of these groups to work in an Agile manner). In this case, the enterprise team can slow down the Agile team with inappropriate bureaucracy. The second situation occurs when an Agile team depends on a non-Agile team to deliver a component or subsystem. If the non-Agile team slips its schedule or delivers inadequate quality, it puts the Agile team in a bind. Both Paul and I have run into organizations where the two-clocks problem caused a bit of trouble, so we were surprised by the survey results.
In some ways the survey results are frustrating because they clearly show that there are still many organizations doing things, and sometimes not doing things, that hamper their ability to succeed at Agile development. In other ways, the survey results are interesting because they show that there appears to be a correlation between agile success and some agile adoption practices. Furthermore, when it comes to large agile teams and geographically distributed agile teams, this survey verified what previous surveys had found Agile approaches work at scale, although it's harder to succeed at scale. The same can be said of other development paradigms of course.
Links of Interest
The original questions, source data, and a summary slide deck overviewing the results of the November 2011 Agile State of the Art are available for you to perform your own analysis.
The Agile Scaling Model (ASM) describes the eight software process scaling factors team size, geographical distribution, regulatory compliance, domain complexity, technical complexity, organizational distribution, organizational complexity, and enterprise discipline and overviews how they affect agile strategy.
I overview some of the issues surrounding geographically distributed agile development in The Distributed Agile Team. The Dr. Dobb's 2008 IT Project Success Rates survey explored the affect of geographic distribution by development paradigm.
The IBM whitepaper Disciplined Agile Delivery: An Introduction overviews the DAD process framework which has effective governance practices built right into it.
The Surveys Exploring the Current State of Information Technology Practices page links to the results of all the Dr. Dobb's surveys that I've run over the years.
My Agility@Scale blog discusses strategies for adopting and applying agile strategies in the complex environments.
Scott Ambler is the Chief Methodologist for Agile and Lean at IBM Rational.