While Scrum can be used in any environment, using it for development of a legacy system is particularly difficult. While the development team may be open to transitioning to Scrum, the team will encounter problems at all stages of development – from requirements management through to testing.
First, the product owner is likely to have a list of product backlog items (PBIs) that cover all areas of the application. When the product owner orders the PBIs by business value it will likely involve the development team working across all modules of the application, not just one. This is not an issue in itself, however when coupled with a lack of documentation of the application and the code (something common for legacy systems), the team will waste time reverse-engineering what each feature does and how it was coded. After a module is understood, the team will make the single required change instead of maximizing their new-found knowledge by working on every PBI in the area. While this is inefficient for the developers, this inefficiency multiplies when it comes to testing of this module, as the whole module or workflow now needs to be regression tested as a result of the single change.
Second, the code is likely to be “spaghetti” meaning it has been re-written, extended and fixed so many times by different developers with different styles and a different level of understanding of what it should do, that it now requires refactoring. However, if little documentation exists – in—line or in the form of design or requirements documentation, it will be hard to ensure the feature still works and that existing workflows are not broken as a result of refactoring. More likely, neither the product owner or the project manager will want to invest time refactoring code that “already works”. If this is the case, then any changes will need to be performed with surgical precision to ensure no defects are introduced.
Third, we encounter the issue of lack of automated tests. Without nightly smoke tests there is no way to detect bugs being introduced. This can result in the creation of new technical debt, as well as the change not being accepted by the product owner. However, an even bigger risk is there is simply not enough time to perform the regression testing manually if no automated regression tests exist, especially if the PBIs cover multiple areas of the system.
To effectively adopt Scrum, the team will need to:
- Identify key workflows and document them,
- Create automated tests that can run these workflows to ensure they are not broken as a result of changes. These tests would be executed nightly so freshly checked in code can be tested immediately and bugs identified within the Sprint.
- Maximize efficiencies by working on multiple PBIs in the same Sprint. This can be an issue if the same code needs to be checked out and worked on by multiple people.
- Spend a portion of the Sprint refactoring code, especially when it is messy or is subject to multiple or major changes.
The above is not easy and comes at a large cost many organizations are unwilling to pay for a legacy system. Typically, a legacy system has few new customers and revenue is generated by annual maintenance fees rather than the more lucrative sale of licenses. As a result, management will usually be unwilling to invest in automated testing, refactoring working code and spending time reverse-engineering functionality. Subsequently the team will be unable to adopt agile successfully and will only be able to adopt some practices.
In conclusion, while all this sounds negative, there are some more realistic options for the team.
- First the product owner should consider a major re-write, preferably in a new technology. For example, re-writing some areas of the application as a web application instead of a client-server application. This gives the team an opportunity to re-write the code and potentially redesign the whole feature, while giving management something “sellable” with a potential revenue source.
- If this cannot be done, the team should instead consider adopting Kanban as an agile methodology. This methodology has less overhead, removing all Sprint based ceremonies.