Portfolio Level Management

In this week's episode, Dave and Peter discuss Portfolio Level Management.  Key decisions are made at every level of your organization, aligning these and managing the larger scale initiatives can be a challenge. 

This week takeaway:

• Fractal nature of work at different levels
• Make work visible
• Follow the decision-making

References in this episode:
Klaus Leopold Practical Kanban — https://www.goodreads.com/book/show/36592352-practical-kanban

Flight Levels — https://www.leanability.com/en/blog-en/2017/04/flight-levels-the-organizational-improvement-levels/


We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com 

Transcript

Peter: 0:03

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 and welcome to another exciting episode of Definitely Maybe Agile with your hosts Peter Maddison and David Sharrock, and today we're going to be talking about all sorts of interesting things related. I think we decided on Portfolio Level Management. So, Dave, would you like to kick us off on this topic?

Dave: 0:29

It's definitely an interesting topic and one that's fraught with a lot of preconceptions coming in, because it's really where the key decisions get made. If you're a stakeholder, you want to see what's going on at the portfolio level. If you're a project manager or somebody who's responsible for delivery, program delivery, whatever it is you obviously want input from there. And yet, as we know, when we're working in emergent agile type of environments, the portfolio is where you're going to see that change coming through. There are options to move backwards and forwards depending on sort of what's going on, where the dependencies are, what slows you down, what speeds you up and what the customers need. So it's sort of where the rubber hits the road in many ways.

Dave: 1:16

What I really like about Agile and how it is applied is the way I think of it is almost a fractal nature of the work. So what we do at a sprint level or at a delivery team level in terms of the work, how we break it down, how we plan it, how we order it and decide what to do and what to maybe wait on doing, how we manage the work in terms of working progress and limiting that work in progress, and things like this all of those operate at the portfolio level in pretty much an identical way, just with larger elements, that sort of instead of dealing with user stories or tasks, we're now dealing with epics or initiatives or programs. But all of the same practices and mindset and approach applies, just at a different scale and speed.

Dave: 2:07

There's a different speed, absolutely yes, that's right cadence and scale and speed.

Peter: 2:12

Sorry, yeah, one of the models I I've quite liked um around this is, uh, klaus leopold's flight levels, where he talks about um three levels to the organization, organization. It's almost a way of scaling Kanban up through the organization, this idea that you have at level one it's the operational scale, level two is coordination and level three is the strategy layer. And so you're sort of taking your flow and you're looking at it at these different levels and ensuring that the right conversations are having and that your right dependencies and interconnects are occurring between the different pieces of these different levels and ensuring that the right conversations are having and that you write dependencies and interconnects occurring between the different pieces of those different levels. Have you run into that one yourself?

Dave: 2:52

Yeah, I mean, I think it's a really nice articulation of exactly that challenge, which is whenever, whether using the flight levels model or you know something very similar to that, and another, one sort of a guiding principle behind that is the five levels of planning that you get from extreme programming.

Dave: 3:10

It's that same idea. We've got different levels and if I take that fractal geometry, the self similar from each level, um, the behaviors and the practices are pretty much identical. But the three things that you're looking at like you said yourself, cadence speed comes in the artifacts that you're dealing with obviously grow as you go further up those levels and also the people involved in terms of they don't tend to be the same ones at every single level because you know the scope of the decisions that are being made changes as you go from level to level. But once you have that in place and an understanding of it, then really all you have to look at is the handoff from one level to the next in terms of what are the artifacts? What are those artifacts that bridge one level and guide the influence at the next level or guide the activity at the next level?

Peter: 3:57

I find a lot of organizations struggle with that piece where they're trying to look at going as they like to, as they look at how am I going to scale this up? They focus so much on how do we implement these practices at the team level and then fall back into very standardized, known patterns as they go further up the organization, which is, in turn, what means they don't end up with a lot of the benefits that they were actually hoping to get out of the changes they were introducing in the first place.

Dave: 4:27

I love the way you've described that, because this is where we have Agile at the team level and there's lots of flexibility there. But then you still have the steering codes and you still have the committee driving prioritization and determining funding models or whatever it might be. And I think you're absolutely correct. You lose the flexibility that you get at the team level. There's maybe not a realization that you can get that same thing across a department or an organization or a product portfolio if you're able to keep those same practices going up, but instead what we do is we kind of rein in and just, you know, only take the operational level out and change that and we don't change everything before it above it. We're not going to see those same benefits.

Peter: 5:13

Yeah, and I like you mentioned the before and above it. It's one thing to talk about the going up, but there's also this going out. It's not just about technology. It cannot just be technology adopting and understanding these practices. We need to look at the end-to-end system. We need to look at everything in the other departments, the other supporting functions, the other parts of the organization which are required in order to deliver value, and if we find ourselves optimizing in just one place, we end up with local optimization and a lot of focus in the wrong places. So that's a common piece. So where would you recommend an organization who's got to the point where they feel they've got as far as they possibly can with the team? They've shown some initial successes and they're looking to scale that up and start to look at the next layers up and start to look at how do I actually track this in such a way that I'm changing the thinking higher up the organization and we're starting to track the portfolio in a more agile fashion.

Dave: 6:13

A great question. So obviously you're doing this, I'm sure with a number of clients as well, and I'm in the process of doing this with a few at the minute. One of the first things is map what's going on. It's a little bit like don't try and change anything until you understand it. So the first goal, if you like once that operational level, the teams are kind of getting the hang of it is let's see, let's make the work visible that's coming in, that's already been committed, that's been prioritized and it's being discussed at these higher level conversations, because if you start disrupting that, the impact is going to come back at you pretty fast. So you'd better have a map for that. I think that's one part of it that comes in very, very quickly. I think the second part is don't try and rock the boat for what's already in the pipeline. And so I almost feel like I've just been near the office where I'm working.

Dave: 7:03

Here. They've been replacing a bridge over a road, a road bridge over a stream, a river bed here, and what's been interesting is one of the first things they did is they kind of just sort of guided all the water through a single channel so that they were able to work outside of where that channel of water is and in some sense that's a little bit that what you end up doing with that portfolio piece is you you don't try and stop that flow of work coming through, because if you stop that all sorts of alarm bells go off. But you do want to channel it and start throttling it down. So maybe you reduce the flow of work through there so that work is still being seen, people can relax and see it. But we can start looking upstream to say, are there better decision mechanisms that we need to put in place? How can we talk about prioritization or definition or whatever? It might be a little upstream.

Dave: 7:52

So that's sort of that second piece, once you've got some visualization of it, is trying to throttle that flow a little bit to get good practices upstream, and then you can look at the whole and the final piece piece in three steps if you like, or the three movements then becomes how can I increase the flow again so that downstream and upstream starts really coming together and working smoothly? But that one is sort of the later on after the first two. What would you add to that?

Peter: 8:22

yes, it's, the cadence is a is very much a part of because you're moving at a different speed and it's this, this whole um run slow to run fast. As a runner myself, it's uh, you notice the differences you? There's this kind of this idea. I've got to push as much through the system as I possibly can. So there's awful lot of learning that needs to occur at every level, and we can sometimes we can get that learning in a low because it's moving faster. It's easier to start to see results faster too.

Peter: 8:51

As you move up the level, it can be harder for the organization to realize that. Well, actually, by starting these, all of these additional initiatives without understanding what the impact and the capacity in the system is, then you, now you're just overloading the system even more and, uh, there's often this disconnect I've found between oh so we've and you've probably heard this too it's like, oh so we've adopted Agile. That means we can now pile more stuff in. But it's this understanding. Well, really, all that's done is it's allowed us to get visibility. It means that we now have a better understanding of our capacity and our demand. We can start to look at them, experimenting and seeing what happens when we introduce new things into the system. It isn't an excuse to say, ok, well, here's another 15 projects I've always wanted to do, that I'm going to pile right into the system, and so it is important to start to look at this throughout.

Dave: 9:44

Yeah, I found because one of the things that really drives a lot of those conversations and can be kind of that rake in the grass that you step on and suddenly stops your movement going forward is a lack of stratification between the different levels. When you've got people from one level interjecting and overseeing and imposing their desires and priorities and needs at other levels, that becomes really really difficult. There needs to be some level of stratification and so the cadence becomes super important because the stratification allows us for the next level up. If the cadence is too long, they will dive in and interject because they have to. They have responsibilities further up that they have to meet, so they have to see progress. So that cadence has to be quick enough that they're seeing progress so they can sort of step back and stop getting involved at that level. And this is that stratification and really separation of roles and scope of decision-making rights, if you like, becomes really quite important. I think in many situations.

Peter: 10:56

We've touched on this a few times, and the importance is something that actually is one of the first questions that I ask as I start to come into organizations and assess where they're at around. Well, how do you make decisions? How do you decide what's going to happen next, how, if something happens, depending on the area of the organization we're working in, how is that then resolved? Where does it go to? Who makes those decisions? And that will often give you some guidance as to how the organization is structured and how they're thinking and where they go. So it's like, hey, if an architectural change is required, if the response is that it needs to go through two architectural boards and then up to the CEO for approval, it gives you some insights into, probably, the pace of change at the organization, if nothing else, but it gives you an idea of some of the areas that you're probably going to need to start to focus and have some conversations around.

Dave: 11:52

Well, and I think it's important to recognize that. I was on a phone call earlier this morning just chatting about a leadership team and the two things come out. One is they need visibility. It's a case of you know, in order to do your job well, you need to have your finger on the pulse. You need to know what's going on. So, even with that stratification that we're describing one of the things we have to recognize by making work visible. We need to help them see what's going on so that if they're asked probing questions, they can immediately and quickly find out what's going on, communicate that easily with that information and I think that sometimes gets forgotten.

Dave: 12:31

We try and shut the door on them and say you're not allowed in this conversation. Well, it may be that their influence is different because they're now a stakeholder rather than a decision maker. However, they need to be able to see what's going on. But then the other one is what do they do? Because if I'm high up in a hierarchy and every decision comes across my desk and if, even if, I can see the results of those decisions, I can see what they are, but now None of those decisions come across my desk, needing my signature, if you like. What is my role? How do I take responsibility for the performance of that group that I'm responsible for, and I think that's a question that people often ignore back to something we've talked about before, which is that the David Fox scarf model.

Peter: 13:26

So this whole point of you're impacting people's status, you're impacting what they may identify with, and a lot of leaders do.

Peter: 13:35

I mean, if you've, if you've got to the position you're in by getting things done and the way you got things done was by telling people what it is that they had to do.

Peter: 13:42

If you now are being told, well, actually, we don't need you to make those decisions anymore, you're directly impacting who that person may think of themselves as, and so there has to be the right structures and support in place to help them through that transition. If it's the transition that you're looking to generate, and then that also is another part of it there has to be understanding that this is what we're doing and this is why we're doing it, and these are the benefits we're looking for out of that, and there is actually an awful lot of the work that's not done that you will now have time to do, because you shouldn't have really necessarily been the ones making those decisions anyway, but we never really want to quite phrase it that way, perhaps, but it's this. We're never really want to quite phrase it that way, perhaps, but it's this we're setting you up to be much, much more successful and have much more influence over the direction of the organization. It's just, and it won't be, through necessarily making decisions for every little thing across your desk.

Dave: 14:39

Yeah, I think I'm, and one of the benefits, if you like, that's that first step of making the work visible is what making the work visible will very, very quickly do is identify dependencies, and those dependencies are often where people further up those levels do get involved in, because those dependencies are often misaligned expectations across departments or groups. It can be just investment that is required in infrastructure or systems or people or whatever it might be, and there's a number of things there which are really the bread and butter of those leaders further up the layers, if you like, that can really get their teeth in. They're tough problems to solve. It's not in any way inconsequential in any way inconsequential. However, until you can see the impact of those and you have a measure, because you can see how that impacts the flow of work through your portfolio, it's very difficult for us to have those conversations and really see the importance of those changes.

Peter: 15:39

Yeah, I completely agree. I think it's something we often miss and we definitely don't want to belittle. There's a lot of pressure on people at those levels to make these decisions and there are decisions that you are still going to need them to make. I mean, not everything is ever black and white. There are always pieces that are going to need to go up and have. Where somebody has more breadth of oversight of the organization, they might have more visibility into the system than you necessarily have, and that means that it might change the decision necessarily because of that sort of the broader site that you have. So we're coming up to our time here, so how would you like to sum this up with our three points for our listeners, dave?

Dave: 16:21

You know, we started right at the beginning talking about self-similarity and the fractal nature of how work gets done and how the portfolio level and Klaus's work on the flight levels within Kanban are all representations of this sort of fractal nature of how work is done in an organization and we jumped off of it very quickly.

Dave: 16:42

I think that's something to really understand and get our head around. That's number one for sure, and I haven't figured out how to kind of drill into that in more and more detail, but I think it's a kind of organizing principle that has a huge impact on portfolio work as it goes. Talked a little bit about how to address it. The second bit that really stood out to me, at least in the conversation, is that making work visible, the steps to making work visible and then beginning to use that visibility into the work to manage the flow of work and therefore start making some changes in the different levels within that sort of portfolio management piece. And then I think the third one is just that stratification and the roles that we've just been spending quite a bit of time talking about and the importance of helping people operate and influence at the right level within these levels so that they have visibility across the levels, but their kind of span of influence or control is well understood and articulated.

Peter: 17:46

I think that sums it up quite nicely. I think, if I was to add anything, it's around that looking at how and where decisions are made to help you identify where in the organization you are and where those are occurring at the different levels, because that will help you understand as well what those decision models need to look like, what those models of the different levels need to look like. So with that I think we're at time for today and, as always, I've really enjoyed the conversation, appreciated all the different places we've gone with it, and if anybody would like to reach out to us, they can reach us at feedback@definitelymaybeagile.com. We're always interested to hear what our listeners have to say. And with that, dave, any last words.

Dave: 18:29

Just again. Always a pleasure, and I kind of feel like we peeled the back, the top off of a Pandora's box on this one, so I'm sure we'll be back to drill into this a little bit more. Anyway, as before, give us some feedback, questions and so on, and we look forward to chatting to you again.

Peter: 18:48

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.