Many of my clients feel stuck with their component teams. They feel they must implement across the architecture, not through it. That’s because the people are organized in component teams.
As the organization grows, so does the number of component teams. The more component teams they have, the more complexity they create in the teams, in the product, and in delivery.
Component “team” members become narrow experts. Work queues behind those experts. Everyone finds it takes more time to finish features.
Everyone finds it more challenging to create features and track progress. No one can tell anything about project or product progress. And the WIP (Work in Progress)? Very high.
These organizations often need release teams because the “team” creating the feature is already onto the next feature because they’re late for everything.
For me, this looks like a lack of cohesion inside a feature team and too much coupling between workgroups (those component teams). See this article on cohesion and this on coupling for more information.
Notice that tight coupling requires more interdependency, more coordination, and more information flow. That’s the overhead of component teams: more interdependency, more coordination, more information flow. (Often, lower finished feature flow.)
Component teams are a system problem. What made sense years ago doesn’t make sense any longer. And, the managers can fix this if they collaborate on the solution.
Why Component Teams Appear to Make Sense
If you think in resource efficiency, then it looks like component teams make sense. All these people are working on the same thing, right?
Nope. That’s an illusion.
I wrote about cycle time for component teams before. I added the image here, so you can see this organization’s best possible cycle time.
Most of my clients cannot deliver in 23 hours. A few of my clients can deliver features inside of a couple of weeks. Most of my clients have trouble delivering finished features inside a quarter. Several of these clients have different deployment/release teams because the component teams have already gone to the next set of work.
I think I have an idea why. When the component team idea started, the architecture looked like the nice small picture above, with a three-tier architecture.
Now, the architecture is much more complex, such as it might be in a program.
This image (from Agile and Lean Program Management) shows how a program manager might think of the architecture for an integrated system product. If your product integrates other people’s modules, your product architecture is even more complex.
Effect of Component Teams in a Large Product
Component teams have to go up and down (and often across in various places) to finish their features. This image on the left is how I often see component teams work through a large program. (I’m not an architect. I take the management perspective.)
The component team has to integrate their specialty into several areas in the platform, into several of the “products” and through the API and GUI. This “slice” is not a thin up-and-down as it might be in a smaller, less coupled product. I showed two features here, red and green. Each feature is unique which means it has its own complexity.
The component teams can’t solve this alone. If you can get everyone together in one place, you might find something like One Experimental Possibility: Self-Organization from Component Teams to Feature Teams.
However, in my experience, once you have a large organization with many component teams, this becomes a system problem the managers need to address.
What Managers Might Do to Increase Flow Through the Organization
My objective is to help the organization increase the flow of work through the system. And, I am under no illusion that the component team coupling is an easy problem to solve. (Some of my clients have hundreds of people in various component teams.)
Here’s an experiment that’s worked for me in the past:
- Can we live with the current cycle time? If so, maybe do nothing for this set of products. Consider changing for the next set of products.
- Understand what the products are. Often, the organization sees the component team as the product. One of my clients had “performance” as a product. Nope, performance is a characteristic of all the products. They had to use the equivalent of “the store” or “email” to use as the product. If you think of “related feature sets” as the product, that’s often good enough.
- Carve out that one product to use as an experiment.
- Dedicate some of the component team people to the product, the store or email in this example. Integrate those component team people into the feature teams.
- Ask the component team members to work closely with the feature teams. I happen to like pairing or mobbing more than I like swarming in this case. That’s because the component team members are experts.
- Make sure you have small stories in the feature sets so everyone can become accustomed to delivering something small as often as possible. I like daily. Measure the cycle time to make sure you have all the people you need.
- Retrospect and experiment as often as you can, to turn up what’s working and address what’s not working.
After you have one version of this working, consider another experiment.
One of my clients has experimented their way through six feature teams now. Each team has required a different approach. That’s because it’s a system problem—and each of the program managers and functional managers had to collaborate to fix the problems.
Is It Worth Breaking the Coupling from Component Teams?
The smaller the organization, the easier it is to address and fix system problems. If you have a large organization, can you break the coupling that component teams create?
You can, even in a large organization. Make sure you want to. That’s why I recommend you measure the cycle time before you start. (See Product Roles, Part 5: Component Teams to Create Slices for what that might look like.)
Make sure you check with the other people to see if they also want to address this problem. You will need to use your influence. (See the influence tag on this site for many articles and posts.)
Then, experiment your way to success. The more you need an agile approach for the business, the more you will need to eliminate component teams.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Component Teams Create Coupling in Products and Organizations Opinions expressed by Java Code Geeks contributors are their own. |
