|Estimation is not a quotation of work.|
Ryan Ripley, a coach, and trainer I respect is an advocate of the “no estimates,” camp of agile. I have blogged about this school of thought, and I consider myself a skeptic. I think it is easy for a team to operate without estimating but executives who are paying the bills are horrified when highly paid professionals say they do not have an educated guess about when they will finish work.
The reality is executives are craving certainty in an uncertain business world. An executive wants to know the budget is not getting wasted. Most executives do not understand the technology which keeps their organization workings, so this creates an additional level of anxiety. Finally, technology is changing so quickly a course of action which made sense at the start of the project can backfire at the end of the project.
Agile and scrum attempt to solve this by using rapid iterations to build a shippable product which business professionals can then inspect and adapt. It works like a charm, but for larger projects with multiple handoffs between systems, it can create a sense of apoplexy. Teams are on schedule but with different cadences of work. Software code on one team does not work correctly with a different team. Meanwhile, time continues to move forward, and deadlines made without any feedback from the people doing the work begin to slip.
Estimates are treated like quotes because when deadlines slip executives can point to the faulty projections as an alibi for failure. Activities such as construction and automotive repairs are easy to estimate because the rules which govern those activities are reasonably constant. Concrete dries at a particular speed. A repair shop can replace a tire in about an hour. The laws of gravity have been steady for eons. The nature of software development makes it nearly impossible for smart people to provide accurate estimates.
Multiply this reality over numerous projects which have to work together with tight deadlines and tighter budgets you have a recipe for madness. The software teams are groping in darkness, and the executive team is demanding some light and direction. What can be done to break this pattern of insanity?
The first thing which needs to change is executives should understand estimates are not quotes of work. An estimate is an educated guess at best and a cruel lie at worst. Software working in production is the only credible sign of progress. Based on what is working in production a leader can make more informed decisions about what to do next.
Next leadership needs to fund cross-functional teams. Often projects are supported, and they have a beginning, middle, and end. When a project ends the team is disbanded and with it the knowledge to maintain or improve the system just created. High functioning teams should stay together and given different projects. A marketing team like this will develop logarithmic expertise and use it to defeat the competition. If you watch Netflix, I recommend the story of Barbie and the “pink berets,” who worked in Mattel’s marketing department.
Finally, leadership should accept software development and other complicated projects should resemble the commute to work. Somedays the traffic is heavy and others it is light. Construction can cause backups, and occasionally a car fire will create a gaper's delay. Accept variability of work and try to avoid forcing unreliable estimates into schedules not grounded in reality.
If executives and business leaders can understand these principles estimates will no longer be an alibi used to forgive failure.
Until next time.