Over the years, the methodologies to implement business systems, ERP and CRM, have evolved. Especially the vendor developed methodologies are constantly refined. However, a trend that has been taking off with the cloud adoption is Agile.
Magic bullet?
Agile has been around for a while, and as a methodology traditionally has been used for custom-built applications and websites. When I was first introduced to Agile, a decade and a bit ago, it was made clear that Agile is not a "magic bullet" that would miraculously fix poorly scoped projects. If the scope did not fit within the constraints of a waterfall project, there would be no reason it would fit within the same constraints if the methodology changed to Agile.
What agile did bring to the table, was a fail fast, correct quickly mentality.
Agile and the Iron Triangle
Agile methodology must follow the same constraints as any other project delivery methodology. The Iron Triangle (Resource, Time, Scope) is equally applicable. A reminder (if at all necessary): The Iron Triangle is a depiction of the trade-offs in the project. At the beginning of the project, the project team agrees what side is fixed, what side is managed, and what side is sacrificed. For example: if there is a compelling event that drives the implementation (for instance a legislative change), the time side of the triangle is fixed - you MUST deliver during that time. The choice remains between what is managed and what is sacrificed... Is scope more important, or money (resources)? That depends on the budgetary impact of the solution, and how much financial buffer there is (as resources are always finite, the choice is determined by the level of flexibility of scope and room in the budget). If there are a relative lot of constraints on the scope, then usually that ends up being managed, and the budget is sacrificed (and a great potential for project overrun!).
With an Agile methodology, it is not entirely clear what the scope is. Therefore, it is not possible to have a fixed scope - Agile lends itself best if the requirements are not yet completely known. The sprints are fixed in time, but it is not known how many sprints are needed to get to the minimum viable product - as such most common in Agile, the resources are fixed, the time is managed (number and size of sprints), and the scope is sacrificed.
The trouble with Agile
Getting a complex system such as ERP implemented using an Agile methodology is like fitting a square peg into a round hole - with enough brute force, it will fit. If you asked me a few years ago, I would have argued with great passion against the merits of using Agile with ERP. I was convinced it would never work. And of course, as is often the case with people saying the word "never", I was proven to be wrong. There have been case studies where ERP has been deployed using Agile. But Agile is not a guarantee to success, nor is it inherently less prone to failure. Here are some things to consider:
Beware of inherent constraints in the package - it is not a blank canvas, whatever you do in iteration 1, will likely pose a constraint in iteration n.
Agile will not make your budget go further - it is a fail fast methodology, meaning you'll become aware of potential problems a lot faster than with the traditional waterfall methodology, but it will not make an under-resourced project successful.
A successful first iteration is not an indication of overall project success. Certainly, the omens are better than if the iteration is perceived to have failed, but until the product is fully delivered, anything could still throw a spanner in the wheels. It may even be that the first iteration needs to be revisited, due to a requirement in a future iteration.
Sprints can be exhausting - the shorter the sprint, the higher the pressure on the team. For a development project, sprints can be quite short, 2 weeks even. In a packaged business system implementation, these sprints tend to be a bit longer, due to the number of dependencies that need to be configured. Due to the minimum viable product requirement in Agile, these sprints, even though they are longer in duration, are high pressure. Every project has its "crunch time” but be careful not to create an almost perpetual "crunch time" due to the sprint sequences.
Documentation is still required - Agile or not, a level of documentation is required. During the implementation sprints, decisions may need to be revised, and it is not practicable to reverse-engineer the previous sprints every time that happens. Furthermore, after the delivery of the product, it needs to be supported. Agile does bring the advantage of not documenting for the sake of documenting - but be aware of the documentation that is essential to the production and maintenance of the system.
Your budget will not go further with Agile - every iteration brings a certain amount of overhead with it. A waterfall project delivered according to plan is still the cheapest way to deliver any project. The challenge with waterfall projects in IT is that they very rarely go according to plan, something that in an iterative methodology like Agile will be made visible a lot earlier than in a classic waterfall project.
Succeeding with Agile - let go of the Dogma
Given the above, it seems that it is quite a feat to be successful with Agile in business systems implementations. The truth is: it is. But so is waterfall. By their very nature, business systems implementations are complex. As such, a dogmatic Agile approach will most likely run your project in trouble quite fast. A dogmatic approach to the Agile implementation will more than likely run you into trouble fast. Use those elements that make Agile successful, but don't shy away from more traditional methodology elements where they can make a difference:
Run a project discovery to gain a deeper understanding of the requirements - this could be anywhere from three weeks to three months.
List the requirements by Story, and by Epic. Also list knowledge gaps by Story and by Epic (a knowledge gap is where you are simply not sure how to implement something yet - i.e. financial dimensions can be a great improvement on the current ledger, but it may not be clear yet how it is to be implemented).
Plan the iterations meticulously - create an overall high level plan and detail the current and following iteration with detail - keep revising the high level plan until complete.
Determine what iterations result in a Minimum Viable Product (MVP), and what iteration will deliver a Prototype.
Verify the prototypes, but test the MVP with rigor, including a User Acceptance Test with security and migrated data in place. Assume an MVP is ready for deployment to production. If that is putting too much burden on the iteration, then demote the MVP to Prototype.
Manage the Iron Triangle on program as well as iteration level. The trade-offs can be different per iteration and to the whole program but should not change mid iteration.
Keep the Scrum meetings, and the Scrum board - but do not ditch status reports, risk and issue logs, decision registers etc.
Plan Iteration 0 for the foundation setup (foundation setup is all the configuration required for the base system, so you can start building on this).
Plan the last iteration without scope, as a final stabilisation. Do allocate time for stabilisation in each iteration (equal to development time in case of MVP, or at least half development time in case of Prototype). For larger programs, plan iterations purely for stabilisation after every three or four iterations.
Hold a regular project health check - and report on the trends from iteration to iteration (Contact Aurelian Group if you want us to provide this service to you).
Most important - projects deliver something your organisation will use for the foreseeable future - it is therefore imperative to surround it with a positive vibe - remember to have fun delivering the system, if you expect satisfaction in using the system.
Originally posted: 14 August 2017