As I’ve taken the journey along the Agile path I’ve come to learn two things I am certain about:
1) A detailed Work Breakdown Structure is one of the largest wastes and mistakes that can exist in a project
2) That not creating a temporal plan at some level can also lead to rework and failing late
On the surface, these comments may seem to be contradictory. I seem to be supporting neither traditional or Agile. And I would agree that it can appear in this way. But like most good solutions, the optimal solution is a compromise between extremes.
In my blog about whether Flow can be used on projects, I emphasize the need to plan. (if you are interested, you can find the blog here) I then continue the planning discussion in my Agile Chicken Little blog. (which can also be found here)
My intent of both posts was to communicate my thoughts on the fact that some level of planning is crucial. But when do you know when the plan is good enough? When is it excessive?
Too Much
I must admit I was someone who used to create detailed work breakdown structures. I even used to assign multiple people to one deliverable and have multiple items in progress. Looking back now I see that this was excessive planning for little value. The detailed project plan was also not an accurate depiction of how the actual project would execute.
But even when I started working on more Agile projects, I still sought out a moderate detail plan to try to comfort myself. I thought that we needed a full prioritized backlog of items. I held frustrating meetings with clients asking them if item 101 was more or less important that item 102. (If you were in one of these sessions with me, I apologize and owe you a beer)
Too Little
But as I stated in my prior posts, the creation of a temporal plan is critical to allow the team to think through the project process, dependencies, and possible conflicts. To start to do the project using just Flow may not allow you to fail fast. You may discover a dependency or conflict late in the process. It is possible that an initial plan would have highlighted this issue.
But creating a project plan at the start can create assumptions and issues all on its own. So what to do?
Just right – Provisional Project Plan
It the game of golf, there is a wonderful concept of a provisional ball. In the case where you have already launched a ball into the woods, you hit a provisional in case you cannot find the ball. It is seen as a time-saver to keep the game moving.
I use this analogy when I create my high-level project plans.
My provisional project plans are:
- Only one way out of many to execute the project – it is not the one correct way
- It is high level to get me to when I can look for more detail to refine the plan. (i.e. finding my first ball)
- It sets the expectations with the clients that the plan will change, but that we have at least thought through one way that the project could be delivered.
We then use flow to prioritize the next group of stories in the project. Once they are prioritized we use flow to execute.
Summary
In my experience, these Provisional Project Plans provide the right level of planning. They allow the team to think through the execution of the project without committing to ‘the’ plan. It also then provides the ability to execute in a flow-based structure within the Provisional Project Plan.
Special thanks to Luke Hohmann who illustrated the waste of creating a full prioritized backlog through the use of Innovation Games. By prioritizing and executing in groups of 10-20 items, we are able to efficiently work in a flow mode. (And update our Provisional Project Plan as we execute)
