On Agile Planning - An Intro

Somewhere in the world right now there are people desperately tinkering, late at night, with a power point deck for some investor or management meeting tomorrow.

The project is being run agile, but that doesn’t seem to be making things less "waterfall”.

The team had started the project by producing a detailed upfront plan that showed what activities would be carried out in every two week sprint from the beginning to the end of the project.

Two months on, the projected milestones are being missed. Our midnight project managers are trying to spin these unforeseen "delays” using clever charts and invocations to various acts of God, and yet, deep down, probably believe that the plan's failure is at least partly their fault: if only they were better at agile, or had spent even more time planning, then all would be well.

This is a pity, and likely compounded by their inability to override the HIPPO (Highest paid persons opinion) who despite encouraging the use of agile might still be locked in a more traditional project management paradigm that assumes the future is and should be predictable (if you have the right "experts" that is).

Spoiler: It mostly isn’t, and it never was.

A Rude Awakening

I still remember on an early innovation project in my consulting career when a senior stakeholder declared: "Just because it's agile doesn't mean we can't plan" and demanded a granular waterfall-esque project plan broken down to the week for the whole 6 month project: “its fine that it might change, we're agile after all... but.."

I'd just joined having spent the previous six years building my second startup, and beyond some kind of high level road map for the sake of investors, I hadn't produced or questioned the absence of such a detailed plan in a very very long time. My team had worked Kanban with a well established velocity and prioritisation tied to a set of business model experiments. It had worked well.

So little had I questioned the absence of a more detailed up front plan that I didn't immediately have a good answer - to be fair, he was right, there wasn’t anything stopping us producing a plan, based on everything that we knew right now: A snapshot in time of our current thinking if you will. My experience told me it would be wrong, immediately, fundamentally (and it was, it really was), but nothing would physically prevent us from doing it.

This raised an important question though: would it be worth the effort? After all, this would mean building a detailed plan we didn’t have confidence in and then spending large chunks of time repeatedly updating it. We’d waste weeks that we could have spent executing and validating.

Like many such good questions this forced me to evaluate at a deeper level some things I had previously taken as common knowledge. I had to challenge myself to understand the "WHY" it made sense to avoid upfront task and outcome prediction at a granular level.

This short series traces that journey and touches on chaos theory, military planning and the #NoPlanning movement: a mountain at the edge of the agile world that many fear to climb.

Part 1: On Agile Planning Part 1 (The problem with trying to estimate chaos)

Part 2: On Agile Planning Part 2 (What can be planned and what can't) - Coming soon.

Part 3: On Agile Planning Part 3 (#ZombieMilestones (or how to budget for all this) - comming soon.