Plan backwards, look forward

A good novelist makes every piece of the story essential to the final resolution. Each event described in the book leads up to one big finale. That’s a good narrative.

We like to see the past in that light. We like to believe everything happens for a reason, and that reason is to get things where they are right now. “It was good this guy broke up with me, because I wouldn’t be who I am now otherwise.” Like the present circumstances are superior somehow to all the alternatives that don’t exist. It was all meant to be, we like to believe.

Kanban suggests we apply this model to the future.

“The first rule of kanban is that the later process goes to the earlier process to pick up products” ~ Taichii Ohno

That is, pull model: start with the customer demand. Figure out what we must do to meet that (deploy), what is the prerequisite for that (testing), what is the prereq for that (code), and so on down a forking chain. Anything not in demand by the next step in the process is busywork. If repairing your development environment is needed to write the code effectively, then it is not yak shaving. If you’re distracted by all the code formatting options, that is the non-work that seeps in to distract us from the end goal.

This is harder than we think. It’s harder because it is not the way the real world works. The Gulf of Mexico doesn’t suck water from the Mississippi River, and the river’s tributaries don’t pull rain down from the sky. This is not how the past works either: all those “it was meant to be” warm fuzzies are a coping mechanism to help us accept the past. Causality runs forward in time. Things are the way they are because they got that way. Everything happens for a reason – usually a million reasons – and every one of those reasons existed before the result. Not after.

Yet, the first rule of Kanban is right. When we’re aiming for something, when we’re building our project’s narrative, we can set up the causalities. Plan backwards, work forwards. If we aren’t careful and deliberate, then our work will emanate from our current situation, as reality does. Water will flow down the path of least resistance. We’ll have pretty colors in our IDE and a feature that no one asked for. Conscious effort can direct our flow.

And be careful to check over and over that our destination is still where we most want to go. Check, re-aim, and proceed down the shortest path from the new-here to the new-there. Otherwise we’re back to Waterfall.

Our project history may never read like a good novel, because we should change our minds on the best ending, and we don’t go back and edit the first chapters. Yet, if we think about it that way – how can all the characters on my team be important to the final solution? – we might get somewhere faster, and be part of a story bigger than ourselves.