Episode Transcript
Richard: Welcome to the Humanizing Work Show. I'm Richard Lawrence here with Peter Green.
In our workshops, the most common impediment to really experiencing the value of an agile approach is that teams aren't actually cross-functional.
That's a big problem for a bunch of reasons. It gives you a longer cycle time from idea to value, 'cause you often have to go through multiple full sprints.
The scrum events can feel like going through the motions, which is demotivating.
It's really hard to plan and review when you don't have the power to actually commit to something.
Prioritization is harder because it's about dependency mapping rather than just what's the highest value or what's gonna teach us the most.
You have slower feedback loops; it takes a longer time to discover if you're wrong about something, an assumption related to the product or technology.
And improvements are constrained to a smaller scope than what's valuable, 'cause you can only improve within your team boundary. You can't improve the overall system of value delivery.
Peter: And a lot of agile techniques have become sort of standard practice now. Doing things iteratively is standard practice. A lot of the continuous integration and deployment stuff in software, just the way things are now. But for some reason, this particular agile approach of building a cross-functional team has been hard to do well.
We're not sure exactly why that is. Anytime we talk to leaders about why and how to improve this, they get the benefit of it. And often we'll start down that path. But when we encounter a new organization or when people come to our public classes, it seems like that's not the standard, the way that a lot of other agile practices are.
Many of our listeners aren't in a position to change their team structure. Are they just doomed to get minimal value out of an agile approach, to suffer all of those challenges that Richard mentioned? What we've found is that there are some strategies you can use if you're on a team with a bunch of dependencies that make things better. So we're gonna share three of our favorite strategies. And these strategies start where you are and then are additive from there. So you can do the first strategy and just stop there. You'll get some benefit, or you can do all three and you'll get the most benefit. So let's start with the first one.
Richard: Alright. The first one is, you're probably already mapping dependencies in some way as you plan across teams. But our advice here is: map dependencies, but as you do, identify and emphasize complexity.
The number one reason cross-functional teams are actually important is that it's really hard to solve complex problems across teams. Complex work benefits from collaboration. Teams are the best technology we have for collaboration. So if complexity is spanning teams, it's really hard to collaborate to resolve that complexity.
So when you visualize dependencies. Recognize that not all dependencies are equal. Dependencies related to whatever's complex about your work are the most important ones to be on top of.
When you have a dependency within something complex, just expect that those interactions are gonna be more frequent. That you're going to have to surface more information about what's going on and really focus on managing those dependencies closely. Other dependencies, like we know that we are going to do localization after we build the thing in our main language, you can predict that relationship and when that's going to happen. That requires less attention than dependency of multiple teams who are building the same thing together.
Peter: Once you've drawn a circle around those teams on your dependency map where the real complexity lies, then those teams can use essentially a mini version of our CAPED model.
Start by mapping the core complexity of what those three teams are gonna work on together. Take that all the way through into our active planning phase with feature mining and starting to iteratively probe on things. Do it in very short iterations, like one week long. Maybe consider temporarily rotating team members onto other teams during that active planning time, or behave more like a "too big" team temporarily while you're addressing the core complexity during that active planning stage.
For example, the Joint Special Ops command under Stanley McChrystal used to have a daily meeting across the core complexity, which was people trying to figure out what's going on and people executing on what's going on- the O and I meeting. They had a 2000 person meeting once every morning to get everybody on the same page. They would address the core complexity and then they'd go off and do their work based on that.
You don't need to do that every day, but you can address the core complexity all together in a, what would feel way too big for most of us, way. And then go off and execute separately once you've resolved the core complexity.
Then once you've resolved it, you can define constraints for handoffs and interfaces between the teams going forward. Now, there are lots of examples of this. Software teams, for example, define APIs, and I'll have Richard summarize APIs for the non-technical folks in the room.
Richard: Right. I, I think of it as just a predictable interface.
It says, you can send me these kinds of messages and here's what I'm gonna do with it, and here's what I'm gonna give you back. And you can do the same thing between teams. You can say, this is what you can expect to get from us, and this is what we expect to get back from you.
Peter: Right. So there are lots of analogs outside of software development, like a team where marketing spans core complexity. And one team is, say, creating a video. And another team is gonna have to embed that in a site or in, in a, um, social media posts can say, the interface here is: it's a core message, this is the core message we're gonna focus on. The video will have these dimensions in length. Do whatever you need to do within that boundary.
In our training, we do a, a playground example where teams build little components of, uh, a little tiny playground for playmobile characters. A slide is a backlog item. A swing set is a backlog item, and then we add a backlog item, which is a soft landing area, like the squishy stuff.
Well, one team is often building the soft landing area for the slide, the swing sets the monkey bars. During planning, they need to go and do some coordination between the other teams. They need to say, about how big will the swing set be? About how big, so they're essentially defining the same thing as an API or an interface between the teams. And then whatever the swing set team wants to build, as long as it fits in that footprint, it works.
The key here is that those interfaces bound the complexity to within the team boundary, and you don't have to fully specify what each team is gonna do within that. You just have to define the handoff conditions to make them more predictable and then have a shared definition of done at those boundaries that starts to create predictability.
But that only works if you've already solved complexity by doing that active planning approach from CAPED.
Richard: Yeah, I think that's a critical point, Peter. People try often try to take this kind of approach too early and define contracts between teams while there's still complexity that spans teams.
The third approach, if you are in the middle of a system where you don't have fully cross-functional teams. And, uh, this is a flavor of the advice we give all the time. If you can't fix it, make it more visible.
And the thing to make visible is the flow of value. So do some lightweight value stream mapping to show how an actual increment of value gets from idea to production. Who has to touch it, how long it waits at handoffs. And that's gonna start showing where the real cross-functional team exists, scattered across the current teams.
This makes the cost of delay more obvious to people who might be able to do something about it. And this changes over time. So this would be a thing you don't just do once, but you do regularly and show how value passes through teams.
Now, we say this in all of our other episodes related to team structure. The best team structure for maximizing the flow of value is going to be one where complexity largely lives inside of teams. You would have a value stream map that, um, basically looks like a scrum diagram. An item goes into the team, they plan it, they work on it together, they finish it.
And the less it looks like that, the more it's a signal that you have complexity spanning teams. And if you wanna make a strong case for fixing things like this, it's not going to be "agile says so," or "the scrum guide says we must have cross-functional teams." It's gonna be making the economic case.
Once you've visualized that flow of value, you can start to quantify what's the cost of having a really long cycle time, having things wait, having rework, and then you can project the potential benefits of reducing the cycle time and wait time dramatically.
And I think we talked about an example of this in a previous episode about making things visible. Link to that in the show notes.
Peter: Most people working on agile teams don't own the org structure. They don't own the design. But they can still reduce the pain of dependencies, they can improve flow, and they can build the economic case for future changes.
You're probably already mapping dependencies, so start there and first, identify where your dependencies are spanning complexity. Second, resolve that complexity together even across teams rather than try to plan it all away. And third, make the flow of value visible across and through teams so that you can optimize it.
And then these three strategies help you work more effectively right away while building the case to better influence for change later.
Richard: And we love helping people solve these kinds of problems in their organizations. So if you'd like to talk through how this applies to your context, we'd be glad to help you visit humanizing work.com and schedule some time with me or Peter.
Peter: And we mentioned CAPED as one of the techniques. If you're interested in learning more about CAPED, we have our next Certified CAPED Consultant workshop coming up in February. We'd love to see you there.
If you've got some value from this episode and you wanna support the Humanizing Work Show, the best thing you can do if you're watching on YouTube is subscribe, like the episode, and click the bell icon to get notified of new episodes. And drop us a comment with your thoughts on today's topic.
If you're listening on the podcast, a five star review makes a huge difference in whether other people who'd benefit from the show find it or not. So we appreciate your support in those ways.
Richard: Thanks for tuning into this week's Humanizing Work show. We'll see you next time.
