Deploying an ERP system, whether it's Microsoft Dynamics 365 Business Central or Dynamics 365 for Finance and Operations, is a mission-critical project. Traditionally, these projects are meticulously planned and executed to minimise the chances of any downtime or system failures. And, traditionally, that's meant months of analysis and design, lots of plans and specifications, before building anything and then a protracted testing phase before go-live. All very waterfall.
Can ERP projects use Scrum?
Scrum is a framework for developing valuable products that solve complex problems. There's nothing apparent in the Scrum Guide that prevents Scrum being used to implement Dynamics 365 ERP systems, but there are some challenges. So let's address those first.
ERP systems are complex and mission-critical
ERP systems are the backbone of most companies. Without them, nothing gets sold, manufactured or shipped, and no one gets paid.
ERP systems have lots of modules and features that take time to configure and customise according to the organisation's requirements. There are extensive systems integration and data migration needs too. ERP projects are rarely completed in a few weeks; a few years is more likely.
When implementing a new ERP system, there's always an existing system in place. ERP practitioners need to implement the new system and seamlessly cutover from the existing system without missing a beat. Whereas with a CRM deployment there is sometimes no legacy system to replace (unless you're counting Outlook and Excel) and cutovers -- while still important -- are less time critical.
ERP customers and consultants have stuck to tradition
Since the 1980s ERP projects had followed a waterfall approach with a heavy investment in up-front requirements analysis and planning. Since the mid-1990s, there was a slight shift towards a more turnkey approach with vendors providing industry templates to reduce the planning and discovery effort.
The Oracle Application Implementation Method (AIM) and the SAP Accelerated SAP (ASAP) methodologies were devised in the 1990s, with Microsoft Dynamics SureStep (SureStep) arriving in 2006. Cloud ERP deployments and the Agile Manifesto were unheard of back then.
Today, SAP has an agile methodology (SAP Activate), Oracle ERP consultants are talking about agile approaches and Microsoft has abandoned SureStep. So perhaps ERP consultants are ready to embrace a new approach.
Critical success factors for using Scrum in an ERP project
There are four critical success factors in successful ERP projects that I've seen use Scrum: choosing the right project, defining the minimum viable product, embracing agility, and going all in.
Choosing the right project for agile ERP
If you're an ERP consulting team considering the transition to agile, choose your first project wisely. Pick one project initially; don't use Scrum on all your new projects until you've learned the lessons from one or two. Pick the right sized project; learning Scrum on a smaller project will be faster and safer than a large, complex project. Pick the right client; propose and use Scrum when the client's team has already had some success with it on other projects prior to ERP.
Defining the minimum viable product
The minimum viable product (MVP) is the smallest set of features you could release into production that would provide value to your users. In some software projects, the MVP is small and can be developed in a few days or weeks. But it's not for an ERP project.
You can't implement a new system for accounts receivable in the first release and provide accounts payable in the second release sometime next year. The MVP in an ERP project has got to include all the critical features of the current system.
The first release of your new ERP system might take many months to develop using Scrum, but you should still focus on an MVP that is as small as possible. Only include mission-critical features. Deploy the first release as soon as possible, get feedback, and iterate quickly.
As ERP consulting firms consider an agile approach, I've seen them send a project manager to an agile training course and expect the project manager to now lead an ERP project using an agile methodology. I've never seen that approach work.
A better approach is to work closely with an agile coach. Have the coach facilitate the ERP consulting team's transition to Scrum and train the consultants with a blend of formal Scrum training and on-the-job coaching.
Going all in
Scrumerfall, upfront design and iterative development, hybrid agile. Some agile practitioners think it's OK to be hybrid, to combine some agile practices with waterfall ones. But I'm with Brett Maytom. I've found that the agile mindset -- like the pillars and principles of Scrum -- are directly at odds with a waterfall mindset.
My advice is to go all in. If you're going to use Scrum in an ERP project, use all of it. Don't go halfway and try to use Scrum after your requirements specification has been signed-off. It won't work, your project will likely fail and Scrum will take the blame. Go all in.