Next »
The Irony About Agile Development
Published on 22/12/07
by Catherine
There’s an irony about agile development. There is no hard evidence that it produces better software, faster. And formal adoption rates, admittedly hard to measure, don’t reach the 20 percent mark. Yet, the ideas that underpin agile development — defining requirements incrementally, writing software in short stints, seeking customer feedback, testing code as it’s written, frequent builds — have caught on like wildfire. They are widely accepted as sound development practices, even among teams that have not formally adopted them.
Agile principles have become IT best practices [for software development]
said Scott Ambler, agile practice leader for IBM.
Changes
Talking to analysts, consultants, developers and tool makers, I found that the groundswell of interest in agile practices is changing every aspect of how software is produced, from tools and processes to the roles people play in agile organizations.
Three key conclusions emerged from the talks:
- Going agile is more difficult than many teams anticipate, largely because it turns the roles of project manager, business analyst, programmer and tester on their heads.
- No two teams apply agile in the same way. That raises questions about what’s agile and what’s not, and more important, whether a process can be improved by adding one or two agile practices.
- Even though “agile” means different things to different teams, it’s safe to say that agile today is a far less dogmatic development approach than it was in 2001, when the Manifesto for Agile Software Development put Extreme Programming (XP), Scrum and other methodologies on the map.
Written by a group of believers in the ways of agile, the manifesto sums up principles that guide software development, including individuals and interactions over processes and tools and responding to change over following a plan.
Bend the Rules, Please!
One lesson learned from the early agile days is that rigid adherence to a methodology may not work in the real world, said Eclipse Foundation director of the committer community Bjorn Freeman-Benson:
XP is a strict form of agile, and today no one does all the practices. Insisting that the customer do acceptance testing and other things that XP mandates was too large a leap to make.
The customer — in XP, that’s the intended user of the software — was unwilling to take on the time-consuming role XP prescribes. So, rather than bend XP’s rules, the development team canceled the project. A better approach is adapting the methodology to suit the parties involved. A project manager could have assumed the customer role, extracting information from key stakeholders, he said.
Early projects like that gave agile a bad name. Today agile practitioners are more willing to bend the rules. But many are afraid to use the word agile. As a result, there is some stealth adoption of agile going on.
Going wAgile
One way to define agile development is by what it’s not. Some teams turn to agile practices to dig their way out of failing projects by doing two-week iterations, engaging in frequent, intentional communication, and doing frequent builds.
But that’s not agile development. They are simply getting a little bit iterative to put their projects back on track. Often, the line isn’t so easy to draw. Many of the experts I talked to said it’s not uncommon for development managers to add one or two agile practices, such as daily builds and early testing, to their processes. Is that agile? Some teams that take that approach believe it is. But wAagile—that’s traditional waterfall development with a couple of agile practices thrown in—may be a better way to describe such efforts.
A process becomes agile when one practice leads to another practice. For example: You decide to do continuous integration which means a new build is launched each time new code is checked in. That, in turn, impacts how you interact with users, how often those interactions take place, and how you do test cases.
One thing leads to another: You can’t apply just one part of agile without ultimately applying it everywhere.
The trick is choosing a balanced set of practices, but remembering that you don’t have to choose the exact set that Kent Beck (XP’s inventor) chose.
The Eclipse Foundation practices its own agile development approach. Known as the Eclipse Way, it sets guidelines for the 87 projects that fall under the Eclipse umbrella.
Faith Versus Facts
The experts I talked to were quick to weigh in on what’s agile and what’s not. But curiously, the question of whether agile practices actually produce better software, faster, doesn’t generate as much discussion. It’s as if a lack of faith in traditional software development methods—plagued by late projects, cost overruns and applications that don’t deliver business results—equals a belief in all things agile, despite the absence of data on agile’s impact.
Agile benefits—reduced time-to-market, better quality and improved predictability, among others—are widely recognized by they are not empirically proven. Still, agile shops offer anecdotal evidence that the approach works.
For some developers and managers agile has made the work more innovative, maintainable and predictable. I think it has enabled my development team to focus on what the business needs in ways that weren’t possible with waterfall. If your goal is to produce something people will use, agile is the best way to work.
Trackback URL: The Irony About Agile Development
Leave a Reply