Life, Liberty, and the Pursuit of Agility

I’ve done 12+ sessions at Agile and Developer “user groups”, Agile or Dev conferences, college classes, and code camps where the main topic (or a big component) of the session was Estimates in Software Development.

Here are the notes from one such session I facilitated last year at an Open Space event (Agile Open California, North)

Session Title: Estimates – Can’t Live With Them, Can We Live Without Them?

The title was my own.  I’ve been talking about, and holding sessions on this subject for several years, and the previous time I was at this event a couple years earlier I did a session on “5 Whys on Why we Estimate”.  It was a very contentious session, with almost everyone (except me) feeling estimates are important and needed for software development, and the problem is just that we’re no good at it… so we just need to get better at doing estimates.  I don’t agree (as you probably know).

The “we just need to get better at it” argument sounds a lot like what I used to hear in “post-mortem” and “lessons learned” sessions in waterfall/phased project environments. A typical “take-away” from those sessions were things like this: ”We missed our deadlines and had a lot of rework because the requirents kept changing, even though we have a change control process in place.  We need to get better at controlling changes to requirements”.  I hope you see that is very likely a bad conclusion.  Essentially, that line of thinking is that “since control isn’t working, we need more control.”

I’ve been suggesting that if we keep failing at getting good at estimates even though we are working hard at becoming better at doing so (and have been doing so for countless years), then maybe we are expecting estimates to do something for us that just can’t be done.   Maybe there are better ways.  [Just to be clear, for me - I feel I have found a much better way and it is Agile Software Developent as presented in the Agile Manifesto (Values and Principles) - the Agile MVP.]

My position: We need to get to the bottom of what it is we want from estimates and predictions, and find a better way to get to what we really want. [HINT: What we reallly want is Sucessful Software Development Efforts (or something like that, perhaps?) .  Or, as long as we are wishing, let's just wish to win the Mega Lottery and then spend our day's doing something we really enjoy. Like taking hikes or arguing - whatever you like.]

Participants:

There were initially 17 participants.  Developers, ScrumMasters, Agile Coaches, Product Managers, etc.  Almost everyone had some experience with Agile/Scrum/XP/Lean.  A few people joined in as the session proceeded, and a few others left.

Purpose:

Explore and discuss what we want out of estimates and the problems we’re having with estimates.

[NOTE: Everything will be tainted because Woody Zuill is facilitating this session, and he leans slightly toward the "No Estimates" approach.]

Process:

My approach for this session: Quickly explain my basic thoughts about the failure of estimates and the purpose of the session, do an information gathering exercise.  Ask why we feel we need estimates, have the participants write their thoughts on sticky notes, group them, and then discuss.

Information Gathering: Why do we “need” estimates

• We gathered sticky notes to identify “why we ‘need’ estimates and put them on easel sheets
• We then gathered the notes into groupings.
• There were 2 main groupings: Estimates are for planning, and estimates are for manipulating
• NOTE: Tne notes below were written by the participants.  Some are a bit cryptic. Not to worry, okay?

• Here are the notes and the groupings:

Affinity Group: Estimates are for Planning

• How many resources do we allocate to do the work
• Length of engagement
• Costs
• To Predict Future Velocity
• You need estimates to determine budget
• To determine when we’ll finish
• Target implementation time-frame & duration for resource allocation & cost estimates
• When to commit to customer delivery
• to decide whether or not to do a task
• To Determine when a feature will be available
• To determine when we’ll finish
• To know when it is done
• It drives the business
• So we can prioritize
• Business needs it for planning
• Request funds for work
• To help balance the work
• Helps in managing resources
• Determine if end result is worth the cost
• To give the customer prediction – to meet customer expectations
• CEO needs it.

Affinity Group: “Gaming” or manipulating the system and related stuff / dysfunctions

• NOTE: I am not discussing these things in this post – sometime soon I’ll cover this stuff in detail.
• The keep your job
• To give a reason to yell at someone
• It’s “How we do things”
• Habit
• Need to get a programmer fired (setting her up for failure)
• To cover your own ass as a developer
• To pit people/teams against each other

Now for the discussion

After our gathering and grouping exercise, we began discussing what we felt this showed us.  During the discussion we just “followed the flow” as ideas were expressed.

We observed, as a group, that estimates are mostly for planning and making decisions about what to work on.

In the discussion, we were in alignment that we “need” estimates so we can plan our work, and so we can make decisions about which projects or features to work on.

After all the effort we put into estimating, we still rarely get things done “on schedule” and “within budget”.

Also, we still frequently ask (or our managers ask): “Are we there yet?”.

Why do we have these problems?  We’ve been doing estimates for years – shouldn’t we be great at it by now? Other similar or related things that we’ve seen:

• Progress isn’t visible
• We seem to be get more behind our schedule no matter what we do
• Money is running out and important things are not even close to being done.
• Stuff we thought was done turns out to not be.

Rarely are the estimates accurate enough to really count on for release dates, costs, etc.

How do we typically deal with “over budget” and “not on schedule” issues?

• We end up cutting features
• Pushing out deadlines and so on
• Hire more people
• Blaming each other about whose “fault” it is
• Agreeing to get “better” at gathering requirements and doing estimates “next time”

Still, others are dependent on estimates such as marketing, HR, Ops, our customers… and so on

• Do estimates really provide sufficient information for these folks to get real value?
• Or… are there a lot of decisions made based on faulty estimates???

So, With all these problems, why aren’t we looking for a better approach? What is wrong with our estimating process? Should we try to get better at it, or… ?”

One reason estimates provide little chance for usefulness:

• The Unknowns might invalidate any estimate we make – estimates by nature contain unknowns
• What is 4 x 8 + 7  / 2 * 83 + unknown?
  • The answer UNKNOWN
  • We can guess, or base our UNKNOWN on similar things.  Might work. Might not.
• Many important decisions are based on UNKNOWN, but we act as if we “KNOW” something
• The argument is often made that we just need to “have some relative estimate…”
  • It is likely that even this leads to bad decisions
  • For example, what good is relative decision based on “This UNKNOWN is bigger than that UNKNOWN?”

MY CONCLUSION AS PRESENTED:

So, if the Estimating process is flawed (and it might be), and getting “better at it” hasn’t worked… Do we really need estimates?  Can we innovate a better way?

• What I am suggesting is that we have to evaluate our dependence on estimates
• My own experiences have proven to me that estimates are not always needed.
  • I’ve been working without estimates for over 3 years with good results in corporate, “internal” projects
  • I’ve had several long term ongoing projects that did not use (or need) estimates – One of over 4 years on commercial software
  • I’ve done contract work with NO ESTIMATES. Many have told me “customers won’t do that”, but there are at least some that will.
    • When a customer sees that more “real” work gets done and more of the right thing gets done with less “busy work” they get on board.
    • Finding ways to pay a very low cost to prove something works, or doesn’t work is very attractive to most customers.  To me, this is a fundamental benefit of an Agile approach.
• My experiences are not proof that estimates are not needed.
  • I am not trying to change the world.  I do want MY jobs/contracts/customers to get the benefit of doing things in a better way.
  • I AM trying to invite conversation about this stuff, and encourage us to explore and replace these painful practices in our profession.

This discussion had more to do with posing the questions than answering them

• It is contextual (as usual)
• Lots of organizations feel they need estimates and you must work within the system.  Sorry for that – but I can’t fix that.
• Often, customers will not entertain using a company that does not provide an estimate.
  • They want to know what they’ll get, when they’ll get it, and how much it will cost.
  • It is a risky situation for everyone – and if you are in that world, there are still ways “sell” the benefits of finding a better way.
• I am suggesting is that we need to do some serious thinking about how to change this reality, and innovate ways to eliminate the dependence on estimates

I am proposing that we need to imagine a different world

• Do some “thought” experiments
  • IMAGINE:
    • What if we were to find that estimates have NO value (zero benefit), should we still do them?
      • What would that look like?
    • What if we were to find that estimates are harmful and are counter-productive?
      • What would you do?
    • What if the were to find out that estimates are fatally TOXIC
      • What would we do then?  How fast would we need to address this?

Take some action that will expose the reality about our estimates

• Can we find a way to wean ourselves from estimate dependency?
• A few things that have worked for me
  • Deliver value quickly and frequently (sound familiar?) – that is: put small chunks into real use early and often
    • Making decisions about “what to do” become less important when we can do “some of this” then “some of that” and see what works (or doesn’t work) quickly and cheaply.
    • People stop worrying about “are we there yet” when interesting (useful) things are continuously happening and being put into real use by real users.
      • It’s like bringing along some new toys and activities to hand to your kids on long trips when they start getting antsy.
  • Lead your customer/stakeholders/whatever to an understanding of what is important to deliver NEXT…
    • … we only have so much work that can be done right now – focus on that
    • … put all your effort into that
    • … and put little time on all else
  • You can introduce this a little at a time.
    • Thinking people who are open to this will slowly come around.  Or not.  Just depends.

Remember: I am just encouraging discussion.

What works for me might not make sense to you.  Maybe someday it will.  When that happens, you will have crossed over into the land of no estimates.  Beware.