Understanding estimation for the misinformed.

When I speak with business professionals, they often need help understanding the basics of agile reformation.  For example, when I hold someone accountable for not doing work, they are shocked I expect results.  I often feel like I am discussing a round planet with people who still think the Earth is flat.  These misunderstandings often lead to dramatic blow-ups as the agile coach expects one result and the business a different outcome.  This week and over the next few weeks, I will try to explain some basic ideas that agile practitioners use.  Today, an overview of why the agilest use story points.

One of the most controversial activities in business is project estimation.  Many estimates for creative projects are a lie.  The company is lying to itself about what it wants and how much it will pay.  The creative team usually lies about how long it is going to take to complete the work.  To any objective person outside this process, it looks like madness.  Everyone is lying; money gets spent, and nothing gets into production.

The Agile Manifesto, with the twelve principles of agile, because the failure of major projects in the business world was becoming unsustainable. The firm spends too much money for too little return on investment; something had to change.  The first thing the agile reformation addressed was estimation. 

A traditional project begins with executives looking at the corporate budget.  After the debt is serviced, shareholders compensate, and payroll is met, a portion of the money is left over.  Managers then submit requests to spend this leftover money on capital improvements and technology projects.  Based on profitability and political clout, this money is doled out.  If you are attentive, you will notice that business executives do not experience the same reality as front-line consumers or employees.  Thus, a software project begins with a pile of money.

Once the managers and directors receive this money, they have to figure out how to spend it. The money comes with plenty of strings. The project has to meet a deadline, which may or may not be grounded in reality. The plan must work with current technology at the firm. Finally, the manager must have people who understand how to take that pile of money and turn it into working software. 

What happens next resembles a demented game of “Name that Tune.”  The manager goes to consulting companies and internal development teams, asking how much time it will take them to satisfy the project requirements. The consulting company bids a price to earn the business, and the internal developers offer an amount to remain employed. It goes on until the bidding ends and the project begins. The costs are not grounded in reality, and neither are the estimates.

What happens next is both farce and tragedy.  The workers with a limited budget and impossible timeline fail to deliver.  Making matters worse, developers are expected to incorporate changes mid-stream, and the deadline does not change.  Eventually, the deadlines are missed.  The budget is used up, and cost overruns are rampant.  Finally, people quit because they are burnt out from working numerous overtime hours to deliver a flawed product.  Quality suffers, money is wasted, and this approach ruins reputations. 

The primary cause of this kind of disaster is that many managers equate time with money.  So, if you have $40,000 and it takes 1,000 hours to do something, this means it will cost $400 an hour.  Now, suppose you have a consultant who will do the work for $200 an hour.  You can do twice as much work.  It depends on both of the people having the same skills and abilities which is not the case. 

Story points for estimates came into being because time does not equal money for complicated projects.  Those projects also feature tremendous uncertainty and are often resistant to automation.  Instead of telling a manager that the team will be able to do the work in 1,000 hours at $400 an hour, a scrum master or product owner will say the team can do fifty story points a sprint and there are roughly 213 story points of work.  The ridiculous game of name that tune goes away and people can start having realistic discussions of time and money. 

Next week, I will show you how that works.

Until next time.