Agile Planning. It sounds like a paradox, doesn’t it? Planning involves setting boundaries, creating checklists, determining delivery dates, and following a step-by-step process doesn’t it?
But Agile, isn’t that all about people doing their own thing? Many people think of traditional planning as the musical equivalent of a disciplined classical orchestra and Agile Planning as the free-form chaos of jazz.
Nothing could be further from the truth.
This article will explain why Agile thinking and planning are not exclusive and can work together powerfully for your business.
Let’s find out whether Agile Planning is something for you.
Agile Planning is a way to plan product development in an Agile environment all the way from the business’ goals and objectives down to the day-to-day execution in development teams.
Product development, especially software development, is dynamic. User and customer requirements change. Because of changes in their environment and because using a product as it evolves triggers ideas in a way that no specification document ever could.
Accepting frequent changes then and planning accordingly, is key.
Like Agile Software Development, Agile Planning is iterative, making it inherently adaptable to change. This allows you to focus your attention on user and customer needs at all levels in your business.
It also means that the plan itself isn’t that important. The real value of Agile Planning lies in the thinking needed to create the plan and how it connects work at all levels to the business’ customer oriented goals and objectives.
Software development had a bad reputation in the 80s and 90s of the last century. Projects overran their timelines and their budgets.
It turned out that developing any software is a complex endeavor in an often complex and changing environment. Something you simply can’t control with the planning methods borrowed from construction projects.
The waterfall approach just doesn’t cut it when it comes to responding to changes in your customers’ environment and needs.
Agile software development evolved because of that. However, many businesses still used the traditional work breakdown planning method for predicting their costs and establishing budgets.
Agile Software Development does away with work breakdown, at least until the very last moment. Some agile proponents even advocated refusing to come up with estimates for the time and resources. After all, what use is it to plan in this way when you know that things change and any plan is likely to be inaccurate the minute it’s created.
However, the need to control costs and establish budgets didn’t go away even when the benefits of agile in delivering software that works and meets the customers’ needs, were obvious.
Something had to change and Agile Planning was the answer giving managers and executives a way to estimate costs and establish budgets without requiring the development department to go back to attempts to predict the future.
The key idea for Agile Planning is to tie everything that’s done in development back to the business’ strategies and objectives.
This means that planning starts at the top — the director and senior management level — and gets progressively more detailed on the way down to the level of the teams that execute the work.
A beautiful metaphor for this planning process is the Agile Planning Onion.
It’s as a visual reminder of the spectrum Agile Planning has to cover across an entire business.
As you can see, the onion has six layers. These correspond to the typical hierarchical structure of most businesses.
In Agile Planning the focus is continually on delivering value to the customer.
The question at all times is: do they value it? Little else matters.
The work a team does is less important than the value of their work represents to customers.
Agile Planning favors making decisions at the last responsible moment. At least for decisions that are irreversible — that have no way back, or the way back would be expensive.
The thing is that not making a decision has a cost, but making a decision too early — with insufficient knowledge and data — also carries a significant cost.
You want to hold off refining (detailing) new features until the last responsible moment, because what needs to be done for a feature changes as other features are implemented. In other words: add details (make decisions) too soon and you’ll have wasted the effort when circumstances change and you need to defer that feature, or maybe even scrap it altogether.
So only fully refine (parts of) the features you’ll definitely implement over the next two or three iterations. And only add just enough detail to features that have to wait longer to inform your planning and prioritization decisions.
You will see from the Agile Manifesto that there is an emphasis on delivering working software frequently.
Likewise, it is a key component of Agile Planning.
Frequent feature deliveries come with several benefits. The more frequent the deliveries of working software, the greater and more detailed the customer feedback. This has a knock-on effect for planning the next iteration and it prevents wandering too far from the client’s desired outcome.
This is one of the contrasts with traditional ‘waterfall’ development and upfront work breakdown planning methods.
Agile Planning encourages a probabilistic approach to estimate project timelines and delivery dates.
Characteristics of a probabilistic approach are:
Characteristics of a deterministic approach are:
The probabilistic approach in Agile Planning has several benefits for your project:
In summary, Agile timelines would be flexible in terms of scope and time (to adapt to changing requirements) but fixed in terms of resources (teams and therefore cost).
And this is exactly what makes it possible to estimate costs and determine budgets without requiring development to come up with estimates!
Whilst not strictly part of the planning process itself, it’s worth bearing in mind that in the waterfall approach, acceptance testing by users and operators are a separate stage after building and technical testing the product by the developers themselves.
In Agile, the idea is to test early and often. Users and operators review and test every feature as soon as it becomes available instead of waiting until the entire product is ready.
After all, the aim is to deliver working software.
When you deliver a feature in an agile setting, it’s tested and accepted. Not in isolation, but in the context of the product as it’s grown until then.
There’s no need for a separate stage or for a separate team to ensure that everything fits and works together. All that is part of the standard process and already completed.
This makes planning a lot easier and delivery dates more predictable because there won’t be huge nasty surprises at the end forcing you to do a lot of rework. The surprises are always limited to what you have done in an iteration and — with customer collaboration and feedback in every iteration — the risk of creating something the customer didn’t intend is small too.
A big hurdle to predictable planning are the lengths developers have to go to keep finished features out of the released product because the business’ calendar dances to a different tune. For example, when a set of new features is to be released during a trade show.
The trouble is that keeping those features ‘in stock’ presents risks because the work on the product doesn’t stop, and incorporating them at a later date means having to redo work, especially a lot of testing.
The way to avoid all that is to adopt continuous delivery with feature toggles controlling what features are available to whom. This allows you to disconnect the moment of release to customers from the moment a feature is integrated into the released code base.
A more mathematical approach is to use Monte Carlo simulations to predict costs and probable delivery dates. They have long been used in Lean Project Management and are a useful tool to estimate throughput for projects.
The Monte Carlo simulation uses historical data on capacity and performance to calculate the percentage chance of hitting a project target, such as cost or delivery date. This then allows you to assess the risk associated with the work.
Having looked at the similarities and differences between Agile and waterfall, let’s look into the key roles and responsibilities in Agile Planning.
Crucial roles in Agile Planning are:
Agile Planning doesn’t really prescribe any meetings or specific cycles and cadences, but there are typical cadences for each layer in the Planning Onion:
For Agile Planning to work, agile thinking, as laid down in the Agile Manifesto, needs to be at the front of everyone’s mind throughout your business, across all its departments, and all your people.
Without agile thinking, the Agile Mindset, paramount in the planning through all six layers of the Planning Onion, using it to your benefit becomes that much harder.
The best thing you can do to get off to an excellent start in your Agile Planning campaign, is to seek training and advice.
Not just for a few, but for everyone involved with planning at any layer of the Agile Planning Onion. After all, spreading the knowledge helps spread the mindset and gets everyone on the same page.
That said, don’t jump in the deep end with everybody at the same time.
Start with the inner layers of the Agile Planning Onion. These are the people that are probably already well-versed in planning their iterations in Agile ways.
Move outward one layer at a time. If you have multiple product groups, you can consider this for a single product group first and use the experience with that to bring other product groups on board.