Resourcing Agile Delivery

 What delivery roles are needed? How many do you need? In this week's episode, Dave and Peter go over everything there is to know about sources that work in agile delivery. 

  This week takeaway: 

• Resource the work. Don't understaff the outcome you are trying to achieve.
• Skills development.  Create a talent journey. 
• Properly define the roles and the accountabilities they will have.

  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:04

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 fantastic episode of Definitely Maybe Agile with your hosts, Peter Madison and David Sherrock. And uh we've got a really interesting topic for you today. So what are we talking about, Dave?

Dave 0:23

We're both of us challenged with that whole idea of operating models, of who's going to be where in an organization. And very quickly, people start worrying about how many scrum masters do I need? Where do the project managers sit? Do we really need a product owner for every team? And as it's now the middle of the year and people are thinking about finances and budget planning for next year, budgetary planning, then the question now becomes how many roles do we need to plan as we scale our agile delivery? I think a long-winded way of saying, let's look at resourcing, let's look at delivery and management of agile teams in an organization.

Peter 1:01

And I think for me, this often comes back down to what is it you're trying to achieve? Because that'll dictate what your outcomes are, will dictate what resources you need in order to achieve those outcomes. And having an understanding of the breadth and scale of what you're going to be looking to do will help determine uh what resources you're going to need to do to help achieve it, just with everything else, really.

Dave 1:25

Like, I mean, yeah, well, it it's it is that there's a hugely important piece here, which is to do with the fact that if you don't really, you know, you're talking about value streams and the outcomes and what we're trying to get out of a group of teams working together on a particular, let's call it value stream or product line or whatever it might be. But if we don't get that clarity at the outset, we end up needing more management of dependencies, more overhead involved in running around and keeping things aligned and handling those dependencies. If we create those correctly, you can actually start minimizing some of those, what I think of as overhead roles, but the oversight through product ownership or scrum mastering on a single team, and as you scale up some of those uh broader roles that come into an organization.

Peter 2:12

And there are different elements of this too. I think if you've if you've got a mature organization that's already using uh practices and understands these ways of working, where you're looking to bring people in to help facilitate a new uh delivery, a new way of doing things, then that's that's quite different to uh an organization that's been operating under a different mindset or a different model, and you're bringing people in to change the way that they think about delivery. And now you're looking at uh needing the people to come in and do the work of trying to uh introduce that new way of thinking, new concepts, new models, new methods, new frameworks, new uh ways of approaching the problems that we're trying to solve.

Dave 2:52

It's as you're describing that, Peter. I'm just thinking immediately there's a there's a huge sort of gotcha in the middle of that, which is there will be in an existing organization which is undergoing a shift into a new way of working, there will be individuals whose roles will significantly change. They will maybe they're program managers or project managers, or they are functional leads that have responsibility for both delivery and prioritization and direction, and perhaps even functional roles like architectural design. And those, there is a almost a purity around the agile approach that says, look, you you can be really smart in all of those areas, but what we're looking for is a role that's dedicated to one aspect with as little overlap with some of these other aspects as possible. And that requires a little bit of an adjustment, I think, for many organizations and individuals. Would you agree?

Peter 3:45

Yeah, I I think there's a word too in uh one of your earlier descriptions as well that I think is important to pull out where you said that it's often seen as overhead to do this. And this this isn't overhead, it's a part of doing the work. So there's this, there needs to be this understanding that in order for us to achieve the things that we're looking to achieve, there is work to be done in setting up uh the workshops, getting the people together, teaching these new things, facilitating conversations, coaching people through new ways of understanding and ways of looking at problems. That is work. And it's it's hard work and there's a lot of work to be done. Uh so I often see organizations uh partly sometimes I think because they look at it as overhead, they often understaff um that um that part of the change if they're going through change and introducing new things.

Dave 4:36

Yeah, I and I I'd even add understaff or what they often it's ends up landing on various people's plates as sort of off-the-desk work that oh, by the way, you're responsible for this, this, and this. The classic Scrum Master as a developer in their daytime job and scrum master in the evening, or the scrum master product owner joint, you know, single role single individual, which both of which are particularly challenging there.

Peter 4:59

Uh they they can be, they can be, if the organization isn't well set up to understand and execute on that. Depend it can work, I've seen it work, but it depend it means that the teams are often already well formed and well understand how to work under those ways, and they understand these pieces. So, so then yeah, the a lot of the well a lot of the things that are being introduced in those newsworks of working are they it they get divided up amongst the members of the team and that they can collaborate and deliver those pieces. Uh so that's when I've seen it work.

Dave 5:29

Yeah, I I it's a really I think it's there's one of the the kind of roots of of uncertainty or or um kind of concern, if you like, that comes from this is certainly I think we've we know where it's going, and and you'll you'll get conversations around how little, how few of these roles you need in in the long run. So one of the ones that we'll often talk about is how a scrum master can often be working with a couple of teams, two or three teams. That's not unheard of. A scrum master from the scrum guide is one scrum master, one team, but we know most organizations don't operate at that ratio. However, the the bit that people forget is when you're starting out, you almost certainly need one scrum master per team. Why? Because those teams don't know what they're doing. The systems are set up in a way to prevent those teams delivering, not on purpose, but just because of the way the approvals are set up, the development environments, whatever it might be, that whole way of working needs a lot of change. Once the organization's gone through that, that ratio really you can pair that down. You have sort of, I always think of this as action at a point. You've got individuals who can place action at a point, can really kind of guide, steer the ship, if you like, and and create or deliver what they need to do, that work that you describe, but at a very light touch way. But there's a big assumption there that they've gone through and sort of fleshed out some of those problems that we know are in organizations that are basically set up to work in a different way.

Peter 6:56

Yeah, and and I think that's a good way of putting it. It's as as you mature, for for lack of a better term, but as you get better at doing these things, you need less guidance. It's like you're it's like you're learning any skill. You're and you're learning that skill, you're getting better at it, you're learning how to collaborate and work, and the the barriers are being removed, you're the the impediments that you're trying to overcome to actually getting the work done, and and things it becomes less there's less benefit in having the person there who's uh sort of holding your hand through all of it. All of it.

Dave 7:28

I I always uh I'm always thinking there is that you can kind of it it's a little bit like a football team that's been working together for a while, coming back to my favorite sport metaphors, right? Which is which now they know how to play the game. So if if your coach doesn't turn up, they probably know enough to be able to go out and play the game. Will they play absolutely at the peak of their delivery performance potential? Perhaps not. But can they hold their own and deliver what they need to do and have fun while doing it and still get the outcomes that kind of they need to do? Probably they can when they've got that experience and they understand the rules of the game and how to do that. But there's also that beginning piece where you've got to be much more heavily involved to help them achieve anything purposeful or meaningful. So, how many do we need? Yeah. So it's it's I think there are a couple of things that come into this. And this is where when I'm looking at those conversations, the first thing is I think you need two distinct roles, actually three, but we'll come to the third as we go forward. Two distinct roles. One that's focused on that management of flow, looking at the system, understanding and working on removing organizational impediments, how the system works. And that's on a on a single Scrum team is the Scrum Master role. And as you scale that up, there's going to be uh increasingly senior or or uh more experienced roles with a wider scope of responsibility, but they're all focused on system impediments and flow and getting things through the system. And then on the other side, you have that product owner role, the role that's worried about are we exciting our customers with the changes that we're delivering? Are we understanding the behaviors of our customers and what they need? How do we make sure that the most valuable things are getting out of the door at any one time? And that on its own is a whole chunk of work with a different focus. So you certainly end up with those two sort of roles coming out rather than a merged role. Let me throw that back out to you then. And so we've now defined two different roles. How many of them would you put in place?

Peter 9:24

So I I agree. I mean, uh, the somebody has to have oversight under an agile delivery model for what is the direction of the product and helping guide what that is and understand that are the customers' needs being met. Are we putting the right uh thoughts into that and managing that within the the organization? Uh the and as I think we've covered the Scrum Master piece around how many we would need the those per team, which seems to range between um zero to one to uh some fraction of that, right? Depending on uh uh how you've uh decided the work to needs to be divvied up and how things are being done and how um well aware the teams are of working together under these models uh and these methods. So so from that perspective, uh the next part of that question comes down to is like, well, how complex is the environment that you're delivering this into? Um, how many teams do I need in order to be able to make the change that I need to? How many different systems am I gonna have to interact with to properly manage this? And then that will determine what that looks like from uh a structure perspective around if I'm looking to build something new and I need all of these different pieces, I need people, these resources, I want to bring um, I want to make sure none of my teams get too large, and I want to make sure that everybody's got the support they need uh based on where they are in their journey and their understanding to be able to succeed in the roles that they're in. So that does that answer the question?

Dave 10:49

I'm I do sort of feel like we're dancing around the real topic, right? So if if I think of um a single value stream, then that single value stream when it's self-contained and there are really dependencies within the value stream, but not from one value stream to the rest of the organization. Then you're typically looking, there'll be a value, an owner of the value stream that has, you know, think of them like a product manager that can see the oversight of exactly where the product's going, what they're trying to achieve, and probably PL responsible to some extent for that value stream. And of course, they'll have a partner in crime, which is somebody who's looking at have we got the structure in place, the organizational structure. And what's interesting here is that partner in crime might be technical, might be organizational, depending on the sort of products you're looking at. They may be an architect or enterprise architect, as much as they could be an expert in organizational delivery, right, and systems. And as you break that value stream down, for example, to product lines or service lines, obviously those typically have their own leads or roles in terms of that product side and the and the system or flow side. And then you get down to the teams and the ratios there might be one to one, there might be less than one to one, depending on complexity and how the organization's going um structured. But I would say that's the simplest and the lightest weight option because they're the assumption there is they're able to operate pretty much unimpeded by bits and pieces around them. For example, you know, if you work in a regulated compliance-heavy environment, or you've got legacy systems and those systems aren't yet decoupled the way they could be, then you begin to see dependencies creeping into that. In fact, they're not creeping in, they're rushing in, right? And so all of a sudden there's a bunch of work to do with dependency management and management effectively of the old way of working that adds work to the table of those individuals.

Peter 12:35

Yes. And I think it's it's acknowledging that there's an awful lot of knowledge required to be able to do that. So you need to bring those people to the table. It's that we can't forget that there's a there's other pieces of delivery that may need to occur outside of this. We need to ensure those are aligned and that we have a an appropriate cadence as well to what we're delivering and releasing within the agile uh delivery that will match up with the uh cadence of how we're managing change in the other parts of the organization that might also have dependencies baked into them. Um and as well as ensuring that we've captured any organizational concerns, regulatory, governance, security, other pieces, and that those are being incorporated into what we need as well. And I think that's probably a topic for a whole other podcast because it's one of my favorite topics. I spend quite a lot of time in that space. And there's so that there's all of those pieces that we that we need to work out and ensure get brought to the table. Uh and it still leaves us dancing around this point, I think, a little.

Dave 13:34

Well, I I think the the I mean this this speaks to that whole idea when we talked about value streams a few podcasts ago, there is a fo the focus of value streams, the the intent, the principle behind it is to reduce, minimize the dependencies. And what we're talking about here is when we're unable to minimize or when we're in the process of minimizing, but we aren't there yet, we need the people around to manage the disconnect, manage those dependencies and get them kind of talked about and get the conversations and and align roadmaps and recognize when a dependency over here and a delay over there is going to change what goes on here. So you sort of see that churn coming backwards and forwards. So to answer the question that's hovering around there, the number of people it depends, of course, because that's why you get really excellent consultants like Peter in to help you set everything up, right? But but it's also we want to understand that it isn't quite, you know, roll the dice and see what comes out. You know, from a value stream to product service line to delivery teams, you can kind of do the maths on that and we can get a rough idea. But now we're gonna have to look at our organization and understand, first of all, do we already have those roles? Is it a repurposing? Maybe we don't need to add anybody at all. Right, in many cases that's true. Uh and the second thing is what are the what are the residual dependencies or the existing dependencies that we will eliminate with time, but right now are front and center in what we're doing, you know. And that's often architecture, the your the the the structure that you have in your product often is a constraint. But it can also be an external um the the arena you operate in. You're a regulated, you're working in a regulated or a compliance heavy or uh uh arena. Well, that that isn't gonna change. That's an outside constraint that you have to work with. And there'll be many others as well. If you're in a large organization, there can be many different value streams, and it's rare that value streams are truly independent. There will be cross-dependencies there.

Peter 15:41

Yes, yeah, and uh and and there's a lot of other places that we can go with that that we've talked about. So I think summing this up, um we well, maybe Peter, just to I wanted to throw one quick thing in before we move on.

Dave 15:54

Okay. And uh that's because earlier on I said there's three roles, and we've only just talked about two. And the third one I want I know I'm just gonna put a pin on this because after we've talked about what you described, we probably need to talk about this as well, which is functional development. That functional leads, which are which are not part of those um roles that we've described, but are just as important, which is how do you manage the career development and the skill development of individual functions? And that's a cross-cutting responsibility, but it's something that needs to be a part of that conversation as well.

Peter 16:28

Yes, the the talent journey, if you like, the like how do we ensure that we're we're properly um well, and it's planning it out, but it's also we're making sure that we're we're serving the the people and teams, giving them the opportunities, giving them the guidance they need, giving them a place to come and discuss and grow and understand all these other pieces as well. And so, yeah, no, I think that's very true too. I and uh I think that some of this ties back to um this idea that as we look at this, as we as we start to go through change in an organization that is adopting new ways of working, this idea of a center of enablement or of enable, this idea that you've got some people who are looking at it and considering these things and bringing the right people to the table to have these conversations about talent journeys and understanding what that will look like and understanding what these changes need need to be brought in and all of the work that needs to come in. And that and that would definitely be one of my main points is that there is a lot of work to be done in making these things happen. Yes, and uh all too often I see organizations kind of brush it to one side and under-resource it and not put enough people into it, and uh it's or say, well, okay, we've got it, we're gonna buy all the tools, we're gonna set all of this up, where we understand our process, so we're golden, and then it all the wheels fall off the car. Uh like if even if they make it down the road a little bit, because they uh what what happens is that people aren't really bought into where it is they're going, the work hasn't been done to help introduce this to people, people aren't necessarily on board with the change that you're doing, and now you have um problems. But so, what other things would you would you bring up to wrap this up?

Dave 18:01

So I I just wanted to raise that one because I think it's an important one that we don't forget that sort of functional career development piece or or skills development piece in there. Um, the the two things that really strike me as we're looking at this conversation is first of all, understanding that separational role and responsibility, which at the agile team level is the Scrum Master product owner. And as you scale that, there is there are still these two functions, if you like, responsibilities that want to stay, we want those to be distinct. We want them to be separated, not overlapping or block pulled together in one particular group or one particular role. And I think the second one is what you highlighted so clearly at the outset, which is it's about value streams and any of the outcomes that you're trying to achieve. It's like everything we often talk about in these conversations is let's get back to what is it you're trying to achieve? How cleanly can we define it? What are the dependencies? How can we really optimize around this delivery pipeline value stream that we're looking at? What have I missed? What would you add?

Peter 18:57

Uh I think the only other thing that we touched on right at the start there was the need for delineation between the Scrum Master role and the PO role and whatever other roles you have. So and I I might actually think a good way of describing that is to ensure that you've clearly articulated what the accountabilities responsibilities of those different roles are that you're going to have, so that everybody's on the same page as to what they should be doing. Um I think with that, I think it's it's a great conversation as always. We've we've gone in a few different directions there and pulled some things together. So um I'd like to thank our listeners as always, and uh, if you can reach out to us at uh feedback at definitely maybeagile.com. So thank you. Look forward to it. Thanks. Bye. 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.