Legacy Systems & Digital Transformations • Ian Cartwright, Rob Horn & Hannes Lowette

This interview was recorded for GOTO Unscripted at GOTO Aarhus.
gotopia.tech

Read the full transcription of this interview here

RESOURCES
martinfowler.com
thoughtworks.com/podcasts/technology-podcasts

Ian Cartwright - Technical Director at Thoughtworks 
Rob Horn - Technical Principal Consultant at Thoughtworks
Hannes Lowette - Head of Learning & Development at Axxes, Monolith Advocate, Speaker & Whiskey Lover

DESCRIPTION
Legacy systems as well as legacy software have a significant impact on any digital transformation project. Join Hannes Lowette, head of learning & development at Axxes, Rob Horn, technical principal director at Thoughtworks, and Ian Cartwright, technical director at Thoughtworks, to learn how to recognize a legacy system. They discuss common patterns and anti-patterns as well as how to break a legacy system into smaller pieces to ensure a successful transformation.

RECOMMENDED BOOKS
Thomas M. Siebel • Digital Transformation
David L. Rogers • The Digital Transformation Playbook
Fawad A. Khan & Jason M. Anderson • Digital Transformation using Emerging Technologies
Tony Saldanha • Why Digital Transformations Fail
Nitin Seth • Winning in the Digital Age

Twitter
Instagram
LinkedIn
Facebook

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket: gotopia.tech

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Transcript

Intro

Hannes Lowette: Hi, I'm Hannes Lowette. I work for a company called Axxes in Belgium. And we are here at GOTO Aarhus. We're sitting in the middle of a construction site so you can hear some noises in the background. I'm here today with Rob Horn and Ian Cartwright, who is talking about dealing with legacy systems. I'm going to ask them to introduce yourselves to the audience as well.

Rob Horn: Hi, I'm Rob  Horn. I'm a technical principal consultant working for Thoughtworks out of our London office. I've been in the software industry for over 25-ish, 25, and 30 years. The majority is sort of on reflection is part of this work, kind of at least 60% of that time has been spent working with different customers, different clients on what we call legacy modernization, we now like to kind of think of it as legacy displacement.

Ian Cartwright: Cool. I'm Ian Cartwright. I also work for Thoughtworks, based in our Manchester office. I've been with Thoughtworks for about 20 years and for 10 years of that I've been involved in helping pull the Thoughtworks Tech Radar together. I'm collaborating with Rob Horn and James Lewis, with some help from Martin Fowler on writing up some of the lessons we've learned, and some of the patterns we've discovered based on a lot of work we've done helping clients replace legacy systems.

What is a legacy system?

Hannes Lowette: All right, I hear you both speak about legacy systems. Now, there are a lot of ways that we can look at those and that we can define those. For a lot of developers, it means that this is software that I didn't write and don't fully understand. Can we maybe get a little bit of a definition in about what you consider to be a legacy system before we go off into how we deal with that?

Ian Cartwright: So, I think there are lots of different definitions of legacy. We heard one from Alan Kay, in the keynote earlier this week, I think he called it any system that doesn't naturally rot away. Which is certainly one interesting way to view it. But what we tend to find with our customers, it's about the technology that the company has not been able to respond to the needs of the business anymore. And what we mean by that is that maybe they need to get to market faster, or small changes have started to cost too much money, or the cost of running the platform as a whole has become too high. And then there are technical reasons. So sometimes it turns out somebody is on an end-of-life platform, you know, they've been told, you know, 18 months, you won't be able to get technical support anymore. But it is more the business definition, it's that the platform is not meeting the needs of the business any longer than I think we primarily focus on.

Rob Horn: And until you start thinking about end-of-life software, none of those things you said are time-related. So legacy, by that definition, could be something that's been written, really recently to kind of rush it and kind of get a product to market quickly.

Hannes Lowette: But it is causing friction for the business.

Rob Horn: Absolutely. As you scale up, and you need to scale out, maybe it's no longer able to meet those needs, right? So...

Hannes Lowette: Right. So maybe to summarize, there is value in the system being there, but you're not able to operate it in a way that would support the business needs properly.

Ian Cartwright: I think to give an example, the classic example is often an older company has been around many years, this system, maybe it is older, and a competitor comes along and starts to steal some market share. Maybe they have a really good mobile app. And so, then the business goes, "Oh, we need a mobile app, or we need to make changes to match the competitors." And to use an example one client, spent six months building a new feature on top of their legacy technology. And their competitor did the same. They matched it in two weeks because they were a newer, more flexible technology that was easier to change, and test, and all of those good things. Because of the mainframe and their legacy they just couldn't move that quickly. And so that was the thing that was starting to hurt their business.

Hannes Lowette: Right. So, you say that most of these projects are business-driven, right? There is a business need to innovate and change things.

Ian Cartwright: Yes.

Rob Horn: It could be innovative and change, but it could be, well, maybe it starts as a kind of tech-led initiative, like the end-of-life example, actually, in business terms represents kind of risk and risk mitigation. I was recently working with a client who, operating a multibillion-pound asset and lease financing company. Running middleware on what their vendor said they were the only customer left globally running this particular piece of middleware, been out of support for many years. So that represents a technology project, we've got to get rid of the middleware, we've got to replace our end-of-life software. But it's a real, real tangible risk to the business so that if this thing should go wrong, they can no longer support that kind of revenue generation. So, it's always business-led.

Anti-patterns for legacy systems

Hannes Lowette: So, when you're looking at these displacement projects, what is one of the things that people often get wrong when they try to undertake a project like that?

Ian Cartwright: One of the things we sort of seeing as an anti-pattern, it can sometimes be useful, but mostly causes trouble is something we've called feature parity. And so, the idea here is often, you know, IT go to the business and say, "Hey, we need to replace this platform." "What do you need in the business?" They will say, "Oh, well, all that sounds like it could be disruptive, I might have to retrain my people, or I don't want that. So just give me what I've got today."

So, what happens is they often then build a huge requirements document that describes all the ways they do the current processes now. That becomes the spec for the new system. So that feature parity is, like, give me exactly what I've got today. But I guess because it's on newer technology, somehow, under the covers, things will be better, more, reliable, or cheaper. The challenge with that is when you go and talk to actual end users of the system, who use this, you know, green screen terminal, or whatever it might be, they're like, "Please, no," the last thing they want is something that works, it doesn't work, you know. We do half the work on a spreadsheet because the system can't accommodate the way we work now. And we have all these workarounds.

Hannes Lowette: So, keeping that as a spec doesn't make sense. You should use this as an opportunity to rethink things.

Ian Cartwright: Yes.

Rob Horn: It's interesting, right? If you're in that kind of situation, you may want to go through a series of archaeology to understand what your scope and your requirements are by looking at the system. If your business...

Hannes Lowette: But not all of the why is gonna be gone, right?

Rob Horn: Right, exactly right. So, you're missing the why. You're also actually missing all of those business processes and journeys that don't happen on the system because the system doesn't support how the business needs to work. So, despite all of that great work on trying to work out your scope, you're missing a whole load of scope. Plus, there's a whole bunch of features and functionality that the business doesn't use. So, if you reproduce that it's a waste. And like Ian said, right, the last thing the users want is the system does the same as what it does now.

Hannes Lowette: And I reckon there is also...the business keeps moving forward on the old platform as well. So, the spec that you make today, that platform is gonna keep evolving while you're writing a replacement, then you're never catching up to it, right?

Ian Cartwright: One of the things I will do is go and help a client assess a long-running program. I've done a couple where the new features going into the old system were being added much quicker than they were to the new system. And so, we sat down, and we realized the new system that was meant to replace the legacy, it would never catch up. And because they hadn't…part of the reason was when you do feature parity, that often goes hand-in-hand with a big bang release. Because the business, as you said, they don't want the disruption. And they think, "Well, I'm gonna get what I've got today. So, what I can do is, you go away and build that for 18 months, 2 years, and then we'll choose a weekend. And we all go home. And on Monday, we'll come in, and it'll all look the same, but it will be on the new system." So, it tends to lead to this big bang release. But the problem is that you're not...

Hannes Lowette: This is very risky as well.

Ian Cartwright: It is.

Hannes Lowette: It's like, even if you get to building other features it's going to be very risky.

Ian Cartwright: The problem is that when you get to the big bang on a fixed date, and you've got this big requirements document that often a third-party supplier has signed on the line, to say, "I will deliver that." And then the business comes and says, "Actually, our competitor's done this, or the regulator has changed the rules," then you get into a change control process, where the supplier's saying, "Yeah, but we're doing what's in that document." And now you want some...

Hannes Lowette: And then the whole thing becomes a contract negotiation.

Ian Cartwright: Exactly.

Rob Horn: Correct.

Hannes Lowette: And that's what the whole Agile Manifesto tells us to steer away from, right?

Ian Cartwright: Then the other thing we often see is even if you do manage to succeed, and it can work, is often when you look at the business case for replacing legacy, the thing that everybody's forgotten about in the meantime. It says faster, cheaper delivery of new functionality, but we've spent two years doing the opposite. We've spent two years going away and working to a spec and not giving you any working software. And often, I've seen a couple of times where they thought they could do two years, do a release, and then transition immediately into a weekly release. But you spent two years practicing how to work in completely the opposite way. It doesn't work. The next release is suddenly six months, a year out. And the business is going, "But hold on, we gave you all this money to get faster releases? What's going on?"

How to tackle legacy systems

Hannes Lowette: So, what would be a better way to tackle that?

Ian Cartwright: There are probably some patterns we can talk about because we're not saying this is easy, this is a difficult problem. I think, in terms of how you go about building the software, we're sort of the only way we've seen really to know that you can release frequently is to start building that way from the very beginning. You need to be able to show that you can deliver value incrementally, frequently right from the start of the legacy displacement project. We just don't know another way in which you can know that you're gonna get frequent software releases otherwise.

Hannes Lowette: Unless you start doing it.

Ian Cartwright: Unless you start doing it. It's like the existence proof of faster releases is to do faster releases. But it does raise challenges in terms of how you break the problem apart.

Hannes Lowette: Because in an ideal world, I guess at some point in the software, you're going to integrate the old system with the new and use some functionality on the old platform, deprecate features and move them to the new, something, a process like that.

Rob Horn:  Absolutely. So, we want to think about how can we, like Ian said, break this big problem up into smaller pieces, then we wanna start delivering those pieces incrementally, whilst using...

Hannes Lowette: Improving on the old technology...

Rob Horn: Improving and gradually...

Hannes Lowette: ...on the old business processes even.

Rob  Horn: If we can, absolutely, right. But gradually displacing the legacy, rather than replacing the big bang, hence, our use of bad words. And like Ian said, in a way, where you're, kind of, transforming or changing your engineering practices to enable you to continue to do that, though, you know, for the lifecycle of this current project and into maybe product kind of mode and ongoing basis, to enable you to continue then change afterward. So as you were kind of alluding to, right? You've got a couple of problem sets now. It's like, "How am I going to break the problem up?"

Hannes Lowette: That first.

Rob Horn: That's a difficult problem in itself. But there's some kind of patterns that we're seeing around how to go about breaking up that kind of problem space. Then it's given a set of parts. How do I now deliver those parts incrementally? And what are the techniques that I maybe need to use to integrate the old world and the new world and, kind of, keep them separate?

Hannes Lowette: Old technology and new technology, even it might be that your UI technologies are not gonna be compatible at all. But you want to put it in the hands of the user as a single product. I found that challenging when we were doing a similar migration.

Rob Horn: Yes. So, if we talk about breaking the problem up a little bit, right?

Ian Cartwright: Yes, I think it is...definitely when I go and talk to our teams, finding the seams, finding the right way to say, "Okay, we got this system, they've been building it for 10, 20 years, it's running, three-quarters of the business in there. How are we gonna break that problem apart into smaller pieces?" And I think the first thing we've discovered is, you have to do that with the businesspeople in the room. Because if you break it up along technological boundaries, that might not allow the business to do what they want to do. So sometimes someone will say, "Oh, well, we'll migrate the database, then we'll migrate the business logic, and then we'll migrate the UI." But the problem is that doesn't necessarily...how do you map that onto business priorities? So, what we try and do with the business folks in the room…

Breaking legacy into smaller dimensions

Hannes Lowette: Has that ever happened, where you take it layer by layer?

Ian Cartwright: We've seen people try it. I don't think it's been successful. Because we're back to the same thing, which is like, "Oh, well, we're just gonna spend 18 months replacing the storage layer." But the world doesn't stop turning, competitors don't stop releasing software. So, the business becomes frustrated, because they're like, "Well, what's going on? We need these new things." And IT tells us there isn't any budget because they're spending it all on database migrations.

Hannes Lowette: So, you're looking a lot more at vertical slicing the applications and finding features that belong together that make sense to replace as a whole? Is that...

Ian Cartwright: We see different patterns. So, for example, with a retailer, what we found is quite often what you can do is look at product lines. So, you might say, "Okay, we might do sportswear first. And then maybe we do men's wear, then women's wear, and then children's wear." And so, we're looking for delivering vertical slices of value. But you have to have the business in the room because they're the ones who know which are the most important in terms of revenue. You also need their agreement that, ah, if somebody is shopping for sportswear and children's wear, for a while, they might see a different user experience between those two product lines. But that's the compromise we might have to make so that we can do this incremental delivery.

Hannes Lowette: And by involving them in the decision, they also know what the effects of what they're going to do are going to be?

Ian Cartwright: Yes. Yes, exactly.

Rob Horn: There are no surprises.

Hannes Lowette: And they can tell you, like, it's important that these features move together because we cannot have this experience or that, right?

Ian Cartwright: Yes.

Rob Horn: Yes. So other dimensions might include customer cohorts. So rather than product lines, maybe you could target a certain segment or kind of cohort of your customer base. There may be some obvious technology seams as well. Talking of the value stream or kind of the user experience, there might be steps of that process, which are supported by different parts of the business or different sets of kinds of users. So maybe you could sort of intersecting or kind of slice in a bit of new functionality as part of that flow. Or like a business capability. Again, a previous client, I was working with their logistics team, kind of, responsible for, kind of, problem exception handling when sort of goods wasn't arriving where they needed to sort of thing. Yeah, we were able to, you know, sort of provide their full suite of kind of the tooling they needed to do just that part of the job. So that was a user cohort, a kind of a value stream, and a set of capabilities all in one kind of piece.

Hannes Lowette: And that means that you're moving one department over…

Ian Cartwright: Yes, possibly. But you have to...I know, I keep saying that you have to have the business in the room, because...and also, they have to be willing to compromise, we've been in situations where the businessperson said, "I won't accept half my stuff working on the old and half my stuff working on the new." The problem was that was a blocker for the whole idea. And so, it's like, well, if you want faster time to market, you've got to be willing to compromise. You know, and there has to be some room to maneuver. Because if you just keep coming and saying, "Just give me what I've got today," you know, well, none of us are gonna get what we want at the end of this.

Hannes Lowette: Well, I feel like in software development, in general, in a lot of processes, it is valuable to have the business owners nearby and available to you, as a team. Usually, they go in the direction of like, these people are very busy doing their job. So, we're going to put an analyst in between them, right? In a lot of cases, that just adds another translation layer between their actual needs and the team building them. I'm not saying analysts are bad at all. It's just a lot nicer if you can involve the people.

Rob Horn: We've got some very happy memories of spending some time, like out of a day in the life of...right? So going and sitting right next to the people doing the day job who were using the system, and it was being replaced. Talking to this young lady who was doing some financing stuff, and she was talking to me very diligently through her, kind of, a process that she follows. And she described kind of downloading a report, printing it off, going back to the system, loading up a screen, and checking the list items that, you know, on the screen matched what was in the report. And I sort of...

Hannes Lowette: Which could have been like a batch job that you're automated in half a day or?

Rob Horn: Right. So, I've been spending some time with some architects as well. And I had to kind of just, "Would you just explain that to me, again,  you're looking at this, you're looking at this, are they ever different?" And she was sort of like, "I'm not sure," went off to speak to a colleague, came back, took the page out of her work manual, tore it up, threw it in the bin. It's like just because of the technology people are not spending time with the businesspeople. They didn't realize that the two things were driven from the same transaction turntables.

Hannes Lowette: And I'm guessing you're getting three different stories when you talk to these three different groups of people. You talk to the developers, and they'll tell you what's wrong with the system technologically and why they want to move. And then the businesspeople are telling you about the value stream and how the system is not complying with what they want to do. But when you talk to the actual users, you get stories like, "Yes, this screen is working against me. So, I have to work around it." Like, some of the business logic is going to be in their heads and not in the system.

Rob Horn: Yes.

Ian Cartwright: Oh, very much so. I mean, we have a client for where IT couldn't understand why the business waited until Friday afternoon to input all the weekly numbers. But they didn't go and ask them. So, we went to ask them. And the reason was on a Monday, they extracted all the data from the legacy system into a spreadsheet. They worked all week long on the spreadsheet, and on a Friday afternoon, they imported the spreadsheet back into the legacy system. So, the view of the business in the legacy system for four days a week was completely wrong. That was why it looks like everybody waited until Friday afternoon to key the data in. They'd been working off a spreadsheet all week. And no one had sat down and had that conversation. It was quite interesting. It was.

Hannes Lowette: But that's just layers in the organization, or not even layers, like it, could be lateral groups of people not talking to each other, right?

Rob Horn: That's right. I say, when you drive change from technology, you miss all this nuance, and this is all scope, right? This is all opportunity for improving business processes, and getting better access to data in a more timely way.

IT as cost vs IT as value generation

Hannes Lowette: Is that like a walled garden sort of problem that still exists where they see IT as something separate from the business?

Ian Cartwright: It's, I think we have some clients, I would call them digital native clients who only exist because of the internet.  I could say like some of the travel sites, insurance comparison sites, or things like that didn't exist before the internet. There you see very much a much tighter collaboration, and the technology is seen as value-generating. But if you talk to old organizations who've been around for 50-plus years, for them, historically, IT was a cost. That was, "Oh, we have to have IT to generate the invoices, or to print out the payroll checks," or something like that.

And so, it was always seen as a cost rather than value generation. And unfortunately, that mindset is often still present. And so, you get this, you go and talk to IT. And they're annoyed, because they're like, "Yeah, but every year, we've asked for more budget to get rid of the system, but the business won't give us the budget." You know, and then you go and talk to the business. And they're like, "Every year, IT comes with this completely unrealistic number of millions of dollars, and we, what do they think is gonna happen?" And it's this attitude of IT as cost versus IT as the value generation...

Hannes Lowette: Is that where you see possibilities to avoid this from happening in the future?

Ian Cartwright: I think so. And I think, as I say, I think some organizations understand this, that to them, there isn't the business and IT, there's often like a product team, who have tech people in, there are businesspeople in and they collaborate. The technology enables value generation, and it's the two collaborating. I think if you can transition to work in that way, then you will hopefully, avoid some of these challenges in the future because you're always trying to improve. And you've got that strong collaboration, stop the walls going up between IT and the business.

Rob Horn: And the other, I guess another aspect of the transformation that we want to sort of help clients with is...the change is the only kind of constant, right? It's sort of like we need to continue to be able to change. So, if I can continue...

Hannes Lowette: Again, Agile Manifesto, respond to change.

Rob Horn: Yes, exactly, right? So this is about your engineering, kind of, practices and continuous delivery, continuous integration, good sort of testing, and all that kind of good stuff, good quality software to enable you to continue to run and change at pace. To continually allow you to switch out well-architected systems and switch out those parts of the software that now maybe are kind of becoming or considered legacy. As time progresses, new security vulnerabilities are found, and you need to continually update your system. So, if you can bake change as something you can continually, kind of, cope with, then maybe that's when legacy becomes a thing of the past. But that takes organizational change not just a project to replace a system from one thing to another.

Successful Digital Transformation

Hannes Lowette: How do you think the idea of citizen developers fits into that whole bringing IT and business closer together? Because we're getting all this low-code/no-code tooling that theoretically should allow people that are more on the business side to scratch their itch, like, fill in the voids in the existing IT systems.

Ian Cartwright: Yes, I think, I mean, in reality, what we're tending to see is where the business has become frustrated with IT. They sort of try and do an end run, they try and go around IT. And these are some of the conversations that start to happen.

Hannes Lowette: Well, it could be supported by IT, right?

Ian Cartwright:  I think, well, what you're finding, you know, often if they go to IT, IT is like, "Oh, no, please don't do that because we'll end up having to support it." You know, but often, that isn't happening, they don't talk to IT because the relationship's broken down. After all, they've been telling us they're gonna replace the old system for 10 years, they've tried 3 times, but it still hasn't worked. And I saw this talk at lunchtime, about how I can just put some doodle ware on my laptop and do it myself. And I think in certain areas, it might work quite well, like report generation or something like that, or analytics, where you can just self-serve.

Hannes Lowette: Like analytic search boards, yeah.

Ian Cartwright: I think where we've seen it being problematic is where people are defining stuff that ends up in production in front of customers. And then the challenge is...

Hannes Lowette: But IT has no clue what's going on. It's there.

Ian Cartwright: And then IT get a call saying, "Oh, such and such a thing is not working." And they're like, "What is that? We didn't know we had that." And the problem is, maybe there's no source control for it. There's not any testing, there's no way to check regression bugs.

Hannes Lowette: There are no decent deployment pipelines, nobody knows anything.

Ian Cartwright: The way you get it into production is you very carefully try and draw the same picture in production as you drew in the test environment and hope they line up. And it's just very...there's a lot of problems that come about because of it. If you're doing something that is going to be customer-facing, there's a lot of good engineering practice that you probably do want. And these low-code platforms don't always provide that. But if it's just an internal report or some analytics, you say, "Oh, I wonder, you know, if these customers do these things. I'd like to be able to answer that question." Being able to do that yourself, instead of raising a ticket with the data warehouse team and waiting three weeks, you know, that makes a lot of sense. Just being able to get that one I need to make a decision immediately.

Hannes Lowette: What happens near the end of one of these legacy displacement projects? From my experience, at a certain point, you have migrated all the important functionality, but there's still a bit of legacy left that is still doing its job. But the push from the business to replace it is not gonna be as big. Whereas to make sure that you meet your goals of no longer having that old legacy system there, you're gonna have to keep investing to get that done. How do you deal with that?

Ian Cartwright: Yeah, I think there's a couple of tactics. I think one is, when we talked about collaborating with the business in terms of how we slice the problem up, we also collaborate on the order that we do things. So hopefully, the things that are left towards the end are low value. You know, maybe these are things that don't generate much profit for the business, or there's only a small number of users who are using that part of the system.

And then I think it's a business decision. Because what you want to make sure of is that the business is fully aware of the cost of providing that service. This is often a challenge because what will happen again, in some organizations is they have one huge bucket, which is the IT budget. So, if you go to them and say, "What is the cost of delivering that type of service to those customers?" Often that's not understood. And so, when you get...and this is where you might even want some people from the finance department in the room, because what you want to do is say, "Okay, we can leave the legacy system on to support that part of the business, but they need to find the budget to pay to run it." And that's a very powerful way of moving the conversation on. If you go and say, "Well, did you know that that costs half a million a year to run that, and only you are left? So, unfortunately, you're gonna have to fund the budget." And suddenly they're, "Oh, no, we can do that differently. We could use a different system." Or even more, interestingly, it's like, well, if that's the cost, that's way more than the revenue we make from those customers. So, we need to migrate them to a different service instead.

Hannes Lowette: Is that powerful leverage that you sometimes use to make decisions about cost versus rush?

Ian Cartwright: I think you do. I don't, I wouldn't call it leverage. I would just say it's trying to have a mature conversation about the cost of delivering this service, and unfortunately, it's often not known. It's surprising how often a business can't tell you, "Okay, this part of the system, we know it costs, you know, 2 million a year to run that." But what revenue does that part of the system generate? Often people don't know. Unless you know that, you can't make the right decisions about what order to migrate things in, and which things you should turn off. So, I remember, we worked with a client who dealt with repackaging. And they had like, something like 30 different sorts of packages that they dealt with. And IT spent several million pounds migrating all of the different package types.

Hannes Lowette: Yes, supporting all of the...

Ian Cartwright: All the different... And they went to the business, and they were like, "Why did they do that? Because only four of them make money for the business. And we were going to retire the other 20 types of package."

Hannes Lowette: Anyway.

Ian Cartwright: Anyway, so why did they migrate them? They just wasted the money. You know.

Rob Horn: Yes. I mean, I guess when you do finally cross the line, right, it should be a bit of an anti-climax. Well, it's double-edged, right? If you've managed to transform, and change is now the norm, then really, it should be an anti-climax, right?

Hannes Lowette: You're successful. You know you're successful.

Rob Horn: Because you know you're successful.

Hannes Lowette: But the users will just feel as if business continues.

Rob  Horn: Yeah, but I think you should also have a big party, right? And celebrate, you know, celebrate the success. Because in the beginning, we've agreed with the business what the kind of success criteria or the drivers, the objectives of, kind of, tackling the legacy in the first place. And after the marathon, because these projects aren't easy, right?

Hannes Lowette: No, it's never a three-month thing?

Rob Horn: No, right? Exactly, right? It's not, well, from what Alan was saying in the keynote, there's nothing soft about legacy software. You get to the end of what is a marathon, you need to celebrate that, right? You need to celebrate, you need to call out all the people that have helped and have played their part in, kind of, this achievement, and demonstrate that you have met the success criteria, and, you know, transformed the organization. Hopefully, their legacy for them will be a thing of the past.

Hannes Lowette: And hopefully, you've already had a couple of milestone parties along the way of...

Rob Horn: Of course, right. Yeah, of course. Yeah. Iterative developments are iterative parties.

Hannes Lowette: Exactly. That's the whole reason we do Agile, right, is to have more parties.

Rob Horn: And celebrations.

Hannes Lowette: Or celebration. I think it's very important to celebrate success with themes. To put it in the spotlight, what people are doing. I have this image from the "IT Crowd," you probably know the TV series where they always forget about IT when they're celebrating things. And unfortunately, that is something that does happen.

Ian Cartwright: Yes. Some organizations forget about IT when they're doing the annual planning as well, right?

Hannes Lowette: Right. So, now celebrate your successes, do it a piece at a time. And make sure that we involve the business in all of it. Yeah, I think that's what I'm gonna take away from the talk that we just had. Is there anything that you guys wanna add to that conversation?

Ian Cartwright: I guess I'll just say that we're continuing to write these patterns up. So, we've talked a little bit about the motivation and breaking the problem up, but there's also Martin Fowler's website, we're writing up patterns that help you then implement it. So, once you have decided how to slice the problem up, and we're trying to get those every few months, although Rob Horn and I are often very visible, very busy with client work, we're publishing those on Martin's website. So, if people are interested, they could go and have a look.

Hannes Lowette: They can go there?

Ian Cartwright: Yes

Hannes Lowette: Ok.

Ian Cartwright: And read more detail on what we're doing.

Outro

Hannes Lowette: And they should come and see your talk this afternoon.

Ian Cartwright: Yes. 

Rob Horn: Come to see the talk. And listen to our technology podcast, the Thoughtworks technology podcast as well, where we've been talking to Rebecca, our CTO on the same topic.

Hannes Lowette: Okay, so go and look that up. And thank you, guys, so much for this conversation. I learned a thing or two that I can take into my next project.

Rob Horn: Cool.

Hannes Lowette: Thank you.

Rob Horn: Great. Thank you.

Hannes Lowette: Thank you so much,

Rob Horn: Been a pleasure. Thank you.