Plans v Planning: their differences, their value and how you can get them right in Lean-Agile software development

Before he was prime minister, Winston S. Churchill in his book A Roving Commission: My Early Life, said of writing, while drawing on a military simile, that:

“[…] [T]he best generals are those who arrive at the results of planning without being tied to plans.”¹

Later, in 1957, the US president Dwight Eisenhower, while talking on US military and foreign policy, is quoted as saying:

“Plans are worthless, but planning is everything.”²

A variation of this saying has been around for well over a century. And while we’re not ones to take the words of revered leaders at face value—our experience shows them (in this case) to be right.

But which do you think has more value: plans or the process of planning?

In traditional forms of software development, you know, such as Waterfall, plans and their reams of documentation are considered of higher value than planning.

But in Agile and Lean-Agile approaches to software development, planning processes are considered higher value.

(Didn’t see that coming? If you didn’t, then check out the rest of our Lean-Agile blog series.)

So, why this predictable, difference of opinion? Glad you asked.

In this blog post, we’re going to look at:

• The differences of value between plans and planning
• How planning is essential to Lean-Agile
• How to reach a compromise on plans
• How to get the most from planning

But first…

Myth: Agile and Lean-Agile don’t do plans or planning

There is a myth that plans and planning aren’t a part of Agile and Lean-Agile. After all, the Agile Manifesto calls for teams to be able to adjust and adapt over keeping to a plan. There’s also a part of the Manifesto which could be interpreted as Agile really disliking documentation. Its’s easy to see how this might get misconstrued Agile wanting to be plan and planning free.

But that’s not the case.

The Manifesto also calls for “collaboration” and in Lean-Agile, we want to “amplify learning”. Those are both pro-planning and plan stances.

Frameworks like Scrum, which offers a methodology for handling the Agile mindset, get especially tarred with the idea that people doing Scrum don’t do plans or planning. It’s all a myth, there are plans and planning in Scrum, Agile and Lean-Agile, and it’s being done in a way that genuinely helps teams and stakeholders.

It’s just that plans, and planning are viewed differently than in traditional software and product development practices. In Lean-Agile and Agile:

• Planning is about building “shared understanding” of the project and the goals and outcomes involved.
• Plans are meant to cover the essential elements of a project—ideally, they help people recall that shared understanding gained from planning, but also offer a minimum document trail (handy for development in compliance based industries).

A not-so Lean-Agile approach to plans and planning a.k.a. we had a meeting and here’s the plan for the project a.k.a. no shared understanding

Sam had spent a full day in a planning meeting with their superiors as they pulled together everything that they believed their next project needed; like requirements, processes, structure and timeline. Sam had been there to answer the few questions upper management had for the development team; Sam had done their best to offer their perspective. They thought they understood the idea the stakeholders had for this next product.

The product owner had pushed the work of writing the plan for the latest product project to one of their team members.

A few weeks after the planning meeting, Sam found a copy of the plan waiting for them, printed and bound, on their desk.

With the plan in hand, and a digital copy saved, Sam organised a project kick-off with the whole of their software team to go over the plan. Sam explained the parts that the team weren’t quite understanding. Or as best as they could recall and understand from the meeting, rarely referring to what the plan said.

Three months down the line, the software for this product was coming together. But a surprise demo request from those upper management stakeholders quickly revealed that what the software development team had been making was nothing like what management had envisioned. The software team didn’t have the same shared understanding of the project as upper management—and even then, a few of them disagreed on what outcomes they were all trying to achieve.

The plan was blamed, and a costly change process was initiated, putting the whole development process back. Release was going to be tight. But another kick-off meeting would see things right.

How could any of this been done differently to avoid waste?

Planning helps us build shared understanding

In his book User Story Mapping: Discover the Whole Story, Build the Right Product, Jeff Patton details a way of comprehending product development that’s very different from what Sam experienced. Jeff talks about this idea of “shared understanding” and how that’s what planning, and plans need to aim towards.

Of plans, Jeff says:

“Ironically, we put stuff in writing to communicate more clearly and to avoid risk of misunderstanding. But, way too often, the opposite is true.

Shared documents aren’t shared understanding.

Shared understanding is when we both understand what the other person is imagining and why.”³

Key here is everyone understanding each other and why. How do you get there? For Jeff, what creates shared understanding is the planning process that teams and stakeholders can go through.

Hang on, why are plans an issue, if everyone has this “shared understanding” anyway?

Under a traditional project, as we’ve said, a lot of value is put on the plans themselves. On the Gantt charts, on the estimates, on the plan documents, and all those kinds of things.

Lean-Agile favours planning rather than plans because plans increase the cost of change and increase waste. When we’re talking about Lean-Agile principles, we’re aiming to eliminate waste and amplify learning.

Whatever is documented ideally offers the ability to adapt to emergent knowledge, rather than be a long series of predictions as to how everything will happen and when. If it’s needed for compliance reasons, the plan shouldn’t go beyond what is needed or duplicate other documentation efforts.

But as Jeff Patton points out, we can’t rely on plans. There just is no such thing as perfect documentation. Not everyone who will need to help work on a project is in planning meetings, and words can lose a lot of meaning once written down and inevitably not read.

The habits of successful planning that builds shared understanding

Successful planning adds a good structure to the conversation. We structure our conversation to try and avoid bad habits. The discussion structure supports the principles of Lean-Agile, such as deciding as late as possible. The habits we’re trying to avoid and those we’re trying to form are things like:

• Bad habit: talking in too much detail, too early.
• Bad habit: making decisions too early.
• Good habit: enforcing a structure to the conversation.
• Good habit: waiting as late as possible to make decisions, with the maximum information available.

Techniques like story mapping offer a way of bringing structure to that conversation and helping people to avoid too much detail too soon when developing their ideas, while also building shared understanding.

Story mapping helps us zoom in to the right level at the right time, so that we can focus on the right thing. The detail happens later, but not before the team and stakeholders have developed an understanding of the whole.

Understanding user stories and mapping that put people first

But Jeff takes the idea of user stories and story mapping further. He puts the emphasis on people first: the users and the developers. As he points out:

“Your company can’t get what it wants unless your customers and users get something they want.”⁴

This also means rethinking the idea of requirements. Jeff explains how discussions of requirements ultimately leads to a distancing between the software and the outcome that we’re trying to achieve.⁵

Or as Jeff puts it in his critical “Read This First” chapter:

“Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build.”⁶

And ultimately, it’s about building shared understanding.

One way you could do basic user story creation and story mapping for product ideas

In terms of when this process might fall in creating software, this is the kind of activity that would happen early on, before deciding features. This process is for when you’re trying to understand your idea.

Jeff’s book goes into huge detail about user story mapping. What we need to understand is that writing stuff down or just discussing what’s going on with teams and stakeholders—none of that is enough. In fact, the more complex a project is, the more of a pressing issue it is to ensure everyone has the same understanding.

The ways to understanding are a lot more than just writing everything down from a planning meeting on a hoard of Post-It Notes. And everyone needs to be involved in that story creation.

Here’s how to bring it all together…

Tools

Tools you’ll want in your planning meeting:

• A large surface, like a white board, a table or the floor, where you can gather everyone’s written thoughts as you go—a “shared workspace”.
• A smartphone to take photos of cards and to film when people explain what their ideas and thoughts are on what they’ve written.
• Post-It Notes and cue cards, plus pens for writing with.

Alternatively: you can use digital tools online that anyone could access while on a conference call, such as Miro or Google’s Jamboard. And then make sure to hold the planning session on a conferencing service where screen sharing, and video recording is possible.

Keeping your stories people first

Here are questions you can ask yourself and then explain to the people in your planning session, whenever you’re thinking of a story:

• Why are we creating this?
• What are the benefits of this for us and the end user (think on audience personas you may have)?
• This idea—what issues does it “solve” for the end user plus us?⁷

Story steps

You’re building user stories. Mapping them out. Story mapping follows this pattern:

1. Think
2. Write
3. Explain
4. Place⁸

As soon as you think of an idea, you should grab a Post-It or a cue card, write a couple of words on it. This helps you avoid losing your thought until it’s time to speak.⁹

Then when it’s your turn to speak and explain your ideas and thoughts, you explain your story as clearly as possible. This is where filming on a camera (or using the record function on a platform like Zoom) comes into play. Tell your story, walk people through it.¹⁰ Doing this also helps you to consider the user journey and where this story fits in that.

And finally, place your story down in that shared workspace.¹¹

Over the course of the planning session, you’ll find that stories move around as you collectively come to understand where things fit.

Story organisation might end up with stories being placed under headers or tagged with extra notes. Like this:

Click on images for a larger view.

Once everyone understands, start prioritising stories

Eventually, it’s time to map stories to some prioritisation, creating a road map that shows a potential journey through development. Through mapping out the stories you can build a picture, through discussion, of the kinds of outcomes that matter for end users and the organisation. And come to understand how long it would take to realise these stories and which are really the bare minimum.

Stories do need to be prioritised even though you may think that every story outcome needs to be developed and done so yesterday. But here’s the thing when developing software and products:

“There’s always more to build than you have people, time, or money for. Always.”¹²

We’re almost to how plans work in all of this, but one more thing we need to keep in mind…

Don’t forget about User-Centred Design

We’ve previously looked into how to bring User-Centred Design into Lean-Agile processes. It’s worth remembering that gaining data from users about their stories is important at all stages of product and software development.

In fact, you need personas and user journeys to have a solid understanding of the problems they face and what they’re trying to achieve, and where your product has the potential to help.

But what about plans?

Here’s the thing, while plans might be anathema to software engineers, it’s important to help them understand why stakeholders want plans. At the same time, engineers still need to be empowered to not provide plans that are more detailed than is necessary, and stakeholders need to understand why they’re not getting detailed plans. Here are some good and bad reasons as to why stakeholders want plans:

• BAD: They can use plans to hold engineering teams to account.
• GOOD: Plans enable them to manage large, complex projects and products, helping them to coordinate the work of multiple teams over time and therefore optimise the whole.
• GOOD: Plans help everyone be clear on what they’re doing and what’s being done, serving as a reminder and lesson of the shared understanding gained during planning (regardless of whether someone was there or not).
• GOOD: With plans, we can compare what we thought would happen with what did happen—building emergent knowledge, amplifying learning, enabling continuous improvement and reflection.

How to get plans that people want

So how do we help stakeholders and teams be satisfied with plans? Here are some steps you can take:

• Treat plans as an artefact of the planning process, but also ensure planning is done with the whole team.
• Work to align goals of the different parties involved.
• Include a record of what the definitions of done are for this project.
• Think about what format the plan is in, for example it could just be a photo of a whiteboard and the Post-Its from a planning session.
• Embrace forms of living documentation that engineering can provide, and delivery teams will get value out of that. This can include forms of documentation that tick stakeholder requirement boxes, such as prototypes.
• Effort estimation and user stories from good estimation processes are a decent example of plans that meet the needs and goals of stakeholders. And these come from good planning (that meets the needs/goals of the delivery team). Successful estimation discussion means everyone understands the problem and requirements properly, and requirements aren’t just handed down.

Planning that involves stakeholders and delivery teams, builds solid foundations for any project

Like with much of what we suggest in the Lean-Agile Series, clear communication and cooperation are key to success. Planning offers the perfect opportunity to do this and ensure that a project gets a good start.

Further reading

Check out the posts below to learn more about how Lean-Agile can benefit your teams and product development.

References

¹ The Rt. Hon. Winston S. Churchill, C.H., M.P., My Early Life: A Roving Commission, 5th edn (London: Thornton Butterworth Limited, 1931), p. 227.

² Blair, W., 1957. PRESIDENT DRAWS PLANNING MORAL; Recalls Army Days to Show Value of Preparedness in Time of Crisis Killian Takes Oath Today ‘You Must Learn’ ‘Quiet Reception’ Predicted Tass Assails Address. New York Times, p.4.

³ Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product (Kindle Edition: O’Reilly Media, 2014), Location 304.

⁴ Jeff Patton, User Story Mapping, Location 424.

⁵ Jeff Patton, User Story Mapping, Location 468.

⁶ Jeff Patton, User Story Mapping, Location 461.

⁷ Jeff Patton, User Story Mapping, Location 597.

⁸ Jeff Patton, User Story Mapping, Location 580.

⁹ Jeff Patton, User Story Mapping, Location 580.

¹⁰ Jeff Patton, User Story Mapping, Location 580.

¹¹ Jeff Patton, User Story Mapping, Location 580.

¹² Jeff Patton, User Story Mapping, Location 643.