4 min to read
On Estimation & Agility
I was doing an estimation review recently.
At first blush, I am instinctively uncomfortable about anything that requires a high degree of predictability in software development since that is going to be violated if you are ever intending to produce software that could be deemed useful by the ultimate consumers!
It is exactly like doing the interiors of a house which is an activity that I was partaking of recently. I was engaging some interiors contractors to do the work. Their estimation and invoice depended on a simplification. They merely told me that it would cost me a certain amount based on the fact that I am finishing a wall that is “y” sq.ft in area. The cost of one sq.ft is x. Hence the total cost is x*y of course exclusive of applicable taxes, surcharges and all the rest of the appurtenances and caveats you would find in an estimate. Now it is possible that I might decide to finish the whole wall or just a small fraction of it. But the estimate (and in this case the ultimate invoice as well) does not change. At the end of the day I felt that the dice was loaded against me since I had to pay for the whole wall irrespective of what parts of it, I decide to furnish.
But I realized that this is the only way an estimate ever works even in software development. I decide on the unit cost based on previous experience. I just estimate the “approximate sq feet” I need to build and multiply it by the unit cost to arrive at the total cost. However, if I were to take a more agile approach, I would exactly pay for the amount of materials I use, the labour charges etc. which would be more accurate. It might or might not work out cheaper. But at least, I know that I get what I paid for and that no one gets “shafted” in the process. Both the parties get a fair deal.
The trouble with software is that there is no raw material to build on. Sure you need application servers, package solutions, products to enhance,languages, operating systems etc. But these are not raw material for the software. These are more like edifices on which the software development rests. So it is all labour charges so to speak. Hence estimation (and ultimately the cost) tends to be time based and the cost is determined by the total time and the unit cost per time for the “labourers”. In short, the numberof people is directly proportional to the cost of the project. This simplification is essential for estimation but is at variance with experience. I don’t get the exact same kind of people. They don’t cost the same. More importantly, the quality of the artifacts that they produce is not the same.
On the one hand you are comfortable with the certitude that comes with knowing what is the exact cost upfront. On the other hand, you want the flexibility of a dynamic solution that is geared towards changing business needs. It is hard to reconcile these two inherently conflicting forces. Hence, all estimates are approximate at best. At worst,they lead to law suits, high attrition and all kinds of unpleasant things bordering on eternal perdition.
This harks back to a comment by Robert Martin in his great treatise titled “Agile Software Development - Principles, Patterns and Practices” which is a book I heartily recommend. You can find a quick and unhelpful review of mine in the Amazon web site here.
Robert Martin says that people are not “plug compatible programming units”. Most estimation processes assume that people are exactly that. They assume that people can be shoved into a software building assembly line and over a period of time - the software comes out the other side! Hence, IMO, the estimation process is at loggerheads with agility.
That is why most great softwares are not produced by SOWs. Software development needs trust. It needs a certain relationshipto be built over time among the participants. It requires passion. Most importantly, it requires excitement from the individuals which can only be obtained if they perceive career growth. Treating them insouciantly as “plug and play resources” devalues them and makes them feel sub-optimally used.
It is not for nothing that Alistair Cockburn opined that:
Process and technology are a second order effect on the outcome of a project. The first order effect is the people.
Comments
Gayathri: Rightly captured Raja!! Especially the plug and play aspects of people. The biggest feature of software which the whole process of estimation ignores is that its not a tangible . Often there is no clear cut way of measuring whether a certain requirement has been fullfilled in its entirety. The typical software process testing is very immature so to speak . It first checks on the functional aspects and is not equipped to mark something complete in all aspects. But the problem is that we bank on previous experiences always and this might be flawed in itself. Thanks for the write up.
Comments