Last time we looked at the concepts of accuracy and precision and how getting the two mixed up can lead to all sorts of problems. We also looked a little at our cognitive bias, that has us assuming that precise numbers are also automatically accurate. The upshot of that is that we humans are absolutely terrible at estimation. We mistake precision for accuracy and our accuracy is really bad to begin with.

That last statement is only half true. We are really, really bad at things like guessing how many jelly beans are in a jar, or how tall that person is, or how much does that thing weigh. What we are bad at is absolute estimates. To make up for that, we are really, really good at relative estimates.

Last time we looked at why we estimate and why there is always pressure to make our estimates more accurate. We have come up with a vast number of methods for estimation all of which aim to improve accuracy. The problem is that most of them don't. What they improve is precision instead.

Most people think of accuracy and precision as being the same thing. But they aren't. My nerdy and pedantic engineering background tells me that accuracy is how close to the true value a measurement is, while precision is a measure of how reproducible the measurement is. A more formal definition (thanks to Wikipedia) is -

A couple of posts back I mentioned Estimation and my desire to poke a stick at the hornet's nest that estimation can be. Estimation is always a controversial topic. It's often at the heart of serious conflicts within organisations. There are a huge number of estimation methods and techniques but nothing seems to prevent these issues from coming up. Before I poke a stick into the hornet's next (well, not so much poke as take a full bodied swing with run up and follow through), I'll spend a little while looking at why we estimate in the first place.

Any time we have two parties involved in something there is estimation happening. Right back from prehistoric times -

They say that when all you have is a hammer, every problem looks like a nail. It’s the same in business – when all you have is a project management methodology, everything looks like a project. Most organisations have become very project focused. Everything is a project. New release of software – project. Some process change – project. That’s great. Projects are good. They are certainly better than the ad-hoc approach we had before projects. But projects do have some drawbacks.

To work out what the drawbacks are, we need to look at what a project is. A project is defined (by the PMI who should know) as something that has a defined scope, a defined start and a defined end date.  So projects are finite in length. Anything without an end date isn’t a project, it's business as usual.

When a team is behind its targets, the natural instinct is to work even harder to catch up. Sometimes though, the best thing you can do is… nothing.

Let’s look at a team. For various reasons, they have done several sprints' worth of work with no test environment available. How can this be? Let’s just imagine that they work for a hypothetical large company with a ludicrously complex process around setting up test environments. I’m sure such things never happen in real life, but just go with me on this one.

Normally, the phrase 'project vision" or "project goal" elicits a collective groan from any team in which it is used. This is because project vision statements are generally... well... crap. Whoever puts them together inevitably feels it necessary to slip into management speak and string a bunch of fairly meaningless weasel words together – "we will proactively leverage our synergies to achieve outcomes consistent with our values going forward...". Lots of words but no actual meaning. No wonder people greet them with a groan.

Some agile teams do well. Many don't. In my experience, there is one consistent thing that separates the teams that succeed from those that fail and that is sound engineering practices. Foremost among those sound practices is Test First (or Test Driven) design.

Having a solid test suite that runs frequently is a key to agility. By frequently I mean every night at least. Without frequent regression testing, teams become risk averse and unwilling to make changes in case something breaks. In an agile environment where change is encouraged, this can be a death sentence for an agile project.