Definitely, Maybe Agile
Definitely, Maybe Agile
Why Dedicated Teams FAIL (And What Actually Works Instead)
🚨 Struggling to implement Agile because you can't get dedicated cross-functional teams? You're not alone.
In this episode, Dave Sharrock and Peter Maddison tackle one of the BIGGEST challenges facing late-adopter organizations: how to increase productivity and deliver value when dedicated teams just aren't in the cards.
In this episode, we explore:
- Why the "dedicated team first" approach often crashes in traditional organizations
- The hidden dysfunctions and perverse incentives that keep teams fragmented (spoiler: it's about promotions and funding)
- The famous "Sock Factory Parable" explains cross-functional alignment perfectly
- How context switching kills productivity with scarce specialists like DBAs
- Three essential steps to make real progress WITHOUT restructuring your entire organization
The Three Critical Steps:
- Understand WHY dedicated teams work before forcing the structure
- Get leadership aligned on real prioritization and trade-offs (not everything can be Priority 1)
- Create genuine work transparency without status report theater
Whether you're an Agile Coach, Scrum Master, Product Manager, or Engineering Leader dealing with organizational resistance, this episode gives you practical strategies to move forward when structural change isn't an option.
Resources Mentioned:
- Peter's LinkedIn Learning Course on Value Stream Management
About Definitely Maybe Agile: Join Peter Maddison (XodiacInc) and Dave Sharrock (IncrementOne) as they discuss the complexities of adopting new ways of working at scale. Real conversations about digital transformation, agile, and DevOps challenges, no sugar-coating, just practical insights.
🎧 Subscribe for weekly episodes on making agile work in the real world
Got a question or topic you'd like us to cover? Reach out to us!
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.
Peter: 0:12 Hello, Dave! How are you doing?
Dave: 0:12 Peter, great to catch up with you again. Hopefully we're just at that turn of the season. So, is the weather—I heard it's like 25 degrees over there, even though it's late fall?
Peter: 0:24 Yeah, it's fall, but it feels like summer, which is actually wonderful. It's kind of nice. I don't know that it's good for the trees, but they're turning beautiful colors.
Dave: 0:32 At least it feels like fall here. We're beginning to see the colors change and it's a little damper than it has been.
Peter: 0:38 So how's it going over at Increment One?
Dave: 0:41 Increment One's been—it's been a good year. I'm enjoying the conversations we've been having. We're making some great progress with the clients we've been lucky enough to work with this year, so looking good. And yourself? How's Zodiac? Kicking doors down as normal, I would think.
Peter: 0:58 Of course! Yes, it's going well. We're having a lot of fun and interesting challenges with our clients and helping them solve some of those problems, which is good. So it's a lot of fun. What's the topic for today?
Dave: 1:11 Here's something I'm bumping into a little bit more frequently than I'm comfortable with: trying to increase productivity without dedicated teams. I think in the agile context, we always talk about the first thing to do is pull together small, cross-functional, dedicated teams. And we're working more and more with organizations—I think you're finding the same—where the appetite to push that sort of organizational change through is just not there yet. Either the understanding isn't there, or the appetite to do it is just not there. That classic late adopter. When you go into the late adopters, they're much less prone to making radical changes or what may seem to be radical changes in their organizational structure.
Peter: 1:59 Yes, I think when you think of the adoption of a lot of these practices, you very often run into—well, there's a couple of roadblocks you typically run into. One of the first tends to be how projects are funded, which is the finance side of things. But moving past that, typically one of the next big ones that you'll run into is always this organizational change, where if I need to bring a cross-functional team together, it's difficult to do that on a permanent basis because I've got to then change the alignment and reporting structure of my organization, or at least it feels like it.
Dave: 2:36 Yeah, it's interesting you touch on that because that first piece—what we see, what certainly my experience has been—is it isn't that we don't like the idea of putting a dedicated team together. We're going to do that for the classic war room mentality. We have an existential crisis, let's bring together some individuals, put them in a war room, shut the door, and focus them on solving a problem. They're used to the idea that when things have to be done, a dedicated pool of individuals, skilled individuals coming together makes a lot of sense. And we can see that when major projects come through, which are larger, have a higher profile than perhaps some of the routine work that comes through an organization. They may well put dedicated people to a project team. What's harder is that routine work—there isn't the recognition or the understanding of what the benefits are of building a backlog of routine work around dedicated teams because there's this need to have that routine work moved, worked on, somehow addressed on a regular basis because we're reporting out to many different stakeholders at this point.
Peter: 3:49 Or you see a dedicated team get put together that gets shifted off to one side who are picking up all of those little pieces, but they don't get any recognition for any of the work that they're doing.
Dave: 4:01 Well, and they get pulled because they're viewed as in the pool of people that we can kind of come and work with. So even though there's maybe some pool of dedicated individuals, resources, skill sets that are being used, they're not actually properly pulled together in a team that acts as a team. They're individuals that are going to respond to the particular driver, work request that is top of their mind at any particular time for whatever reason.
Peter: 4:31 Almost sounds like operations.
Dave: 4:33 Well, I mean, isn't it? So my original—when we used to bump into this, what would happen is you don't understand, you need dedicated teams. And we immediately hit this impasse that we're not going to get past. We're not going to get dedicated teams, or if you really shout loud enough, we're either going to go, "Stop, we're not doing this," or on paper, "Here is a dedicated team." And yet we know that on paper it doesn't translate into actual available people. So if that's the case, you can't just say the first step is we need a dedicated team.
Peter: 5:09 No, no. The way I often think of this is the reason for those dedicated teams—like that dedicated team that you create has to have a purpose. They have to be coming together to build towards something. They have to own and have accountability for it. And that team needs to do that, which requires that you've got an understanding of what you are going to align that team to.
Dave: 5:33 And I think you hit the nail on the head earlier in the conversation when you said that the lines of—you know, the dotted lines, solid lines of reporting, line management, whatever it is—has to be put to one side while these individuals work on that team. So there is a mechanism whereby we will relinquish our oversight, our direct management ability or opportunity with individuals when they go to special projects in some way. However, we don't want many people to be doing that because we actually still feel a need that we need to be able to coordinate work across a range of different people that work for us, whatever that function might be.
Peter: 6:18 And for the leaders that are potentially having a change in who's reporting to them, this can be a very scary thing too. And very often organizations do a very poor job of managing that. And I've seen it go very, very badly on a number of occasions where it's done wrongly. And some of this also is—it's bad for the people in the teams, too, because they lose a lot of the certainty as to, well, who am I supposed to go to if I need help? Or if I've got something that hasn't got anything to do with work, who do I go to? Like, that certainty gets disrupted, and anytime we do that, we're causing a lot of disruption in the organization. So that is yet another concern with that type of change.
Dave: 7:08 Well, I feel that one of the first things that we have to recognize—if I can't go in, there isn't that, you know, we don't have the authority or the leverage to be able to drive that significant shift. And it certainly was a lot easier to do in many cases in the past. Early adopters tend to be much more open about that sort of change. I also think that one of the first things we have to understand is what are the—and I will call them dysfunctions, but let's say incentives—what are the incentives that are leading to "Let me keep my functional group of individuals over here," or whatever it might be, these team members that aren't really team members but are distributed across the organization. What are the incentives that drive that? And you've mentioned one of them being, well, I have a management responsibility and I need to be seen to be managing, and so I can't have people independently working on teams because then it questions, you know, what am I managing at that point? Definitely that's something that needs to be addressed. But I think of it as there's often layers of these incentives that have to be really understood and they're often not discussed or they're not transparent.
Peter: 8:15 Yes, I would agree. Incentives play a massive part in it. But one way of thinking of this is—if you think of an organization that delivers a product to market, let's say that they manufacture socks. We're going to make socks, right? I'm just picking one at random. So I've got a department of thread acquisition whose entire job—they're incentivized by getting the best possible price for thread. I've got a department that's responsible for managing the machines that are going to make it, and they're incentivized by the uptime of those machines. And I have another department that is responsible for packaging and shipping these things off to the right customers. And those three parties have very different metrics they're getting measured against, very different priorities and very different incentives. But the actual overall—if I wanted a cross-functional team that made and delivered socks to a particular type of customer, that cross-functional team would need people from all of those different areas to exist in it. Now, but the incentives are all different. And so each of them cannot succeed to their incentive if their people are taken away and put in this other team potentially, because maybe that team decides, well, actually I'm not going to—I'm going to pick a better quality material, I'm not going to get the best price, which means I'm going to actually increase the cost. So that means that executive's going to miss out on what they need.
Dave: 9:47 Well, and maybe this is worth us introducing incentives and dysfunctions in this area, because part of the incentives—which is actually maybe more of a dysfunction that we sometimes come across—are things like, in order for me to be promoted, I need to have a certain number of people reporting to me.
Peter: 10:05 Yes, that's another thing.
Dave: 10:06 Because immediately now, what does it count as being reported to me if they're given over to dedicated teams? It's going to vary, right, on the organization. Another thing comes in when your projects are funded on an annual basis. We have funding allocated and we need to use that funding or lose it, or other dysfunctions that come around with how funding is handled in an organization. It's often allocated in many organizations to an individual skill rather than to a team. So now we have this situation where my, let's say, senior developer or senior database engineer, I only want them on a team for a certain number of days before I now need to move them somewhere else because of the way funds are allocated around projects. So those are just two examples of—I'd say there are incentives, but they're actually dysfunctions in how the work is funded or how people are promoted in the examples that I used.
Peter: 11:14 Yeah, but another really classic dysfunction that you just touched on there with the DBA one is that there's this kind of assumption that you could just drop the DBA in and that they're going to magically suddenly understand everything about that particular product's databases and how they're structured and how the schemas were built and why they were built the way they were built, and they'll instantly know all of that. And then they'll go away for six months, come back, and suddenly magically be able to be dropped in and understand it all again. And that's just not the case. Context switching kills you in that case. It's going to take them a while to get back up to speed to understand what's happening here, unless you've got an incredible consistency across your environment, which...absolutely, yeah.
Dave: 12:00 Now, let's—so we're looking at all of the reasons why we might bump into some of this. Let's start being a little bit more solution-oriented. So where do you go from here? And I dare you to try and figure out how do you work around some of the dysfunctions and the incentives that we've discussed.
Peter: 12:17 So I mean, one part of it is—leaders do have to go first on this. We do have to bring the leadership together. If you take my example of the sock makers, those three leaders need to agree that together they do have a common goal, and that between them they need to be accountable and responsible for deciding how they can both meet their incentives and ensure the success of the teams below them to deliver to that common goal. And how are we going to do that? So that piece is absolutely key. As a part of that, figuring out what that common goal is becomes essential.
Dave: 12:54 But it's more than a common goal, right? Because what you're actually now talking about is this—let me call it a project or initiative over here—is our primary objective for this quarter, let's say. And these other initiatives or projects that come from maybe different stakeholders will be down-prioritized, deprioritized compared to this primary one. So now we're talking about prioritization across major initiatives with multiple stakeholders, of which many stakeholders will not have their primary initiative top of mind. And now we're really getting into some quite nuanced stakeholder communication, executive leadership agreement. There's an alignment problem there.
Peter: 13:39 You remember Mark Richards we had on here a little while back from Lean, and he was talking about exactly this and mechanisms for looking at that alignment across different executives. It's exactly that, yeah.
Dave: 13:51 So it's interesting. What I often see, for example, is we're not going to get that, right? If I'm not going to get dedicated teams because of some of the incentives or dysfunctions that we've talked about, likely there is still that level of misalignment around effort. So then it becomes, how do we make this work well enough? And I think that one becomes really challenging because the reality is we're not solving problems, we're bringing transparency into where the issues are so that hopefully people can learn as they go, right?
Peter: 14:29 Yeah, well, this is a good starting point. We were talking about solutions, and that there is a key part of the solution. It's one of the bits that we really have to start and focus on first. That bit has to be working. One of the other common solutions that I've seen coming out of there is that initially those leaders don't really understand—in my sock example, which I'm keeping just for the amusement value because it's the first thing that came to mind—they don't necessarily know whether they're making socks. So they might know that they make socks, but they might not know what type of socks. And they might not know enough information about what's going to be particularly special, what types of things they need to do, which makes it very, very hard for them to create that alignment because they're all going to have a different perspective. So that piece has to come in too, getting to that, because then you can start to say, well, how do I start to align these teams to different potential areas? And some of that's going to come out of—I have to also then understand what are the underlying systems and processes in place that are used by your team so I can figure out what is the right mix and alignment of people, where do I have gaps? What might I need to bring in to start to do this?
Dave: 15:49 It's the dependencies, right? So who are we dependent on? What is slowing us down? What decision points, what departments that create particular value, whatever that might be—where are we slowing down? And I think this brings us very quickly to work transparency. And so one of the big headaches that I see in a lot of organizations on this one is they have work transparency about individual initiatives or projects because there's a steering committee for that one particular piece of work, but where they're lacking overall transparency is across the entire pool of work. And so, how do you bring forward that transparency across a whole bunch of different work in a way that does not impose tremendous reporting requirements, you know, whatever it might be? How do you get to this position where you're really able to see where the organization, that group of individuals, where they're working, and where the dependencies are beginning to sort of incur delivery delays or costs associated with getting things out the door?
Peter: 16:52 And I know that you within Increment One have a number of methods you probably use. I definitely within Zodiac have a few different ways we'll approach this depending on the knowledge, expertise, appetite, and the level within the organization. Because often this gets done in larger organizations—of course, a subset of that organization—but it boils down to a form of mapping exercise, whether it be domain-driven design, event storming, value stream management, value stream mapping type exercises, or flow engineering is another piece, which is effectively value stream mapping starting from—but it builds on the same set of components around creating visibility and transparency to the work process for all those involved in it.
Dave: 17:44 Yeah, and using the tools which are already in place as much as possible, trying to leverage the information that the organization already has in a way that isn't focused on an individual initiative or program, but is kind of raised to the level and looked across the whole thing. And that one, it takes a bit of thought, but to your point, it's just understanding how the work packages are described or what things we can capture that really show what is moving. So instead of—what we want to avoid is the "What do you want to tell me you were working on last week?" right? Because I'm going to get fictional interpretation. I'm going to feel something should have moved because somebody somewhere feels they have to say this was moving forward, even though that wasn't really where the work was done. So it doesn't become "I'm going to ask everybody where they're at." It's going to look at how can we draw data out or information out without actually going out and asking people to effectively tell me what they think we want to hear, which isn't as useful, right?
Peter: 18:52 Yes, yes. I mean, and typically the process we follow is a mix of all of these different pieces. Yeah, you go and talk to people, you do the Gemba walk part of it, right? You go and see, well, how do you do that? Like, how does this work?
Dave: 19:06 But the Gemba walk doesn't say "What are you working on this week?" It says, "Look, let me look over your shoulder and let's see how do you solve that problem? I see you're working on this one." And it's very much rooted in actual work being done.
Peter: 19:19 Yes. And then you look at what is documented and what is the data, what are the systems telling you? You understand that part of it. And then the third leg of that three-legged stool is the mapping exercise. Bring everyone together and see if they were telling the truth.
Dave: 19:36 Well, yeah, and then it comes down to delivery, right? So let's see what this pipeline of work, what's actually coming out. And what is actually coming out of the other end, we're going to find out where the priority is, because the things which are actually completed and exiting that pipeline are going to be the things that can break down some of the barriers internally.
Peter: 20:00 Yeah. If anyone wants an overview of value stream management, they can go do my LinkedIn Learning course, of course.
Dave: 20:07 Exactly.
Peter: 20:08 So we should wrap this up. I think we've—best of luck.
Dave: 20:12 Yeah, let's see. I'm not sure we've got to the end of a conversation, but let's try.
Peter: 20:16 Let's try. Well, it is a conversation. I mean, it's one I'm very passionate about and we'll happily talk about for hours. But let's see if we can wrap this up in some nice three points for our listeners. Would you like to go first?
Dave: 20:29 So maybe the starting point would be create cross-functional dedicated teams. And I think we've talked about what happens when that doesn't happen, but I think the first step we talked about is it's dysfunctional and we're always going to be compromised. So I think the first takeaway is let's go learn why dedicated teams work as well as they do.
Peter: 20:51 And I think—I'm going to take you back a step from the piece we were talking about. Can you put it in context of socks? Well, maybe not in context of socks, but I can give you an example from my past. And this is an example of why that can be bad if you say that my primary goal is to create permanent cross-functional teams. What happens is they go into the DBA department and they say, "Okay, you DBA are on that one, you DBA on that one, you DBA on that one, you DBA on that one." And that is the stupidest idea—it's like that is going to break everything. So it isn't that the primary goal can't be dedicated teams, it's got to be dedicated teams aligned to delivery of something. Delivery of socks.
Dave: 21:45 Delivery of software. And again, I think you're absolutely right on being too generic. I think the challenge of orienting the development work around these value streams, creating dedicated teams that shift—somewhere there, that challenge is one not to be shied away from. In many organizations, certainly what we're finding at the moment, there's a little bit of reluctance to do that. And I guess the key takeaway is go focus on that and understand what is involved in moving to a more value-focused, value-centric, product-centric—yeah, we'd often talk about delivering more value. And how it shifts your functional sliced individual model into something else. That's the first takeaway. What would you say the second one is? If we assume that battle is lost, let's say, what's the next piece?
Peter: 22:36 You've got to get your leadership aligned to this because it will fail if you don't. And plus, you need them to help you figure out the priorities and where they're going. And what the priorities are. What are we all going to agree? We're going to set up this cross-functional team to do that.
Dave: 22:56 I'd say this one is summarized in the fact—can we as a leadership group trade off between A and B and C and D? And if everything is a priority one and we can't trade off and we can't stop activity or whatever it is, that's the bit that we have to be able to do. We have to take those tough calls of "Yes, they're all vital, yes, they're all important. However, if we have to focus on one area, it would be here. And the cost of that is going to be these things here on hold."
Peter: 23:28 And that conversation has to happen. And you very quickly see where it isn't.
Dave: 23:33 And yeah, it becomes pretty obvious, pretty fast.
Peter: 23:36 Yeah, and until that conversation happens, and until it truly does—because the other thing is the other very common failure mode there is that everyone gets together and agrees, "We're all going to work on D," and then they walk out and work on A, B, C.
Dave: 23:50 Yeah, yeah.
Peter: 23:50 You always have time.
Dave: 23:51 Well, and that brings us to the third point. And the third point is work transparency. Yeah. So if that's really going to happen, if everyone's going to agree on one level and act in a different way, that activity, we need to make it visible in some way. And yes, as we said before, it can't be "Go ask people." There's other ways of doing it. But we need to kind of think about how we can get some understanding of where activity, where work is being done, what results, outcomes are being delivered, and where work is getting blocked.
Peter: 24:22 Yeah. Number of socks delivered.
Dave: 24:24 There we go. Whole pairs, not individual socks, I assume.
Peter: 24:28 Exactly. Yeah, we're not going to measure by each sock, we're going to measure by—we're all going to agree that our goal is to increase the number of socks we deliver.
Dave: 24:36 On that note, yes. Top of mind. I think, as always, a great conversation. Interesting nuances there that we've uncovered, and a fetish for socks I had no idea was on the table.
Peter: 24:50 Well, thanks, Dave, and I look forward to next time.
Dave: 24:53 Thanks again, Peter.
Peter: 24:54 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.
.png)
.pdf.png)