In June, I went to the first Agile Development Conference in Salt Lake City, and it was one of the best conferences I’ve ever attended—partly due to the insights I gained from the Executive Summit track.
Beginning with two presentations and followed by facilitated group work, the summit offered a venue for people to share their real-world experiences adopting agility in organizations. Roy Singham, CEO and President of ThoughtWorks, spoke first, sharing his organization’s experiences running agile projects for their clients. Next, Kevin Tate, Chief Architect at Alias/Wavefront, described Alias’s experiences in adopting agile techniques. The two executives explored a consistent theme: agile works in practice.
Singham began with some perceptive observations about agility, noting it as the approach of choice for high-end developers—an interesting implication when combined with Fred Brooks’ observation that there’s a 25-to-1 productivity ratio between the best and worst developers. Singham believes that agility should be one of your major development options, echoing my own experience that you must be prepared to apply the right process for the job. He also believes that agility is moving into the mainstream, pointing to the fact that companies such as Giga and Gartner are now discussing it.
Selling Agility
Next, Singham described several reasons why an organization should consider adopting agile approaches, noting that existing methods have not slowed project failures. This is clearly evident in the third edition of the Standish Group’s Chaos Report, which has examined the IT project success rate for more than a decade. Although existing methods are better than ad hoc development, they aren’t being adopted on a wholesale basis by developers and hence have not improved our success rate. For example, significant evidence shows that code inspections are an effective best practice where solo programming is the norm. It’s a great technique that could potentially improve code quality, but few use it because most programmers consider code inspection a bureaucratic time-waster. It’s interesting to note that agile practitioners have found that pair programming and collective ownership of code achieve the same goals (and more) as code inspections—and most developers will use these practices.
For most projects, change—either changing technology or changing requirements—is a hard, cold reality. Agile techniques, Singham suggested, are useful in dealing with change, in part because they take an evolutionary (iterative and incremental) approach to development, and in part because agile practitioners view change positively. As in most fields, attitude counts.
Singham also stressed the need to test effectively to ensure quality. The agile community has embraced test-driven design (see my column, “Extreme Testing,” June 2003) and actively develops tools to support testing activities.
Agile Pros and Cons
Singham then enumerated seven advantages to agility from which executives can benefit. First, because the business owns the requirements, there’s a greater chance that they’ll actually get what they need. Second, the enhanced collaboration and communication reduce misunderstandings. Third, extensive testing and design (agile practitioners design every day, contrary to what you may have heard) result in significantly higher quality. Fourth, agility focuses on high-value activities and reduces IT bureaucracy—providing more bang for your development buck. Fifth, early delivery of business value and improved IT-business alignment ensure that developers produce software that is actually needed. Sixth, risk is mitigated through transparency of the process and increased customer participation. Finally, with frequent deliverables, your assumptions are proved or disproved early, once again mitigating risk.
Agility isn’t without its challenges, however, and Singham didn’t
shove them under the rug. Fundamentally, it’s a developer movement, and
can be difficult to align with business. In the past, the IT community told
the business community that software development is a serial process, and they
were only needed at a project’s beginning and end—thus, the
reality that we need their input throughout the project will take a while to
sink in. Singham then described cultural barriers to agility within IT departments;
for example, other groups such as data professionals or QA staff are likely
to work in a traditional, serial manner. These folks will need training and
mentoring to adapt to evolutionary practices. Singham also pointed out that
not all people are “wired” to handle ambiguity, nor do they thrive
on it, and suggested repurposing those folks as appropriate.
Although time to market is a strong advantage of agility, it’s no longer
a critical factor—thanks to the current economic climate. At present,
then, this advantage could just be considered a freebie.
In another caveat, Singham examined the agile precept of incremental delivery, arguing that it can increase the costs to the business due to increased training and installation costs resulting from a greater number of deployments. You need to train people more often, and they’re more frequently disrupted by new releases. In some environments, constant change isn’t good.
He also pointed out that delivering a partially built system often isn’t sufficient to meet business needs, insisting that you really do need to deploy a fully functional system on the first round. That said, agile teams are likely to deliver a full system faster and more effectively than traditional teams—perhaps time to market is still important after all.
Beyond Consultants
Taking the podium, Kevin Tate discussed Alias/Wavefront’s experience of adopting agile software processes. If, within the last decade, you’ve played any computer games or watched any movies, you’ve probably seen work that employs one or more of Alias’s products.
Although Tate clearly corroborated Singham’s advice, the most interesting aspect of his talk lay in his comparison of Alias’s experiences with traditional and agile development approaches. “The Familiar Path” depicts the traditional development scenario in which customer involvement is nonexistent throughout most of development, risk is high throughout and doesn’t fall until system and customer testing, and quality isn’t achieved until late in the lifecycle (when it’s most expensive to do so). Tate contrasted this with “A New Way,” which outlines the same trends for an agile approach. Throughout the lifecycle, customer involvement and quality are high, and risk plummets. Although this graph is anecdotal, it’s compelling evidence that shouldn’t be ignored.
One of the most impressive newsbytes that Tate shared with the group was the fact that Alias SketchBook Pro, a drawing package for the Tablet PC, was developed with an agile approach. So the next time that someone tells you that agility doesn’t work, tell them to download the 15-day trial version.
I’d like to extend my heartfelt thanks to Alistair Cockburn for organizing this conference. Although many people were involved, it’s clear that his hard work truly enabled everyone to have a stimulating interchange.
Scott W. Ambler is a senior consultant with Ronin International Inc. His latest book is Agile Database Techniques: Effective Strategies for the Agile Software Developer (Wiley, 2003).
