The Never Ending Project

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 Peter Maddison and Dave Sharrock. How are you today, Dave?

I'm doing very, very well, Peter. So spring is coming in the air. That's the feeling I get. Something's changing. So um yay, bunny rabbits, flowers, everything. Snow's melting, it's great. Chocolate, chocolate will soon be on the uh on the shopping list, I should think. Um what are we talking about today?

Well, today I think we were talking about the never-ending project. No dragons, no fairies, nothing in sight, but it's definitely a never-ending project.

This is uh we're talking here about the continuous delays that happen on big, major projects which have a deadline, but we can never quite get to that deadline. We can never quite get everything across the line that we need. Is that right?

That's right. Yeah, where we're it's like there's this imposition, we've got to get it out the door, we've got to get it out the door, and uh, it's like this is a six-month project that uh we'll we'll do it, and then 18 months later you're still working on it and nothing is done, nothing's out the door, and uh it's still ongo and ever and ever and ever, that never-ending project.

Okay. And uh let's let's avoid for the moment thinking about why we've got to that point, because I I think there are many topics around that that we've discussed. And look at it from a different perspective. Is is is if you were brought in, Peter, and that's what you inherit, what is it you're going to do to try and get this never-ending project to be a delivered project? What do you do first?

Well, I I think the first thing that you do is you go out and you start to communicate to the stakeholders and identify who's everybody that's involved in this? Who who is it that needs to be involved in this? Uh how how is this entire engagement structured? What is there in this so that we've you can get a good firm understanding of like what exactly is it we're dealing with here? Uh, because the the next thing on the agenda then is like stop, just like stop doing all of this. You're just you're just running around in circles, you're on the treadmill, you're nothing's actually getting delivered. There's so let's take a breath, work out where we are, understand who needs to know what and when they need to know it, and then we can take that breath and uh decide what are we gonna do next.

And I think there's some important things that you're picking up there. One of them is is it's that sign of madness is to try and do the same thing over and over again and expect different results. And part of what that sort of phrase is talking about is the fact that when you get to a certain stage, and these are big, complex projects, when you get to a certain amount of complexity, um continuing to move forward is actually the worst thing that you can do because it's things are continually changing all the time, and you're not getting any sort of of control of where you're at. So we're going to begin by putting some constraints on this and get some control, and that starts with breaking the bad news to the stakeholders. Like we've got to tear up any sort of calendar expectations that we have there. We've got to reset expectations around this is an emergency that we have to find our way out of, and it's not something where you know we can keep expecting something that was written in a document 18 months ago.

Yeah, we used the uh term uh uh watermelon metrics in a recent uh uh presentation with this this idea that it's uh green on the outside and red on the inside. And if you don't take that that step back and start, it can seem like everything that's being put up, everything's good, everything's great. And then when you start until you have that opportunity to start to peel it back and see where things are going wrong, it uh it can be very difficult to actually forward from that.

As you're moving towards stopping everything, uh I think it's important also to start looking at what the priorities are. So we're going to whittle down a long, long list of expectations and promises and so on down to some of the core changes and try and prioritize what's the key functionality that we need to kind of stabilize and get into a position that we can push out of the door first, recognizing that it will not have all the bells and whistles and it probably doesn't even have some of the core functionality that is required. But we're we're wanting to create an experience where we can start walking step by step rather than being in this continuous I can never get it out of the door type of world.

Exactly. And it's um we want to be where we've delivered something. We need that like piece of success of finding a something that we can deliver complete in its completeness, and this will at least provide some value out of the work that we're doing, and that way we we've we get a lot of wins out of that. It's uh it's it'll increase morale, it'll increase feeling that we're actually making progress, and it'll help us with um being able to start to create uh the the initial spark for some of the momentum we'll need to build to actually get through whatever else needs to be built.

Yeah, and and unusually for me, because normally I'm a huge fan of focusing on customer value, but I'd almost consider it less about the success, the small wins or successes than small areas of stability and control. Because what you often have is a system where every time you try and move around, it's actually destabilizing something else. So we need to get to that position where we've got stability, we've got something that's predictable that we can make a small change to, push it out, and everything still stands up and is doing what we expect it to. And that gives us the platform from which we can now really start honing in on okay, what's the value that we can get out of the it's important that you I mean you building anything on a shoddy foundation is always going to uh uh bring up a lot of risk.

And we we've talked about that a few times around ensuring that we've got a stable platform to build upon gives you the confidence that you can continue to build. And it's uh so it's absolutely critical that you do that.

So, what else should you do? Well, um, and this is somewhat counterintuitive, but if you've got no, you've probably got a whole bunch of teams working on this, so you've got a lot of capacity, and what we're talking about now is first of all stopping all of that development activity and that kind of whatever the activity is that's going on, and then we're going to focus them on that small area of stability and control that we can build out the quick wins. What do we do with all of those other development people who are able to make changes to the system, but maybe aren't involved in that direct focused area of activity? And I think the first thing that we want to look at there is integration cost and how quickly they can make a change to the system and integrate it all and get it validated so we can make the goal being very small changes to the system that can be integrated into the whole and another small change integrated to the whole rather than trying to put off that long, laborious, costly integration process. And that often feels like too little, too late, or a lot of activity that doesn't feel like it's valuable. What would you add to that? Agree, disagree, or additional thoughts?

Well, it uh it ties well into um what we were just describing around that system because what they're really doing there is they're helping build the system, they're building the the platform, they're making you giving you something solid that you can build other things on top of while you build that move that piece that's ready to start to go out to the the customers that you can learn from. So I think I think it is critical. It's this uh you we don't rise to our goals, we uh fall to the strength of our systems, a quote that I love to use, but it's this uh this um by James Clear. But we it's this this piece. It's like we've got to start to build, and it's probably not a bad analogy, really. If you think about it, we've got to build this habit, right? And if we've been at this for so long, we've been working so hard, and everybody's sort of getting fairly drained drained by this point of uh, and there's been probably five or six project managers have gone through the uh entire engagement by this point, and it's uh it's painful, right? And people are wondering if this is ever going to be done or if I'm gonna be working on this forever and ever and ever. And then at that point, it's kind of this um you need to start to build some new habits within the uh organization.

I think we're also fighting human nature at this point because human nature is, I know this is painful, but trust me, we just need to power through this and we're going to get there. And it's just around the next corner. It's a little bit like when you're on one of those long hikes and the weather's coming in, you need, and at some point you've got to kind of kind of got to stop and just reassess and say, hey, we it isn't just about it's another mile, it's another mile, but actually let's properly reassess and and really treat this in a different way and change our behaviors. And as I say, human nature is we're nearly there. It's I know it's been painful, but it's only it's we're we're six weeks away. We're going to get there. And the reality is that six weeks becomes three months becomes six months. So in order to change that, we're going to have to kind of stop and say, let's get to the point where we can make small changes and integrate them all to safely. And now, when we get there, we can actually start leveraging the fact that we have a lot of production capacity, a lot of people who know the system, they know what's going on, but then we can focus them on technical debt and defects rather than new features. I mean, it isn't about new features at this point. This is about stabilizing and getting something out that we can build on, right?

Yes, yeah, exactly. So if we're gonna sum all of this up, I think I think we've covered off uh five points, and I'm gonna list them as I was thinking of them. We've got the stakeholder communication uh going out and talking to everybody who's gonna be involved in it. We've got stopping and taking, like assessing, taking that breath, understanding, like, hey, okay, and uh then we're going to um identify and prioritize the one thing we should work on, the the thing that's gonna help us uh get saying outdoor to create that stability to help us be able to move forward and from there do one thing at a time. Do the start on the next thing, the next thing. Meanwhile, everybody who's not working on getting that one thing ready is gonna be working on improving the system, improving the integrations, bug fixing, removing technical debt. Uh is there anything I've missed, Matt?

Well, as I'm looking through and listening to that list, I think that um part of it is that prioritizing the one thing and making sure it's small, not big. It isn't you know reducing it to 97% of what we originally planned. It's really kind of let's look at what the 20 to 40 percent solution is that we can just get out there. It's about stability, not feature-rich delivery at this point. Um and and I think then the other one is just that integration cost, because if I'm doing technical debt and defects, but I'm then waiting six weeks before I integrate everything, those are big changes that we're trying to integrate. So the integration costs really become a focus quite early on.

Yeah, no, for sure. Okay, well, thank you very much, Dave, as always. Uh, I always enjoy these conversations. If uh anyone wants to contact us, they can at feedback at definitely maybeagile.com. And then until next time, thank you.

As always a pleasure, Peter. Talk to you 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.