Revisit feature team

I visited a client recently on consulting LeSS. They assured me that they had feature teams in place, "they are stable as line organization unit, and the size varies from 10 to 15 people." The large size smelled. I learned further... It turned out to be like this.

Line team A is one of the few feature teams in their organization. In line team A, there are 12 members, named as A1-A12. At one point of time, this is how the work is done inside line team A. They are developing 5 features, and different members are working on different features. After a while, it changes. They form different teams for new features, as shown in the below.

So, what is the real team here, the line team A or various feature x teams?

What defines a real team? Roughly based on the book "The Wisdom of Teams: Creating the High-Performance Organization".

• common goal
• shared responsibility
• interdependency among members

In short, the members collaborate to achieve common goal with shared responsibility.

As only those people working on feature x are responsible for its delivery, rather than the whole team collectively responsible for set of features, I would say that the line team is not a real team, it is more like a working group. The real collaboration unit are those feature x teams. So, we get stable line A working group and dynamic feature x team.

In traditional matrix organization, feature project is formed with members from various functional line groups to deliver a feature. However, the dynamic feature x team here has some major difference than feature project. The below table from feature team primer summarizes the differences between feature team and feature project.

Except for the first point, feature x team in this organization is pretty much in line with the definition of feature team. The main difference is whether it is stable or temporary team.

Why does stability matter? The main supportive evidence comes from the book "Leading Teams: Setting the Stage for Great Performances", where it is stated that team performance peaks at team's year 3-4.

How do we create stable feature team from the current state? As line A is already stable, we may try to make line A team real team. It means that the whole line A team takes shared responsibility for set of features, and it self-organizes to deliver with collective ownership.

Software development is inherently uncertain, and team will inevitably encounter unexpected things. The whole team can respond to those and take collective effort to adapt. For example, when 3 members (A1/A2/A3) work on feature 1 and find that it is way more work than expected, and feature 1 has the highest priority for the whole team, they bring it up and discuss with other members and together decide how to adapt. As it becomes real team, it makes much more sense to hold collaborative activities such as planning, daily standup, review and retrospective with the whole team. The team leader or team coach focuses on increasing the whole team awareness of the overall situation and fostering the shared responsibility in making adaptation.

The challenge with this approach is the large size. Based on both research and practical experience, small-size team is preferred. In Scrum, 7+/-2 is recommended size, and I would personally recommend 5-7. Small team is usually more effective, and it is more possible to create collective ownership. Therefore, instead of building the large line team, we may split it into two smaller teams. Each team is taking shared responsibility for set of features, and two teams are both stable over time.

Once you make it work, you may then blur the boundary between them and develop the broader sense of ownership. Boundary creates identity, which is good for team development; while boundary creates silo too, which is bad for the whole product. We try to hit the balance. Will you gradually make the large line team work again? I do not know, and it would be interesting to experiment...