Lesson learnt – Agile legacy replacement

Some lessons you just have to learn the hard way. In the past I was involved in a  project to deliver a new system to replace an existing legacy application. The business wanted something that, at a minimum, would be able to do what the old one did, and then they would be able to iterate on top of that to deliver lots of cool cutting edge stuff to take the company into the future – cue motivational music, pictures of soaring eagles and graphs all pointing north. All sounds great, and the principle of an MVP and then iterating sounds like the business has swallowed the Agile pill.


But step back, and reconsider – that MVP is to deliver what the existing system already does. This is the organisation’s main operating system – been in place for 10+ years, has organically grown through unstructured in house development without logical architecture or any regressions scripts. What we have is the result of 10 years hard work without internal quality assurance, documentation or even the physical presence of the people that built it (most having left).

Being an old system, the code is tightly coupled and the User Interface is the type with a black screen and a flashing cursor. This isn’t the world where you can remove one web page with another one.

So what do we do? There are two options here, neither very pleasant, and I have learned the hard way which is the right one.


Option 1. Investigate the current application and structure the first release of the agile programme around that functionality

Option 2. Build a large integration cross matching tool to be able to connect the legacy application to your new world (that initially has nothing in it) that once you deliver the MVP, will be thrown away.


Or to rephrase – get cracking with a large MVP, or go for a small MVP and saddle the organization with the large overheads of building integration capabilities that will be written off shortly.


Now the initial high-level estimates from the experienced architects with some understanding of what the application should do suggested the MVP will take a year, and that integration thingie maybe 2 – 3 months – so 20- 30% additional costs.


For Management this was an easy decision – and a mistake. They chose option 1.

We started and then we found things were more complicated than we thought, but with no way to connect our fledgling application to legacy we just had to swallow it. A year passes – the application is nowhere near the legacy – so there is no question of being able to go live – the business would not be able to operate, so we have to continue on. The risk profile of the programme is the only metric heading north and the soaring eagles have long since deserted the skies.


Two years down the line – we have a very large incomplete complex application – sitting in a staging environment. The initial estimates have been discussed and rediscussed. The minimum application functionality has been trimmed and trimmed in an attempt to bring forward the point of first release to prove the application and to start the Agile Delivery…. The costs are off the chart, not a single line of software is truly working (whilst it could work – it isn’t viable without the rest of the missing functionality). Now that 2-3 months work to link the systems at the outset doesn’t seem quite so stupid, but as we progressed we never thought we were more than 5 months from delivery…..


At many times though this I spoke to other Agile Delivery managers / coaches etc with the same question – how do you deliver an Agile project with such a large MVP – same answer – “you can’t, you need to break it down”. But I can’t break it down, because I need the whole legacy functionality because I can’t pass the workflow between the new application and legacy. Ultimately of course they were right, and what we were now involved in was much closer to a badly defined waterfall implementation than anything truly Agile, although we dressed ourselves in Agile Governance and did have a pretty solid CI and test automation.


I have learned now, the ONLY way to build a replacement system to legacy is to build it in such a way that it cannibalises the original, if you are fortunate that the legacy is loosely coupled with web based UI, then life is going to be easier, if not then you will incur programme costs to build an integration layer between old and new. This integration layer is the COST OF SUCCESS. With complex workflow you need to be able to pass the transaction from legacy to new or visa-versa. Failure to do that means your delivery is subject to your ability to accurately estimate something that is very large and poorly understood.


I really rate the people who made the initial estimates – these are not stupid people and those estimates were logical reasoning but based on incomplete information. The error was in asking someone to estimate that in the first place.


Follow me / help me on #philagiledesign


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s