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.

Thumbnail image for revisit feature team - line group snapshot 1.jpg

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.

revisit feature team - line group snapshot 2.jpg

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.

 feature team

feature project

stable team that stays together for years and works on many features

temporary group of people created for one feature or project

shared team responsibility for all the work

individual responsibility for 'their' part based on specialization

self-managing team

controlled by a project manager

results in a simple single-line

organization (no matrix!)

results in a matrix organization with resource pools

team members are dedicated - 100% allocated - to the team

members are part-time on many projects because of specialization

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.

revisit feature team - one large team.jpg

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.

revisit feature team - two small teams.jpg

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

About this Entry

This page contains a single entry by Lv Yi published on February 9, 2016 2:34 PM.

Shared backlog with one priority was the previous entry in this blog.

Two Approaches for Solving Dependency is the next entry in this blog.

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