Better Programming

Advice for programmers.

Follow publication

The Importance of Continuous Planning in Software Development

Michael Spragg
Better Programming
Published in
5 min readDec 29, 2021

Photo by Patrick Perkins on Unsplash

Once again the team realized they were going to miss the deadline.

They had done everything right: refined all their stories, estimated and re-estimated, kept connected through daily stand up, automated their pipelines, and covered their code with well considered and automated tests.

The stakeholders were happy with the demos, giving useful and timely feedback throughout.

And yet… the deadline loomed and it was becoming increasingly clear that they were not going to make it.

Where did it all go wrong?

Let’s wind back to where it all began, or rather where some of their working practices started turning mainstream: the agile manifesto.

A huge industry has spun out of what is a pretty simple piece of writing, and seemingly as with everything great, lots of different interpretations and lack of critical thinking have caused a huge number of problems for people.

Let’s pick on one line of the manifesto (and remember to read the whole thing): responding to change over following a plan.

So we don’t need plans, right?

Well, you do.

And more than that, you need planning.

What’s the difference? A plan is an artefact – and output from an activity, specifically planning.

Planning is where you get the value, and at its best in software development it is a collaborative, inclusive exercise that draws on the experience and perspectives of the whole team.

Our team kicked off their work by creating a plan. They thought about risks and what they could do about them, and ended up with something that looked like this.

Best case they would finish early. There was a risk that they would miss the deadline, but realistically they could deliver their project on time.

So off they went.

The plan is useful as a communication tool and a reference document, but as your man Eisenhower said, no plan survives first contact with the enemy.

Each time you complete a task from your plan, you should be asking, what’s the next best thing to do, rather than what’s next on the plan?

The answer to the question may well be that the right next move is to do the next thing on the plan.

But what if it’s not?

What if the previous step, shock horror, took longer than you thought it would?

What if, during the preceding step, you discovered something new?

What if in the intermediate time when you were completing that step, something external changed? Your biggest customer had a change of management. Your best salesperson nearly closed a deal but needs something different to nudge the prospect over the line (don’t do it…). Your CEO had an amazing idea in the shower.

Or you got some feedback from your existing customers that they don’t love the idea you’re executing. Or have discovered a really irritating bug and are starting to make noise about canceling.

Or… or… or…

Life happens, plans have to change.

That’s why planning is so important. And so important it needs to be done again and again. On a continual basis.

It doesn’t really matter what scale you operate at, continuous planning is critical to success.

Whether you are the exec team guiding the business on a multi-year strategic plan, a product manager scaling a product that has found a good fit in a promising market, or a developer cutting the code that unlocks the next value, you need to plan continuously.

Geepaw Hill has a concept of many much more smaller steps (MMMS) that neatly explains the optionality of moving from A to B, and avoiding the trap of thinking that the optimal strategy is to take one step. He is advocating from a coding perspective and has a key concept of ensuring that each time you make a change you leave the system in a “ready” state, i.e. ready to be used, and ready to be changed.

At a code level, this means making the smallest possible pull requests and having seriously short-lived feature branches.

And this concept applies as you zoom out from the micro of making really frequent code changes (seriously, we’re talking minutes) up through the project level to the company level.

Having high levels of interruptibility is a real positive attribute in a busy and complex world.

I am not advocating you flip-flop, continually changing your mind and chasing the latest idea or fad.

What I am advocating is that you continuously check where you are against where you want to be and decide on your next best move based on the latest information available to you.

Abandoning your vision or your North Star is not something to be done lightly, though it may be your next best move. Chances are the next best move is probably not abandoning it, rather refining your hypothesis slightly, or expanding on an aspect of it and testing that.

Without the act of continuous planning, you won’t know. And worse, you might execute a brilliant plan, brilliantly, and find that where you have ended up is not really where you need to be right now, as your customers and the world have moved on.

And what of the team at the start of the story? Well, they still find themselves falling victim to Parkinson’s Law, but now that they are continually planning, they have far better conversations about what to do.

By continually planning they end up with a far messier plan, but around their 3rd planning session, they are starting to realize that everything needs to go brilliantly in order to deliver everything by the deadline.

And their worse case is spiraling off to infinity.

So those inevitable conversations about compromise are happening earlier and earlier. They are able to plan their next steps based on better information and involve the right stakeholders. They get to have better conversations on scope and deadlines and also get creative about what they are building and how they are building it.

In summary, plans are somewhat important. Planning is really important and should be done on a continuous basis.

Sign up to discover human stories that deepen your understanding of the world.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Michael Spragg
Michael Spragg

Written by Michael Spragg

Interested in stuff… product, software, fintech, greentech, media, science, technology, education, sport, politics, fun, food, you know…

No responses yet

Write a response