Agile Planning is NOT Scrum Planning
Most articles on the internet that talk about Agile Planning will try to convince you that Scrum Planning and Agile Planning are the same thing. This is plain wrong. Scrum is a prescriptive framework for software development that proposes one concrete way to plan. It is very popular in the software world but has been the subject of severe criticism.
We won’t go into the details of why Scrum planning is flawed, as we would rather talk about Agile thinking applied across various industries and not just software. It is more important to know how to apply generic techniques and practices on the global company level, irrespective of the type of business. For the time being, it is only important to know that Agile Planning does not necessarily involve the Scrum framework, not at all.
Agile Project Planning VS Traditional Project Planning
In the past business leaders spent enormous amounts of time laying out detailed plans of execution for years in the future.
For a long time, this way of planning worked perfectly. However, as the business landscape became more dynamic in the last decades of the 20th century, business requirements began to change more frequently and a new more flexible way of planning became necessary.
This need became obvious and somewhat critical with the rise of knowledge work. While just 50 years ago people worked primarily in factories, these days the work gets done in offices, where people use their heads more than their hands. It is precise knowledge work where Agile planning is most needed.
The main difference between Agile planning and the traditional way (also known as Waterfall) is that the first one is iterative and adaptive to changes, while the second one is a step-by-step heavy planning process.
We have to mention that both approaches have their virtues. When you’re building a bridge or a building, you want to have a very detailed and well-thought-of plan. You don’t want to make this Agile in the sense that you welcome requirements too late in the process. Of course, it can happen, but changes might be extremely expensive to implement.
In knowledge work, however, change is welcome at any stage of the process, even at the very end. The goal is to create a solution that satisfies customer, and everything is allowed. Simply said, in Agile project management you lay down detailed plans only for shorter time frames, and you can easily make changes when needed.
Characteristics of Agile Planning
First, let’s focus on the different levels at which you can plan. These levels are best described by the “Agile Planning Onion”:
It is fundamentally important to grasp the idea that Agile Planning is applicable at every slice of the onion. You don’t just do Agile on the team level (Day, Iteration, Release). You can have an Agile product management service, Agile portfolio management, and Agile strategy. Actually, being agile in your strategy is what defines business agility in general. If you have trained your teams on some Agile methodology, but you haven’t changed the way you manage goals and strategic initiatives, your company is not Agile.
As we already stated, but didn’t explain, Agile planning is iterative. This means that you develop and adjust your plan multiple times, as you find necessary. The goal is to invest time in planning at the best possible moment and adjust to changes easily if they occur during the execution phase.
Irrespective of the level at which you operate, your Agile plan will have similar characteristics. Let’s explore them in no particular order.
- Goal from the eyes of a customer (value)
- Lack of detail whenever it can be avoided (commit as late as possible)
- Frequent deliveries (small batch size)
- Date ranges instead of single date estimates (probabilistic vs. deterministic)
- Focus on the work and not the worker (no particular assignees, the team is responsible)
- No separate phases for Quality Assurance (quality is built-in)
- Two-tiered plans (Timelines for initiatives, tasks have no start / end dates)
- Data-driven (Based on historical data and Monte Carlo simulations)
Goal from the eyes of a customer (Value)
It is crucial for an Agile plan to consider what exactly the customer wants. If we need to borrow a term from the Lean dictionary, we would definitely use the word Value. In other words, our plan must be clear on how and when we are going to deliver value to the customer.
In this regard, the more the plan is focused on outcomes the better. If you have been taught to put activities inside the plan, think again if you really care about what people do and not what the people have actually done.
If this sounds strange, ask yourself the question, “Does my customer care what the designer has been doing from 9 to 6, if the work has been finished?”. On the contrary, your customers wouldn’t want to hear how busy everyone is, in case the job hasn’t been done.
Lack of detail whenever it can be avoided (Commit as late as possible)
Imagine you’re preparing for an expedition to a high mountain that hasn’t been explored before. You would definitely know something about it, but you’d be lacking the details. You are going to have a rough estimate of the duration of the expedition so that you prepare enough food and water. However, you won’t know if there’s a place suitable for camping and where that place might be at all.
If that’s the case, does it make sense to plan when you’re going to eat? Probably not. What you would do is to start climbing. When you feel tired, you’ll start looking for a convenient place to set up the basecamp. As a matter of fact, if you plan the schedule in advance, you might end up having dinner in the middle of a dangerous river that you had to cross.
Many projects in the knowledge work realm sound quite similar. You know a lot about the project in advance but not enough to commit to every single piece of it. Yet, many managers insist on having a very strict and detailed plan for every single project deliverable. It’s interesting that in real life we are offloading the commitment to the last responsible moment, but we fail to do so in our project plan.
Frequent deliveries & fast feedback loops (small batch size)
Projects are big batches of work by definition. However, there is no obligation to deliver them all at once. In fact, most customers would want to have an early preview of the results, just to make sure that the project does not deviate too much from the result they expect.
Suppose the project team misunderstood the requirements and set off to work on something completely different from what you, as a customer, envisioned. Would you rather give them feedback early on or wait until the project deadline? It is more than natural to give feedback early in the cycle and prevent wasting precious time and resources.
An Agile plan should accommodate for frequent deliveries and make the collection of feedback explicit. Certainly, the feedback taken should be reflected in the next version of the plan, which would definitely improve the likelihood of successful project closure.
Date ranges instead of single date estimates (probabilistic vs. deterministic)
When customers ask about the project duration, they usually expect a fixed date. But you would be surprised how many customers would actually approve if you provide a date range instead of a single date.
If the date range is reasonable enough, most reasonable people will agree with the estimation. As they say, it’s better to be roughly right than to be precisely wrong. And this is what we would encourage everyone to do – use date ranges that are based on historical data and forecasting methods to create your Agile plan.
Focus on the work and not the worker (the team is the owner)
This comes from the same perspective as the late commitment example. If you assign people to the jobs too early, you’re risking to do the wrong thing at the wrong time. Coming from the perspective that we care about the flow of work and not necessarily utilizing every worker at 100%, it’s okay to leave the people on the team to self-organize delivering the project.
It is most certainly true that you have specialists on the team and that creates a lot of dependencies, especially in larger companies. The natural response of an Agile coach would be to eliminate the dependencies, but this is an answer detached from the real world. You can’t just remove all dependencies without creating a ton of problems elsewhere in the organization.
The reasonable approach is to manage dependencies coming from the holistic view of your organization and value streams. If the flow of value to the customer is blocked because of team X, then that’s where you should be focusing on, even if it means that team Y will have nothing to work on. This is a bit radical and requires a paradigm shift, but it’s a fundamental concept in Agile and Lean. It’s needless to say that in such situations, your plan has to reflect the focus on block/issue resolution with less focus on employee utilization.
No separate phases for Quality Assurance (build quality in)
Toyota became the biggest car manufacturer in less than 50 years, starting from a small family company. One of the principles they used was “Build quality in”, which means that no time should be spent fixing the product, after it has exited the production line.
You should strive for the same level of quality during the execution phase of the project and by any means try to avoid a final “Quality Assurance” phase. If you have a big final quality assurance phase you’ve most likely ignored the quality aspect throughout the project life cycle and once you get into the quality phase, things start to look ugly real fast.
Of course, it’s better to have a final quality check instead of shipping a defective product, but this should be an exception rather than the norm. Under normal conditions, final quality checks should not be necessary, as the teams involved in the project have been taking the necessary measures throughout the lifetime of the project.
Two-tiered plans (Plan only the initiatives and not the tasks)
This is one of the most important characteristics of a good and effective Agile plan. If you have a high-level plan of all major deliverables (initiatives) then it’s easy to break them down into tasks and then pass the tasks to the teams for actual execution.
While this might sound trivial, it represents a substantial difference compared to the traditional Gantt chart plans. When you break down an initiative (project deliverable) into its comprising tasks, we recommend that no start and end dates are determined for the tasks, unless absolutely necessary.
For example, a task that represents the creation of posters for a concert would be useless after the concert, so it must have a deadline attached to it. However, more often than not, tasks won’t have any real deadline.
When you skip the start/end dates for all individual tasks, you allow your teams to pull new work when they actually have the capacity and not when you thought they should have the capacity. The word PULL here is used on purpose, as it illustrates the PULL principle that we know so well from Toyota.
The fact that you put start and end dates to the initiative but leave out the dates from its children tasks, detaches the planning from the execution. At first, this may look like a stupid thing to do but it’s actually a very smart approach because you still maintain the plan in terms of time and commitment but you allow your teams to take the optimal decision, as they are the ones closest to the work.
Data-driven decisions (use your historical data to plan the future)
If you use the Kanban method to run the day-to-day tasks in your teams, it is easy to employ statistical methods for data-driven forecasting. One such method that is widely used in the Agile world is the so-called Monte Carlo simulations.
The Monte Carlo simulations take as input historical data (throughput and cycle time). Then, with the help of mathematical algorithms, simulate thousands of possible outcomes for your project. After assessing all the possible outcomes, the Monte Carlo simulation provides information about the possible completion dates of the project with some probability attached to the forecast.
For example, a Monte Carlo simulation can forecast that there is an 85% probability that your project will finish by the 2nd of July. Alternatively, the forecast can tell you that there is a 95% probability that you will deliver 200 tasks or more by your deadline. This gives a good indication about the project status and it’s based entirely on statistics, which can save you the trouble of estimating all tasks one by one.
Tools like Kanbanize combine this idea with the previous one (two-tiered plans) to create a continuous forecasting system that informs managers of the actual status of all projects and their deliverables. Actually, Kanbanize extends this type of continuous forecasting to the portfolio level, as it’s easy to see a real-time forecast of all projects in the portfolio. All you need to do is run the day-to-day tasks in a set of team Kanban boards and connect them to the parent projects.