This is in fact a tricky spot: for both Agile practitioners, and the economic buyers. I will pick up the case for Agile practitioners a bit later, let's see where do the economic buyers stand with price-to-value game. So far, these group of people were sold on the Agile methods with the fact that they would get to see what's getting cooked in the kitchen. In turn, there were no certainty on the cost involved in cooking that dish. Increasingly, the economic buyers realized that they don't really need to be in the kitchen to see how the cooking happens. It's important to get the dish right; it should be palatable, and it should be hygienic. In other words, the software application delivered for use should be effective in meeting its objective of existence, and it should be trustworthy for carrying out the business. The economic buyer, may be the CFO of the company, doesn't need to spend time in seeing that a singleton class is getting developed, tested, and deployed for other classes to invoke it.
Once that's realized, the next big question is how to ensure that the software production cost is contained with respect to the value it will eventually deliver. The easy path would be to determine the value (or IRR), and calculate back the maximum amount of money to be spent. Once the maximum amount of money to spent is confirmed, that becomes the budget for that particular application development.
So far so good. The problem is that there is still no certainty that the application will get developed within that budget. After running sprints after sprints, the budget may get burnt completely only to deliver a bunch of classes and database objects with no realizable business benefits. The poor economic buyer, being part of the entire drama of cooking codes, would now be left with the pieces of marvels, but without any clue what to do with that. Agilists delivered, though.
On the contrary, the help is actually around. The IT service suppliers are available to design, develop, test, and deploy codes with demonstrable credentials in hand. The competition among them brings the benefits of bidding fixed fee quote, thus insulating the economic buyer from any financial risk. This is a proposition too hard to resist. But can Agile methods be fitted with this fixed fee structure?
Agilists, on the other hand, had a different problem in hand. What used to be a sideline process so far, has become a mainstream. Being a mainstream software engineering process, it's difficult to avoid the monetary question: how to ensure that the business benefits are realized at right cost? To address this concern, the initial thought was to follow Agile methods with a fixed budget. The product owner should know how much money to spend. Based on that, the product owner would determine the number of sprints to be performed, with the number of team members. Subsequently, the product owner should also make a broad classification of the features and functionality to various sprints. With this, our Agile project has become a fixed sprint project. A seemingly uncompromisable deviation, but okay!!
The fun part of market forces is it not only negates inefficiency, it also makes an open mockery of it. When the competition demanded to quote fixed fee for a software development project, even if it is supposed to follow Agile, it really pushed Agilists very hard. Too hard to stay sane. This time the question of ethics came out of the pocket. Apparently, asking developers to develop a program in fixed fee is an unethical practice. With this hypothesis, the argument was structured that software development in a fixed fee fashion is unethical practice. Agilists, being always on the right side of ethics (no matter how much they abused the traditionalists before), cannot accept this. So, Agilists will do T&M work.
Without going to the details on ethical practices and all that, let's try to look into the issue with our feet on ground -
1. Agile is going to stay, some of its practices are not available anywhere
2. Fixed Fee work is inevitable, a buyer is not actually buying programmers' time, buyer is buying a piece of software
3. How to fit the best of Agile practices into a fixed fee project would be the puzzle to solve.
My next post will try to address it.
