Applying Scrum to an ERP (Enterprise Resource Planning) project which touches almost every area in a company can be a daunting task at first glance.
In this article I hope to provide the umbrella structure used on an ERP implementation of Microsoft Dynamics AX. The umbrella structure for the ERP project ended up looking like this:
- Requirements gathering
- Scrum Planning
- Sprint Execution
- End-to-End Testing
- Final Cut-over
With any agile project requirements gathering will need to occur. While this could be included in Scrum Planning below, the importance and magnitude warranted that it be broken out. Before any requirements work could begin, training on requirements gathering and Scrum were necessary. For this project, the requirements were captured in the form of user stories in a SharePoint list-based product backlog. The key to success during this phase was how to orchestrate gathering the key requirements from across the entire organization.
For this project, around 150 stakeholders participated in requirements gathering over a 5-month period. A “lean” approach was utilized to identify key business processes by value stream mapping. Then each process was broken down into user stories (requirements).
All the normal Scrum Planning activities apply to an ERP project – just to a level of detail beyond a typical agile project.
- Identifying Product Owners (yes, plural!)
- Defining the “definition of done”
- Estimating the product backlog (business and IT effort)
- Release planning and backlog prioritization (what is the minimum set of user stories needed for an ERP go-live date?)
- Solicit acceptable target dates for go-live from the business
- Determine optimal sprint length based on guesstimated project duration
- Determine the number of Scrum teams required and their relative size to obtain an acceptable target date for go-live
- Develop a high-level timeline from requirements gathering through post-implementation support
- Develop a budget and obtain funding
- Obtain resources (business and IT)
- Develop a change management approach
The normal components of a sprint still occur within sprints targeted at the build out of the software; final end-to-end testing, and training / cut-over / go-live.
- Sprint Planning and Review
- Task execution consists of both business and IT tasks
- Daily stand-up (Scrum) meetings
- Inspect and adapt
- Visibility (sprint burndown, Scrum board, release burndown, budget)
Some of the sprint execution differences with this ERP project over a more typical agile project:
- Had multiple product owners from across all areas in the company pulling user stories into the sprints.
- A large number of subject matter experts from across all areas in the company participating in the sprints.
- Geographically disbursed Scrum teams added challenges to meetings and communication.
- All code and configuration went to production at the end of each sprint.
- A change management mini-plan was needed for each sprint.
The requirements gathering and Scrum planning are significantly more in depth for an agile ERP project. Business and IT time needs to be planned and funded. During sprint execution, the Scrum Teams will maintain consistency on the IT side but will vary on the business side from sprint to sprint based on the business areas involved in the sprint. Inspection and adaptation are critical to the success of steering such a large ship – so it is important to take advantage of every opportunity. Visibility involves a large audience and requires an easily accessible approach. Finally, change management is critical to the project’s success and needs to be addressed during Scrum planning and sprint execution.