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

Hello World

Something to open my blog site with…

What is scaled Agile. Well we know what Agile is, been enough books on the topic. I have often said that “Agile Doesn’t Scale” – but that is just a glib throw away remark aimed at those that think they can put a process in place, and, like a clockwork mouse, just let it go.

If we run on the premise that a small scale Agile (assume SCRUM) team is effective then multiples of that team would also be effective. However this will only remain true if the inputs and outputs of each team remain true to the original team’s principles. So you know what you want, you can deliver it in the team and what you do is put into production to gain learning for future work. Having multiple teams able to operate independently and a Dev Ops capable of deploying each team’s work is a rare situation – but if you have it then you have a wonderfully scaled agile project running with the same processes and governance that you had in the original small project.

And….. back in the real world where you have features that are being delivered by multiple teams, maybe over multiple sprints (moving to a multi-sprint release model) with dependencies in all directions, well then the original process and governance model doesn’t cut it any more. Now we enter the hot topic of the moment – how to apply processes and governance to enable Agile delivery at that scale without killing the goose that laid the golden egg.

So if you are going to ignore some of the basic principles of Agile Scrum projects by not immediately releasing and adding external dependencies then you are going to need some manner of process to compensate – if you don’t then you are in a world of anarchy. It is those processes that shape what we all know have come to accept as “Scaled Agile”. There is no right way to do that (although there are some wrong ways) and I hope to give (and learn) some thoughts on that topic in future posts.

Phil Thompson

Follow me on @philagiledesign