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.

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.

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.

R3-loop: Rework hurts efficiency

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

Specialization

R1-loop: Over-specialization hurts collaboration

Over-specialization does not get fixed when members have their own backlogs (B1-loop). The resulting narrow knowledge breadth continues to hurt collaboration, and creates unintended impact on efficiency.

Besides, with dynamic requirements, the needed effort in various functions and components will change, which creates two more dynamics, shown as the additional R5 and R6 loops in the below updated diagram.

As members have their own backlogs (B1-loop), the change on effort leads to:

1) Partial allocation

Some members will work in multiple feature groups, then multi-tasking ensues.

R5-loop: Multi-tasking hurts efficiency

More backlogs leads to more multi-tasking, then lower efficiency. The multi-tasking creates another unintended impact on efficiency.

2) Temporary group

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

R6-loop: Group instability hurts collaboration

More backlogs leads to less stable group. The feature group consists of people who are able to work on various backlogs. The more backlogs, the more change the group composition endures. It takes time for the group to jell and become effective. Temporary group hurts collaboration, and is hard to sustain the improvement. The group instability creates another 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.

R4-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.