I was notified the other day of a discussion on estimates that flicked a few nerves.
The discussion surrounded eliminating points from the estimation process, attempting to break cards down to equal sizes.
I can understand the appeal, assuming everything averages out, however I don’t think it’s possible really to break down the cards to equal size chunks, and if you have varied sized cards, you lose the best thing to come out of agile methodology.
The separation between COMPLEXITY estimation, and TIME estimation. (I’ve ranted about that before)
There are two primary arguments that come out of developers who don’t want to estimate.
1 - I don’t want to commit to an estimate, and if I give you one I am committed
2 - If you want a number from me you don’t trust me to do the work
Both of these arguments are demonstrably false. Additionally, they are somewhat contradictory, but often held together.
If you don’t trust your ability to hit an estimate, then why do you expect your client to trust your ability to do all the work they require in the budget they have?
It’s a response to the fear of contract heavy development where planners don’t trust developers that swings the pendulum to the complete opposite direction, where developers don’t trust planners and refuse to allow them to plan.
It’s fairly self evident that it won’t work. Any significant development will need some planning to happen around release dates. This planning will be done whether you chose to engage in it or not.
By delivering accurate estimates, which are regularly checked, you are actually making it less likely that unreasonable delivery dates will be targeted, and making the discussion around moving them a whole lot more accessible and scientific.
Personally, I’ve lately been on a project where estimation was largely dropped for about 3 months.
While we did deliver _something_ along dates which were presented to us, the process was not pleasant for anyone involved.
There were many overtime hours and weekends worked (no way of measuring their positive or negative impact) there were many hurt feelings and complaints every time a new date or requirement came down.
The team had a fantastic level of skill, and the delivered product was a success, however there was not the sense of achievement and satisfaction you might expect after doing so. In general people seemed to think we could have done a lot better.
Contrast this with my latest project, where estimation and regular analysis has been kept up for the 9 month start to launch.
The scope was bumped up by about 50/60% twice, and the team was doubled each time.
The original launch date was pushed out by 3-6 months.
There was of course, pressure to increase velocity and discussions were had, however they were accompanied by scientific data, the tone was never “you are not doing enough” because what we were doing was clearly visible in the burn up chart.
Once the planners moved the release date to account for the new scope and the achieved velocity, the project continued, as planned, and delivered a smooth release without any over time and while some people got a bit stressed in the final week, every single person I spoke to afterwards was satisfied with the result and happy with their achievements.
Now both of those situations were environments where the client already bought into the “agile” mindset, they were both reasonably flexible and had the ability to break away from “planned work” and focus on “delivering value”
I have been on at least two projects previously with pushy, borderline hostile clients, with less ability to shift from the established plan towards delivering real value.
In both projects I can think of, where estimations and velocity were tracked, the conversations over what gets delivered were framed in scientific reality, which goes a great length to cut through the political argy bargy of ‘you were contracted to deliver x dot points by y date’.
The problem seems to boil down to people believing that reasonable project planning, is on one side of an axis, with accurate developer predictions being on the other side.
It’s a false dichotomy, the two are in no way mutually exclusive.