As I’ve written these product role posts, a number of you have asked about how to use component teams. You might have a security team. Maybe a performance team. Regardless of my desire, you have component teams. You want a more agile approach to manage the interdependencies among the teams. You want to be able to deliver small features more often.
Visualize Where You Want to Be
I like to start with the results I want to see. First, remember the component teams by layer image?
This shows how we need component teams to deliver smallish slices of features.
Let’s see how to make that work.
I have several assumptions for being able to use component teams:
- Each “task” or piece of work is a connected story to the other layers of the product. Nothing is only architecture or design.
- Each team can check something in each day or so. Nothing is longer than a cycle time of 2 days. We’ll see why this is important in a minute.
- Each team has the capability to build and test the entire product at all times. That way, they know they’re not doing something wacko with the product.
Measure the Cycle Time to See Cost of Creation
The reason I said each team has to be able to check something valuable into the code base is about cycle time.
The product cycle time is the addition of all the component teams’ cycle time. Addition.
Here’s how this works for a client of mine:
The teams work hard to make this cycle time work. They do no other work. They still have a full cycle time of more than two work days.
Note that each team has a cycle time of a day or less. Because they can’t see the total feature and because they do thicker pieces to manage the handoffs between teams, everything takes longer.
In another program, the program manager realized that while each team “finished” inside of a day, their final system test for each feature took two more days.
Component Teams Increase the Cost of Creation
In my experience, when we have component teams, we have interdependencies. Interdependencies create wait states, even if we don’t have explicit wait states as with the Best Possible Cycle time image above.
One team might not take a long time as a team. But the feature, the slice, takes longer than we might imagine and longer than we want.
Consider Alternatives to Component Teams
I’ve been trying to solve this problem for years now. Some organizations have so ingrained component teams—working across the architecture rather than through it—that I don’t think they can easily solve it.
Here are ways you might consider what’s possible:
- Focus on flow. Measure your cycle time for a total feature. Not what each team does, but for a usable feature. (Story, some form of user-based value.) Ask yourself if that time is acceptable. If so, fine. You’ve solved your problem.
- If your cycle time is too long for what you want, please review the flow efficiency series. That will help everyone rethink what they want. Do they want to focus on the individual or optimize for the feature? If they choose individual, you’re done.
- If you do want to optimize for the features, invite the teams—not the managers—to address this problem. Consider a lean coffee or an open space. Let the teams develop their answers to the cycle time problem. You might have to educate them on possibilities they hadn’t considered before. As part of that education (cycle time, flow efficiency), do consider sharing the experiment in self-organization to create feature teams. Once the teams decide what to do, they can tell the managers. The managers say, “Thank you,” and look for features. (Do I need to explain the roles of the agile manager?)
I’m not a fan of adding more process. I am a fan of explaining the outcome(s) I want and helping people explore the problem space so they can consider alternatives.
Yes, I have at least one more post in this series.
Series so far:
- Product Roles, Part 1: Product Managers, Product Owners, Business Analysts
- Product Roles, Part 2: The Product Value Team
- Product Roles, Part 3: Product or Feature Teams
- Product Roles, Part 4: Product Orientation and the Role of Projects
- Product Roles, Part 5: Component Teams to Create Slices
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Product Roles, Part 5: Component Teams to Create Slices Opinions expressed by Java Code Geeks contributors are their own. |
