The team organization is the core issue when scaling out agile methods to the company scale. Here, many may mention "feature teams" but often forget the true meaning of these two words!

You are willing to change your teams organization and understand the differences between a cross-functional team and a feature team? This article proposes a few approaches to understand these models, and more importantly to know which one to adopt.

1) Identify the pain points leading to a change of organization

Changing an organization is a complex human process. It takes time and presents difficulties that should not be underestimated. The first step before contemplating any solution is to get back to the root issues and make sure that change is a solution.

-> What pain points urge the will for a change of teams organization? -> Is such an organization change the actual solution to these pain points?

For instance, here are a few difficulties we came across in clients contexts where the team were organized in traditional silos:

• A time-to-market considered too slow
• A repeated difficulty to synchronise big projects requiring the coordinated inputs of several teams
• A hard time to innovate efficiently, to work differently
• Some low quality issues related to the team segmentation (e.g: who assesses quality? The dev team or the QA team?)
• Some communication issues between teams / silos (e.g: IT vs business)

In these contexts, it makes sense to plan a new organization aiming for the creation of multi-skilled teams.

2) Create cross-functional teams

A cross-functional team is a team gathering all necessary skills, from concept to production, to achieve the product. The SCRUM methodology, among others, promotes this model. In such a team, there is no more silo: everyone works together and is collocated to enable an optimal communication. For the same reasons, a small sized team is preferred: 6 to 12 people per team (pizza-team).

Such a team is made of enough people to achieve the project. Therefore, it must be given the necessary autonomy to take decisions according to the company's strategy, and the responsibility to reach its objectives (which of course must be reachable).

We can schematize a cross-functional agile team and other actors with whom the team interacts closely this way:

A few interesting questions arise here:

-> Is the company ready to create small collocated teams mixing business and IT (developers, testers, even operators) for them to work together every day? -> Are the members of these teams motivated by this gathering and the direct communication it enables? Depending on the company's culture, setting up such team structure may not be easy, especially when it comes to communication. Where it used to be ruled by documentation, it becomes more direct. Issues and their argued solutions become the responsibility of the team. Its members have to review their whole working habits.

Another issue also emerges: how to share knowledge between people of a same trade (for instance, front-end developers) who are now scattered into different teams. A possible solution is the creation of communities of practice enabling periodic meet-ups for these people to share their expertise and good practices.

At last comes the sensitive topic for any transformation: the (re)definition of roles within teams, including the new place for middle management who used to ease transit of information… To address these important matters, we recommend to test this kind of organization with 2 cross-functional teams comprising several people eager to experiment this organization. The try-out should last several months (at least 6 months). At the end of this pilot stage, the members will have apprehended and adapted the roles for a better match of the context, and will be able to provide a feedback on the experiment.

3) Create "Feature-" or "Component-oriented" teams

Feature team

To loosen coupling between cross-functional teams, some organizations specifically dedicate them to the development and support of a clearly defined functional scope. These are feature oriented teams, or Feature teams.

Here is an example by Henrik Kniberg of Feature teams as seen at Spotify:

-> Can the company identify within its activity independent features that could be handled by loosely coupled teams? -> Is the software architecture compliant with such organization?

It is worth stressing that feature teams need to be as independent as possible from each other, on both organizational and product architecture levels. A feature team must be able to deliver a new version of its scope without impacting other teams, fostering an optimal TTM.

Component team

"Component-oriented" teams:

• have a strong technological specialty (specific language, software package...), known by a small group of people,
• and/or manage a "service" used by numerous teams (billing tool, emailing service…) which should be kept whole for SLA consistency issues.

Dean Leffingwell (author of the SAFe framework) presents here this difference between Feature and Component teams:

-> Are there any "component-oriented" teams within the company that are likely to stay organized this way?

Component and Feature teams are not incompatible. However a Component team may face a few limitations:

• Its TTM is more significant than that of a Feature team because it handles requests pending from various stakeholders. Therefore, it has to stage its developments to deliver fairly distributed features to the requesters.
• To respond to these demanding teams, it tends to require (too?) early design
• Finally, as a silo of skills, it can slow down innovation since any idea issued by another team must come across an "administrative" request to be added to the backlog.

To limit these issues as well as the global TTM of an organization, one should keep the number of Component teams lower than the number of Feature teams. We believe the proper proportions to be Feature team [70-80%] vs Component team [20-30%].

Conclusion

An organization with specialized cross-functional teams solves many issues encountered in a company organized in silos.

You can find many examples and resources regarding this topic on the web (starting with this article about Feature teams by Craig Larman, or this video dealing with agile at Spotify). Nonetheless, beyond the chosen theoretical organization, the true challenge is actually implementing this new communication model between the key players. An experimenting phase between employees motivated by change is a great way to initiate this kind of transformation.

What about you? What team organization do you implement?