Peter and Dave discuss capacity planning in transitional organizations, emphasizing a balanced mix of agile and traditional project management. Key points include the importance of due diligence, blending different methodologies, prioritizing tasks aligned with organizational goals, and strategically sequencing improvements for continuous enhancement.
Following on from episode 115, today's episode, Peter and Dave delve into the complexities of capacity planning in organizations undergoing transitions, emphasizing the need for a balanced approach that incorporates agile principles and traditional project management practices. They stress the importance of due diligence, the interface between different methodologies, and the necessity of prioritizing improvements to achieve a more agile and efficient workflow.
This week's takeaways:
For collaboration or feedback on our ebook, contact us at feedback@definitelymaybeagile.com. Be sure to subscribe, spread the word to a friend, and join our engaging conversations. Who knows? You might just be our next podcast guest as we continue to explore the rich tapestry of agile transformation.
Peter: 0:05
Welcome to Definitely Navy Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello.
Dave: 0:14
Peter, good to be catching up yet again and having a conversation Now. We promise to kind of follow up a little bit. I think the last conversation we had was all about capacity in, I would argue. So I think, somewhat ideal well, not idealized, but high performing, high functioning, agile organization, predictable capacity on teams, things like that.
Peter: 0:38
Yeah, it's kind of, and we, although we touched on like what are the prerequisite, like what you need to see, we didn't really touch on like what happens if you don't have that, and so that's kind of the yeah, that's the other half of the audience, if not more than half, right? The other 80% of the audience Parade is 80, 20.
Dave: 1:00
So I'll let you take the lead on this one, because I think I kind of ran off with the lead between my teeth last time.
Peter: 1:07
Oh, I don't know. Well, this is a common problem. If you don't have stable teams, or at least you don't have teams that are cross functional, due to a variety of reasons, the most common of which is agile only exists in technology, and the rest of the organization operates in a waterfall fashion, and so they have waterfall methods by which they determine what work needs to be done, and the marketing already has their three year roadmap. They've already laid out everything that's going to happen over the next three years, and they're telling technology what technology needs to deliver. So now technology has got to respond to that.
Dave: 1:42
So Well, they're being asked how much money is it going to cost? How many people? And so now, how do we commit to a committed multi quarter, multi year roadmap? Yeah, if we know there's a bunch of emergent stuff that is bound to come up.
Peter: 1:59
Exactly, it's the how many people are you going to need on the 30th of November, two years from now? And he's like well, I don't know. So the end if from our previous conversation, if we don't have stable agile teams, I think actually in that instance, even if you have stable agile teams, the answering that question does come difficult because of some of the reasons we were talking about last time. But if you don't have that cross organizational transparency across those barriers, it becomes difficult to get people to buy into what needs to happen.
Dave: 2:39
But I was going to say I think a part of this is a trust issue, and I don't want to kind of paint the picture that nobody trusts one another. But we made a very clear statement in the last conversation that if you have a functioning agile team it's small, it's dedicated, it's cross functional, it's working on a single product and so on you can kind of take their capacity, their commitments to the bank right. There's a confidence in where they're going. But if you're in a world where maybe it's just incredibly dynamic and everybody's changing their mind all the time or you're pulling people backwards and forwards off the teams, so the teams aren't predictable, there isn't confidence in knowing where the teams are going. This is naturally going to raise a lot of questions about capacity. What I think is important for us to recognize here and I think both you and I both view this the same way, peter which is stop relying on agile and coaching. You've got to go do some due diligence and roll your sleeves up and don't look at the sort of work that's being delivered or expected to be delivered and what skill sets. And so that whole conversation about understanding what types of work will be done and trying to figure out how much of the work is driven by, say, business analysts or driven by marketing, or driven by different technology groups and so on. And in an agile context, we stay way above that and just say, hey, we've got teams here, let's just use that. Whereas actually now we have to get a hands dirty and shift from a coaching stance I would argue from a coaching stance to a consulting stance. Roll our sleeves up, get a spreadsheet out and really begin understanding what the needs are.
Peter: 4:18
Yeah, what is the work? Where is the work coming from? What's driving that work? How does it get done? Who needs? What skill sets are required to deliver that work? What are, what is the underlying systems and technical architecture needed to support it? And where are those pieces? How are they interconnected? And then we can talk about how are the teams organized around that? And we need to understand all of that to be able to think about how does work get delivered to really start to be able to answer the door or even attempt to answer the capacity question.
Dave: 4:46
Oh, and it's interesting. So this is where where I think there's a lot of uncertainty in the in the industry at the moment, because, honestly, if you go talk to an agile coach, they're going to tell you one thing, and if you talk to a project manager, program manager or kind of traditional consultant, they're going to tell you a different thing. And then there's all the papers that say you need one foot in each camp, which is confusing again. And I think to your point about how are you going to get the work delivered. That's the question to look at. Are you, is the organization in the process of really shifting towards dedicated teams? In which case, lead that one with an agile kind of view lens to the conversation. So when you're looking at how the work is going to get delivered, you're going to be forming teams, you're going to strengthen that team capability. You're going to be looking at bringing business and IT closer together, recognizing that there are emergent needs we don't have in the roadmap. So that three year roadmap is going to tweet. Tweet can change a whole bunch of things that come together with that. I still think, and I still think you need to do the due diligence of understanding what's there, so you're making the right, you know, requests for recruitment or whatever it might be, for skills you're. You're kind of looking I always think of this as time horizon. You look over the next three months, six months or so, and you are transitioning, but in those three to six months you're going to have to do, you know, have to sit down and really plan it quite closely.
Peter: 6:12
Yes, yeah, I mean the. That shift is very interesting and part of the. I think one of the pieces that I find people get caught up in is and this might sound like a bit of a trope at this point, but it's the agile. For agile sake. It's like well, I've rolled out scrum everywhere, I've got everybody putting tickets into JIRA, so therefore it must be agile and everything's working. And they're missing that underlying point, which is how do I get delivery out faster? How do I actually start to operate faster? How do I find out as quickly as possible that I have a problem? The whole point of this is that we know that the world is going fast. We know there are far more. There are changes happening much more rapidly, so we need to be able to learn so we can respond to have worked on smaller pieces, we need to be able to, but we also need to be willing to learn from that, and a lot of that can get lost in all of the rest of the noise around it. The taking a step back, a second, one of the pieces that I've commonly, commonly seen and had to advise and this is not an agile thing. I never think I've talked about it, but when you hear I've got, I've got work coming from multiple different directions. I've got lots and lots of stakeholders across the organization that are driving work into different parts of my organization, the different layers in different places, and that one of the first things you could do there is to say, okay, like let's get those people together to create a common understanding of what is all of the different work and where it's all coming from, so we can start to think about what are the ways that we take work into the organization? What does that look like? How do we sort of, how do we manage that? Before you get to the stage of like right sizing it or thinking about where are there, what the teams are that can deliver it, and then forming the teams around that you need, because that really gives you that air cover and it's the piece to be able to say we're not, we've got to work on how we're going to move this out.
Dave: 8:15
I think of this as the agility in the DevOps space that you and I both work in, but it's growing up in that space, it's stepping out into, and one of the things we're coming across a lot now is the interface between traditional project management, which is not going away and it's still necessary and important on major whatever infrastructure changes or system changes and so on, coupled with the sort of agile mindset which has so much to bring to it. But it's not an either or thing, and I think that's where it's a case of understanding small batch sizes, shorter feedback cycles, building and integrating frequently All of these principles that we lean on all the time, dovetailing that with enough of the right documentation, actually planning things out and managing things which you can't manage in the short cycles that maybe agile teams are working with, that they span multiple cycles, so you're going to have to go manage those in different ways. So there's a lot we can learn from both sides, which is why, when I look at this, it isn't or both sides, both approaches, and what I'm seeing more and more is that bit about capacity management, when we step away from sort of credible, confident, agile teams that we really understand and can work with into the sort of transitional states. You need to bring both muscles out right. You've got to use your agile thinking and mindset and approaches, but combine that with that due diligence and making sure you've got the details. And then and also and I think this is the important bit is where are you trying to get to? Is it a transition and trying to get out the other end to be more agile, et cetera, et cetera the bits that we normally talk about in digital transformation or is that going to be the way of working for a while, which is more of a mix?
Peter: 10:07
Right, right which.
Dave: 10:08
I do not. I mean I hate that whole hybrid conversation or a bit, but there is the reality that there's a zone where both things are happening at the same time. How on earth do you straddle that? How do you cross that safely?
Peter: 10:23
I think there's this piece of well, are we getting better yet? It's the. What are we introducing change? It's back to that same thing. Is that, are we putting the pieces in place that are helping us improve and how do we know if they are? It's kind of like what are the? So that we're constantly looking at as we look at, how do we prioritize as an organization? Well, I was running workshops last week on this, so it's kind of top of the mind at the moment because I'm also looking at how do I translate that into a view of the world. But it's the. How do we build a structure for this organization to prioritize what work it's going to focus on next in a better, more holistic fashion, so that we're bringing everybody's point of view to the table, and so running through that and using things like customer journeys and understanding what that looks like, looking at moving towards using things like user story mapping but that's kind of a future state of it. The first part of it is okay. Do we all agree where the problems are? Which of those problems do we think it's going to be most beneficial to try and tackle first? Okay, let's go tackle them now. Okay, now let's think about everything else needs to go around about who's going to do it, who's going to drive it. What's that going to look like?
Dave: 11:38
Right, yeah, and if I bring this back to our capacity conversation, that's where we start really doing that due diligence of breaking things down. Going now we know Exactly what's the problem. We're not trying to do capacity planning for every single idea that's been thrown on the table. We're going to do this just enough, just in time, and focus on, you know, 2024 or the first six months. What are the things we have to move and deliver? And then we'll have a look, and some of that will be done in an agile way and some of it will be transitioning and some of it we're just going to. We know how it works. We don't want to boat. We're going to keep going in that direction. And I think those are the conversations which sometimes get difficult, because everybody's trying to ask for a different thing. Yeah, and I think I totally appreciate where you're coming from when you're saying start off with what it is that you're trying to achieve, get that priority aligned and agreed, then the work that gets done. Now you can often clear the air and really say you know, how are we going to do the capacity planning around this? And as you kind of work through that, you can then end up with that if this is our capacity plan, what does that leave off the table that we thought we were going to be doing and start addressing some of that.
Peter: 12:45
One of the pieces that I thought was really good that one of the other coaches that I was working with running these workshops used was the. This doesn't mean that all the rest of this stuff isn't going to happen. It just means we're going to focus on this one first. So the reassurance that there's all of this other.
Dave: 13:02
I was going to say I'd take a very different approach, but that's probably a way better one.
Peter: 13:08
It's like you will get your other toys at some point.
Dave: 13:13
Yeah, and I mean, isn't that the yes and we don't? There's no point starting this right now. So let's just pull back a bit, Because if we don't start it right now and we focus on what's in front of us, we will get to start that sooner and get to deliver it sooner, and then because focus is critical, and then it's yeah, so that takes us down that path, which is which is really good.
Peter: 13:32
So do you think we covered the subject of this podcast today? I think we focus.
Dave: 13:37
Actually, it's one of I really enjoy these conversations because we kind of it was far reaching and jumped around a lot, but I also think we touched on some really important topics which is that sort of transitional state where we're not in this sort of the upper 25%, the upper quartile of agile delivery organizations and we're a little bit below that just now. In transitioning. Then we need to do both things. We need to do our due diligence, we need to understand priorities, as we do in both cases, but also kind of understand the work is good. We don't have to transition all of it. We have some stuff which has done the way we've always done it. We're going to have some things which we're going to use this as an opportunity to transition to a new way of working, whatever that might be, and that one will have to explore a little how that estimation and capacity management is taken care of. Things like that. Yes.
Peter: 14:27
Yeah, exactly, and there was some good learnings around there. Like it's not one and done, and starting with the understanding that you've got to start this, your first attempt might be a catastrophic failure hopefully not, but you've got to.
Dave: 14:43
Well, I just want to pick. That's absolutely true and this is something we've got to bear in mind. This is that we are on the boundary between people who understand agile is about learning. So you're going to make things won't work the way we thought they would. We'll think about it and change a few things and they'll be continually better. And then we're working alongside other people who the idea of having a plan that then fails to deliver what was on the plan is just not something they can entertain. So, to your point of that, setting the scene, helping people understand it's going to get better, and this is not necessarily going to be as pain free and and you know several significant digits accurate in terms of what we're going to make a commitment to yes exactly.
Peter: 15:27
It takes time. Experience actually takes experience. Yes, come to the time.
Dave: 15:31
Yes, there isn't a blue pill that allows you to gain all the experience in one go, right? So?
Peter: 15:36
yeah, unfortunately not, unfortunately not. Well, thank you, Dave. There's a fascinating conversation, as always, and I really appreciated it, and so, wrapping up today, we'll say don't forget to subscribe and subscribe.
Dave: 15:50
Refer a friend. Raise some questions or comments that feedback@definitelymaybeagile.com
Peter: 15:56
Come join us on here and we're happy to chat as well.
Dave: 16:00
Right, we're looking for a few more guests, aren't we? So that would be good too.
Peter: 16:03
Yeah, awesome, until next time. 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.
