The Feature Team Conundrum

A "feature team" is a development team that is able to take a story and implement it in its entirely, even if the story affects components throughout the entire technology "stack" of the organization's digital platform.

To be able to do that, a team must have available automated deployments and high coverage automated integration tests for all aspects of functionality that their story might impact. Otherwise, they have no way to tell if they have "broken something".

In addition, a feature team's members must have a working knowledge of the entire technology stack. That is sometimes a tall order. For example, a company that I helped had a digital "telematics" platform that consisted of embedded C++ code running in tens of microcontrollers, running custom operating systems with custom chips, on each of nearly a million machines in the field, all sending real time messages to a telecommunications gateway which formatted the messages into an Azure HDInsights event stream, feeling many Hadoop, Storm, and Spark multiprocessing pipelines, which in turn fed myriad databases which acted as the source for many Java data analysis applications and Web Node and native mobile applications used for monitoring the machines, as well as pushing code updates to them.

I did not encounter anyone at the company who was able to work across the entire technology stack.

The concept of "feature team" need not be all-encompassing however. One can have a feature team that is able to work across a portion of the "stack", and still be able to complete a features that are defined in terms of part of the overall end-to-end flow. That still has value, even if it can sometimes make stories less user focused.

Sometimes it makes sense to have a team own a component. In that case, the team's stories are usually expressed in terms of an API change. That is a common approach for core microservices. This is because maintaining design cohesion for highly shared (core) microservices is usually very important for maintainability and the integrity of critical business transactions. However, other services that are less critical might be maintained by feature teams.

My intention here is not to delve into all of the tradeoffs for a feature team approach versus a component team approach. I only mention it because Agile coaches often assume that feature teams are what "mature" Agile teams are, but in reality the right approach depends.