This morning I was fiddling around with TweetDeck (I’ve been neglecting my feeds) when I came across a tweet from Scott Ambler (@scottwambler) referencing a tweet from Tom Gilb (@imtomgilb), the guru of requirements, wherein Mr. Gilb exclaims:
Massive €142 billion IT failure. Agile did not solve it. Coders cannot solve it. Requirements cited. Wake up!
Here is the article, by-the-way: http://www.bcs.org/content/ConWebDoc/19584
The only trouble is that Agile is not even mentioned in the article, so the assertion that “Agile did not solve it” is disingenuous.
The article mentions that 7 of 10 projects were likely using Waterfall, based on some previous research, but there’s no mention of what the other three were – not even speculation. The analysis goes on to explore multiple angles about where development efforts were stopped or not, leading to the conclusion:
Developing an alternative methodology for project management founded on a leadership, stakeholder and risk management should lead to a better understanding of the management issues that may contribute to the successful delivery of information systems projects.
Sounds like the way I describe Agile to folks. No, Seriously.
But here’s the big miss as far as I’m concerned – and this goes for the various Standish CHAOS Reports that we hear about from time to time – the definition of failure is this false triangle:
…projects that do not meet the original time, cost and (quality) requirements criteria
Where is the value proposition? None of those three data points are important if the customer received enough value from the solution to make the investment worth it.
When will they add the question, “Did the resulting solution deliver enough value to warrant the extra investment in time/money?”
I’m not saying that any of those projects could be cast as successes if the value question were included in the analysis, but there might be some. Do you think all those expensive and/or late projects were useless?
I doubt it.
Even leaving Agile out of it – although I think it would be hard to deliver software consistently in the following examples without using some elements of Agile – let’s look at some possible outcomes using strictly scope/cost/time:
- Your customer decides that you have delivered enough value after two thirds of the allotted time and don’t need to go further. Failure (scope and time)
- Your customer realizes his/her initial idea had some flaws and changes direction to meet reality: Failure (scope)
- Your customer discovers that the competition has already delivered similar functionality and we need to add some new abilities: cost is not a consideration. Failure (scope and cost)
I could go on, but you get the drift here: Scope aka requirements are the problem. Or rather, signed-off, big-requirements-up-front contracts are the problem.
Yes, you can manage all this in a Waterfall environment, sort of. But if you really could, you wouldn’t be using classic Waterfall, would you?
Agile methods provide an answer for these challenges because we concentrate on delivering value, close involvement with the stakeholders, and regular feedback at short intervals.
Value is the missing metric.