Estimating Tasks
It is even more interesting that the spread sheet he (my builder) was talking about was his estimation spreadsheet. By adjusting several parameters, notably foundation size, room types and quantities, square footage, and some more – he felt comfortable that he had sufficient accuracy to cost the job, and stick to it! It was pretty simple and he confided in me that every so often he adjusts things in the spread sheet, but overall it is sufficiently accurate that he never messes up too badly. We talked about that a bunch. Once he was done with his line item estimates, he adds two additional categories – contingency and profit. Between the two, he has never lost money. He did indicate that on occasion he doesn’t make money, but he has never stiffed a sub nor failed to pay a bill. He has been stiffed by a customer.
[another aside for another post: While he was building our house, he was building a larger house on a more complicated lot. That owner was a PMP, I met him at a benefit for the Boys and Girls club, a hazard of using this builder. He had instituted a formal change management process with the builder so that both costs and changes would be managed completely. His wife was to be the arbiter and inspected the job site daily (or there abouts). We chose a more agile approach (surprise!). We were in our house 30 days late, but within our budget. They are 90 days late and counting and are 25% over budget and growing. However, they will probably have cable before us.]
The spreadsheet was used for the bank – to tell them why monies needed to be drawn down and what inspections needed to be completed in order to prove completion of rewardable milestones. The key to the spreadsheet was its heuristics that were developed over 20 years of building in the same towns with ostensibly the same vendors and subs. Much of the statistical variation had been eliminated, but there were still risks. No one could have anticipated that the hurricane would increase fuel so dramatically in turn increasing costs of things like bricks and plastic, nor the run up on copper that resulted from completely different reasons.
Now, if we could estimate our tasks with a spreadsheet, maybe we would eliminate the statistical variation as well. But wait! The variation on the house had to do with the weather and world events, not design. Our mason had built enough chimneys to know that a two story rumsford with strong detailing would take X days + Y depending upon whether it was too cold for the mortar to set. He reviewed the design, estimated the materials, and put in a bid. He ate a little of the bid because it turned out the foundation was mispoured and some augmentation was necessary (an extra day or so). The foundation contractor split the cost, we saw none of this.
So, what is the difference between the chimney and estimating and executing against a software story? Well, let’s think…In both cases, you want the final acceptance test to be a mere validation. It is really expensive to pull down a chimney and redo it if it doesn’t draw properly, just like throwing out an entire function and re-implementing is not cost neutral either, so that is not it. In both cases, customer expectations must be taken into consideration. In the masonry, there are fewer external interfaces, but there are some very basic ones (the foundation). Perhaps the biggest difference is that in software there are multiple ways of creating the logic tree that would carry the instruction flow - more than one way to skin the proverbial cat.
In masonry, there are many patterns to laying the stone or the brick, but each is an embellishment upon the basic plan. In software, there are innumerable paths that the logic can be defined to accomplish the task. The complexity becomes massively greater when dealing with an existing system because of the number of additional interfaces that must be managed and decision paths that must be integrated.
In agile, we try to break stories down to their elemental functions and then build them up including only those blocks necessary to produce a sufficiently strong structure. Unless specifically included in the story, all embellishment is extracted. The initial implementation should clearly be functional, but remain basic. This concept, YAGNI*, helps create a set of estimate-able tasks. What allows these estimates to become more accurate is the power of the group.
*YAGNI – You Ain’t Gonna Need It!
[another aside for another post: While he was building our house, he was building a larger house on a more complicated lot. That owner was a PMP, I met him at a benefit for the Boys and Girls club, a hazard of using this builder. He had instituted a formal change management process with the builder so that both costs and changes would be managed completely. His wife was to be the arbiter and inspected the job site daily (or there abouts). We chose a more agile approach (surprise!). We were in our house 30 days late, but within our budget. They are 90 days late and counting and are 25% over budget and growing. However, they will probably have cable before us.]
The spreadsheet was used for the bank – to tell them why monies needed to be drawn down and what inspections needed to be completed in order to prove completion of rewardable milestones. The key to the spreadsheet was its heuristics that were developed over 20 years of building in the same towns with ostensibly the same vendors and subs. Much of the statistical variation had been eliminated, but there were still risks. No one could have anticipated that the hurricane would increase fuel so dramatically in turn increasing costs of things like bricks and plastic, nor the run up on copper that resulted from completely different reasons.
Now, if we could estimate our tasks with a spreadsheet, maybe we would eliminate the statistical variation as well. But wait! The variation on the house had to do with the weather and world events, not design. Our mason had built enough chimneys to know that a two story rumsford with strong detailing would take X days + Y depending upon whether it was too cold for the mortar to set. He reviewed the design, estimated the materials, and put in a bid. He ate a little of the bid because it turned out the foundation was mispoured and some augmentation was necessary (an extra day or so). The foundation contractor split the cost, we saw none of this.
So, what is the difference between the chimney and estimating and executing against a software story? Well, let’s think…In both cases, you want the final acceptance test to be a mere validation. It is really expensive to pull down a chimney and redo it if it doesn’t draw properly, just like throwing out an entire function and re-implementing is not cost neutral either, so that is not it. In both cases, customer expectations must be taken into consideration. In the masonry, there are fewer external interfaces, but there are some very basic ones (the foundation). Perhaps the biggest difference is that in software there are multiple ways of creating the logic tree that would carry the instruction flow - more than one way to skin the proverbial cat.
In masonry, there are many patterns to laying the stone or the brick, but each is an embellishment upon the basic plan. In software, there are innumerable paths that the logic can be defined to accomplish the task. The complexity becomes massively greater when dealing with an existing system because of the number of additional interfaces that must be managed and decision paths that must be integrated.
In agile, we try to break stories down to their elemental functions and then build them up including only those blocks necessary to produce a sufficiently strong structure. Unless specifically included in the story, all embellishment is extracted. The initial implementation should clearly be functional, but remain basic. This concept, YAGNI*, helps create a set of estimate-able tasks. What allows these estimates to become more accurate is the power of the group.
*YAGNI – You Ain’t Gonna Need It!
posted by mgelbwaks at 8:44 PM
0 Comments:
Post a Comment
<< Home