Planning, Estimation

My team makes a quarterly plan to aim at Big Goal, and weekly or biweekly plans to figure out how to get to Big Goal using small steps.

My teammates and I play a game of innacurate estimations to see whether the plan is too big or too small or just right. Some teammates focus on the things they know in the estimations, because a plan is only an approximation, a guess. Others, though, don't seem to understand that a plan is an estimate, and an estimate is not accurate.

Each quarter, we have delivered as much as was finished; the plan doesn't change that truth. So why does it make my stomach churn when there's a focus on the uncertainty of planning, a focus on where plans don't help? Because it mistakes a tool for a goal: planning is a tool that helps ensure we don't commit to too much work, so we don't disappoint stakeholders. An accurate plan isn't the goal; happy stakeholders is the goal.

I find that people who want to focus on the deficiencies of the tool have often been unwilling to either come up with a new approach to meet the goal, and unwilling to give up the mindset that they spotted something wrong with the tools we use. I often speculate that this is because planning feels like commitment, and my teammates are too uncertain about their own ability to commit. I've fixed this in the long term by building up trust, demonstrating that I use the same tool, teaching that I'm not concerned if the plan is accurate, I'm concerned that it helps our stakeholders to have predictable throughput they can rely on. Nobody's upset if we underpromise and overdeliver, because nobody cares if the plan is accurate: they care that their projects aren't blocked by engineers who promise too much because they hate the awkward conversation that happens when we tell someone that their project isn't realistic.

Like so many other problems, the solution is winning trust, demonstrating consistent trustworthiness. DevOps is a people discipline; trust your people and show them your tools help them.