If you are organized as platform team, middleware, and front-end teams, you have a component team organization. That made sense at one point in your history. But if you are transitioning to agile or have transitioned, and if you want to use agile on a program, that might not make much sense now.
If you have a program, you have many people in your teams. Your platform team might not be 7 people, but several teams, maybe 50 people, if you are large enough for a program. Your middleware teams could be another 100 people, and your front-end teams could be another 100 people. You have lots of people and lots of teams.
I bet you do not have an even ratio of platform, middleware, and front-end teams. You have experts, here, there, and everywhere. And, if you are anything like my clients, you have trouble releasing features in an agile program.
What are the problems?
- You have experts embedded in a wide variety of teams
- The experts need to multitask to serve a variety of projects, so you incur a cost of delay to multitasking and queues
- You are not releasing features. You have trouble when the components come together.
Even if the teams are agile, your program, the collection of projects is not agile.
What can you do?
You can ask the organization to try this as an experiment, for no longer than 2 weeks:
- The only measure of success is running tested features. And, no one, especially no manager, gets to compare teams. This is an experiment that the organization is going to learn from. Some teams will have small and easy features. Some teams will not. This is not a competition. If you start comparing teams, the teams will game this measure and the organization will lose the learning. It’s not about the number of features. It’s about learning how to manage the stream of features through feature teams.
- Ask three teams to volunteer: one platform, one middleware, and one front-end team. If more teams want to volunteer, fine. But you need three.
- Those teams stop multitasking. Those teams agree on one ranked backlog among the three teams. (I know, this might be the most difficult thing your organization has tried. I know you have experts. Ignore the fact you need experts everywhere. Agree on only one ranked backlog.)
- Ask these three teams to self-organize as feature teams for now. No changing managers. No changing desks. They get to decide how to organize. If you are a manager, no decreeing who is a feature team with whom. Let the teams decide who is on what team. This works best in one large room. However, I have seen geographically distributed teams who were desperate to release a feature do this over distance.
- Ask the Product Owner for these teams to make the stories as small as they can make them, preferably one or two team-days or less. This could be a huge challenge for the Product Owner. That’s okay. This is an experiment. I recommend a kanban board and limiting work in progress for this experiment.
- Tell the teams that if they don’t have the expert they need for a story, that’s okay. They can pair, swarm, or mob together to get the story done. But, they are not allowed to interrupt another team.
- The teams work on their backlog for this experiment (not any longer). They see what happens when everyone works in feature teams of their own making and no one multitasks, to get features to done. Remember, this is an experiment.
- Retrospect at the end of this experiment so they can see what happened.
- Decide what to do next. This is an experiment.
To sum: One self-organizing team, composed of platform, middleware, and front-end people. One backlog. One product owner. No longer than two weeks. Visualize the workflow. Limit work in progress. The only measure of success is running, tested features. No multitasking. Retrospect at the end. See what happens.
There are many things that can go wrong. But, there are many possibilities of learning here. This works best if the managers step back and don’t interfere. It works best with collocated teams. You can do this (and I have) with geographically distributed teams.
When I’ve facilitated this, the teams learn tons about how to work together and what they needed to do for their program. In several organizations, they wanted to do this again as an experiment.
Managers have to allow the teams to organize the way the product requires. Otherwise, you have Conway’s Law in spades.
When I have done this, I have had these results:
- Most of the time, the teams were able to finish some of the features in their backlog without too much trouble. These features required some of the team to work together, either discussing the feature, or pairing.
- They were able to finish most of the features in their backlog with a little trouble. These features required the entire team to work together.
- Some of their features were too large to finish in the timebox.
These results don’t surprise me. I bet they don’t surprise you.
Every so often, teams have trouble finishing any features. They learned that they did not have sufficient expertise to do anything on their features in their backlog. One team spiked a feature for a day, swarming on it. They had more questions than when they started. They needed an expert who was in another team.
If you put the focus on releasing running, tested features, that is what people will do. But you have to focus on it.
Component teams aren’t bad, per se. But component teams don’t get you running, tested features. This is one possibility. Based on your experiment and reflection, you could try something else.Tags: component teams, experiment, feature teams, geographically distributed teams, program management, project management, self organization