Rethinking Component Teams for Flow

A couple of weeks ago, I spoke locally about 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/UI people. Or, they can’t find enough database people. Or, enough writers. Or 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 a not-complete 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 and CoD Due to Other Teams Delay. Also See Diving for Hidden Treasures.)

What can you do?

  1. 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).
  2. 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).
  3. 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.
  4. Rearrange backlog ranking, so 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 resource efficiency, not flow efficiency. And, 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, 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.

6 Replies to “Rethinking Component Teams for Flow”

  1. Great post! I got frustrated just reading it.

    At first I asked myself how blind an organization has to be to not see the folly of having only 12 overcommitted experts for 200 teams. Then I became more empathetic and imagined they “found themselves” in this position because they naively staffed up the 200 teams and only later realized how much UI work was involved.

    I like the kanban board solution because it can provide enough evidence to move the organization to act effectively. But I can only live with that if I’m sure the organization treats the whole debacle as part of their learning curve, not to be repeated once they’ve learned they need to staff up UI or staff down their ambitions.

    If, on the other hand, it’s going to be treated as business as usual, it’s an engagement I would prefer to decline.

    1. Bob, they got here because they used to be waterfall. The idea was that the UI people would do “all” their work after the requirements. Of course, they had a ton of rework. The managers didn’t understand why things were so “slow”. Now that they can see the time, they have more options.

      One of the things I like about agile approaches is that we have multiple ways to visualize the work. In waterfall, I found it difficult to visualize work. In agile, I find it much easier, as this kanban shows. What people do with the visualization? Well, that’s always the big question.

    1. HI Ian, let me ask you a question: How does quantifying team capacity have any value if the team is bottlenecked by a scarce expert? I’m not trying to be difficult. I just don’t see how to quantify something with bottlenecks. I can calculate the cost of delay. I can monitor cycle and lead times.

      Maybe you’re asking this question: How do you calculate the capacity of a team when you count the work flowing through the scarce expert? I would count the number of features that team can release over time. The problem is that the “team” changes when the expert comes in/leaves.

      Are you asking a different question and I’m being difficult? (Sorry, not trying to be.)

  2. Hi Johanna, can you give any guidance on how to transition an organization from component teams to something more cross-functional like feature teams?

    1. Hi Rick, you might consider the ideas in this post: One Experimental Possibility: Self-Organization from Component Teams to Feature Teams.

      Here’s what I have found (which might not be your experience): Once people realize the flow of work is not contained inside the team, they get frustrated. If you ask the teams, “What can we do about this?” they might not have any ideas. If you say, “What about we try this as an experiment?” and suggest self-organization, they have at least one idea. The key is to help the teams get to at least three ideas.

      Some other ideas teams have considered:
      – Mobbing with the expert. Sometimes, that makes the expert nervous. Sometimes, that makes the expert worry about their role in the org.
      – Having the expert teach a class in the expert’s basics. (Often, the team will decide to pair/mob on that work.) The expert then reviews the team’s work until the team gets it right.

      Part of this is the managers transitioning their thinking from resource efficiency to flow efficiency. If the compensation system is set up for managers to be rewarded on the accomplishments of “their” people, it might be a lost cause until you can change the compensation system.

Leave a Reply