Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Who says agile development can't be faster?

Matthew Heusser | March 5, 2013
The agile software development community claims that changing the way you work doesn't make things faster. Then why do it at all? Compare agile to traditional development methodologies and you'll see that agile can, in fact, be faster.

At Agile Testing Days in Potsdam, Germany, in November 2012, Lisa Crispin and Janet Gregory, authors of Agile Testing: A Practical Guide , made the bold claim that "agile means faster" is a myth.

They also did it wearing plastic, light-up snake heads designed to resemble the snakes of Medusa. Here's proof:

Janet Gregory (left) and Lisa Crispin make a point about myths with a bit of a theatrical flair.

The point the pair tried to make is that an agile conversion is a long haul that requires an investment of time. Along the way, the team will make some mistakes, experiment to learn new skills, get messy-and slow things down, at least initially.

Still, the idea that "agile is not faster" didn't seem right to me. I decided to ask again.

My opportunity came later in the conference, when I found myself with a few minutes to talk to Gregory. I asked her exactly what she meant.

The point of agile is not speed, she says. It might be a by-product, but it won't happen right this second. Gregory explains with an example: "Say you know that your team can accomplish 15 written requirements in a year, and you decide, today, to change to an agile method of software delivery. In a year, you won't have all 15 done. An agile conversion slows you down, at least in the short term-and that short term is not a week or two. It may be a year or two."

This is not what the typical CIO wants to hear. In fact, he's likely to ask, "If agile isn't faster, why do it?" Here are three reasons.

1. Agile Is Building the Right Thing Through Steering

Peter De Grace published Wicked Problems, Righteous Solutions in 1990, back when "agile" had something to do with yoga or touching your toes.

According to DeGrace, a "wicked" problem can't be completely understood until you've first attempted to solve it. And, it turns out, wicked problems happen all the time in software.

Fred Brooks, author of the classic Mythical Man Month, once said in an interview that, when he first wrote the book in 1975, "I counseled programmers to throw the first version away, then build a second one. By the 20th-anniversary edition, I realized that constant incremental iteration is a far sounder approach. You build a quick prototype and get it in front of users to see what they do with it. You will always be surprised."

One big problem with the traditional approach is that it fails to validate the idea until later. Over time, unvalidated ideas lead to work that may be rejected or thrown away, something Eric Reis stresses as waste in his Lean Startup work.


1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.