Agile for PMs – are there any plans?

The “Agile for PMs” articles are written for experienced project managers who are interested in exploring how Agile development differs from classical project management.
In these articles, “Agile” is generally capitalised (and sometimes used as shorthand for “Agile development). The Agile Manifesto is described in more detail in other Plays on this site.

As we saw in the AgileProjects article, Agile development shares many characteristics with Programmes which we will explore in these articles. Planning is a central part of projects and project management in order to deliver the organization’s objectives.

How do we plan in Agile development? Is it different from projects and, above all, is there a sound reason for the differences?

Is there planning in Agile development?

I see frequent misguided quotes such as “many organisations are using [Agile] to avoid careful planning and preparation” (Harvard Business Review). It is easy to misunderstand Agile as some sort of unplanned chaos. And there’s further confusion from that line in the Agile Manifesto…

(we have come to value) Responding to change over following a plan

Manifesto for Agile software development

Of course, unplanned chaos is not what the line means (more detail on this specific value in another article). It doesn’t say we shouldn’t make a plan. It says “responding to change” is more valuable to an experienced team than (blindly) following the plan. “Responding to change” itself implies a plan. How can you have change without a baseline from which to change?

People are often surprised when I tell them that when I’ve reviewed planning in projects and Agile developments, I’ve typically seen similar amounts of effort being spent. What differs is how the planning is done and what activities build the plan. As we’ll see in this article, the differences between the project and Agile environments lead to different types of planning, but often not different amounts of planning.

What does an Agile plan look like?

In general in projects it is assumed that we can make a plan and then monitor and control the project to force it to comply with the plan. The way we represent a plan affects our way of thinking. The square edges of Gantt charts encourage us to see schedules as accurate predictions of a real future.

A plan has value, but as a model or a map to guide us and to compare real events with expectations. The model should not be confused with the actual reality of what is happening. In complex environments it is a mistake to try and force reality to match the plan.

In a project, it is effective to use a Work Breakdown Structure, because we have a complicated goal and we look to decompose it hierarchically to simple tasks.

That set of tasks then becomes our planned work. We expect this to be the sequence of events which occurs and we track by variance against the plan.

If the variance is kept low, we will reach our goal as expected, so our objective is to monitor and control to push reality towards the plan.

In Agile development the key planning tool is different. We refer to this tool as a backlog. The backlog is an set of work items (as is a Work Breakdown Structure) but with specific and different characteristics:

• All items on the list are currently believed to add product value if we were to do them.
• The list is ordered. Items at the top are prioritised to be worked on before the items further down.
• Items are different sizes and definition. Those at the top are small, well defined and ready for work. Those at the bottom are larger and need further investigation.

Is this just a project plan in a different format?

A backlog is not a project plan.

It does not tell us a definite route to reach a fixed goal. Instead it is a representation of our collective current best knowledge. It is a developing document not a fixed one, less a map to our goal and more an explorer’s chart with white spaces and the occasional “here there be dragons”.

The backlog captures the work that we currently believe will add value. It is the reference for the latest best information for how to progress. We are confident that completing the top items will add the most value right now and so head us in the right direction.

Why don’t we turn this into a project plan?

It is true we could do more planning work for each of the items on the backlog. Wouldn’t we then end up with a complete plan for a project? This is a key point for how Agile manages complexity.

A backlog is not a weak plan, it is fundamentally different. Turning it into a project plan, we’d be ignoring the two dimensions of complexity discussed in the AgileComplex article.

• If we will be learning as we perform the work, we cannot separate the planning and the work. The more we wish to plan, the more of the work we would need to complete. So we keep the planning work lightweight for each item until we start.
• If we are likely to see high levels of evolving goals, then time invested in planning will be wasted if the work is not needed. We choose to push planning and decision making as late as possible as a strategy to manage change. So planning is focussed on the top items on the backlog, where we have the most confidence.

Where does Agile planning happen?

In a project the bulk of the planning is at the start, and the bulk of the work is done by planners (typically project managers) with input from technical experts. In Agile development, the structure of planning is different in both timing and individuals.

There is an activity in Scrum called “Sprint Planning” (or “iteration planning” in some other approaches). At the start of each iteration (Sprint), typically every two weeks, the team chooses work items from the top of the backlog to focus on for the next iteration.

There is often an incorrect belief that this is “the planning” in Agile. One short meeting every two weeks doesn’t sound like extensive planning. There is certainly an element of planning in this meeting. There’s no exact equivalent in traditional projects, but it is more of a team review of the plan than a planning meeting.

Backlog Refinement

The real planning happens in backlog refinement. The backlog is not a static item like a project plan. There is an expectation that it will change through the two factors of complexity – learning and evolving goals.

Backlog refinement is the continuous, ongoing updating of the documented plan (the backlog) with the latest understanding across the organisation. This can include:

• Changing the ordering of items
• Adding in new work due to learning, which could be investigation or rework
• Adding in new work due to evolving goals, which could be new features
• Breaking down larger work items to smaller, better defined work items
• Investigations to add definition and clarity to work items

While project planning is primarily front-loaded, Agile planning is a continuous process. It involves the whole team and is ongoing through backlog refinement. Planning even continues on individual work items as they are worked on. Since learning is emergent, individual work items are less defined at the point they are started.

This approach is designed to optimise for complex environments. It ensures that the next items to be worked on are well enough defined. It also ensures that learning and continual change are managed flexibly, avoiding wasted work and slow decision making.

Releases – fix schedule, not scope

The approach to complexity also extends to the management of release points. Projects have a clearly defined end goal which specifies all or most of the scope. This also extends to project milestones, which tend to be scope-driven.

By contrast, Agile development, as we have seen, tends not to focus on a single goal. Release points, rather than being fixed scope, tend to be fixed schedule. That’s why we see regular updates to software (for example Microsoft Office 365 monthly formal updates).

Backlog is the tool used to manage this. A fixed scope milestone requires us to have a work breakdown, and then adjust the schedule to respond to change. With a fixed schedule we reprioritise backlog to optimise the value we deliver from the release. There will be some committed items but there will also be some level of change