Have you ever asked a grizzled old grill-master how long they cook a Brisket for only to get the answer “until it’s done”?  Probably not, but the point stands because it’s the right answer.  Most smoking and grilling can’t be done in a set time frame.  Doneness is measured by temperature, not time.  I think that analogy carries over to the world of software projects well.  All project management really.  Software projects big and small are notoriously fickle in their time to completion.  Consider how often you have stalled on a small problem after a streak of blazing through features.  As humans, we have a strange obsession with time that doesn’t always align with reality.

So, how the heck does anyone manage to make a good brisket in time for dinner anyway?  The answer is forecasting.  A forecast is a prediction which changes as the circumstances change.  Forecasts are naturally at odds with our obsession with time.  While we rely on forecasts constantly we secretly hate them because they are more complicated to manage than time.

The weather report is the most prominent forecast in our lives.  It changes all the time and boy to we love to complain about how often it changes or how unpredictable it can be.  Yet, we still find it useful even if it is just for making small talk.  We also accept that aside from vagaries like it will snow in the winder, it is very hard to put a timeframe on weather patterns.

While it is futile to time the weather, a brisket, or a software project, forecasting provides a great deal of value as a way to manage all of these things.  However, it requires a different mentality altogether.  Consider the statement “I will go to the park on Wednesday”.  Come Wednesday you will be at the park rain or shine.  The weather forecast says it will be sunny.  If it isn’t you will be disappointed.  Compare that to “I will go to the park when it is sunny.”  You look at the weather forecast and see that both Wednesday and Thursday are supposed to be sunny so you decide to play it by ear.  You will go to the park when the weather is nice and enjoy it.  In both cases a forecast is leveraged, but the way that it is leveraged plays a tremendous role in the outcome.

How do you forecast?  It’s simple, you take measurements and look for common patterns.  This implies some amount of discipline in the practice of measuring to make use of a forecast.  The quick read digital thermometer is the mainstay of the cooking world.  The software world likes to be more creative and has an array of convoluted methods for measuring output to choose from.  Personally, I don’t think it matters what you choose as long as you pick something and stick to it.  However, the sticking to it part is generally the thing that organizations struggle with for cultural reasons.  In my experience this comes in the form of subverting the measurement into a target.  For example, if you use SCRUM with story points the utility of the method will be lost the moment someone says that each developer should deliver x points per sprint.  Now staying employed depends on hitting that number and your forecasting tool is useless.  This common pitfall is known as Goodhart’s law, and can summarized as “When a measure becomes a target, it ceases to be a good measure”.  Keeping this from happening is surprisingly challenging due to our obsession with time.

In short, if you want my advice for getting better outcomes on briskets and software projects, stop estimating and start forecasting.  Take measurements and don’t turn those measurements into targets and you’ll have a good forecasting tool.  Just don’t ask me why your brisket is tough if you ignore my advice.