#NoEstimate, successful projects in an agile world. Part 1.

It is known and has been documented that up-front work rarely delivers more than unnecessary time spent in our IT projects. CHAOS Report 2005 showed that this traditional approach was not viable. Approximately 16% of all projects were delivered on time 2005. Over 80% was delivered after budget and time, and the rest was more or less failed projects. Only 9% of the 16% successful projects had been supplied with all the requirements customer wanted. 78% of those 16% had about 74% of the customer’s requirements and expectations.

And the size of the companies did also matter, small and big delivered different results in losses on budget. The large companies went over with a budget of about 180% while smaller companies went over by more than 220% in several projects.

That means there is a 75% chance that a project of 1000 hours will cost a small business about 2200 hours for all the requirements.
Source: http://www.projectsmart.co.uk/docs/chaos-report.pdf

The numbers were changed in the CHAOS report 2013 when agile methods have reached their success by 2005. Approximately 39% of the projects was delivered in time and budget with a 100% agile methodologies such as Scrum, Lean, XP…

Why does so many project fails?
The answers are many, it is everything from how we manage projects, knowledge in organisations, how we manage our customers and attacking redundant work.

A big mistake is that we are so fixated with time. We use time to estimate the costs. This approach automatically more or less means that you agree to an up-front process that’s likely limit the customer the opportunity to request changes and you for welcoming them.  Customer thinks that estimate is almost a contract when we are done. This approach is often called Budget-Driven Estimation or Promise-Driven Estimation. And the real problem here is that customers know that estimate is just a “guess”. But they always refer to it as a promised timeframe. So in the community people want to change this word to something else though estimate is almost always converted as a promise. It would be much better to call it. “We guess it will take 1000h!” instead of telling the customer “the estimate is 1000h.” You get the point right?

And remember that estimate does not actually tell the story about the delivery time frames. The actual delivery time depends on current priorities, WIP and lead-time. But! When a customer asks “how long?” and we answer “eight weeks”, or “1200h” they think the clock has started, and expect to see results after 8 weeks or exactly 1200 hours. But the reality may be that the team will not begin work on the basis of existing PIA and priorities.

Another reason is when leaders see the team members as a developer that you can move around or replace whenever you want. We believe that a developer is equal another developer in skill and knowledge.
Two brothers created in 1980 an idea that people are not equals because they have the same title. They identified that people attack problems differently based on their experience and knowledge. And therefore created the Dreyfus model.
To rank where people exist in all there unique skills.
Source: http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

It is also common to add people to an ongoing project and believe it will create greater efficiency when it’s usually do the opposite. Each new person has to be trained in collaboration, customer requirements, knowledge of the customer, etc. and it usually takes focus from an already productive team. “Nine women can’t make a baby in one month.” It’s called The Brook’s law.
Source: http://en.wikipedia.org/wiki/Brooks%27s_law

To prevent much of this we can focus out processes on the agile manifesto.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

It is important to keep an open dialogue with the customer to ensure that risks are lifted up early on the surface as soon as we learn about them.
Then there is also plenty of time to reduce them. Clients / stakeholders do not like surprises as for the development team!

An estimate should never be treated as a commitment or a promise. It’s not a contract. Therefore, avoid negotiating with time to calculate the budget. Instead focus on the value for the customers and charge for them instead. Be value-oriented not time-oriented. (Part 4 in this series will show some ideas how you can get paid and sell your projects value-oriented.)

So when estimate seams so bad, do we need them? Yes and no.
You can read more about it and #NoEstimate in my Part 2. (will be published soon.)

Advertisements

5 thoughts on “#NoEstimate, successful projects in an agile world. Part 1.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s