Plans are nothing; planning is everything

by Apr 14, 2021Agile Thought Leadership Blog & News

Plans are nothing;Planning is everything

A recent piece in the Harvard Business Review entitled ‘Have We Taken Agile Too Far?’ (penned by two former Amazon execs) claimed that “many organisations are taking [Agile] too far and using it to avoid careful planning and preparation.”

This is a common misconception of Agile, based on a misreading of the fourth tenet in the Agile Manifesto, which is ‘we have come to value responding to change over following a plan’.

Too many people misread this, taking it to mean ‘we respond to change instead of following a plan’.

A fundamental misunderstanding of Agile

This is a fundamental misunderstanding of Agile. What we actually say in practice is that, although there is value in ‘following a plan’ we prioritise the ‘responding to change’ element.

That is, while there is value in the items ‘on the right’, as in the Manifesto, we value the items on the ‘left’ more. It is not a case of one or the other.

With our partners we tend to find ourselves using Scrum as the go-to framework, and in Scrum, planning is integral to the framework. In Scrum we are relentlessly planning.

Both tactical and strategic planning is built into the Scrum framework. Which means, for example, in a 10-day (two week) Sprint you are potentially planning at least 12 to 13 times.

Before we start a Sprint (a timeboxed period where the team focuses on value delivery) we execute a ‘planning’ event. We plan the next 10 working days. As a team we create a small, semi-strategic plan for the next two weeks, where we outline the objectives that we are going to achieve. And then every day we mature and deliver that plan, refining it, on a daily basis to make sure we stay on track to deliver.

The plan animates the daily stand-up (or Daily Scrum). Typically, every morning the team is coming together for 15 minutes discussing what we did yesterday, what we are doing today, what the impediments are preventing us from delivering and coming up with plans to figure out how to overcome those impediments.

The team leaves that 15-minute stand-up with a clear idea of what everyone is doing, situational awareness of what the plan for today is going to be and a list of impediments or challenges that the Scrum master is going to take care of, to help the team move forward.

We also have an event called ‘refinement’, also a form of planning. Here the team looks ahead to what we will plan to achieve in the subsequent or upcoming sprints. All of this relentless planning actually creates and follows a roadmap.

Agile Teams are not random

Agile teams don’t just bumble from one delivery to the next. Agile teams deliver purposefully. For example, a central role in Scrum is the Product Owner. This person’s whole reason for existing is to generate value for the firm’s customers and clients. They do this by understanding what the market needs, and charting the roadmap to delivery

Professional Product Ownership is a high art and science; it employs overlapping approaches such as Jobs-To-Be-Done theory (made famous by Clayton Christensen, Tony Ulwick and Alexander Osterwalder) as well as ideas from Lean Startup, Business Model Canvas, Value Proposition Design and others.

Strong Agile teams (and Scrum teams in particular) don’t just start building things randomly. They follow a plan which consistently delivers and tests results and updates the strategy based on those learnings. 

In working with our partners to help accelerate delivery, manage change and reduce risk we see that – very much in line with the illustration above (via Brian Sjobern) – traditional planning approaches give the illusion that the delivery plan is as riding a bike g in a straight line towards hitting your target. In such a straightforward scenario, who needs to replan? We see this with classical planning approaches whereby teams rarely replan (if at all).

An Agile approach recognises that reality is often far closer to the second image above. That the reality is almost always turbulent

Agile teams plan often

“The map is not the territory” is a phrase coined by the Polish-American philosopher and engineer Alfred Korzybski. He used it to convey the fact that people often confuse models of reality with reality itself.

Models represent things, but they are not identical to those things. Plans are models and they are essential to guiding our actions. We must still remember to update our models – our plans as we learn along the route to delivery.

This is why famous military commanders have said things like, “no plan survives first contact with the enemy” or “plans are nothing, but planning is everything”. These are warnings against mistaking the plan for reality. Or mistaking the map for the territory.

What this means is that our roadmap is not saying “this is exactly what is going to happen at this time”. Instead, it is saying “these are the major milestones we’d like to achieve, based on what we know today.” As we get into the game, as we get into the territory and embark on the delivery journey, we encounter problems.  There will be challenges to overcome, and new insights we could not have predicted in advance. The plan will have to flex, shift and move on our way to delivery. 

It’s like the aircraft metaphor, to quote Stephen R. Covey: “The plane takes off at the appointed hour toward that predetermined destination. But in fact, the plane is off course at least 90 percent of the time. Weather conditions, turbulence, and other factors cause it to get off track.”

Agile planning is about recognising that, once you’ve written down a plan, that plan is going to go out of date as soon as we start to engage. Therefore, what we need to be doing is constantly planning and re-planning, constantly shifting and moving, and staying aligned as a group and as a team, on the way to delivery.

Many people still misunderstand the Agile Manifesto. They think that in Agile there is no such thing as planning. The reverse is the truth, : in the Agile world, it is all about planning.

(illustration by sami soderblom)

 

Jay is co-founder of Fractal Systems Consulting, an agile consultancy run by a group of Professional Scrum Trainers, change agents and agile delivery coaches who have deep experience and know-how in creating behavioural change, come and find us at Fractal Systems

Additionally, if you’re interested in learning in a fun application rich environment that focuses on real world applied approaches, come along to one our training sessions – Agile Scrum Training.