Pitfall #6: NOT Starring Feature Teams

Part 6 in our 10 Agile Transformation Pitfalls and How to Address Them One of many on a feature team isn't what you want

Being one of many is a red flag on the Path to Agility®. The success of your Agile transformation depends on cross-functionality from feature teams. Image courtesy of Ohmymag.com

Look around you. If you and all of your neighbors have the same job title, it may be time for a new seating arrangement. While there are some advantages to having specialist or component teams, for the most part, they create silos and impede communication. In our sixth installment of our Agile transformation pitfalls series, we discuss how your definition and makeup of “team” could be impeding your organization’s adoption. Here are links to previously discussed pitfalls if you need to catch up.

Feature Teams vs. Component Teams

Slice of cake - example of feature teams

 

In Agile, create vertical feature teams instead of horizontal specialist teams. Image courtesy of Jeremy Jarrell

A feature team has the capability to build a complete working product or a feature because they have all the necessary skills in one team. In the graphic above, one team equates to one slice of cake consisting of one layer each of user interface, web server, and database. A component team is based on code ownership and specialist function, for example, the database team vs. the web server team. One horizontal slice of cake represents one component team.

According to the “Feature Team Primer” by Craig Larman and Bas Vodde, there are six characteristics of a feature team:

  1. Long-lived
  2. Cross-functional
  3. Co-located (Best-case scenario)
  4. Work on customer-centric features, end-to-end
  5. Composed of specialists
  6. 5 – 9 people (Scrum)

One misconception about feature teams is that each member needs to know the entire system or possess the skills of other members. This is not true. Rather, it’s the team as a whole that’s cross-functional. Feature assignment should also be based on the team’s current ability level instead of randomly assigned.

Go Feature Or Go Home – Advantages of Feature Teams

Since the ultimate measure of success for Agile is the ability to ship working product, a cross-functional feature team is the building block of an Agile framework. Feature teams have been around for some time and used in large products like telecom systems. However, Agile and Scrum have brought feature teams to the forefront, because of the following advantages:

  1. Feature Teams Increase Customer Value  Component teams focus on lines of code completed. Product (feature) teams tackle features prioritized to deliver the most customer value.
  2. Feature Teams Are Stable  Feature teams are focused on delivering a working product or feature. While the team makeup is not permanent, feature teams don’t change with every iteration, thus creating a more stable work environment.
  3. Feature Teams Increase Learning  While shared code between feature teams can cause some limitations, knowledge sharing through increased communication and collaboration between team members increase learning and therefore organizational flexibility. A side effect is that over time, highly functional teams, as entities, are capable of taking on work that’s in a different domain than their previous or current project.
  4. Feature Teams Limit Dependencies Between Other Feature Teams Since feature teams are product/feature based, not code-based, the entire project doesn’t fall apart if a unit falls behind. A system built on component teams is like dominos stacked behind each other. If one falls, they all fall down.

There’s no question that creating and supporting feature teams is a critical step in building an agile infrastructure. The real question is how to best transition from component to feature teams.

 

Follow the entire series:

For more on our approach to building lasting business agility, you can check out our Transformation Services page.