I heard this sentence today: “This is a classic example of a project where hardcore waterfall would be the best way to go. You know, detailed specs up front and not even a single line of code before the whole thing is formally approved.”
A gem. A real gem. I mean seriously. OK, just before you stone me to death let me introduce the context.
A project under discussion just went through a second demo for the client and it was the second time most of assumptions changed and the whole thing will have to be completely remodeled. What a nice case for applying agile methods you say. Well, sort of. The problem is the contract with the client isn’t really agile. Not even close. It is good old fixed-price deal. I would say say fixed-price, fixed-scope but it seems the scope is not as fixed as the vendor expected. And now that you ask, the client isn’t going to pay a penny more just because it seems both sides have hard time understanding each other.
The vendor could always try to harden their positions and reject to redo the damn thing. Sure, that’s always an option. Less likely to be executed when we discuss a key customer which feeds big part of the vendor. Unfortunately this was exactly the case. What more folks on the client side kind of used to work like that – changing their mind just before moving the project into user acceptance tests is almost expected.
The only hooks the vendor could use were any formal agreements which were in place. And because of flexible attitude and “we we specify details when we need them” attitude any specs were very general and highly interpretable.
So it seems that applying hardcore waterfall would probably be the best choice in this situation. It would be so no because it would yield the best application which is optimally adjusted to client’s needs, but because it would force the client to think through the whole thing at the beginning and it would also normalize cooperation between both sides.
Actually in the long run it could be win-win, even though odds are the quality of the application in the short term would suffer. However, in this case it isn’t software quality which is the issue. It is high, and unplanned, cost of redoing the app a couple of times and how the situation affects relation between the vendor and the client.
Whenever you think about methods of your choice, consider all aspects, not only how flexibly you can react to change. After all, change is not always that welcomed.