Agile Project Management is one of the buzz words for the past few years. It’s based on the success in agile (software) development and lean management in general. But, does it actually work?
Agile is usually used as a synonym for scrum. You have 5 or so team members in a room or around a whiteboard and discuss / agree on the next deliverable. The standard is 2 or 3 weeks for such a sprint and the effort involved is measured in story points. Assuming you know the amount of story points in the project you can measure how fast you go and depending on the success rate (eg completing the stories in a sprint) the project manager can easily tell if the project is on time. ideally the reports tell the PM much more. He can see which area the shortfall is and mitigate the problem with a targeted approach. During a sprint the team gets together regularly for a short standup and inform each other on progress or hold ups. This allows early intervention. At the end of a sprint the team gets together including the customer and show the deliverable. This also allows early detection if the customer is satisfied and the team delivered on expectations.
One can easily the great promise of this approach and where management is keen to get it done this way.
- early detection of problems
- early detection if the output is to the customers liking
- small wins along the way
- targeted issue mitigation
- clear planning horizon
The assumptions that this will work out should be clearly spelled out:
- the project can be broken into distinct and small enough workpackages
- the work packages fit into a sprint
- the customer is available at the end of each sprint
- the story point estimation for each work package is good
- the project team size is between 5 and 12
Having that – Go for it!
Alternatively you consider Kanban boards. Kanban works on the premise we have multiple things we can work on, some have dependencies, others are stand alone (planning). These can be allocated to the right resource who takes responsibility for the work. (doing). It is possible that the ownership is handed over to another team member when a different subject matter expertise is required, although usually these would be 2 different work packages that are dependent. Ones a work package is completed it moves to done. The team meets at regular intervals to keep each other informed. In a KanBan process it is up to the Project manager to communicate with the customer when sufficient work packages are ready to be shown. A KanBan board has usually multiple projects and is much more practical to show the workload of individuals. In contrast it is harder to judge the status of a project or to assess the complexity / duration of a work package. Thus KanBan work package usually show a start and a target date. Priorities and stati are discussed in regular stand up meetings.
- work packages are largely independent
- work packages run in parallel to the capacity of the team
- the customer is not involved during the doing phase unless specifically needed for a work package
This is a pretty much simplified view and the experts can and should add much more detail to it. So use it as simple guide to get started.