Number of backlogs and multi-learning: 3) feature group

In this article, we shall look at a variant of the functional team and component team structure - feature group. We shall revisit the dynamics with functional team and component team, and see how much similarity and difference feature group has with them, in terms of its impact on the agility and the lever. 

#backlogs and multi-learning - article 3.png

Feature group is also called feature project. It is formed to deliver customer value, consisting of people from various functional and component teams. Each member has its own work and priority, thus its own backlog. Same as the functional team and component team structure, for the value delivery, it requires the work in multiple backlogs, and they are dependent on one another. The difference between them is on whether those backlogs are responsible by functional team and component team, or by functional members and component members in the group.

Feature group

Let's start from the same diagram for the functional team and component team structure, and understand how it applies in the context of feature group. 

Thumbnail image for #backlogs and multi-learning - article 2.4.jpg

Individual responsibility

Members in the feature group take individual responsibility for either function or component, thus, have multiple backlogs. Why?

B1-loop: specialization for efficiency

The functional or component specialization is good for efficiency. It is now on members, rather than teams, but the same efficiency thinking applies.

This weakens the group's common goal, and likely leads to the following dynamic.

R2-loop: Local identity hurts collaboration

Members still keep strong local identity for their functions or components. This hurts collaboration, which leads to 1) increase integration effort, thus lower efficiency; 2) increase integration time, thus longer e2e cycle time.

The feature group could lessen the silo thinking, as the group may develop a common identity in addition to local identity, something like this - "you belong to this 'team' (feature group), nevertheless, you still do the work in your speciality only."

Cycle time

In the structure of functional team and component team, the related parts may be done at different sprints, thus, the e2e cycle time could be several sprints long. However, the feature group should have the common goal of delivering customer value within the same sprint. In that case, the level of synchronization improves, then, waiting is confined to a sprint. The longest e2e cycle time would be a sprint. This also lessens the below problem.

R4-loop: Rework hurts efficiency

The rework caused by asynchrony still exists, but with the improved level of synchronization, the resulting rework gets decreased.

With the dynamic requirements, the needed effort in various functions and components will change. With members having their own backlogs (B1-loop), it naturally leads to:

1) Partial allocation

Some members will work in multiple feature groups, then multi-tasking ensues. What is missing in the above diagram is: more multi-tasking, lower efficiency. This creates another unintended impact on efficiency.

2) Temporary group

Group members will change accordingly, thus the group becomes temporary.

R3-loop: Group instability hurts collaboration

Temporary group hurts collaboration, and it is hard to sustain the improvement. The unintended impact on efficiency still exists.


R1-loop: Over-specialization hurts collaboration

Over-specialization does not get fixed when members have their own backlogs (B1-loop), which results in partial allocation and temporary group. This continues to hurt collaboration, and creates unintended impact on efficiency.

In summary, the main dynamics and problems with functional team and component team remain with feature group. However, feature group may have a common goal of delivering customer value within the same sprint, and develop a common identity as a group. Therefore, it is usually better than no group at all, in terms of our goal for agility.

Feature team

To improve further on agility, having fewer backlogs in the feature group is a key lever. In fact, this is the main difference between feature group and feature team. The real feature team has only one backlog, and members take shared responsibility.

R5-loop: fewer backlogs drives broad learning

Feature team may also start with multiple implicit backlogs due to the skill constraints, but by having one explicit backlog, it drives multi-learning and reduces the number of implicit backlogs over time. On the contrary, feature group accepts the status quo and keeps multiple backlogs forever.

Having one backlog removes the need for partial allocation and temporary group. With the dynamic requirements, the needed effort in various functions and components will still change, and there will be mismatch between the work and the skill. When that happens, we take advantage of it and trigger cross-functional and cross-component learning.

The same list of techniques for cross-functional and cross-component learning still applies.

  • specification by example
  • collective code ownership
  • pair/mob programming
  • communities of practices (both functions and components)
  • component mentor
  • current-architecture workshop
  • multi-team design workshop

Multi-learning further enables fewer backlogs, until eventually achieving one backlog. By then, feature group becomes feature team.

About this Entry

This page contains a single entry by Lv Yi published on June 21, 2019 11:05 AM.

Number of backlogs and multi-learning: 2) functional team and component team was the previous entry in this blog.

Number of backlogs and multi-learning: 4) specialized feature team is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.