Creating the Right Conditions for Stable Teams

Anytime something must be managed outside of the team, we’re creating a dependency. And dependencies kill Agility.

But sometimes we need expertise on multiple teams and only one or a few people with that expertise. How do we keep them from becoming a bottleneck, or destabilizing our teams?

It’s all about making trade-offs and balancing tensions.

Here are some teaming conditions should you avoid, and what to do instead.

Get on-demand access to watch the complete talk along with all five of the other Business Drivers of Agility series webinars with Mike Cottmeyer here.

Transcript

So here’s the interesting thing. There’s always going to be a tension, and this is where we got into in pretty good depth in the encapsulation versus orchestration thing.

So you have a team, right? And I can do one or two things, right? I can put a person on a team and leave them there for a little bit. And I can measure maybe velocity goes up sometimes velocity goes down when you add another person to the team, right? There’s no linear correlation necessarily between human beings and the throughput of a team.

So my first inclination would say, okay cool drop that person on the team and don’t create a dependency between them, okay? Probably the thing I would hate to see the most, is to have multiple teams and have that single person on all three of these teams. And manage that way, because here’s the problem, right? If the person over commits and gets overloaded on any one of these three teams, they are going to make the prioritization decision about who gets the work done and who gets starved, okay? That’s the condition I want to avoid is time slicing people across multiple teams.

What I will usually do… What I’ll usually find these are all just trade-offs and it’s all situationally specific, is if I have a Kanban up here, that’s like doing some sort of analysis, design, build, test, deploy queue. What I might do is I might take this person if they’re like a specialist and they’re contributing to the architecture design or definition of the feature or something like that, what I might do is put that person up here and have them operate on the highest priority features that are coming in at this level. So that when things go down here when they get into build, then that person’s expertise is captured in the backlog. And they’re unavailable ad hoc resource for this team.

So everything is tensions and trade-offs, right? There’s never a super, super clean answer. And that’s where I started in the first thing with this idea of encapsulation versus orchestration.

My preferences to encapsulate ’cause that’s going to give you the greatest agility. Where you can’t encapsulate, you have to orchestrate. The worst thing you can do, and this is what the… And using that language, right? If I put a person here, a person here, a person here, the same person, and I have no orchestration layer, then all I’m doing is I have unmanaged dependencies or I have this person actually managing their own commitments. And that can be an incredibly volatile thing. And you’re likely to starve one of these teams from being able to get their work done. So look for opportunities for encapsulation first. And if you can’t encapsulate explicitly orchestrate and I liked the idea of doing that with Kanban. But avoid the condition where you put an unmanaged dependencies between teams. That’s how I hunted down.

My sister one time said she goes like, “How do you walk into any organization “and like have a recommendation “on how they should do something “or take these random questions on a webinar?” It’s because at the end of the day, these are your companies, they’re your decisions to make, they’re your objective. Like, it’s your stuff, right?

What I’m doing is I’m walking you through the trade-offs that you have to make. And I’m basically pointing out when you’re violating the laws of physics.

So encapsulate where you can, that’s preferable, orchestrate where you can’t, that will reduce your agility. But if you choose to time slice people and create an unmanaged dependency, you will likely create douse. And you can do that too, right? I just don’t recommend it.