Product Roles, Part 3: Product or Feature Teams vs Project Teams

An agile approach requires a cross-functional team. That means that everyone on the team focuses on the same intent. That intent might be an entire product. It might be a feature set as part of a larger program. But, the team focuses as a team.

That cross-functional team is a product team or a feature team. I tend to call them feature teams because they might move from feature set to feature set when they work as part of a program or over time as the product evolves.

I don't actually care what you call these teams, as long as you have the same intent: the team works together to finish work on a product or feature set.

Feature Teams Don't Have Cross-Team Interdependencies

implement by featureYou might have seen my implement-by-feature images before. Notice the slicing of the feature through the architecture. When a team slices through the architecture, they are able to create small stories, the kind of stories that allow experiments and business value verification. (The minimums in Part 1.)

Can Your Team Create Features Alone?

But, I don't see teams being able to implement by feature often enough. I more often see this organization, where the teams focus across the architecture, not through it.

The platform team provides the red pieces at the bottom.  The platform team is a cross-functional team with developers and QA and maybe a DBA if they need it. However, even if they are cross-functional, they are still a component team because they can't create a feature slice through the architecture.

Neither can the Middleware team (dark green), or the App layer team(s) (blue) or the GUI (teal). (If you are color blind, can you see any of the colors in here? If not, what would work for you? Thanks.)

When an organization is based around project teams, they too often organize like this. The managers think the various component teams are more efficient if they focus on a layer of the architecture, rather than slicing through the architecture.

When organizations create component-based teams, even if the teams are cross-functional, they need to plan all together to see when a feature might be ready. They do need everyone in the room for Big Planning, where they have string connecting the various interdependencies. I explained about this in How Long Are Your Iterations, Part 2.

The planning is a problem because the team configuration means we interrupt the teams on a regular basis to replan. They're not working on new features. They spend time estimating and organization in prep for a new plan that might need to change the next week.

That's a problem, but it's even worse for the product value team. When teams organize by component, not features, the product value team cannot shepherd the business value of the product.

Change Team Organization to Focus on Product or Features

I do recommend that the teams move from component-based teams to feature teams. I suggested one way everyone in a given location could do that in One Experimental Possibility: Self-Organization from Component Teams to Feature Teams.

The value of product or feature teams is that the product value team can then create small rolling waves and replan without a lot of pre-work in the form of story breakdown with estimation. Instead, they can use cycle time. For example, teams might always do an experiment in one day—they would timebox the work to one day and work on just that experiment as a team in one day.

When feature teams don't rely on anyone else to finish a feature, lots of the difficulties in product development becomes easier:

  • The team can deploy on its own
  • The team can define its various cycle times, either with measurement or with timeboxing
  • The product value team can replan more often with less pain
  • Everyone spends much less time in meetings and in estimation because the  work has more ease.

I will have to write a post about the cost of creation. Argh, this series is getting longer!

When everyone focuses on product-based roles instead of project-based roles, everyone wins. (You can still do projects. Yes, that's part of the next post, I think.)

Series so far:

2 Replies to “Product Roles, Part 3: Product or Feature Teams vs Project Teams”

  1. Joanna,

    I agree with the concept, but I’m not sure how to implement this in a large organization running multiple projects in the same application concurrently.

    For example, how can we give each project team autonomy over their own release cycle if there’s another team changing the same UI?

    Thanks.

    (PS Sorry if this is duplicated. I kept getting an error when submitting the comment logged in to Google.)

    1. Drew, thanks for your perseverance. It looks like one comment to me. On to the problem.

      A couple of questions and don’t feel you must answer in public:
      – Do you have a program-wide roadmap so everyone can see the big picture? That helps the teams themselves sequence the work.
      – Do the teams release something small every day? If not, how often do they release? The more often the teams release something small, the easier it is to sequence the work.

      I’m wondering about the need to change the UI often. If the changes challenge the teams, what happens with the users?

      Too often, I see this when the product people don’t agree on a strategy for the entire product. Or, when the projects are independent instead of collaborating as a program. The strategy helps everyone see the top goal. Each project might have its own specific contributions for that goal. When the teams understand the goal and they all work towards it, they can decide how to sequence the work.

      I also wrote Managing the Stream of Features in an Agile Program several years ago. At the bottom, I suggested that yes, component teams can integrate their work as a series. I need to write more about that and add pictures.

Leave a Reply

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