- Posted by liammclennan on May 14, 2009
When a customer sponsors a software development project they want to know two things:
how much will the project cost and when will the project be finished.
The trouble with agile is that it cannot answer either of these questions with any degree of confidence. Put another way, the trouble with agile is that it exposes how difficult and costly estimation really is. The agile promise is that for the time and money the customer allows they will get the most value possible, but the magnitude of that value is not known in advance. Agile does not increase the customer's risk, but it increases their perception of risk.
Today I read cogentconsulting's Customer Brief. They talk about how agile should eliminate waste:
we don’t want anyone to spend too much time documenting details that turn out to be irrelevant, or writing down things that can be communicated more effectively by phone or face to face,
and how the customer must give up their fixed-price safety blanket:
you need to be comfortable with the concept that some things will turn out to be cheaper and easier than expected, and some things will turn out to be harder and more expensive than expected.
I was also intrigued by their careful handling of reported defects:
unfortunately, we don’t have an indisputable way of making that distinction [between a defect and a change], so instead we treat every change as simply that – a change.
In other words, the customer bears the risk of undiscovered, misinterpreted or incorrectly implemented requirements. Caveat emptor. That such a mature and respected company felt the need to write such a strongly worded disclaimer makes me think that I am not the only software provider dealing with this challenge. It reinforces the need to educate customers on their role in an agile environment.
I have found some hope reading about Kanban and lean. The refreshing change is that Kanban has removed all pretense of estimating project time and cost. It includes some vague forcasting but the customer is never given the impression that they can fix a feature/time/budget trinity. I like kanban because it is honest, however I doubt how well it will work for a commercial project.
