Let me tell you a story...
Meet Jake Bignell, he's the CEO of Legacy Corp and runs a software as a service business. They've been around for a while, have a technical estate full of legacy software products and about 800 global employees. They're a publicly traded business. The company has ridden the turmoil of the financial crisis relatively unscathed and over the last five years, they've seen significant encroachment from start-up challengers in their sector.
The business is frustrated. It just can't seem to get things done anywhere near as quickly as they'd like. Features that take their competitors weeks to produce, seems to take their own technology team a year. Something has to change.
Enter Agile. The silver bullet. The digital transformation that will save the business and get features into production every two weeks. It's going to be great!
They socialise Agile around the business. The CTO and heads of department within technology give presentations on 'Scrum', speak at town halls and team members go on week-long courses to gain fancy new titles like 'Product Owner' and 'Scrum Master'. They hire an 'Agile Coach' who's got a raft of certificates and a large daily price tag.
All in all, the Technology team are feeling pretty good about themselves. The business feel's great too because it's got a story to tell to customers and investors. Much back-slapping ensues.
Six months later, Jake wakes up in a cold sweat during the night and realises that they've spent a heap of money, resource and gone through lots of pain only to have slowed development down even further. They've implemented this new delivery model? They've got all the right people? Why aren't they getting features to market faster?
Sound like a familiar story? It's happening all over the market right now - people waking up in the middle of the night, in a cold sweat and going through 'Agile Comedown'. It's the realisation that, you know what? It's just not that easy folks.
So what happened?
Agile is not a magical cure for outstanding technical debt or legacy monolithic infrastructure.
For those reading who don't come from a technical background, let me explain. Every time you release a new software feature, whether that be web, application or something proprietary, you've got to test it. Many of the large-scale older developments in the industry (with many exceptions) were built using Prince 2 style waterfall delivery. This meant that you built and built (and then) tested at the end of what is often a very long project.
These pieces of software tended to be very large, monolithic style 'applications'. This means that if you want to add or change something you need to test the entire application to ensure that what you've changed doesn't break anything, rather than just test the bit you've built works.
It's like replacing a window in your house. You want to replace the window and ensure the window works, right? Ensure there are no drafts between the window and the wall? You don't want to test the ENTIRE house to make sure that fitting the window in your back bedroom hasn't stopped your upstairs landing light from working.
That's what technologists have to do with a lot of legacy products and software. However, in many cases instead of it being Jimmy's ground floor apartment in Soho, it's a 90 floor uptown skyscraper.
So what really happened?
The team moved to Agile ways of working and everything that they built from that point onwards was of better quality, better engineered and benefitted from all of the well-established benefits that Agile brings to a business - however, it didn't solve the businesses core requirement of speeding up delivery.
Legacy software is often very difficult to change confidently (changing the ground floor bedroom window of apartment 1, causes the 89th floor, apartment 8925 hallway light to flicker when you open the fridge door) which means that the speed of development is by its very nature, slow and fraught with risk.
One of the core principles of Agile is to release every sprint (minimum) and to build, test and deploy during your sprint without any spill over into another. However if the legacy estate is so time-consuming and expensive to test, this breaks the process before you've even begun. This is because it drastically reduces the amount of work a team can do in any given sprint before you need to stop and regression test the changes.
Deploying Agile principles and modern development techniques with legacy systems in place requires your team to have significant Agile experience and maturity. In an immature or even moderately capable Agile organisation, this is likely to create more problems and not even be a partial remedy. How these processes fit in with your existing technology and software needs to be evaluated before your business commits to the move to Agile.
