News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

Agile Principles Are Changing Everything


From requirements to tools to organization, development ideas have been turned on their head



January 1, 2008 — 
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.

Based on interviews with more than 20 analysts, consultants, developers and tool makers, SD Times 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 interviews. First, 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. Second, 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. Third, 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.”

Please Bend the Rules
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,” he said, recalling an XP project he worked on as a consultant earlier in his career. 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, recalled Freeman-Benson. 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. “Insisting that the customer do acceptance testing [and other things that XP mandates] was too large a leap to make.”

Early projects like that gave agile a bad name, said Tom Stiehm, managing architect for the consultancy Command Information. Today agile practitioners are more willing to bend the rules. But many are afraid to use the word ‘agile,’ he said. “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, said Forrester analyst Peter Sterpe. “They do two-week iterations, engage in frequent, intentional communication, and do frequent builds.”

But that’s not agile development, he said. “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 interviewed 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, said Forrester analyst Carey Schwaber, author of “The Truth about Agile Processes,” an August 2007 report. But “wagile”—that’s traditional waterfall development with a couple of agile practices thrown in—may be a better way to describe such efforts, she said.

A process becomes agile when one practice leads to another practice, said Freeman-Benson. He offered an 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, said Schwaber. “You can’t apply just one part of agile without ultimately applying it everywhere.”

The trick is choosing a balanced set of practices, added Freeman-Benson. “But you don’t have to choose the exact set that Kent Beck chose,” he said, referring to XP’s inventor.

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 interviewed by SD Times 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.

The Forrester report noted that agile benefits—reduced time-to-market, better quality and improved predictability, among others—are widely recognized. “But they have not been empirically proven,” the report said. Still, agile shops offer anecdotal evidence that the approach works. Ray Goodman, a senior vice president for inventory software developer Direct Tech, said Scrum has reduced development cycles from six months to about three or four—not counting one pre-Scrum project that took two years. “But we don’t yet have a sense of how Scrum has impacted the business [overall].”

Ken Judy, vice president of software development for Oxygen Media, reported that agile has “made our work more innovative, maintainable and predictable.” The cable television network has practiced its own variant of XP and Scrum since 2004 and has not measured whether this approach is faster than waterfall. Oxygen software developer Wendy Friedlander said adopting agile has enabled the development group 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.”


Share this link: http://www.sdtimes.com/link/31484
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading