AI Is Speeding Up Delivery. Are You Building the Right Thing?

Welcome Back And The Big Question

Welcome to Definitely Maybe Agile, the podcast where Peter Madison and David Shurk discuss the complexities of adopting new ways of working at scale.

Hello, Dave. How are you doing? Always good to catch up. It's uh well it's been a while since we've had a chance to just have a one-on-one chat.

It it has, hasn't it? I I mean I'm uh it's a bit unusual, so I uh I feel like it'd be good to dig into an interesting topic. What do you have for me today?

I was gonna say we've had some fantastic guests in the last few weeks that have kept us busy, and and it's always a pleasure to have the guests coming on board. But sometimes it's just nice to just talk a little bit about what's going on in the world of well, the the stuff that we do, process improvement, product delivery, getting things out of the door in a timely manner.

Yeah, all of that kind of fun stuff. Because uh so the what you were you were mentioning right before this, we were we were chatting about what different areas and different things are that are happening in the world around us. And you were mentioning you were seeing a

AI And The Return Of Projects

rise or some people commenting on the fact, yay, we've got AIs, let's go back to doing projects.

Yes, yeah, the resurgence of project delivery over product delivery, right, or agile delivery. And I think that that's certainly something we're beginning to see. I'm bumping into this in a number of conversations where it's almost like the tide has been going out for some time on project versus product and shifting towards product delivery, and all of a sudden, AI is enabling organizations to put all of the plans together, big plans, and so this sort of renaissance, if you like, of big upfront design and you know, huge projects being delivered over longer time frames, in some belief that this AI augmentation is going to make it more successful than it has proven to be in the past.

Which seems completely the opposite of what you would expect. Um and because I mean with we know that the the reason that we that everybody was like breaking, I say everybody, but the the people who moved to a product delivery type uh mindset and method were doing this because they understood that breaking things into smaller incremental pieces, putting them in front of a customer, because we simply don't know if what we're building is the thing that we should be building. So we need to get feedback as quickly as we can. So we need to build as a complete small piece of it, get it in front of a customer, ask, say, hey, what do you think of this? Get that information back and then figure out what we do next, and then rinse and repeat and incrementally build it out. They that that logic hasn't changed just because we can do this faster. In fact, if anything, we can now do this much, much faster and in parallel.

So it's kind of like now in 3D, we can well it's interesting when you say that because what you're describing is first of all an ideal state. And many of the organizations never really got to the validation piece. They talked about iterative and incremental, they took that on because it reduced risk and delivery risk, but they didn't do the business risk, the sort of, is this what the customers like? Is that what they need? Are they prepared to pay us more for it, stay with us, be engaged with us longer? That element, there are many organizations that definitely did go in that direction, but we both of us work with organizations that kind of didn't really take that on board and are still very kind of, you know, get these features out of the door and make sure you meet the specifications that we've agreed internally rather than validating what customers really want and they're looking for.

Yeah, which is interesting, really, isn't it? Because that we've we know and we have seen on many occasions that that when you put it in front of the customer, that's when you realize that what's actually going wrong.

Yeah, absolutely. Yeah, yeah. And then and then there's a whole kind of process that goes through, and and you know, product delivery optimizes that process, really sort of shrinks it down so you can get quick feedback, you can build that back into it. We don't have to necessarily go through some of the hoops that you jump through when you're doing something in a more sort of scaled project-driven approach where you're gonna have to wait 18 months or two years before the annual budgeting cycle comes around, it gets you know grouped together and actually delivered and so on. So there's definitely that sort of shift. But we would, or at least that that recognition that there are companies that aren't doing that validation. But there's another piece that I wanted to add into that, which you were just touching on, which is the AI augmentation didn't really touch the validation as much as it touched building and releasing features and enabled,

Why Validation Still Matters

like I think of it as commoditization or utility. You know, it's almost that getting a feature out of the door is a utility now. You just turn on the tap and it goes. And so instead of going, okay, now we can do lots and lots of micro changes and maybe look at how those changes are going to change what our customers deal with, those micro changes have got bucketed up into these bigger releases because there's confidence that that release will not have the headaches that they used to have in the past.

Yes. And we we understand and have known for a very long time that if you jam everything into one big packet, then you're gonna it's gonna be much more confusing to figure out well, which part of that big packet was the thing that did what I wanted. And what about the other 80% that we didn't actually need? Um, do I still continue to add and maintain that complexity? Because that that's the other problem you get. The more stuff you jam into uh production, the more stuff there is in production that needs looking after, and the more things that can go wrong. So we we also need to consider the the entire system, not just the part of it that we're looking at. And so I do find it interesting, this idea that uh the big upfront design and planning piece of it uh is sort of comes back into the vogue. I yeah I think that there is a piece here where we we are looking at the coordination of AI agents to build out the various parts of the system, and that we a lot of that requires much better uh understanding of the context and the design of the pieces that we're building. So that is 100% true.

But but that that is that is the same problem of building cars by hand in a garage where we're all kind of tinkering and and we're artisans building out the car and shaping the wing mirrors to match and moving that to effectively uh you know forward bringing on the assembly line, in that when you go to the assembly line to move at speed, I need to think about the entire picture of what we're doing, not little pieces of it. And I feel that in until recently we've been able to think about the little pieces because we never went quick enough. There was never really the assembly line type of model and speed that we saw in automotive uh industry versus computing, which is a bit weird. Software actually doesn't have that, it still has a very artisanal kind of um way of working

The Hidden Cost Of Big Releases

where you know solution design gets done over here and specialists come in and do their piece and it all gets stitched together. Now that changes. We've talked about context. We talked about you need to know what the big picture is and be able to articulate that and break that down in a way so that now all of those, the agentics side of things, the AI piece knows what it's validating and evaluating again.

Because if you I mean, theoretically, you could say, okay, here's my entire application. I'm going to take that entire application, I'm going to break it down into all of the pieces, and I'm going to spend probably quite a lot of money uh sending it through a set of agents to go build out all those different parts of that solution. And then you might put it in front of a customer, and the customer's going to go, Well, I didn't need that. Yeah. So you're I need this bit, but I don't need everything else that you've given. Yeah. So I'll look somewhere else. Yeah. And I'll go find the thing that actually does what I want. Yeah. And they and this, I mean, this is from a business perspective, this difference of you look around at everybody else and say, Well, we've got to catch up, and they've all got all of these features. And so I've got to have all of those features too. But if you actually go and talk to the customers of those other businesses, and they say, Well, out of all the things that they have, I use this one feature. All of those other things they have, I don't care. And they weren't, and quite often they'll say, and it had nothing to do with why I picked them. So sometimes we'll sometimes people will well, they'll pick it because, well, they had 10 features. I only actually ended up using one. The other nine, I did entice me, though, because look, it says, look what we've got. Um, but if you can say, okay, so that one thing that uh that those customers really, really like, can we do that better? Can we do that faster? Can we do that prettier? Can we make that easier? Um because then you've got something that a customer might want.

So so as we're chatting about this, how do what do we actually want to see? Because I don't I don't think either of us want to see a resurgence of project delivery. I mean, there's a lot of reasons we we've talked about why project delivery actually increases your risk, whether it's business, customer-facing risk, whether we're building the right thing, or whether we're building it right, and whether that technical feasibility risk is being addressed appropriately, delivery risk is being addressed appropriately. None of those are solved with a project delivery mind.

I I think there's it you still end up in a situation where we we've got to have a big North Star picture of where it is we're going. We need to have a rough idea of what are

North Star Context And Outcome Metrics

the main things that we think we're gonna need and what goes first. Um so we need some form of prioritization. From that, which should be a small piece, we want to break that down and have the agents go and execute. If we're really unsure, one of the wonderful things we can do now is try a couple of things. But to do that, let's just say we're gonna pick one. We we're good enough to be able to prioritize, and we're going to we can build that out, we can try out multiple different versions, we can do all sorts of fun things to experiment with that, but we've got to have a clear understanding as we go into that as to what is the outcome we're looking for and by what measure, how are we gonna measure it?

How are we going to know that I was just going to say that part of this is this resurgence of the project plan end-to-end. And and whenever we've worked, uh certainly my experience has been that when you're introducing iterative and incremental ways of working, that product delivery piece, it's always within a container that is some form of project plan with a beginning and a middle and an end, because that's the longer term piece that sits within the firm, within the company as the container within which this product delivery is being done. But the critical thing is that that planning or that description of the North Star and what the goal is, that's become context, become how do you define the boundaries within which your agents are going to be doing their various tasks. And that's research, it's sort of elevated to being super important again, whereas before it's been kind of package it up and put it to one side. So that bit I completely see, but the problem is the delivery piece should still be tiny and iterative and incremental in the ways that we've always talked about, even though it's cheaper to do it, you know, it's cheap now and you can do it at scale. But why would you?

You don't reduce the risk. And it should be tied to those concrete measurements of outcome that you're looking for. Absolutely. So you you should be looking for that as a part of it, and then you feed this into the engine as you go too. But on the other end of that, you gotta think about uh especially if you're delivering something that humans are gonna consume, which isn't always the case, but say you are, then you need to have an understanding of what is the rate at which those humans are going to be able to consume the thing that you're building, and how am I going to understand um whether they liked it or not, or whether it's useful to them, or how it needs to change, or what might need to be different, before I come back and just build the next one and just basically pile more slop on dip slopes.

Exactly, exactly and just end up with a gloopy soup thing that's not really what anybody needs. Which again, we're beginning to see as a consequence of it.

Um so I think I think it's a combination of these different pieces. Because I think I I there's a there's a part where uh it's not about being on a soapbox about projects or not projects, it's about thinking about your entire end-to-end delivery system, yeah, understanding how that works, how it changes as a consequence of bringing AI into it, thinking about how do I know that the product that is being created, the thing that's coming out of the end of the pipe is of value. And how like how am I gonna tell that and feed that back into the system? It's that continuous learning, uh, that is the system learning what's going right. Because in a in an idealistically simple solution, uh, which um if it's got humans involved at the end, it ain't gonna necessarily be simple. Uh, you can say, uh say say you could you've definitively determined that uh it if uh we reduce the number of clicks from five to four, then then it was a success. And then that I can measure for that and I can then feed that back in. And the this A, I can monitor and say, oh, it's going up to five again. I better make a change. What change might bring it down and then continue to improve the system, uh, and it which is uh systems theory at this best. Uh yeah, but that um the the fundamental um uh uh the ability

Systems Thinking And Feedback Loops

to do that um at scale in a highly complex system with many, many levers and uh little uncertainty around what it is going to be, and potentially humans who you may not easily be able to sort of determine something as concrete as that to measure that then it but you need a you need a longer life cycle and you need a way of having that fed back into the system and you need to think about what that looks like because then you can start to think about okay, what I need I need a point here where I can say, where do I now? What needs to change about the next thing that goes into the funnel?

Well, and that and that kind of pushes away from this, let's group all the changes together in one big bang release, which is I think that when we started this conversation, we were going back to the it feels like those sort of big projects are beginning to kind of be brought back into they're back in vogue. And we want to be aware that that's just because there's it might be something that's sort of doable with the AI augmentation, we don't want to go in that direction because you don't solve the underlying problems, that risk problem point that you're making about how can I create these positive reinforcing loops where the system is and understands what different parts of the system are trying to do and therefore can fine-tune and optimize those individually. On its own. On its own, even. Yeah. So how do we summarize this conversation?

I I I can go first if you like. Um so projects are good, projects are bad, they're necessary, you know, in the sense that we need some kind of what is the sequence of things that we can overall. Let's have an idea we're doing. There is still a very good case, say is don't overplan every last little detail in every step of what needs to happen up front, because that isn't going to get you the results you need, because you know it already is going to have changed, so you're going to have wasted your time creating a bunch of steps that aren't going to need to happen. So that's there's no value in doing that part of it. Uh, there's there is definitely value in thinking about your end-to-end. So this would be my second point. There is value in thinking about the end-to-end system and how uh as you start to introduce

Summary And Listener Call To Action

uh AI into the way that your delivery system works, what changes, like what's going to be different. Um, and are you creating and understanding the the right measures to be able to learn what's necessary from your customers to inform those delivery systems so that the product feature you're building is being built right? But also so that you can think about what's coming next. And over to you, I'll let you have the third one.

So here's one of the I I feel like we're we're hitting a maturation of this the sort of life cycle process that we've been discussing over the years. And it's so it instead of it being a step back where we can no longer think in terms of product and we can go back to thinking in terms of project, I think that's a retrograde, retrograde step. I think what we're actually seeing is that as the technology's changed, as things are progressing, we've now kind of bringing together the two sides of it, that big picture piece of project. That one is back in vogue, correctly so, is driven a lot by this sort of need for a holistic North Star context-driven view of the systems and what we're trying to create. But then coupled with that is the fact that delivery still needs to be this small iterative. So you're bringing the best of the product delivery world coupled with the best sort of long-term perspectives that you get from a project world rather than letting go of that product delivery. You still need that muscle, you still need to be able to use that. In fact, it gets easier when it's structured correctly, but we want to dovetail that with the project view.

Sounds good.

We've done what we can.

Uh, with that, well, it's a pleasure as always, Dave. Always uh good to uh chat about these things. And uh I look forward to next time. Right, until next time. Thanks again. Thanks. And uh to all of our listeners, don't forget to hit subscribe, tell your friends about us, and uh send us a message of feedback at definitely maybeagile.com. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Madison and David Sharr focus on the art and science of digital, agile, and DevOps at scale.