Agile ERP Implementations – Planning
This post is an extension of the overview – read this first: Agile ERP Implementations
The Scrum methodology is a framework for developing high value products iteratively using self-regulating teams to improve synergy and effectiveness.
Scrum prescribes the following projects activities which are all related to a specific Sprint:
- Sprint Planning Meeting – scope and approach for the next Sprint or Increment
- Daily Scrum – short daily meeting to coordinate within the Sprint team
- Sprint Review Meeting – review of the current Sprint on Product Backlog
- Sprint Retrospective – review of how to improve the Sprint
Scrum does not however specify Pre- and Post-Game activities and does not prescribe the processes and techniques for building products.
An ERP implementation is a complex project where the implementation process will impact the Scrum methodology:
- Multiple Sprints in Parallel
- Interdependent and prerequisite Sprints
- Significant non-Sprint activities
- Coordination of internal; external or offshore project resources
- Management of third party product and service deliveries
To keep the spirit of the Scrum Guide each Sprint should be self-regulating to produce the next Increment whilst the Product Manager must ensure each Sprint is executed in the right sequence. Planning the Scrum project becomes focus on coordinating Sprints rather than planning the individual Sprint itself.
Pre-Game Phase
The Pre-Game planning is to ensure the following:
- Project Kick-off
- Creation of Product Backlog
- Creation of Sprint overview plan with expected number of Sprints and their dependencies and needed non-Sprint activities
- Creation of strategic working documents like Stakeholder and Risk Management strategies
In particular for ERP implementations there is a specific process that must be followed as ERP systems require a sequential setup process due to module and functionality dependencies.
Sprint Phase
The planning of the individual Sprint is very much given by the Scrum methodology with the Sprint Backlog and the addition of a few ERP specific processes:
- Scrum items:
- Sprint Planning Meeting – scope and approach for the next Sprint or Increment
- Daily Scrum – short daily meeting to coordinate within the Sprint team
- Sprint Review Meeting – review of the current Sprint on Product Backlog
- Sprint Retrospective – review of how to improve the Sprint
- ERP specific items:
- Development Work – functional or technical work to produce features according to Sprint Backlog
- Acceptance and Sign-off – client approval of “done” features
- Increment Delivery – apply new features to Gold environment
The Sprint Team will plan the Development Work within the team so no project plan will be made for the individual Sprint – however a generic plan can be made to communicate the expected process for each Sprint – for example:
All Sprints will start with a Sprint Planning Meeting to produce the Sprint Backlog based on selected features from the Product Backlog. Next the Sprint will commence where Daily Scrum; Development Work and Feature Acceptance and Sign-off as on-going processes.
When the Sprint is complete the Increment is delivered and Sprint Review and Retrospective will take place.
Depending on the Development Work the Increment Delivery can be anything from setting up the Gold environment to deploying a new database.
So a multi-Sprint project could look like this:
The Scrum methodology states each Development Team organises their own Sprint. So the Product Owner concentrates on coordinating Sprints and other dependencies like Infrastructure.
The above example having 4 Increments would have a 4-5 months duration – so a fairly simple implementation.
Post-Game Phase
According to the Scrum methodology the Product Backlog is never complete but from an ERP project point of view there must be a go-live point and a point where external resources are released. The Product Backlog and then accumulate and a Phase 2 project can be initiated at a later stage.
An example of a Post-Game phase with a go-live and support phase and wind-down period:
