I have received several questions recently about how agile project management methodologies such as SCRUM can be used with deliverable-centric methodologies such as PRINCE2 or ElephantPM. ElephantPM is similar to PRINCE2 but is tailored for small and medium size enterprises (SMEs).
Whereas ElephantPM is a generic methodology that can be used for almost any project, SCRUM is best applied to software projects and I will discuss it in this context.
The first thing to understand is that it is not an either/or choice. SMEs will normally need to use both methodologies because,
- ElephantPM is about WHAT gets built
- SCRUM is about HOW it gets built
There is also a difference in perspective,
- ElephantPM
- Planning the entire project at a high level and the next stage in detail
- Considering technical and business risks
- Focused on delivering systems that deliver business benefits
- SCRUM
- Planning for this sprint and the next
- Considering technical risks
- Focused on delivering working systems
The interface between the Project Organisation and the SCRUM team is the Product Owner and her Product Backlog which is the definition of “what” the project will make. In smaller organisations the SCRUM Product Owner may also be the ElephantPM Project Manager.
Avoiding planning-conflict
ElephantPM requires all the project team members to “plan ahead as far as you can see“. This conflicts with the SCRUM’s Backlog Grooming Process,
During each sprint the team should spend time doing product backlog grooming to keep a pool of stories ready for the next sprint.
This conflict only arises because in SCRUM there is no Project Manager role and a close planning horizon,
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner.
In essence what the SCRUM team is saying is “our business’ planning is so poor there is no point in us investing any effort in thinking about stuff we will have to do in two months time”. This does not hold true for an ElephantPM project which establishes reasonably stable requirements during the early stages.
To avoid planning-conflict it is helpful to meet with the SCRUM team and explain why this SCRUM principle does not hold and longer range planning is required. This is best implemented as additional Backlog Grooming workshops that consider all the sprints in a stage. The standard SCRUM workshops will be held and we expect that each sprint will need to be re-planned just before we do it and reviewed after we have done it, in the normal SCRUM way. It is to be expected that because we have planned the sprints ahead of time we will have to do less planning during the sprints.
Another false-conflict between ElephantPM and SCRUM is that SCRUM teams are “self-organising”. ElephantPM fully endorses this, the Project Manager does not care about “who does what”. Activity management is properly the concern of the team and their line managers.
Summary
The Product Owner is the key link between the Project Manager and the SCRUM team. She decides WHAT should be made in a Stage, the SCRUM team decide HOW and WHEN (which Sprint) it should be made and the Project Manager ensures the project progresses within tolerance. ElephantPM requires a bit more effort to put into Backlog Grooming before each stage commences but this will reduce the Backlog Grooming effort required during the sprints.
Dr James Bayley 