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
You 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:
- 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
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Product Roles, Part 3: Product or Feature Teams vs Project Teams Opinions expressed by Java Code Geeks contributors are their own. |
