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 steaks, 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.
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, still get paid? Why aren’t we paid by the kilo?
Quite recently I encountered a fine example when I asked the participants of a course on software estimation I ran 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.
Getting paid by the 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 software. Wouldn’t that change the world in software development? That would mean that we actually would be bothered whether the requirements are done, our use cases are buildable, the software was tested as soon as possible, the acceptance criteria clear, the users involved, and the customer 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 getting paid by the function point, or the smart use case point.
See also: Accelerated Delivery Platform.
P.S. I am currently writing a small white paper on accounting techniques in agile projects. If you would care to review it, don’t hesitate to drop me an email.
7 thoughts on “The butcher model for software development”
Those are called fixed price projects.
The analogy of the butcher is obviously flawed. He doesn’t have to design and grow a cow, before he can deliver the meat.
You can buy software by the kilo, just grab a retail package of the shelve in a store and go pay for it.
kind regards,
Jeroen
Dear Jeroen. I have to disagree with you. The idea of a fixed price project is to pay for the project after all functionality is delivered. In this model you pay for the use case as soon as it is delivered. Not at the end of the project. In agile projects, especially in Smart projects, where smart use cases are the primary driver, individual features are delivered one at a time.
@Jeroen Trappers: The way fixed price projects are run in most companies I’ve seen it’s more like going to the butcher and asking for a 4 years supply of meat for a fixed price without really knowing how much meat you’re going to eat the next 4 years. The butcher will try to sell you as little meat as possible and you’ll probably end up trying to order far more meat than you need in order to get the best price.
Of course any software engineering analogy is flawed in some way but I like it for the point Sander is trying to make.
Jeroen,
I disagree (and subsequently agree with Shoogend), you don’t have to approach this like a fixed price project. What if you were working on an agile project and you got paid by the point? I have seen that work. The butcher doesn’t have to design or grow a cow like we don’t have to deal with registers and bits anymore (I understand it is taking the analogy a bit far). The butcher does have to design (cut and cleave) the meat and package it according to his craft.
I work in a model like this, because it creates a natural tension to do good work. I get paid for what I do, and get paid less for mistakes. This seems self evident to me that I should be paid based on the merit of my work.
Good blog.
Hi there,
the idea is valid. The only challenge I see is how you describe the features you are going to get paid for up front. In small or even medium sized projects the customer may be willing to accept those conditions (if you can give the customer a price/effort range). But in a lot of cases the customer may want to know upfront what the piece of software he ordered will cost (especially if we are talking many hundreds of use cases).
The main issue is still: if you go a butcher and order a piece of certain meat, you and the butcher know the “characteristics” of that piece of meat, and in addition, those are well defined (not just by you and the butcher).
But there is no such definition for software or even components of software (unless you go to get a packaged product with its advantages and disadvantages). If the customer agrees to use that model and you get payed by function points (or any other unit) the customer still doesn’t know up-front how much or what he will get and how much it will cost in the end, unless you find a way to define it up-front.
One aspect that’s definitely good for the customer with this model is: he/she will pay for functions and not for effort spent or planned. So the risk is up to you, the provider of the software (component).
Just my two cents 🙂
Cheers,
Michael
@Sander:
If I understand you correctly, you want to tailor the accounting to the development cycle, but in a “fixed price” kind of mind setting. When developing incrementally, with each release, the product offers new features, which are paid a fixed price for when available.
Lets call it an incremental fixed price project (or something in that genre) then, I still don’t like the analogy to the butcher ;-). I think that also, for the first few “sprints” — scrum lingo — this kind of accounting can be difficult, because a minimal foundation of a project has to be put in place, setting up the environments… So there would be a startup cost involved as well — “features” the client hasn’t asked for.
If I’m not mistaken this kind of accounting is already used for delivered fixed price projects, when change requests are asked for.
So you can think of it like this: your first release is very basic, almost no real features. Then the client asks for changes (features) which are accounted for one by one.
In reality, I think this kind of development will overall be more expensive, because every time a new feature is requested, there will potentially be a lot of impact, compared when features are roughly known beforehand.
@Michael Pichler
I roughly agree with you.
The method you propose is already in use at COA (Centraal Orgaan Azielzoekers).
They call it the pallet method. Not waiting until all pallets are known, but start loading the truck from the moment the first pallet is presented.
This method has as said some setbacks: it is only valid if the architecture and infrastructure are in place and known.
You always run the risk that the truck is too small or that the first pallet has to be unloaded at the first address. It also usually implies that the space in the truck in not efficiently used.
So you analogy with the butcher would be valid if you had to choose between beef for a gas stove or for a electric stove, where the number of flavours you are going to use determines the price.
Comments are closed.