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.
Case Studies: Hotels.com Speeds App Development with Agile and Formula One Racing Team Speeds to Agile Development
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."
Related: 6 Ways the Cloud Enhances Agile Software Development
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.
Agile teams build just two weeks of work at a time, sometimes less. They get feedback from the customer and allow the customer to decide what to work on first, what next, and when to ship.
2. Agile Is Skipping Requirements Not Worth Doing
When I worked on projects 10 years ago, we made a formal document called the functional specification. It neatly listed everything we intended to put into the software. Put another way, we had those 15 requirements that Gregory mentioned.
However, because we put everything together in one lump, we avoided the hard work of deciding what the priorities were. Everything, like in Dilbert-land, was Priority No. 1-and some of those requirements were just not worth doing.
That statement is not intended as an insult; it is more like a rule of physics. If you list all your software development ideas, some will offer more value for cost; others, less. Put the work in a priority order and you get to build the high-value things first. By the time you get to the bottom of the list, you could implement the feature, sure-but you could also call the project done, ship it early and do something else more valuable with your time.
That's what happened on my first agile project. The customer looked at what was left and decided we could call it done and ship early. I remember it fondly. That kind of thing never happened on a traditional project. Because projects were big and hard to initiate, we were more likely to get kitchen-sink behavior.
3. Agile Is Knowing the Old Way Isn't Fast, Either
The third reason to do agile is because I object to the fundamental premise that it's not faster. Remember the setup: A team that could get 15 requirements documents done in a year in a traditional model would be slower when moving to agile methods.
After years in organizations that tried to know everything up front, I consistently saw one thing: Projects were late and the project managers, who had been so certain, were now surprised. Things happened that they never could've predicted, and we'd say we "did the best we could under the circumstances.
My experience isn't unique. The sixth edition of Barbara C. McNurlin and Ralph H. Sprague's Information Systems Management In Practice claims that the average cost overrun of a large ERP project is 179 percent, the schedule overrun 230 percent. In other words, comparing an agile team that can't get something done in a year to a more traditional team that can is a false comparison. In a year, the traditional team will have 12-and-a-half requirements done, a mess on the floor and nothing to ship.
You're free to disagree, but here's an exercise: Take a random sampling of a dozen traditional projects from your company and see how late they were compared to their original plans.
So, Yes, Agile's Not About Speed
This suggests that the agile approach helps the team get something to production faster, build the right thing and eliminates low-value features. One question remains: Is it faster?
Tips: How to Keep Cloud Projects Agile, Simple
Crispin and Gregory might argue that it does not matter, that focusing on pure speed in the short term leads to shortcuts, pain and slow performance in the long term. I contend that teams can focus on eliminating waste and improve velocity as they improve process.
This is a dangerous, difficult thing, more than a bit like dynamite: You can blow things up with it, but if you aren't careful, you might become one of those things. Either way, the debate is certainly still on, and I expect the debate will continue.
The next Agile Testing Days is this November in Potsdam. If you'll excuse me, I have a proposal to write.
Matthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, on Facebook, and on Google +.
Read more about agile in CIO's Agile Drilldown.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.