All of this was focused towards estimate quality…not software product quality. I was worrying about how to represent the time to build the software to stakeholders and accountants so that we could reasonably know how much it would cost. Then we could make better decisions around whether to start it or not.

The odd thing, at least in my experience was that no matter how hard I tried nor how much effort I expended on estimation and planning, over 60% of my projects went awry. They failed. They were Death Marches. They were incredibly painful. And in many cases, they resulted in people losing their jobs.

I guess my point is—estimation is incredibly hard.

Now you may say, well Bob, you simply were poor at estimation and didn’t really perform it all that well. My counter is that I am really good at estimation. I’ve studied a wide variety of techniques and applied them diligently. I’ve even taught software estimation at international conferences. So, while I still have much to learn, I’m not a tool-less novice.

And I guess my other more crucial point is—estimation was the wrong place to be focusing my efforts!

What the Agile Methods Taught Me

When I first was introduced to the agile methods I was struck with the practicality of the planning. Instead of focusing on planning & estimation, the methods broke things down into two levels—high level release forecasting and low level detailed iterative planning. More importantly, it was the interplay between these two levels over time that refined your estimates.

No longer did you try to predict a guaranteed endpoint for a project. Instead you gave a reasonable, high level view that you promised to refine every time you got real-time performance results from your team. You would then narrow your view over time as you iteratively gained traction delivering real, working software. At each point of actual data, you would update your release plan / model and re-communicate to stakeholders where things actually stood in relation to their expectations and your previous views.

If you were behind schedule, stakeholders had the option of dropping, reducing, or re-framing scope based on business value and priority. But in order to hold to a date, they would have to adjust something. If you were ahead of schedule, a not so rare event, they could pull in more value-based scope and deliver more than anticipated.

High Level – Release Planning

The methods don’t spend a lot of time estimating in excruciating detail at the high level. Instead you estimate work (usually expressed as User Stories) in generic level of effort/complexity units (usually expressed as Story Points) so that you can plan the number of stories you can fit into a series of sprints to meet a content commitment for your stakeholder.

Remember, release planning isn’t a firm commitment. Nor is it exhaustive, detailed planning. It’s a best guess, high level view to packing work into iteration sized time-boxes. However, there’s a missing point to accurately planning a release. What you might ask?

It’s the teams’ own velocity. Put another way, the teams’ ability to execute and deliver fully done stories within your iteration time-box. The first time your team actually delivers work from a 2-week sprint you have a wonderful data point—actual team velocity! Please don’t undervalue it.

Low Level – Sprint Planning

But I got a bit ahead of myself.

In the agile methods, where does the team dig into the details? Refining tasks, looking at dependencies, breaking things down into smaller, quantified (hourly) units of real work to be completed? They do that on an iteration (Sprint) by iteration basis—grabbing a small “chunk” of the work, always the highest priority and most urgent work, and breaking it down for the very next Sprint.

If you ever get the chance to attend a proper Sprint Planning session, you’ll have transparent access into a software team breaking down work into very small tasks. You’ll begin to understand all of the complexity and nuance for each story. You’ll hear the testers challenging the developers on testability and how challenging this piece of code will be to test—which will add more tasks for testing and quality.

If the team feels a more detailed design is required, you’ll hear them discuss it. How much? Who should be a part of it? And what does the review look like? Etc.

In general, you’ll experience all of the complex gory details of software development—the real work involved for a single sprint. Then they’ll do something wonderful. They’ll commit to the work and deliver what they can (fully done) at the end of the sprint. You’ll now have an actual data point for the teams’ capacity that you can compare and contrast against the overall release plan—with full transparency into the plans and details and with no extra padding allowed.

How cool is that?

Wrapping Up

I do quite a bit of sharing on agile methods nowadays—via presentations, formal training, and coaching. Believe it or not, I often get challenged on some critical aspects or techniques surrounding agile. None more than the point being made here.

The challenge goes – “There’s no way my boss will put up with a non-committed date for a project” or a “We’ll know how long it will take when we see it” approach to project estimation will not work in my company because we live in the “real world”.

My counter then is usually the same—“Fine, do what you’ve always done”. Try to predict the future on a highly complex software project without doing any real development. If you can guess correctly, then great—stick with your practices.

BUT, if you notice that you often fail. And by often I mean 50%, 60%, 70% or even 80% of the time to successfully meet your stakeholders expectations, THEN you’re practices are clearly not working for you. 

Admit that and try something a bit different. Agile Project Managers make the above approach work every day in a wide variety of business, customer, and technology contexts. It’s no longer a bleeding edge technique! It simply drives more real-time transparency into project progress. It helps with adjustment based decision-making. And it leads to more collaborative and successful outcomes.

From my perspective, if your methods aren’t working that well for you then what do you have to lose? So, what DO you have to lose?

Don't forget to leave your comments below