The software looks good... All you need to change is what it does!

It is not fun when projects go miserably wrong. Luckily enough for us, software engineers, we got used to it. In a recent project I have been involved with as a volunteer developer, we had to face a very brutal reality as we were getting ready to release the product. The product did not meet the expectations of the user group in the organization. For one, it was perceived as counter-intuitive. And secondly, major objections arose by different members of the organization. It was too late to fix all the issues in time, and therefore, we had to postpone the public release.

What went wrong?

Well.. It is difficult to blame the failure on a single reason. And there is really no point of pointing fingers. What matters here is that we have all come out of this learning many lessons. Here is a few off the top of mind:

- Iterative development was called "iterative" for a good reason. Because it should be. While we were in fact developing our project in iterations, we were not effective at showing the actual end-product to the user group to obtain their feedback at the end of every iteration. So at the end of the day, the iterative notion was not REALLY there. When we finally demoed the product, we got bombarded with comments and questions about the absence of certain features, and the inclusion of others.. etc.

- The main business processes should be clearly defined. The flow of certain key processes and the financial aspect of the product were not clear in the minds of the business representatives. Being agile enough to accommodate changes in the process is absolutely important. But when the key processes are vague, chances are we are going to build the wrong product.

- Business decisions should be taken and owned by business people. Because of the previous point, some business decisions were taken during technical meetings by the business representatives in a very ad-hoc and informal manner. It turns out that the decisions had not been sufficiently discussed with the people involved in the process. When the product was demoed, you could see all kinds of facial expressions. Surprised..  amused.. disappointed.. indifferent.. tearing. Most importantly, nobody owned the decisions that had been taken and therefore we were simply asked to wait for a reconsideration of such decisions.

God bless Agile methods! They are there for a reason. And you will never get to appreciate the thoughtfulness of the Agile approach to software development until you experience a not-so-agile one.

http://dilbert.com/strips/comic/2006-01-29/