In the Agile Dragon, Scott Sehlhorst, a software guy with a mechanical engineering background, has written a very interesting take on the agile approach vs. an approach called “Interaction Design“. While I love many of the ideas and even the results that come from good interaction design (check out The Inmates Are Running the Asylum for more info), I am very sceptical of Scott’s weak arguments about the weaknesses of agile.
He posits that agile’s greatest strengths come as a result of being able to accomodate change. He also makes a pseudo-mathematical analysis of the cost of change in an agile method. Finally, he asserts that good requirements as derived and set forth by the interaction design method eliminate a fair amount of the need for change.
Agile’s Greatest Strength
Agile method’s greatest strength is actually about early delivery of working results. As I said in response to his post:
The end of the first iteration (usually somewhere between one and four weeks) results in a little bit of software that actually works. This has the staggering advantage that the customer/sponsor can take that little bit of usable softwareâ€¦ and use it! Even if the client waits for a few iterations before the software has enough functionality, and only then uses it, the advantage is still huge. In any process where all the requirements are gathered up front, regardless of how or what is done with them afterwards, there is a large delay in getting the first bit of usable working software in the clientâ€™s hands.
This delay _costs_. It costs both money and opportunity. Regardless of how stable or unstable the requirements are, agile methods deliver a return on investment much much sooner than any other approach to building software. As you pointed out:
â€œCustomers know what they want – higher profits, greater market share, etc.â€
For both of these desires, the best way to get them is by the reduced cycle time that using an agile method provides.
Cost of Change in Agile
Agile methods acknowledge that a customer/client knows a lot of what they want already… and that they even know what is most important! Therefore, the further along in a project one goes, (barring the kind of unforeseen change to which agile responds well) the more stable the resulting product will be.
This emphasis on the early deliver of highest value requirements gives the customer/client even more options: the project can be cancelled early if the cost of building features is higher than the value delivered by those features. This is impossible in a waterfall approach.
Good Requirements and Interaction Design
I would love to see some more careful analysis of this. I don’t know enough about interaction design to say if this is true or not, but I do know that this is a big claim that is contrary to much of the statistical evidence. I’m willing to accept that it is possible, but I’d love to understand better the theoretical underpinnings. Scott?