Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

'No estimates' in action: 5 ways to rethink software projects

Matthew Heusser | Nov. 6, 2013
The idea behind the #NoEstimates approach to software development isn't to eliminate estimates but, rather, to explore other ways to solve problems without specifically asking, 'How long will it take?' Here are five real-world examples of teams that are doing just that.

The common objection to this is governance - that Carmack owns the company and can therefore do what he wants - but publicly traded organizations need to give advice to shareholders and the board on projects.

It's worth noting that Apple, one of the largest publicly traded organizations in the world, is secretive about upcoming products and refuses to make quarterly earnings estimates for shareholders or Wall Street. It doesn't seem to be hurting them.

NoEstimates Really About Solving Problems a Different Way
"My boss would never go for that" may sound like an invitation for dialogue, but it's actually a fiat. Any further conversation boils down to "would not, would too" - and that's not a helpful. Clearly, many software customers want estimates. In many cases, those are reasonable.

Turning the conversation a bit, here's the next logical question: What problems do estimates solve, and can we solve them a different way?

This has been done before; it reminds of Henry Ford's famous claim that if he'd asked his customers what they wanted, they would've told him faster horses.

The line is usually used to dismiss customer concerns, but let me suggest a different idea. Ford's customers were telling him exactly what he needed. If Ford had applied the 5 whys technique to that request for faster horses - driving in to what the customer really needed - he may just have found the automobile.

It's the same with estimates. If we apply "Why?" for estimates, we can drive down into needs such as planning and funding decisions. All the examples above are innovative environments where the technical staff found a way to provide for those needs in a different way.

That conversation can lead to answers such as "It's a lot of money to us" and "We want to reduce our risk." These are things the team can work on. Estimates might not go away, but the focus on estimates, and the amount of time and effort involved, might decrease. This means more time and energy can be spent actually building and testing software.

Wouldn't that be nice?


Previous Page  1  2  3  4 

Sign up for CIO Asia eNewsletters.