How the heck Do you plan an Agile project?
If you listen to some Agile proponents out there you might think that Agile projects do not have a planning phase. You may have heard the following:
- You shouldn’t create a plan as things will change and it will be wasted effort.
- You shouldn’t create estimates as they will just be wrong and it will be wasted effort.
- You should just start executing iterations and you will then determine your team’s velocity and what you can achieve.
- You just keep on working on prioritized stories until the client tells you to stop or runs out of money.
As long as we are doing Agile projects we must first remember what a project is. A common definition is:
“a task or planned program of work that requires a large amount of time, effort, and planning to complete”
So really, any work cannot be termed a project without a plan. I would also add one additional criteria to what comprises a project. I believe a project requires two key criteria:
- A plan that defines scope, cost, and schedule. (At whatever level deemed appropriate)
- A vision of the solution that defines success for the project sponsor and the project team.
Too often I feel that projects are started without the vision fully crystalized. If there is not a vision of the solution, how can the following be determined?
- How can the project team be sure the solution truly solves the business problem
- How can the project team be sure that the solution is functionally and technically cohesive, consistent, and correct
- How can the project team be sure that the project budget and schedule can deliver a solution that satisfies the minimum client success criteria?
Without taking the time to confirm the vision of the project we are risking the success of the project.
Kan Ban boards are not the Plan
What made me think about this? I have seen more and more Kan Ban boards which people use as the project plan. Kan Ban boards are intended to be visibility into the project plan and status, but should not be the project plan itself. There needs to be a plan outside of the Kan Ban board that defines the project plan with some amount of dependency management. In addition, a separate vision of the solution should also exist. (Both functionally and architecturally)
Without these two artifacts I would suggest that you may not have an actual project and your Kan Ban board may simply be stickies on a wall. 
So how do you plan an Agile project?
Now I am not proposing a detailed work breakdown structure for an Agile project. I believe there are lightweight methods that can provide the value for minimal cost. I typically plan an Agile project in the following 4 ways.
- Ensure that Project kick off, Charter, and risk sessions are held. These are very short meetings but start to ensure that all team members share a common understanding of what the project is expected to achieve.
- Hold a Rapid Discovery Event to confirm the scope, objectives, and high-level plan of the project. This session should take only 1-2 weeks for a 3-6 month project. This event is critical to build a common understanding of the vision and solution.
- Create and estimate the project schedule at a deliverable-level with dependency management to ensure that the project can deliver the minimum client scope, budget, and schedule requirements
- Gain agreement from the client as to how the Agile project will be run and the ‘rules of engagement’. We have already confirmed we think we can deliver the minimum functionality, so this meeting is focused on gaining agreement on the process of how we will work together to deal with change.
I’m not proposing a detailed project plan, requirement document, or architecture document, but a little work on all three can go a long way to ensure success.
