Handling dependencies

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 May Be Agile with your hosts, Peter Madison and David Shark. So, how are you today, Dave?

Brilliantly well. Thank you very much. And uh it sounds like both of us are full of energy, which means we've been avoiding what this week, do you think?

Oh well, I I wonder. I think maybe it's just too much caffeine in my case.

I was wondering if it's just we've been avoiding those tough conversations around dependency management and how we've maybe got all of our processes handling dependencies really, really well, perhaps.

Oh, yes, of course, of course we do. They just handle them perfectly. I mean, I've got I've got no dependency, so I've decoupled everything in my entire system so that I can operate completely independently of every other part of the organization. And uh everything I do has no impact on anybody else. It's fantastic.

So we shouldn't talk about the 15 minutes we've just spent getting our systems up and running just to record the podcast. No, no, we probably should avoid that topic. Handling dependencies. It's getting getting closer to the topic. This is uh close to, I think, any um kind of delivery or execution uh um consultant's heart in the sense that that we know there's going to be dependencies. We do lots of things to try and avoid them, but we're gonna have to do something about handling dependencies. What have you learned in terms of good practices to handle dependencies?

So one of one of the biggest pieces is uh, as we were talking about earlier, like admitting that they're there, having the conversation and the open conversation around, hey, what am I gonna need to do in order to be able to get this done? Who's gonna need to be involved? Do I have an understanding of who are all the stakeholders in the delivery of this system? Uh and are we actually bringing them together to have that conversation? Because we know that when we have these dependencies, at some point we are gonna have to make some decisions uh based on those dependencies as to do we do A first or do we do B first? Uh do we decide which things are we gonna need to focus on? So that's one aspect of dependencies. Another aspect of it is uh have we had the conversation to understand that uh if I make a change now, what impact will that have on you? If I if I make this, uh for example, uh talking to a client uh just yesterday about from an organizational perspective, making this technical change would appear to be the right thing to do because it solves a particular technical problem. But from the part of the organization that would have to update all the documentation and educate all of the customers and do all those pieces, they don't have the resources to do that right now. Uh, if we balance these two pieces and look at which one should we do, it becomes a little clearer to say it's not so cut and dried. I've got to understand the dependencies between across the entire system to decide what should I do.

But can I I I I think you've just described a huge range of space within which you can look at dependencies. And I want to narrow this conversation down a little.

Okay.

Uh, because there's there's a planning aspect, right? The time horizon of if I make this change, what impact does it have downstream? Are we going to be able to support that change and so on? I see that much more about planning consequences of making changes to the system. So let's not look at those time horizons which are which are long, if if that makes sense. One of the keys to handling dependencies that I like to focus teams on is the currency state, the look at let's worry about what's right in front of us, not what may or may not be in front of us in a few weeks' time, a few months' time, if we make this, this, and this change, just because that very quickly becomes a fool's errand. So the focus, the ability to focus conversation on the immediate dependencies across teams or systems or or business to IT, whatever that might be, that currency becomes a really powerful lens, first of all, to focus the conversation, but also a filter to take out what I would refer to as those planning or those consequences, the dependencies around consequences, which are a different beast, versus handling the dependency of execution or implementation, which is typically a right now problem.

Yeah. And then uh when I was describing that uh that talent, the dependency there was that if we take this action right now, then we're gonna break another part of the system. Uh, the there's uh the the Yagni out of XP, is this so you ain't gonna need it. Understanding that have we properly looked at the scope of this? Uh are we properly understanding that? That's uh I think another key component you're describing there.

Yeah, it's it's interesting that I was just uh chatting to a colleague who's comes off of working with um Amazon for the last six years. And what was uh I was trying to understand how how they approach uh the the pressure situation when something isn't going right. And bearing in mind there are many large organizations and they have lots of different ways of looking at it. One of the things that became really interesting is the conversations that he had experienced were focused on the YAGNI bit, immediately going down, not to not to execution, why haven't you done this yet? And you know, can we cut this corner or that corner or whatever it might be, which I think is other organizations might spend more time on, but go straight to the product manager to say what's in scope, what's out of scope, and why is this in scope? And why is why is that really necessary, or can we, you know, so the whole thing becomes a product manager scoping conversation, which is again, if you look at that dependencies and in terms of immediate consequences, that's a really healthy way of saying, hey, let's not look at this from a how are we going to wrangle this over the line and look at it from a perspective of how do we simplify this? So this dependency problem reduces until we're looking at something which we can simplify and understand and actually go and clean up.

Yeah, and I and I like that simplify lens. I mean, it's this how do we take this to what is it we actually need to do? Because once we understand that, we can then more easily manage the dependencies because we've got a much smaller scope. We've got we can start to say, okay, it's like what if this is what I really truly need to actually get done, I I it's going to be much easier for me in that smaller space to be able to say what are the dependencies on this small piece versus trying to look at, well, everything I could possibly do, the domain of the possible, and which would then lead me to, well, I if I look at the domain of all the possible things that we possibly want to do in the next six months, and I look at all the dependencies that can be drawn from all of those things that I could possibly want to do, then I end up with a massive web of I'm now touching every part of the organization, uh, versus, hey, if I can focus, then maybe this is a good way to say, okay, my if I just do this piece, what is it that I need to have in place to make this piece happen?

I think you you mentioned a really good point, but you you're skipping around the the piece that makes it work, which is an understanding of priority. And I find it, I mean, this is something that I've spent uh several years now realizing more and more, and I think it's to the point now where I may well become a bore about it, in the sense that if you don't know your priorities, you can't do exactly what you just described, which is whittle down a complex kind of challenge into something which has a simplicity around it. So perhaps one of the first things for understanding or handling dependencies is having a very clear understanding of organizational priorities and then as they pertain to the product that you're working on.

And uh I think that piece of having that clear understanding of what I should prioritize against and how should I prioritize at the moment I need to make this decision? And having the so that clear visibility, and we we talk about this a lot. It's the like what what is the outcome that we want? Do we understand what are the things that we revalue and that we're aiming for? And that we're so I mean all of it ties back to that. It's like I need these pieces to be able to prioritize what I'm going for.

It's uh well and I'd also add, you know I mean you just mentioned it about you know it being visible, and sometimes we talk about it because we use visual language, but we find out that what we're actually doing is going into a meeting with maybe a few bullet points of text, but no visual representation of what the dependencies might be. So another piece to this whole conversation, if you like, is is being able to visualize when different stories impact on other stories, when different deliverables impact on other deliverables, or when different um decisions how they impact other pieces. So and there is no there's no hard and fast rule on what that visualization might look like. We all have our favorite ideas or favorite methods that we use, but uh it is so much easier to have a conversation around a clear visual of what the challenges are than it is to talk about you know JIRA tickets or uh line items in a spreadsheet, which is just not you know that there are too many assumptions, too many implicit uh um information that we too much implicit information that each of us individually are bringing, so we can't have a reasonable conversation there.

Yeah, I remember uh a member of my my staff uh years ago who came into my office, he was uh and back in the days I actually had an office, but the uh he was absolutely furious and quite red in the face, and he's like, I've been having this yeah, this screaming match with this other member of star, and we haven't been able to get to agreement, he can't understand it, he doesn't understand what I'm trying to explain. There's all these dependencies all throughout the and I said, Well, did you draw him a picture? Exactly, exactly. It's uh yeah, a picture is worth a thousand words is not used often enough. It's uh too often we too often we talk even using visual language and we describe things to each other. Um and I I I find that in this medium when we're very much uh in video calls all the time, uh it gets even worse where you're on a video call and everyone's talking back and forth and but nobody's like the can you just give me a picture? Can you just show me what this looks like? Uh so that we're all on the same page as to um what it is that we're talking about, so that we're we understand each other and we and if we draw something and it's wrong, that's fine. But now at least that gives us a starting point to say, okay, well, what does it look like?

Yeah, I I would add, and and I think there is a danger sometimes that I draw my picture. And if anybody's played Pictionary, we all know this one. We all try and draw whatever it is, and we try and get other people to interpret it, and of course it becomes a hilarious parlour game, but absolutely not a great conversation in a decision-making uh discussion. So I'd point that those pictures need to be co-created so that we're, you know, a number of people, stakeholders in that conversation are adding their own details, their own interpretation. So now you're getting a picture of sort of a combined view rather than my perspective versus everybody else's perspective.

Yeah, the the biggest organizational example of that I've typically seen is the ARB, the art architecture review board, where you have to, in a large organization, prepare a 20-page deck with all of these pictures and images in it, and you send it to the board that looks at it and they scratch their heads and go, Well, this doesn't make sense.

And it's like, well, you didn't help I I know the ARB, ARB is one of your favorite uh meetings. I do know that from many conversations with you. Yes, yes.

Tear it down.

Now, if we look at you know, from in the handling uh dependencies, at some point you're going to end up having a conversation or a meeting around dependencies. And um, whether it's you know some sort of of review conversation or whether it's a scrum of scrums or some teams depend deliver uh developer-to-developer conversation. Um one of the things that I always want to inject before those conversations happen, uh, and I'd like your insight into this one, Peter, is the the importance of using technology, of using your systems to manage dependencies as much as possible. And the classic one is is you know, microservices APIs, any sort of service interface that allows you to determine whether or not those dependencies are being met or not met generally. Uh, but there are a lot of other things that you can use around that technology or around you know heuristics or or built-in rules that would guide those conversations. What have you seen in that area?

So exactly as you say, around if we you can describe it as a service contract, but if you think of anything that's delivered from one area to another, there's there's this description of what it is that is expected when we move from here to here. And this comes up a lot when we start to think about how do you apply, say, lean practices, or or if we look at Kenban and we say, okay, what is it, what is the definition of ready, what is the definition of this being prepared to go to this next piece? What is the contract between these different areas? And I'm purposefully pulling a lot of similar ideas from different methods here to describe that this idea of um what is my my point at which I know that this thing is prepared for this other piece? And we're doing the same thing with an API. And you run into these problems too, though, that if we're not aligned as an organization as to what happens when I change, then you do still run into problems. There's a conversation from my uh from uh one of our customers uh recently where they they did this integration, they all agreed on what things should be, everybody laid it all out. Uh two weeks later, everything blew up. And uh when they came back together, what was going on, and one of the groups with all of these dependencies said, Well, yeah, well, I changed my API. It's like, great, did you tell anyone? Like, did you consider that everybody else was connecting to your if you didn't?

So it's I I like what you're saying there in the sense that um I have in the back of my mind, and when we're making notes for this, I mentioned it, is that uh we often think of handling dependencies as being a conversation. We need to have a conversation. There are dependencies between different parties, let's talk about them and figure out what we need to do. We can use priorities to make decisions, we need some visual thing that would allow us to have a good conversation. In the back of my mind, every time you hit that conversation, in the back of my mind, I'm seeing that as a failure of technical or process-driven management of dependencies. Now, not to say there's anything wrong with the conversation, but exactly to your point, it means hold on, is it, first of all, did we do everything we should have done? Did we follow the technical process guidelines for making changes to an API or for whatever it might be defining, you know, the next generation of X, Y, and Z? If we didn't, that conversation can end really quickly because we can go back and re-redo those steps. Or if we did and they didn't work, we can revise those steps. But it feels like there's always that piece first as part of that conversation. Why are we even having this discussion? Is there not some way that we could have captured this or removed the necessity for this because we had really good structure in place that would allow that uh to become obvious?

An interesting uh way of describing that is what assumptions am I having to make for this to be true? If I look at how I'm managing those dependencies.

And how can I make those assumptions more explicit? So maybe I can look them up or I can find them described somewhere. So all of a sudden, you know, we don't have to make assumptions and try things out and have this meeting. We can go and check them because they're explicit and we can build against them and do whatever we need. Yeah, great point.

So if we if we look at like how we would wrap this up, I know we've covered a lot of ground and uh I was rambling on about all some of the recent dependencies I've seen in some of my work. And uh uh what what points would you sum this up for our audience?

I'm drawn to the the beginning of the conversation. We've first of all focused on, well, focus, currency, the the the sort of horizon over which we're looking at a problem. I think that's really critical because otherwise we can end up um being drawn up and down that sort of time horizon and mixing the conversations that we need to have. Uh putting that to one side, I feel like there are sort of three things that we really need to have in place in order to handle converse uh dependencies, have the right conversations. One of them is if we don't have priorities, we can't make trade-off decisions. So we need to understand the priorities and how they impact what we're discussing. Number two is we need a visual representation, something that's co-created, something that we share, we understand, we probably modify and update in some way. Um, and number three, while we're having that discussion, we want to be continually updating those technical rules or the process rules that that should manage a lot of these dependencies on our our behalf. So that we're we're recognizing that that that conversation is incredibly important. We do need a conversation to handle dependencies, but it should be in the sense of starting that conversation to say, is there something we could have done to prevent this? Is there an implicit assumption, as you pointed out, that we need to make explicit so that this conversation doesn't actually have to happen?

I think that uh brings it together nicely. Uh it's uh um so with that. I mean, if we want to talk about handling dependencies, do you think we've we've covered everything we want to cover?

I think there's enough there to pull it together. I I think there's more to be discussed when we look at those longer-term ones. Maybe that's a separate conversation because those consequences of decisions that are made today or in the near future, we definitely need to address. But I think for handling dependencies on a sort of, you know, for the the teams right now, in terms of what they're executing now, we've kind of covered it.

Yeah, the here and now of handling dependencies. I like that. It's good. So uh thank you very much, Dave. It's uh it's always a great conversation, always enjoy these. And if anybody'd like to reach out to us, they can find us at feedback@ definitely maybeagile.com. Until next time. Until next time. Thanks. 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.