Using Agile in less-than-perfect situations since Y2K
The one or two of you who actually come to the site to read these posts may have noticed that a few weeks ago, I added a link to Improving Podcasts in my sidebar. Allen Hurst, I, and a few other Improving employees have started producing a bi-weekly (every other Tuesday) podcast covering software development topics.
We have three episodes produced, and the latest was posted just this afternoon. (It may take some time for it to show up in iTunes.) The topics to date have centered around Agile projects management and development practices. Head over there, listen, subscribe, and please provide feedback. We really would love some positive feedback in iTunes, but to suggest topics, ask questions, or invite yourself to join us, the best place is the web site itself.
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.