2010-10-06

{water}Falling out of Agile

The waterfall approach


My last two software development groups switched to Agile while I was part of them. In both cases, it was a relatively amazing experience for me. Instead of towards a long term goal and finding out just how far off the mark we had been from the start when we finished, we were able to change directions so quicker in the middle of development.

If I was to plot a big project's path before we started with Agile, it would look something like this:



Each line in that graph is at least a month. At the end of the first phase, we had a usable product, but we realized that it really wasn't what our customer actually wanted. We eventually built what our customer actually wanted but it took close to a year, and we radically changed the product's direction several times.

The agile approach


Compare that to our path under agile:


Each segment is two weeks. At the end of the first iteration we had a somewhat usable product, but we realized then that we were already headed in the wrong direction. So we changed the product's direction early and often. Note that at each step our goal is the same as a phase in the waterfall method, but we change direction way before we reach our goal. Instead of taking over a year, the project took fourteen weeks. The development team was happier since we did not have to throw out huge chunks of code that we had written, and the business owners were happier since they could see our progress towards a goal.

Back to the stone age with you!


My current project is using more of a waterfall approach to designing an API. Instead of biting off tiny chunks of the API for development and building the client to go along with it, we're building the API out fully first, then building the clients to consume the API.

So far this has already led to lots of wasted effort. If I think I understand the business case for something and build an API for it, the API will work awesome until I try to use it for a real-world test. Then I find out that the definition of a concept I was operating under is wrong. So then to get the client to successfully consume the API I have to write the client and change the API at the same time.

We had a contractor work for three months on a large segment of the API that we ended up completely not needing. While working in a more Agile way wouldn't have kept him from writing all of the few thousand lines of code that has been since deleted, it would have shown us much earlier that he was going down the wrong path and at least some of his work may have been saved.

Agile wants a usable piece at the end of each iteration. That requires building at least an example client along with the API.

No comments:

Post a Comment