(Originally published by Lv Yi on June 21, 2019)
In this article, we shall look at a variant of the functional team and component team structures - a feature group. We shall revisit known dynamics of the functional and component teams, and see what’s similar and different between them and a feature group in terms of impact on organizational agility.
A feature group is also called a feature project. It is usually formed to deliver some special customer value by picking people from various functional and component teams. Each member has their own work and priority, thus their own backlog. This is similar to the functional team and component team structure where all the work needed for value delivery is in multiple interdependent backlogs. The difference is who is responsible for specific backlogs, teams or individual members of a feature group.
Let’s start with the diagram for a functional team and component team structure, and understand how it applies in the context of a feature group.
Members in a feature group take individual responsibility for either function or component, thus, they have multiple backlogs. Why?
B1-loop: specialization for efficiency
The functional or component specialization is good for efficiency. Except that now it is 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 a strong local identity with their speciality. It hurts collaboration and leads to 1) increased integration effort, thus lower efficiency, and 2) increased integration time, thus longer e2e cycle time.
The feature group could reduce silo thinking by developing a common identity in addition to local identity. Something like: “You belong to this ‘team’ (feature group), nevertheless, you still do the work in your speciality only.”
In organizations with functional and component team structure, related parts may be done in 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 and waiting is confined to one sprint. The longest e2e cycle time would be one sprint. This also lessens the problem below .
R3-loop: Rework hurts efficiency
The rework caused by asynchrony still exists, but with improved level of synchronization, the resulting rework gets decreased.
R1-loop: Over-specialization hurts collaboration
Over-specialization is still there when members have their own backlogs (B1-loop). The resulting narrow knowledge continues to hurt collaboration, and creates unintended impact on efficiency.
Besides, with dynamic requirements, the effort needed in various functions and components will change, which creates two more dynamics, shown as the additional R5 and R6 loops in the 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 with ensuing multi-tasking and associated context switching cost.
R5-loop: Multi-tasking hurts efficiency
More backlogs lead to more multi-tasking, which lowers efficiency. In other words, multi-tasking creates another unintended impact on efficiency.
2) Temporary group
Group members will change according to the amount of specialized work needed. Thus the group becomes a temporary group.
R6-loop: Group instability hurts collaboration
More backlogs lead to a less stable group. The feature group consists of people who are able to work on various backlogs. More backlogs, more changes the group is likely to endure. It takes time for any group to jell and become effective. Temporary groups tend to have low collaboration levels, and it is very hard to introduce and sustain any improvements. Thus, group instability creates another unintended impact on efficiency.
In summary, the feature group has the same main dynamics and problems as the functional and component teams with additional problems related to multi-tasking and group stability. However, a feature group may have a strong 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.
To improve further on agility, having fewer backlogs in the feature group is a key lever. In fact, this is the main difference between a feature group and a feature team. A real feature team has only one backlog, and members take shared responsibility.
R4-loop: fewer backlogs drive broad learning
A feature team may also start with multiple implicit backlogs due to skills constraints. But one explicit backlog drives multi-learning and reduces the number of implicit backlogs over time. On the other hand, a feature group accepts the status quo and keeps multiple backlogs forever.
Having one backlog removes the need for partial allocation and temporary groups. With dynamic requirements, which is very common, the effort needed in various functions and components will still change, and there will still be a mismatch between work and skills. 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.
Multi-learning further enables fewer backlogs, until eventually achieving one backlog. By then, a feature group becomes a feature team.
RSS feed