Most of the projects I have worked on in the past few years have been replacements for legacy systems. Often the legacy system is a core part of the business, built and enhanced over many years. When it’s decided to replace the system, the organisation often has to decide if they want to undertake the redevelopment using Agile methodologies or more traditional Waterfall techniques. There’s lots of hype about Agile and considerable bandwagon jumping. I’ve worked as a Product Owner for most of the past few years and I love the flexibility Agile brings to a business. But I don’t think Agile is suitable for every project in every organisation.
Legacy systems like these can prove very difficult to replace by Agile methodologies. The main problem with redeveloping such a system is that the MVP (Minimum Viable Product) is basically the functionality delivered by the legacy system – and this is normally colossal. On such a project, the agile principle of satisfying the customer through early and continuous delivery of valuable software is largely irrelevant – such a customer typically wants to be left alone until the replacement is produced in a big reveal.
In my view, in an organisation which uses waterfall, such a project may not be an appropriate one to use as the start of an Agile transformation. In considering the use of Agile, the organisation needs to ask itself:
1. Can the functionality delivered by the legacy system be broken into bite-size pieces each of which can be delivered within a few sprints and can deliver business value?
2. Does the whole organisation (not just a few nerds in Technology) understand Agile, the benefits it can bring and the challenges involved?
If the answer to both is NO, then it may be best to use a waterfall methodology. If there are vendors involved in delivery who use Agile then you may need to agree that they can use Agile internally if they wish but they will need to adhere to the milestones of a traditional project plan. In such a case it’s probably best to use a traditional contract with detailed requirements. Alternatively you could define a high-level Product Requirements Document (PRD) and then agree that you will provide a Product Owner to work with the vendor to define the stories to be delivered. The latter approach brings challenges in terms of scope and prioritisation, but there are ways to help this which I’ll discuss later.
If the answers are more YES than NO, then an Agile approach is probably the best one. For medium to large organisation who are used to a waterfall approach, I’d suggest a variant such as SAFe.
Have you any experience of using Agile on legacy replacement projects? Have you found a magic bullet?
Deryck Fay 