Transforming Project Management: Embracing Agile and DevOps for true value and adaptability

In this thought-provoking episode of Definitely Maybe Agile, hosts Peter Maddison and David Sharrock explore how successful organizations deliver value in today's complex environment. Discover why project success demands both effective execution and tangible business outcomes. The hosts examine the crucial differences between ordered and unordered problem spaces, revealing when to apply Agile versus traditional project management approaches. Learn practical insights about balancing execution with outcomes, and why the most successful organizations master both methodologies. Essential listening for project managers, Agile practitioners, and technology leaders navigating modern delivery challenges.

This week's takeaways:

• Organizations succeed by flexibly switching between agile and traditional project management based on context
• Success comes from delivering tangible business value alongside traditional project execution
• Match your methodology to the problem: ordered problems suit traditional approaches, while complex problems need agile methods

Chapters

• 0:04 Agile Frameworks and Project Management
• 11:38 Adapting Agile and Project Management
• 16:18 Digital Agile and DevOps at Scale

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you?

Dave: 0:14

Peter, great to connect with you, catch up with you.

Peter: 0:17

What are we up to today?

Dave: 0:18

Well, today, what value are we going to create today? What's the outcome we're seeking? Well?

Peter: 0:22

you see, you just stole my thunder, didn't you create today what's the outcome we're seeing? Well, you see, you just stole my thunder, didn't you? So today, and I, earlier this week, crossed my path, there was an announcement and I think you were saying you'd heard about this quite a few months ago, but an announcement by the PMI about how it isn't just the iron triangle that matters, it's not just that we deliver on time, on scope, on budget, but it also matters that the projects that we deliver also deliver value, that the outcome matters, which is a change. I mean. The interesting part is they say well, that's what we've always believed, although if you go back in time, that hasn't necessarily been true, absolutely.

Dave: 1:01

Yeah Well, and I think that I mean, everybody's heard of the iron triangle and, to be fair to the PMI, it's a very easy mantra to talk about, of fix, you know, being delivering on time, on budget and on scope and things like this. So they've kind of been caught up in that and that's what many of us who work in, say, the agile arenas and DevOps and so on, look at that and go well, there's nothing here about outcome and there's nothing about what we're delivering. Is it the right thing or is it not the right thing?

Peter: 1:33

And it is very powerful too. This is the other piece we were chatting a little before we started recording and there is a lot of value and power in what project management brings to the table and especially if you're doing something that has a very particular order and needs to be done in a particular order and you've done it many times before and you've got a good understanding of it or it's fairly well known what we need to do, Like if I'm building a house and I'm going to put down the foundation and I'm going to put up the walls and I'm going to put on the roof, All of the things happen in a particular order and, having done a little bit of home construction myself, I can say that when you don't do it in the right order, bad things do happen and it gets very expensive and causes some unneeded rework.

Dave: 2:18

I think, as you're describing that, I'm sort of playing back in my mind and thinking the era when Agile really starts emerging in the early 2000s as an alternative way of delivering software.

Dave: 2:31

In particular, a lot of the work that was being done at that time were major projects which were, as you said, if you're going to release some huge ERP system at the end of 12 or 24 months worth of work, there's obviously a lag between when you start that process and when you finish it. There's a lot expected around making sure we get the right thing out of the door at the end of 12 or 24 months. But I think it's also the time when the internet is beginning to kind of generate more churn and give more opportunities to fine tune things for end users use. So now we've got this conflict between it used to be execution. We needed to be able to get things out of the door when we planned to, but that problem starts shifting in the early 2000s to be. It isn't just about getting something out of the door. It now has to match the expectations of the end users the consumers at the other end as well, and their mind was being changed very, very rapidly.

Dave: 3:28

If you think early 2000s, even early 2010s, you've got the iPod coming out, the iPhone coming out, We've got technologies social media built on top of internet, technologies built on all of these things which are really consumer facing concepts and are changing the behaviors of consumers and end users dramatically through that period.

Peter: 3:47

Yeah, I mean I'll talk about the. We moved from a technology perspective, from a hey, it's very expensive to buy and put the infrastructure into place. It costs a lot of money to do that. So that was where all the focus and all the money was like how do we reduce costs, make it smaller, make it more? How do we handle that? Because go back to the beginning days, it was where a computer would take up a room and it costs an awful lot of money to put all that iron into one place. Where we moved into, the abilities to start to look at the network became the thing and the communications became the thing between the different systems, to where we are today, where it's all about the platform and the interactions to that, and the power comes much more into the hands of the end users who are now interacting into the systems. And that sort of evolution across many different dimensions has very much changed the nature and how we go about executing, especially in the digital space. But that's kind of the one of the differences that we see there.

Dave: 4:46

I really I think if we're looking at that sort of broader picture, I think we get into that place where there are two pieces that we have to be balancing and we've almost overcorrected on the one hand and we're now beginning to see that correction level back a bit.

Dave: 4:58

So you know, a couple of decades ago the focus was on execution, on time delivery, on budget delivery. So really about, can we do what we promised to do in, as you said, in these very costly environments and keep control of that budget? In the decades since then it's shifted to be that that isn't the costly bit. The costly bit is if we deliver something over 12 or 24 months but customer behavior and expectations have moved dramatically away from that. We're now left with a major deliverable with no perceived value coming out of the other end. So now we've got that other piece, which is how do we make sure we get something in front of a customer or a user which is useful to them and which is immediately cements the relationship that we're trying to build with them?

Peter: 5:44

Especially when we don't know what that is, or we're trying to solve an unknown problem, or we're trying to do something completely new or enter a new marketplace that we haven't been in before, where we just don't have that knowledge. We need to set up the capability of learning as quickly as possible and and basically optimizing for that.

Dave: 6:01

So and I I think this is where we're going to end up talking about the Kenevan framework, dave Snowden, the Kenevan framework and this is where the Kenevan framework really looks at two different worlds. One is an ordered world, where things are predictable and change maybe a little bit more slowly, and even if they do change, they're changing in a way that we can anticipate. And so in that ordered world, the focus becomes execution, because we're not really expecting the outcomes to change too much. We still have to get stuff out of the door, we have to generate value. However, the focus there becomes more project management in terms of how that work is being delivered. But then you've got the other side of the kind of types of problem that we're solving which are unordered, of types of problem that we're solving which are unordered. They're nonlinear, they're variable, probabilistic. Things change and surprise us by how rapidly they change and how they change in directions we may not have predicted.

Peter: 6:59

And then one of the other things you see in the audit space. That's also where you see lean, lean, you could argue as a practice sort of spread, the little cost too. But in the audit space, the idea of just-in-time manufacturing. Where I can, because I can know enough about my system, I can start to analyze the data of that and start to predict what it is that I'm going to need and start to build up the pieces that would ensure that delivery is going to continue to run smoothly. I can learn a lot more about how the system is going to operate because I've got consistency, which on the unordered side, I have far less of that.

Dave: 7:33

Well, I mean, efficiency is not the goal in the unordered space. So when we look at the unordered space and for those familiar with Kinevon, we're talking about complex environments, complex problems or even chaotic ones potentially, but let's ignore that for the moment. So if we think of unordered problems being, you know, complex technologies, nearly all technology problems really now end up being in the complex domain. If you're looking at anything where you're interacting with consumers and you're interacting with a mass market that changes almost on a whim, based on whatever the direction of different things are going, you know different ideas and memes and influences and needs and expectations are moving. So those unordered, complex problems require a very different approach to solving them. The agile frameworks are highly optimized for that type of problem space.

Peter: 8:23

Yeah, and you do run into problems where we start to try and apply it across all of them. You see this where it's like, well, if we have a project management practice, we're going to apply project management to everything that we do.

Dave: 8:35

Or, if we have agile teams, we're going to use agile teams for everything that we do as well. Yeah.

Peter: 8:41

And equally doesn't apply in that audit space. It's not going to be as an efficient way necessarily to solve some of the problems in that space.

Dave: 8:49

I think one of the interesting things I find in that you know I spend a lot of time working with agile teams and I think we've seen in the last few years this mistake seen in agile teams, which is they heavily focus on the outcome. They talk about outcome all the time but by doing that, they take their attention away to execute from execution.

Dave: 9:07

So all of a sudden, you end up with a team that's highly focused on trying to get outcomes out, but they don't have a reputation for continuous, consistent execution and delivery and getting stuff into the wild, as it were. When they do get stuff in the wild. It's highly outcome-focused and so on, but there's a need also to be consistent delivery engines as well.

Peter: 9:29

Yes, continually being putting it, but I mean that goes though with, ideally, you have both, because then you can learn rapidly from what you're putting out there as to whether it is valuable or not. And this is, of course, where we start to think about the sort of DevOps space and start to think about what is it we're doing to optimize our delivery practices and processes so we can learn faster, get value in front of customers quicker. It's a key part of that whole digital piece, but we very often see agile teams that are not set up to succeed in that perspective.

Dave: 9:59

Well, so I'm just trying to clear in my mind what I'm really trying to point out. It isn't about the execution, because delivery on the team, like you say, they typically are doing that, but I think there's an element of a reluctance to commit to a date, reluctance to be able to say, you know, we'll explore this problem and by you know, march 31st, june 30th, whatever it is, by a fixed date, there will be something in. You know, we will have reached a certain point and I that's. That's the thing why. That's why people are sort of pining for that project management rigor around fixed date, fixed scope, type of, you know, fixed time, fixed scope type of pieces whereas we want to hold on firmly to the focus on the outcome.

Dave: 10:42

So let's keep scope on the table and modify scope all the time um based on what we're hearing and what we're seeing in the market. But we also have to be able to kind of look into the medium to long term and make commitments so that we can you know, so the business can operate effectively.

Peter: 10:57

Yeah, well, and this is that aligning with marketing and sales, ensuring that we're delivering what people are expecting, that there's some form of roadmap that we're able to put out there, and there's always that challenge. I mean, from being the executive on the other side, I always raise an eyebrow at the coming next month that you get from the software vendor, which so rarely actually occurs.

Dave: 11:22

Yeah, Now, what would you say about the unordered types of problems make it so unsuitable for, say, traditional project management methodologies, but very suitable for agile methodologies.

Peter: 11:38

I think there's an element of the. There's a shorter timeframe to understand it. There's this concept that we look for what's the next point of learning that we're going to get in an agile, unordered space. So we're looking for how can we run a quick experiment to see whether what we think might be true is true and find out whether or not that's the direction we should go in. So it's much more adjust as you learn versus a project management approach, which very much says well, I already understand what it is I'm trying to do and where I'm trying to get to. Let me put in stone all of the dates and steps that I'm going to have all the way along that to get me there. There is, I think, on both sides. You have a risk management approach where we look to manage risk on both sides, but I think it's done slightly differently. But I think there's an element of that in there. There's the capturing understanding what risks you might actually have and then tracking that in a RAID log and then looking at it.

Dave: 12:36

Well, I mean that has so much to do with you know, if things are changing all the time. Tracking risks is almost like a hypothetical exercise. It doesn't mean the same as validating that you've got the risks under control by pushing something out and seeing whether or not it works or it behaves in the way you expected it to, driven by a rapid, a dynamic, unordered, non-linear environment where it's not easy to project forward what we expect to see happen. So by that definition, we're releasing in shorter cycles, we're validating things continually through experiments and so on In the audit domain. It's just that much easier because it's you can okay easier. There are many projects which are very, very complicated to get out the door, but it's things change at a different pace yeah, and the reality is, too that.

Peter: 13:29

I mean, we're talking about this in a very black and white terms. I mean, the the best project managers I've ever worked with have always been very adaptable to what the situations are, and it's because you have to be so it's. But there is still that kind of fundamental underlying set of differences between the two.

Dave: 13:47

I think you bring a really interesting point up, which is it's easy to think it's you know it's A or B and the most successful kind of organizations people, you know, programs will be the ones where they have knowledge of both and they're kind of going backwards and forwards depending on the types of challenges they're facing. That risks don't get swept under the rugs.

Peter: 14:23

We don't have our RAG report, which you know green on the outside, red on the inside that people are actually talking about. You know watermelon metrics that we're actually looking at and raising and talking about the risks, and that they're not disappearing into the work. Yeah, great. How would you wrap it up? Well, I think we started from. The PMI cares about value now, and we covered quite a bit of ground around the concept of ordered and unordered and application of different methodologies to different spaces. So I think that's one of the key takeaways there is that it's not either or.

Peter: 15:02

It's applying the right methods to the right problem sets is definitely the way to go. Understanding what type of problem you're dealing with then becomes key, so that you know what the right way to address it is. Another piece, though, which we didn't talk about, which we sort of were alluding to there, was that the nobody cares about your methodology piece. But it don't get so locked in to. This is how it must be done and miss out on. Well, maybe this isn't that type of problem and I need to adapt, or maybe this isn't the right method and I need to rethink what method. So make sure that you're adapting to what the problem is that you're needing to tackle now.

Dave: 15:43

I really like that because I think we were kind of closing it out on some of that and that realization that we need to be adaptable and it's peer-to-peer right. So it's not, you know, one methodology is better or worse than the other. It depends on the situation, on what we're dealing with, and the organizations and the teams that can smoothly transition from one to the other based on context, based on what they need to achieve, are definitely going to outperform the sort of superstars in one form or the other.

Peter: 16:11

Yeah, and when you want to figure that out, then just call Zodiac on increment one and we'll come along and help you figure it out.

Dave: 16:18

An excellent plug put in at the end. Yes, absolutely.

Peter: 16:21

Yeah, awesome, okay Well, thank you as always there. Yes, absolutely, yeah, yeah, awesome, okay Well, thank you as always, dave, it's always a pleasure.

Dave: 16:26

On that note, all I'd say is subscribe if you liked what we're talking about, so you can keep in touch and feel free to send comments or questions in at comment at feedback@ definitelymaybeagile. com.

Peter: 16:38

Thank you. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.