Over the last year or two I have been exploring OKRs—Objectives and Key Results—with several organisations, from a few hundred people in size to a couple of thousand. Some are well over a year in, some are just starting out. There doesn’t seem to be much out there in terms of experience reports or hands-on advice so I have tried to capture the advice I wish I’d had when I started out.
Experienced delivery folks can have surprisingly good instincts for macro-level estimation, as long as we are careful to manage blind spots and cognitive biases. This can be an important tool in early project investment discussions, and can remove roadblocks where people are uncomfortable or unwilling to provide estimates.
The goal of software delivery is to minimise the lead time to business impact. Everything else is detail.
Last year I wrote about how we are doing planning all wrong, or rather, how we seem to focus on the wrong things when we do planning. We obsess about stories and story points and estimation, because that’s what we’ve been taught to do.
Business people want estimates. They want to know how much it’s going to cost them to get a solution, and they want to know how likely it is to come in on time and on budget. And of course quality is not negotiable.
I’ve been having difficulty recently with a trend I’m seeing on projects. What happens is this: we (an agile development team) engage with a client for a short period—typically 2-4 weeks—to investigate how we might work with them to solve their problem. During this period, we drive out lots of stories, do some technical investigation and estimation, and out of this we generate a high level release plan. All very good, you might think. But then, unfortunately, everything is mysteriously forgotten about except the release plan, which suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan. Well ok, it’s not quite that dramatic, but it certainly doesn’t feel very agile to me. Hopefully I can explain why.