Rethinking Component Teams for Flow
Rethinking Component Teams for Flow
How can you fix shortcomings on your teams? A common approach is to bring in specific area experts to augment your capabilities, but this can be hard to manage.
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
A couple of weeks ago, I spoke locally about how to manage your project portfolio. Part of the talk is about understanding when you need project portfolio management and flowing work through teams.
One of the (very sharp) fellows in the audience asked this question:
As you grow, don’t you need component teams?
I thought that was a fascinating question. As agile organizations grow, they realize the value of cross-functional teams. They staff for these cross-functional teams, and then they have a little problem. They can’t find enough UX and UI people, or they can’t find enough database people, or they can't find enough writers, or they can't find some other necessary role for the “next” team. They have a team without necessary expertise.
If managers allow this, they have a problem: They think the team is fully staffed, and it’s not. They think they have a cross-functional team that represents some capacity. Nope.
Some organizations attempt to work around the scarce expertise problem. They have “visitors” to a team, filling in where the team doesn’t have that capability.
When you do that, you flow work through an incomplete team. You’re still flowing work, but the team itself can’t do the work.
You start that, and sooner or later, the visitor is visiting two, three, four, and more teams. One of my clients has 12 UI people for 200 teams. Yes, they often have iterations where every single team needs a UI person. Every single team. (Everyone is frustrated: the teams, the UI people, and management.)
When you have component teams and visitors, you can’t understand your capacity. You think you have capacity in all those teams, but they’re component teams. They can only go as fast as the entire team, including the person with the scarce expertise, can deliver features. When your team is not first in line for that scarce person, you have a Cost of Delay. You’re either multitasking or waiting for another person or you’re waiting for an expert. (See CoD Due to Multitasking, CoD Due to Other Teams Delay, and Diving for Hidden Treasures.)
What can you do?
- Flow work through the experts. Instead of flowing work through teams that don’t have all the expertise, flow work through the experts (not the teams).
- Never let experts work alone. With any luck, you have people in the team working with the experts. In Theory of Constraints terms, this is exploiting the constraint. It doesn’t matter what other work you do. If your team requires this expertise, you need to know about it and exploit it (in TOC sense of exploitation).
- Visualize the flow of work. Consider a Kanban board such as the one below that shows all the work in progress and how you might see what is waiting for whom. I would also measure the Cost of Delay so you can see what the delay due to experts is.
- Rearrange backlog ranking so that you have fewer teams waiting for the scarcity.
Here’s the problem: When you allow teams to compete for scarcity (here, it’s a UI person), you don’t get the flow of work through the teams. Everything is slower. You have an increased Cost of Delay on everything.
Visualizing the work helps. Flowing the work through the constrained people will show you your real capacity.
Needing component teams is a sign someone is still thinking in terms of resource efficiency, not flow efficiency. I bet some of you will tell me it’s not possible to hire new people with that skill set locally. I believe you.
If you can’t hire, you have several choices:
- Have the people with the scarce expertise consciously train others to be ready for them, when those scarce-expertise people become available. Even I can learn some capability in the UI. I will never be a UI expert, but I can learn enough to prepare the code or the tests or the experiments or whatever. (I’m using UI as an example.)
- Change the backlogs and possibly reorganize as a program. Now, instead of all the teams competing for the scarce expertise, you understand where in the program you want to use that scarce expertise. Program management can help you rationalize the value of the entire backlog for that program.
- Rethink your capacity and what you want the organization to deliver when. Maybe it’s time for smaller features, more experiments, and more MVPs before you invest a ton of time in work you might not need.
I am not a fan of component teams. You could tell, right? Component teams and visitors slow the flow of releasable features. This is an agile management problem, not just a team problem. The teams feel the problem, but management can fix it.
Published at DZone with permission of Johanna Rothman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.