An Agile project plan is a must in today’s volatile knowledge work environment. Learn more about the Agile planning process in the following paragraphs.
Failing to plan is planning to fail. This quote by the time management expert Alan Lakein perfectly summarizes the importance of planning in project management. As much as we hate fixed dates and fixed scopes in the Agile world, it is the everyday life for many organizations, and the importance of planning cannot just be ignored.
Even if we go outside the realm of fixed-date, fixed-scope projects and dive into the product development world, planning is still of crucial importance. Most customers won’t commit budget to an open-ended specification and will demand a delivery date alongside the quote.
Assuming such a reality, a natural question to ask is “How do we create an agile project plan?”. This is a tough question, and most materials on the topic only cover the software development practice. It creates an impression that Agile is suitable only for the software industry, but nothing could be further from the truth.
Most articles 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 it is often 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 at all.
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 was 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 an Agile project plan 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. Here, welcoming requirements late in the process with an Agile project plan is not the most suitable approach. 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 customers, 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.
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.
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 project plan will have similar characteristics. Let’s explore them in no particular order.
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.
Imagine you’re preparing for an expedition to a high mountain that hasn’t been explored before. 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.
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.
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.
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 what 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.
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.
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 an Agile project timeline for your plan.
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 OK to leave the people on the team to self-organize around 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 Lean and Agile project planning. 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.
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.
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 Agile project 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 technical details of the work.
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.
10 Years Kanban Experience In 1 Free Book:
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.
As we’ve already discussed the characteristics of Agile planning, let’s take a look at a practical example of building an Agile plan and how we do it at Kanbanize.
Let’s say we have to plan the creation of a new website. As the scope for that is quite big, the first thing that we would do is define different functional parts (deliverables) that will be continuously released to the market.
Here, we should note that we won’t plan the deliverables in detail. An Agile project plan leaves this for the “last responsible moment” and includes it progressively throughout the course of the project. This will save us the otherwise wasted time of unnecessary planning and help us retain agility for any emerging changes.
To build a roadmap for the execution of the deliverables, you can use an Agile project timeline. In Kanbanize, for example, we use a Kanban timeline (as seen from below) to accomplish that. There, you can input one or more of the deliverables to be executed in parallel or visualize a sequence when some of them are dependent on one another.
Once we have the major functional parts of the project visualized in a roadmap-like view, our next step would be to break them down into individual tasks. As we progressively elaborate on our plans in Agile, we will start with the most important deliverables at this point in time.
To visualize the tasks and their flow to completion, you can use a dedicated Kanban board. In Kanbanize, we connect the Agile timeline containing the project roadmap together with the Kanban board as seen below.
This gives an unmatched view of the entire project progress from concept to fruition. As a result, we can clearly see which deliverables are currently in progress, what’s their status and who is working on what at any given moment. This setup also allows us to collaborate with one another when tasks get stuck in the process and therefore resolve the issues in a faster way.
Through the concept of “just in time” planning, we are able to retain agility for any last-minute changes, emerging requirements or shifting priorities. This allows us to better satisfy customer needs with the delivery of our projects.
And Optimize Your Workflow.
Agile planning is a new, flexible way of organizing future projects and adjusting to changing requirements without generating waste. These are the most important characteristics of a good Agile plan:
During the 30-day trial period you can invite your team and test the application in a production-like enviroment.