Suppose that while getting the groceries for the weekend, I decide to buy some steaks. I’m not sure yet whether it will be tournedos or regular steak, but meat it is. So I go to my local butcher shop and lay down my requirements. The prices for tournedos and steak are known, they can be viewed from the examples on his counter. The butcher gets paid by the kilo. If I want to buy a kilogram of tournedos, I will have to pay him Euro 30,00 and if I’m buying a kilogram of regular steak – fine with me – I am going to lay down Euro 25,00. That’s a plain and simple accounting mechanism. The butcher delivers the goods, and I pay for the goods.
We are currently working on a small white paper regarding accounting models for agile project, more specific on Smart and Feature Driven Development (FDD) projects. When it's done, it will be published on this website.
Sander Hoogendoorn
Chief Architect ADP
Getting paid for hanging around
Sounds like a feasible model, doesn’t it? So why can’t we have such a model in software development? Why is it that so many analysts, developers, testers and yes also project managers just sit around in projects doing their thing, not delivering software, and still get paid? Why aren’t we paid by the kilo?
 Paying per delivered steak |
Quite recently I encountered a fine example of such a project when I asked the participants of a course I ran on software estimation to tell what they were doing. One of the participants was a tester. He was hired by a large well-known governmental agency in the Netherlands to participate in a project. And with him about thirty other developers and testers. However, when they entered the project, the requirements were not ready. So they had to wait. For one and a half year they had to wait. And they were still waiting. And they were getting paid to wait. Not their fault, but nonetheless. Just to many people in software development get paid for lingering, for hanging around. It’s all about being there.
Paying per smart use case
Now suppose we would follow the butcher model. That is, we would only get paid (by the kilo) if we deliver the meat. And in our case the meat, of course, would be the working software. Wouldn’t that change the world in software development? That would mean that we actually would be bothered whether the requirements are done (medium-rare, not well-cooked), our use cases are buildable, the software is tested as soon as possible, the acceptance criteria are clear, the users are involved, and the customer is up-to-date. It would mean that we were actually motivated to deliver.
So, if software development is craftsmanship, as many claim it is, and not a work of art, as others fanatically believe, why not model our work like butchers and bakers do. Deliver by the feature (or by the smart use case) and get paid by the function point, or rather by the smart use case point.