Ep. 115: Capacity Planning

Peter: 0:05

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, good to see you again, Peter.

‍Dave: 0:16

I think this is a dangerous conversation. We've just got off of a long weekend, or a good weekend. We're relaxed, full of energy. It's a Monday. What are we talking about?

Peter: 0:28

Capacity planning, and it's a favorite topic right, especially this time of year, because you've got what?

Dave: 0:34

was the year.

Peter: 0:35

Yeah, then it's like what's the plan for next year? I think this leads into road maps, but let's focus on the capacity planning piece of it, and I know you've got some very strong opinions on this, so I'm quite looking forward to this conversation.

Dave: 0:48

I have a lot of interesting conversations about this, where it's a very interesting question, because so many times it comes off of the back of we've spent three or six months. Everyone's created Agile teams. They're comfortable, they're seeing the Agile teams deliver, Everything's really good. And then all of a sudden it's this time of year and they have to plan for next year and they start thinking that they've got to be able to break all of that work down and they don't recognize they've already got a really, really good measure of what capacity they have, where the bottlenecks might be, by just looking at how the Agile teams are functioning, where the bottlenecks are, where the impediments and dependencies crop up and so on. So they've got all the raw materials. But what often happens is we end up back in spreadsheet situations. We look at every piece of work, we try and figure out how many hours, days, whatever contribution we're getting from different skills and it all of a sudden breaks down to people again instead of understanding the teams are already there and we've already got much of the data. We need.

Peter: 1:49

So the solution to capacity planning is create the teams first.

Dave: 1:53

Well, let's put it a slightly different way. Right when? How do I put this? We can either we're either going to handle every individual skill set individually, in which case you're in a resource managed world, or I have project managers and resource managers determining who works where. Now, that's a model that has worked and continues to work in some environments. If that's working and it's giving you what you need, then you know how to solve the resource capacity planning problem, right?

Peter: 2:21

Yeah, it's what I would call a work-centric view of the world, where we look at the work, we estimate the work, we say, oh, that's going to take four hours and Bert over there can do it.

Dave: 2:34

And we're optimizing delivery and we're optimizing cost by making sure that Bert spends four hours over there doing and then we pluck him from there and move him to another place where he can do his equivalently expensive role in another piece of the organization. And the reason we're chatting a little bit about this is both of us have worked in the industry long enough that we don't really rate that way of working because with the pace of change, that shift from work-centric to customer-centric means that we have to let go of that whole resource planning. You get better performance by stepping back and creating an environment where the teams can take care of much of that themselves.

Peter: 3:16

Yeah, I mean I totally agree, and that underlying piece of building the teams is not the focus that we're looking at at the moment, but there's a set of questions that always come up, and so I thought this might be an interesting way to approach this conversation, because we're looking at next year and we're thinking of that. Somebody said, okay, and we're going to withhold judgment on the whole, you just planned out the whole of the next year, even though you probably don't even know what's going to happen next quarter or next month, and so I wasn't going to go on the gay porn table. How many people do I need to deliver on what I've committed to?

Dave: 3:49

So I've seen this work so well and I'll talk a little bit about my experiences in this area. But here's, I think, one of the stumbling blocks, as you were saying that I was thinking, you know this is one of the big changes that we've seen and that is that agile teams aren't the agile teams of yesterday. So I think we've both had enough experience of working with, and we've been fortunate to work with, some solid, small, dedicated, cross-functional teams that are focused on a particular product, particular functionality that they're building, and they have predictability and they own their product and they're very kind of engaged and involved and focused on what they're building. As I look at more and more organizations today and this is that whole adoption curve we're at the tail end of that. That definition of an agile team is being watered down. They're dedicated, except for when they're not, and they're cross-functional except for these key roles which we can't possibly put on teams, and we know all of the reasons why it's not quite there. But what that means is, whereas in that previous example I was describing, you can kind of take the work that that team does, delivers to the bank, there's confidence that when the team says, this is what we can work on. You know it's going to come back and they're going to be pretty solid about what they can deliver, whereas I think so many of the teams nowadays certainly that I bump into are not set up for success. So they have good sprints, they have bad sprints, their predictability has a lot more sort of variance to it, and that causes lack of trust and credibility in their output, which means now how could I possibly use that for capacity planning?

Peter: 5:30

Well, that's loud, because I mean the trust erodes at the other side of that equation. But so to be able to let go, as you were describing, to be able to rely on the consistency of the teams and use that as your measure for determining the answer to the question of how many people do I need, you've got to be able to have some trust in the consistency of what those teams deliver. And I came up in a conversation today with one of the coaches on my team who was working with a client's team and that client's team was lead, was somewhat frustrated because they'd yet again rolled everything over to the next sprint. Nothing had got delivered out of what the initial initially had committed to, and so we're like we didn't actually live any of it.

Dave: 6:15

Well, and so now, how can you plan for next year? You can't. You don't have confidence in the team's ability to deliver. So we start looking elsewhere to come up with that capacity plan. And what I wanted to draw attention to is worked with organizations where they have a handful of teams, a dozen teams, 50 teams, whatever it is. They can look across those teams about what they can deliver. And there's a question there about how to look across teams to look at their total capacity, because everybody is estimating in subtly different ways. So there's a few problems to solve there still. But once you've got that solved, you've got this sort of you know, you know the capacity of that delivery capability give or take. Certainly, if you've got that credibility, you've got enough of an idea to be able to look at a strategic roadmap, to look at the amount of effort in there and tell within you know a reasonable amount whether or not you're needing extra teams or you don't need extra teams.

Peter: 7:09

Yeah, well, this is this comes down to. I mean, there's still an estimation on the how big is that work? And to understand that, we need to break it down into small enough chunks that we can understand it well enough to be able to do that estimation, and so there's a piece there that needs to be done. I think there's another element where people go almost too far in that they try to break it down into too much granularity and then at that point you've run into another set of problems, which is I'm spending all of my time estimating and none of my time actually doing the work. So there is an intersection there between those two, which I think is kind of interesting. And I think another question that comes up, going back to the question sort of trope that I was starting on there that I think you touched on, was the how do I know? What type of people am I missing?

Dave: 7:55

Yeah, so, and there's a bit in the middle here which is the how do I know what type of skill sets I'm missing, ties to where the bottlenecks are, and so one of the key steps so if we, if we get to the point where we've got strong, credible agile delivery from the dedicated cross functional agile teams, there are still skill sets that those teams need that are probably not on the team. So this is where the shared services and that might be infrastructure or compliance, it might be UX, maybe a number of different things where, all of a sudden, I have and the interesting thing is now I've got two areas to look at. One is do I have enough capacity to get things moving, deliver substantial work? And that's where the teams come in. That's broadly a case of looking at the work coming down the pipeline, looking at that roadmap, estimating it and comparing it with what delivery capacity we have and seeing what the gap is. But there's another layer to that, which is where are my bottlenecks going to emerge? And you start from there. You're looking at your shared services and you're understanding how long are the cues of work going into those shared services? Is there a strategic risk? Have I got one or two people controlling all of the access into data, for example. So I've got a strategic risk that I need to protect myself from there. Or have I got other skills which? So one of the organizations we're working with right now. They have a ton of marketing activity, they're rebuilding, they're rebranding and doing a whole bunch of work in marketing which is going to overload their design and UX capabilities. So you already know there needs to be a conversation about are we prepared to slow this down? Are we outsourcing that and getting certain things brought in? And remembering, just because you outsource it doesn't mean there's no admin cost and no overhead on your side all of the things that come with that. So there's a few conversations to be had there, but it's not impossible to look at that and understand it.

Peter: 9:55

Yeah well, and part of that is operating a level where you can see across everything. Another mistake that I commonly see organizations making in this capacity planning is capacity planning in islands. So I've got product, I've got engineering, I've got marketing, but each of those is operating dependency. I've got no visibility to be able to do the kind of analysis that you were just describing, where it's like. I know that this is going to cause massive problem here. I need to go work out how I'm going to solve that problem and, as you say, I've got choices then to make. But if people aren't talking at the right level and that isn't visible, then you're going to start to run into those problems and then I think that also then takes you back down the oh, we've got to plan every single little piece of this out.

Dave: 10:42

It's interesting. What you're just describing is exactly something that we're looking at right now, and what's going to play a big role in that solution is pieces of work that cross those groups, because if I have a piece of work in my group, my I'm always going to underestimate the amount of kind of work I'm going to need from others, and the classic one is business rolls out a new system and they don't think IT needs to be involved, and how many times have we seen that? Right happens all the time. Salesforce, yeah. So so, and these are these cross cutting initiatives right, and as soon as I look at them from a cross cutting perspective, and now I can start saying well, you'll contribute something, will contribute something. What's that sort of difference? You know what's the ratio, if you like, of what, what contribution everyone makes.

Peter: 11:33

And again.

Dave: 11:33

We can now start having reasonable conversations around capacity.

Peter: 11:36

Yeah, I mean the difficulty. Often I see that arises there as well, but I never had the capacity for that. I never had. I don't have the ability to consume that. I'm already working on the things that I said I was going to work on, and this is something new and I don't have the capacity to take that on, so something. Then it becomes the case of well, if I say yes to that, what am I saying no to? What am I going to stop doing?

Dave: 11:59

Well, and this is that whole, you know now just stepping back from when we started. So this is why capacity is such a headache, because it bubbles up very quickly whenever you try and do something across the organization. Because what we actually find is that everybody in the organization is quite rightly focused like myopic in their view. They're looking at what's in front of them and what they have to worry about. They're not thinking, oh, there's this piece of work going to come in in two months time and I need to reserve capacity for that. They've probably got three or four months backlog of work they're dealing with. So this is where that quarterly planning, cross cutting initiatives, looking across the organization, becomes so important. We don't need to spend a ton of time doing it, but we need to spend enough time that people are aware of some of these impacts heading their way.

Peter: 12:46

Yeah, yeah. So you've got an understanding of like, where are we going Like, and are we all aligned to that direction? And it's curious, I would say. But we see these kind of problems everywhere. And I think the other interesting one and it was interesting that you started from that point where the capacity with the teams, but when you've got an organization that has already committed to all of their future work and has, but is still operating in a we give work to Bert but is looking to change if there's so let me spin this one around a little bit into because I think this is there are.

Dave: 13:28

There are two models. There is the traditional model that we used to and I get a spreadsheet and I look at how many hours I need from different skill sets and we look at Bert's contribution and we adjust how many Bert's we need in the organization and I must admit I don't spend a lot of time. I don't. I don't from an agile context. I don't find that a useful conversation to have. What I find much more useful is let's make sure your teams are delivering and get those to a stage where they're delivering. Let's understand the shared services and if I can just give you one of the best examples I've had of this is, in a period of one week we got together with an organization and it's multi millions of dollars. This isn't one or two teams in a startup. It's a significant medical company that's delivering medical products. They had hardware and software and they had I think they had around six or eight agile delivery teams and we sat down and looked at what they had for the coming year and they were receiving funding. They had a whole bunch of opportunities opening up. So they're their backlog of ideas, initiatives, opportunities that they wanted to pursue was considerably larger than what they've done in this calendar year that was ending, but we had, like that, 12 months of solid agile delivery behind it and they'd good experience of estimating initiatives at the highest level. In that one week conversation they freed up the funding to double the capacity of the organization and started the hiring and releasing of that funds very, very quickly. And that came about because, first of all, they had credible confidence. They had confidence in the capacity of the agile teams. They had confidence in the estimates and they could see. They knew they were going to have to adjust scope they even you know but they could see they had a doubling or more of opportunities coming down the pipeline. They knew how to go about delivering that, so they just needed to bring new teams in. It was a pretty straightforward conversation and what struck me about that was that was decisions made with a significant price tag, but made early with confidence, and then followed through from an executive team that understood what they were looking at. Now I've seen that a number of times it works very cleanly with enough there's gray area, you know you're going to miss the occasional developer and tester and things like this, because you don't bring enough in. But generally there's a really good present. Star.

Peter: 15:47

Yeah, once you have, because what you're describing is that there is an alignment around. How do we identify what the value of the things that we're going to do are. We've got a method of understanding what, coming to an agreement as to what the effort is, to a certain level of confidence. And if we don't have that, we know how to go about getting it. So we're looking at our prioritization mechanisms, which are built into that. We've based on a historic experience of teams like this delivering. We've got an understanding of what it takes to stand these up, how long they'll get to be credit. We understand our underlying technology, so it isn't the technical architecture which we can deliver on top of, and so we've got that, those practices, in place. So once those sorts of things are through, then capacity planning becomes easier in an agile space, because you're now saying, okay, I'm just really am adding another chunk of capacity and another chunk of ability to deliver. So as long as I have these, this work, coming in that I want to take on, then I can, and I can divide that up and break it in the insensible manner to deliver it out to delivery teams. I've got a way of handling that throughput. So it's just add another block of capacity.

Dave: 17:03

I love the way you're describing it and it just occurred to me is it's like adding a lane to a highway. You've got three lanes. You know you've got way more capacity than those three lanes will handle. So you can kind of do a back of the envelope calculation. It's a bit more than that, but to decide, do you need four or do you need five lanes. And those are the sorts of conversations we're talking about, very, very successful conversations. One other thing I should add. I think there were three executives in the case that I'm thinking of, and certainly in other cases it's been that sort of three to six. You can get into certain organizations where you've got, you know, eight to 12 executives trying to decide on priorities. Well, you're not going to get that sort of rallying around what the problem is to be solved there, I would think.

Peter: 17:45

It can be tougher for sure. I've seen that the more people you have in the room that you have to get aligned, the harder it is to do. That goes without saying. That is just a good one.

Dave: 17:56

For sure, and I think the only thing I would say that in sort of, when I look at these nowadays, I spend more time on is the shared services, to find out what those specific to your point of what skill sets you need. I think that conversation is one that's taking a very simplistic, agile view of how much capacity do we have in the teams, does not take enough consideration to is, you know, are we, do we have enough architects? Do we have enough compliance? Whatever the skill set is, those, those individuals that are going to be critical, they'll be the bottlenecks. Can we make sure we've we've kind of doubled down on those as well?

Peter: 18:31

Yeah, I know, I know what you mean. I've seen that many times before too.

Dave: 18:35

How would you summarize it?

Peter: 18:36

I feel like I'm hesitant to appeal back at the next layer, but well, if we were to wrap this up and summarize it, I think the piece that I really liked was around considering the what you need in place for it to work. Like what are the criteria you need to be looking for. If you're looking at capacity planning in an agile world, you're deploying, you've got teams that are functioning and able to deliver, but also the where that's coming from. Like what are the things that we're looking for?

Dave: 19:05

Like if this is why organizations like that are able to function in this manner, and I don't know if we got enough into why this is a much better way of working, but well, maybe we'll pick that up in our next one, but I think, you know, in our conversation, one thing that struck me is that those prerequisites to that is, you know, solid teams, teams that are credibly delivering enough of a product road map looking ahead. That is not, you know, sized down to user stories, but is something that is well enough understood and the estimation of kind of volume is there. We touched right at the end of prioritization across a sort of, you know, a prioritization process which is fully supported. That would be the way it could be fully supported with a dozen people, but often the more people, the more fingers in the pie, the harder it gets.

Peter: 19:57

I think I really enjoyed that conversation, but, as always, and if you want to hit subscribe, we're always like new subscribers and you can reach us with feedback@ definitelymaybeagile. com. And until next time, Dave, for sure, until next time, Peter. Thanks. 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.