One Experimental Possibility: Self-Organization from Component Teams to Feature Teams

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.

6 thoughts on “One Experimental Possibility: Self-Organization from Component Teams to Feature Teams”

  1. I really like the idea of feature-teams as a kind of pattern to reduce silos and friction but i also like another pattern to reduce silos and friction: “You build it, you run it”. Both patterns seems somehow othogonal to each other, you can’t run features, but only components.

    So do one have to decide which is more appropriate in your organisations-maturity-lifecycle and isn’t the devops/running-problem even more important to tackle because it creates the bigger boundaries?!

    1. Hi Kim. You do have to decide which is more appropriate in your organization. I’m for thinking over blind adoption, always.

      If you can get to features with component teams, fine. I was just thinking, maybe your product is a library. Maybe you don’t need feature teams. Maybe it’s okay if you stay in component teams. In that case, “you build it, you run it” is great.

      Whatever kind of team you have, I hope you release small features. The smaller the feature, the easier it is for the devops or the production support people (whomever they are) to support the released features.

      If you do have boundary problems between teams, the smaller the feature, the easier it is to understand where on the boundary the problem is. “Is it my problem in the middleware, or is it your problem in the platform?” If it is “our problem” as a feature team, it is less of a problem. If the feature is small, it might be more understandable. Maybe. Sometimes, small features produce mighty big problems.

  2. Pingback: Five Blogs – 25 September 2014 | 5blogs

  3. Pingback: Revue de Presse Xebia | Blog Xebia France

  4. For having experiments features teams for almost a year, it’s not a silver bullet.

    The main mistake we made was taht we did an organization big bang by moving from full component team to full feature team in one day. We get 6 month before we get useful feature out of dev, productovity was very low.

    One trap on feature, is we get some teams of generalists and we have to do an epic which need some particular expertises in some area. Some expertise was so low in the feature team that almost nothign happen during months before getting something working end to end.

    To force the picture, component vs feature team is expertise vs generalist.

    At the end we change the organization to a mix of component & feature team to get the best of all world. Main benefit is even in component team we stop multi tasking (multitasking is not good for quality), because small stories ends up in feature team and component team can focus on complex stories which need expertises in one particular area.

    1. Hi Youen, wow. What an experience you had.

      I’m glad you wrote about your experience. Your experience is similar to mine. It is possible to do a big-bang approach to change, but it is quite difficult, as you discovered. I like an agile approach to change: do a little bit, get some feedback, and try/experiment with the next piece. Start small, and see what happens.

      As you discovered, the component teams are experts, which is why I suggested asking 3 teams (or whatever you need) to work together, so they would have the expertise to do what the product requires. You did this by having a mixture of component and feature teams.

      Stopping the multitasking is essential. No one can do great work if they multitask.

      Small stories always help you make progress, too. I wonder if the component teams could make progress, if they could make their stories smaller? Well, maybe that is your next experiment. One thing at a time.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: