Practically Agile

Using Agile in less-than-perfect situations since Y2K

Embrace Failure

I just can’t say how much I agree with this. One of my favorite things about Agile methods is their ability to find problems quickly. The problem is that it makes it very difficult to sell to folks who are used to methods with slower feedback loops. I can think of several projects over the last two or three years where the team exposed significant problems very early on in development.

In one case, we were able to pinpoint a major domain modeling problem early on. The customer kept phrasing things as though the application centered on one concept. Through a very early (iteration 2 or 3) demo, we were able to discover that this was due to thinking of how the system being replaced worked. In fact, what the customer’s business really needed was to be able to focus the system on a completely different concept. Because we found it early, we delivered a much better and more valuable system.

That said, the point of the linked post — and this one — is that software projects will fail, Agile or not. While we often sell Agile as a way to get to value quickly, we should also sell the other side — it also is a way to get to failure quickly. And that is a good thing.

It occurs to me that we talk about something similar in Episode 1 of Improving Podasts. What? I haven’t mentioned that yet? Hmm…

. 14 Jul 09 | Uncategorized | Comments (4)