How not to boil the ocean

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely Maybe Agile with your hosts, David Shark and Peter Madison. So how are you today, Dave?

Peter, I'm doing very well. Very well. It's uh I was gonna say it's a gorgeous day in Vancouver. And what I mean by that is it's wet and rainy, but we're okay. We're used to that. That considered a gorgeous day over here.

Um, what were we talking about this week? We're gonna talk about boiling the ocean. Um, and we're not about the specific heat capacity of a large body of water and the amount of energy it would take to actually boil the ocean, uh, because then we'd be getting into physics and all sorts of fun stuff that I daily remember, and I'm surprised I even remember what specific heat capacity is. But uh but but that is gonna be the topic for today.

So you mean big, big programs and how to deliver those iteratively, right?

Yes. So where the the situation where we find ourselves in, and we we talk about this a lot in that we say, well, you've got to start small. You and then you end up in a large organization that's got a large legacy systems, and they they're going, that's fantastic, but I gotta do all of this. Um or they or the alternative is well, we want to we know that we need to improve in order to deliver new capabilities because this is a perfect, this is like a good case. We want to be able to improve so we can deliver faster to our customers. That means we need to adopt methodology X, Y, and Z, uh, and we need to get them in place. But I've got a thousand stuff that I need to roll this out across. Um help.

Well, I I think uh we don't help ourselves in these conversations. You you're absolutely right. These there are large systems when you come from a digital application background, especially you know, in cloud-based and all the rest of it. Uh you can make small changes and build and adapt over time. But the reality is if you're gonna swap out your financial system in the back end of a financial services firm, this is not going to be a drip-feeded type of approach. I think uh one of the things that I've noticed is a lack of the right sort of preparation for these things. So, first of all, I think we've got to recognize that planning is needed. You're going to plan anything like this, and this might go against the grain, but you don't start shifting that size of problem by doing this in two week sprints and hoping you'll emerge the right way forward. What I find interesting is though that that planning is often functionality driven in the sense that they're going, what function do you need here? What step do you need here? And the whole thing is about what widget do you need, or what piece of functionality do you need, or what's the process that we are mapping into the system. What I'm missing is two perspectives which aren't dealt with in anywhere near enough detail. The first one is customer journey and understanding, ignoring the system. What is the customer journey? What is the end user experience that we need to support and build to? What are the problems we're trying to solve? How do they do them? How do we want them to do them? And I think the second piece there is the technology goals. Again, what are your technology goals? What are you trying to move to? What are the problems you want to solve by moving from a legacy system to a more modern system from a technology perspective?

And I think that uh, and this could take us in different directions, but it's it it winds up with this question of, well, should I? Uh and am I doing this for the right reasons? And sometimes uh when we come in as consultants and coaches as change agents into organizations, we find ourselves in this situation where, well, of course you want to do this, and without remembering to take the step back and saying, well, actually, if I look at the larger system and if I look at everything end-to-end, is this really where we should be focusing? This may, on the surface of it, appear to be a very expensive piece of that system. But if I'm spending $20 million to keep my mainframe up and running on a, say, I don't know, $10 billion worth of business that's flowing through it, and that thing is keeping it up and running and it's stable and it's working. Why do I want to change game? Or at the very least, why do you want to change all of it? Which bits, like what is the the customer change? To your point, what is the the outcome I'm looking for? What is the benefit of me doing this? So that I can start to take that step back and say, well, maybe it isn't that I need to rip out and replace this entire thing. Maybe what it is is I need to improve it enough to make the things that are now currently hard flow more smoothly within the system. And so that I'm taking a more holistic view and looking at the small incremental improvements that I can make that will help with that.

I I I think one of the interesting things that you get as you start looking at the problem, both from the end user and from that technical strategy point, which you're discussing there, is the realization that maybe there are quick wins. There's the low-hanging fruit that you can make small changes with peripheral functionality, if you like, that is going to improve the customer experience. And I do want to clarify that doesn't mean shelving the major changes. It just might be that there are some really great opportunities for light touch, high return on investment steps that will smooth the journey today for the customer rather than worrying or focusing everything on a two-year-from now all-in major shift in technical platform, for example.

Yeah, we see this. Um, I think it's a mistake that happens, especially in very, very large-scale programs. Public sector governmental ones often come to mind with this, where there's this well, in order for us to get to that piece, we need to roll out this huge program. And it needs, and there is a lot of complexity. This is not a simple thing to do. There are there are a lot of stakeholders with a lot of um a say in what needs to happen, which of course creates a lot of complexity. So, understanding where do I start in all of this? Like what it what are the small pieces I can do in all of this to like help get us towards that customer journey.

So, so how would you advise somebody to choose where to start?

So, for when I look at the the those large complex pieces, there's this the one of the first things is with the the experiment that's going to show you whether the direction you're about to pick is the right one to go on. So understanding, and there's a number of different ways of framing and creating that experiment. We've talked about it in previous podcasts, and like what a good experiment looks like versus a bad experiment, and how do we um set that up.

And I just want to just uh have a shout out here, David Bland's uh latest book, Fantastic Ideas on Exactly That Business Model / Idea Validation. So just we'll put that in the notes. It's well worth looking at for a kind of a catalogue of approaches that you can take.

Yeah, awesome. Good, good call back. So we so there's that piece of like that. How do I I create that piece that's gonna show me that I'm gonna be going in the right direction? How am I gonna quantify and understand where it is I'm going to say, okay, am I going in the right direction? And setting that up to be small enough that I can learn rapidly to decide whether I want to make a bigger investment in that direction or I want to pick a different direction to go.

So I I would categorize that as the lean startup MVP approach, right? So you're you're validating the change. Perfect. There's another area that I just want to consider there, which is risk and why you're making the change. So I've seen many scenarios where a system is being sunset. It's definitely at risk, it's going to become a security liability very shortly. Absolutely, there needs to be a change. But typically, even within that situation, there are certain aspects of that application, for example, which are more at risk than others. So is there some way that you can do a risk profile so that you can move certain aspects forward more quickly while holding off on some of the other pieces?

I'd say absolutely, in terms of so there's a few different interesting ways in which we can start to classify and prioritize the work that we have in front of us. And if we look at this from a from a leader perspective, what are the things that we care about and how are the actions going to impact those things? When we look at risk, there's many frameworks you can use to classify that. And managing risk is one of the key pieces that we want to understand in our organizations, because there's lots and lots of different types of risk, which is why we have lots and lots of different ways of managing lots of rules and governance and regulation and standards and policies that we all of which act as frameworks under DRC to help us manage all of that, um, so that we've in larger organizations so we can understand what is the the impact of these different risks, which ones should we be paying attention to? How do we rank them and decide what risks are the most important? Uh, and so there's those those kind of models we can.

And I wanted to add a third option, and this one is something that we see a lot when when a new system is being brought into place. And uh, if I'm quite frank, that the business is somewhat lazy in terms of describing what they need transferred to the new system. I completely understand this. If if we were, for example, if anybody's moved house and you get somebody to help you and they say, What would you like me to move? Sometimes we go, you know what, I don't have time to try and think about it now. Move everything, and then I'll figure it out later. So this is the we need 100% of the existing functionality plus loads of new functionality because the new system is going to let us do things we didn't know about before. And I always think of this as that Venn diagram. You've got the functionality that you have in the existing system, of which a chunk of that is critical, is heavily used by your end users, is vital to the service you're trying to provide, but a big chunk of that is a waste of time. It's been there forever, four people have used it, nobody's got to the end of a process flow or whatever it might be. I think part of that due diligence is the first thing is understanding what functionality are you leaving behind. First thing. Secondly, of course, as you look into the new system, we want to bring over the functionality we want to keep. And then slowly, how do we, you know, do we bring all of that functionality over? Do we bring a part of it? Do we add something in that is going to help us build things out? And if you if you layer onto that the customer experience, what people are trying to get out of it, now I can put customer problems in there and we can deliver slivers of customer problems. So now we're beginning to break that major change into slivers of functionality solving single problems and build up a broader and broader system that can deal with more and more different customer expectations.

And that's and when you have the opportunity to do that, uh that that gives you uh ultimately the kind of flexibility that you would need ongoing, because in in theory, eventually you'll get to the point where all of the uh the bits of functionality you truly care about are now broken up into those pieces that you've managed to bring across, and you can leave all the other pieces behind. And there's this uh like if I go and open the closet uh in my house, and there's these plastic boxes that have been there for nine years with stuff that nobody's ever looked at, and it's the all of that functionality I don't actually need in the old system. And uh, but uh I brought across anyway because I was moving house.

Well, it's it's easier, isn't it? That's a it's a it's we're just it's effort. I just have to move things. What I find really powerful is you start having those conversations about what's the functionality we leave behind, what's the functionality that we carry over, and how do we add to that, is the increased awareness of the customer journey, of what their experience is, first of all, what they do, and equally what they don't do. And so you typically find the team that's involved in that, as they go through that process over many months of deciding what to shift where, they become really close to how customers use their systems. And it's it's rare to find people who really understand how work flows through a system, how the service that you're offering really impacts the end user as they're look using that. So I think there's a huge benefit in that program of doing that. In fact, I just want to put a little hook in there is that huge benefit is so powerful, you definitely don't want to have mainly outsourced individuals doing it because the knowledge is going to leave your organization.

It uh it reminds me of uh years ago being very closely involved into uh an effort to move uh workload off the mainframe into a distributed system. And one of the mistakes that surprised me, and then I wasn't the one managing this transformation, but I was uh because I was working from an infrastructure operations, I was providing like guidance as to like the the underlying systems. And uh coming into it, I was talking to them from a business perspective as to what they were doing. And the interesting part I found and that just shocked me was that well, we're we're not gonna worry about the business processes, we're just gonna take everything that's there and we're just gonna recreate it in the new system. Uh and I was like, What? That that's a terrible idea. Uh for for one thing, they're gonna operate very, very differently under the new um paradigm. Another, you're missing out on this fantastic opportunity to better understand your customer, to better design the system to meet the needs that you you have. Uh, and you're not and it's gonna also take an awful lot longer. And uh uh not that it necessarily uh made me feel bad, but I was right, it ended up taking an awful lot longer. And what they ended up having to eventually do was go in and break down the business processes, understand what the actual customer needs were so they could properly model the system. Uh, unfortunately, it took them about five years to into the program to work that out, but but that's what they had to do.

Well, it's uh uh I've I've been involved in similar ones. One of the more recent ones with a it was a major healthcare authority introducing electronic records management systems. And and this what I find it is interesting is you're using layman's terms to describe the system. We're not talking about as from a say a um BSA, a business systems analysis perspective. We're looking at it from what are the problems that we're trying to solve? What are the the journeys that people have to deliver? And it's to do with, in the case that I'm describing, patients going into a hospital and seeing um somebody within emergency and then getting follow-on treatment and all of the bits and pieces that go through that, which have to, yes, it has to be captured in terms of data and in terms of well-structured data in well-defined processes that meet certain expectations, whether it's around compliance or best practice or whatever it might be. But having the conversation around the real like journey and experience just changes how we see those system upgrades or the system changes.

Yeah, I agree. It's uh yeah, I think we often come back to this, but visualizing the system we're working within is one of the key pieces to understand before we go about making change and understanding all the different parts of it and how they're gonna interact, um, at least in a in terms of what is that uh that uh the the flow through the system that will create the value for the customer so that we can understand uh what it is will happen or start to make um experiments around how we will change that. I think that's an essential part of it.

Perhaps uh one of the consequences of the way that we're describing these slices and the sort of small slivers of functionality, uh, there is a consequence which leads to running parallel systems, some sort of duality. I've got my old system, legacy system over here, and I'm beginning to build a brand new next generation system over here. At what point do you start shifting functionality over from one to the other? And the costs which are associated with that. There's data synchronization that has to be done in there, and there's people have to manage both systems, there's licensing costs and so on. Insight from your side, what do you recommend there? Do you like it? Do you think it's essential?

It's I don't know essential. Um I think you typically end up with a few different paths forward, and one of those paths it uh is it's usually better to be able to run two systems in parallel, unless there's a massive amount of underlying cost for doing so. Uh, not just from licensing, but from in terms of the capacity I would have to have under that to run it. Um if there's and if that also whether it introduces additional complexity or there's such significant differences between the two different systems in the way they operate, that it's good it'll be too jarring um to run both of them in parallel, either for the the the end user or the operators of that system. So that there are uh reasons why you might not want to. Uh if I run into a situation where it comes down to licensing, my my typical strategy is to go to the vendor and say, well, if you're gonna charge me X amount for to be able to run both of these in parallel, then I would uh say, well, you're just giving me an excuse to instead of spending that money with you, to go look at your competitor and spend the money with them. So that's there are ways of helping uh negotiate your way into a situation where this works more in your favor. Um with that, I think I think we're at the end of our time here today. So I think it'd be a good chance to wrap this all up. Uh, what what points do you think our listeners should be able to pull out of uh today's conversation?

Um I think I I picked up three things as I'm going through that. One at the the starting point is that whole way of stop looking at it in terms of a big bucket of functionality that we have to define and move over, and start looking at it a lot more in terms of both the technical objectives, why are you making that shift in systems, what's the expectations that come from that, but more importantly, from the experience, the user's experience perspective, and what is the product really trying to deliver in terms of a service as you make those changes. That's the first thing. Uh the second thing is we talked about three different ways to look at uh deciding what to do first. Risk management, just looking at risk, trying to understand that. That's obviously one. One of them was the um the uh spit of functionality, whether you're carrying all the functionality over or a part of the functionality over. Um, and then the other one is problem like identifying the individual problems that are going to be solved so you can sort of chip away at the block and move things through in that way. Uh and I think uh the final thing is the consequence of that is balancing sort of do you have one system and a big cutover, or do you you know how how early can you cut over to the new system with parts of the functionality? And one thing I'd add there is that in today it's easier and easier to have those systems running in parallel just because so frequently it is software as a service, and you can scale up your licensing over time and the other costs associated with it. So it's not quite as hard and fast that you cannot have two systems running in parallel.

And in fact, I think that's probably and well, not even probably, but that is where we should be aiming for. So when we see opportunities to make that the case, we should make that the case. I I think that sums up our conversation today beautifully, Dave. And so uh with that, I'd like to say if anybody wants to reach out to us, they can at uh feedback at definitely maybeagile.com. And uh thank you for the time. It's always a wonderful conversation, and uh look forward to next time. Excellent. Great pleasure, we'll talk soon. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps at scale.