Agile development aligns tech, business better

Studies show agile development works, and yet few companies follow its principles.

Farm Credit Services of America doesn't sound like an organization that courts controversy. The cooperative association makes loans to more than 66,000 Midwest farmers and cattle ranchers so that they can buy cows and pigs and tractors and backhoes. Its main reason for existence -- providing $11 billion of operating capital and real estate financing to those who feed America -- is as homey as the images of cornfields, gently rolling green pastures and rugged, resolute farmers that adorn its marketing materials.

It's also based in Omaha, known more for steaks than as an avant-garde laboratory for one of IT's most hotly debated development methodologies: agile programming.

But agile is exactly what Farm Credit Services has embraced, whole hog.

The agile advantage

Agile programming means different things to different people, but at the core of all agile development methodologies are these principles: Business stakeholders are colocated with small, autonomous development teams; the teams rely less on upfront requirements and documentation than on face-to-face conversations; those conversations provide a continuous dialogue for software design, testing and refocusing. The constant refocusing, its advocates say, leads to more timely and useful business tools.

Agile's ascendancy is in direct response to IT's dolorous history of software project failure, cost overruns and the concomitant business dissatisfaction with traditional IT design and development -- the waterfall methodology -- in which development slowly cascades through a series of steps, including requirements analysis, design, implementation, testing, integration and maintenance. But for a variety of reasons, not everyone has warmed to agile. In fact, just 17% of North American and European companies use agile development processes, according to Forrester Research Inc.'s Enterprise Agile Adoption in 2006 survey.

Farm Credit Services welcomed agile programming because the waterfall method had been failing the organization, as it has many others. "We got requirements and would build [the applications], and nobody was happy at the end," says Farm Credit Services CIO Dave Martin. One particular project, which was a migration from a mainframe-based customer application-processing system to a Web-based version called PinPoint, involved more than 200 pages of requirements and, by the end of 2004, had taken nearly three years to complete. In the interim, the requirements and business needs had changed, and most of the members of the original business team were gone. The resulting bug-filled system was shelved not long after its shaky debut.

And that's not unusual. According to the 2006 State of Agile Development survey by The Agile Alliance and VersionOne LLC, respondents said only 29% of traditional projects were "somewhat successful" or "very successful." (Conversely, respondents said 81% of their agile projects achieved that level of success.)

The Standish Group International Inc., which famously compiles its Chaos data on software project failures, reported in its 2006 research that just 16% of waterfall projects succeeded as opposed to 41% of agile projects. Standish Group Chairman Jim Johnson, who has been studying project failures for years, says it "boggles" his mind why companies still resist agile development. "To say that companies or CIOs are reluctant to embrace agile is like saying they wouldn't take aspirin for a headache," he says. "And they're not only not taking the aspirin, they're banging their heads against the wall and wondering why it hurts."

10 questions to see if your company's developers are agile

Lots of companies claim to be agile. But are they really? VersionOne, an application life cycle management provider, created this list to help you figure it out.

You might not be agile if ...

1. The "Send/Receive" and "Save As" buttons initiate most team communication.

2. Your whiteboards are mostly white.

3. "Test-driven" still refers to your car.

4. You don't yet know what PHB stands for. (It's the "pointy haired boss" in the Dilbert comic strip.)

5. You know that CPM stands for critical path method of project management, and continue to rely upon it.

6. You spend more time trying to ­manage project dependencies than remove them.

7. Someone still believes in the "Can't Chart." (Oops, that's the Gantt chart.)

8. Developers only develop, testers only test and managers just manage.

9. Simplicity is presumed to be simple.

10. A change control board meets ... ever.

SOURCE: "Are You Agile" from VersionOne

1 2 3 4 5 Page 1
Page 1 of 5
9 steps to lock down corporate browsers
  
Shop Tech Products at Amazon