Feature teams are the choice for projects with deadlines
The concept of feature teams became popular not so long ago and for sure can be considered as a modern way of organizing project teams (or scrum teams). In this article, I’m going to explain the benefits of running a project with feature teams and compare the approach to the more traditional way — component teams.
Feature teams deliver value for a product
A feature team, as the name implies, is a team that works on a particular feature of a product. A feature team delivers value for a product, not just a value for a project. It is fair to say that delivering a product as a set of features, one by one, can be considered as the most natural way of communication between a customer and developer teams.
A feature team always consists of generalist specialists or has all the specialists who are required to complete a particular feature. In the context of web development, a feature team may include frontend developers, HTML/CSS coders, backend developers and dev ops specialists who work together on a single feature in a time.
Component teams are the traditional way of running a project
A component team works on a specific part of a feature and is not able to deliver a product feature alone. Because of narrow specialization, the deliverables of a single component team are less important to a customer than a feature team deliverables.
Returning to the web development example from the above every layer of feature or a product requires to set up a component team — frontend, HTML/CSS, and backend. More importantly, component teams must establish a clear way of communication and collaboration. These things are crucial because very often, an output of one component team becomes an input for another component team.
Managing of components team is hard
It really is, for numerous reasons. First, as mentioned above, the communication and collaboration between component teams must be crystal clear. Otherwise, consequences may be critical to a project. E.g., providing a backend team with specs that are different from frontend team specs slows an API integration down. Even worse, in some cases — makes API integration impossible.
Another issue is the waterfall tasks management. A component team that depends on the results of another team has to wait. Such relations make the process sequential and inevitably delay the final release of a feature.
On the other hand, feature teams are more independent. Therefore flaws in communication and collaboration are less critical here. However, the trick here is to break a project into features properly. These must be big enough features, to stay separate from each other. Avoid nested features. Otherwise, feature teams may keep strong dependencies between each other.
Delivering features is a natural way
Any customer is happy to know that a feature is released. No one is interested to know if a database is ready or if backend API passes all tests if there is nothing final to play with. To track progress by the number of features released is a natural way for customers, for sure. Don’t forget that customers are often non-technical persons. However, they always want to know where you are with the project.
Planning by features is also easier for a project manager. Because unlike with component teams, with feature teams, a project manager doesn’t have to synchronize between teams to release a feature. Synchronizing is not necessary, because a single team releases a feature with all layers encapsulated in. A single team is responsible for everything related to a single chapter of business logic.
Generalist developers drive feature teams
The ability to develop every component of a feature in a feature team is ensured mostly due to the generalist developers. They can handle different parts of a system on their own, not waiting for feedback from teammates. Often generalist developers are even capable of releasing a sub-feature alone. Such independence significantly reduces the amount of communication and saves a lot of time!
However, there are caveats. You may gain in speed, but you may lose in quality if all developers of a feature team are too generalists. It is crucial that every feature team has a team leader who understands how every component works, almost in depth. Alternatively, a feature team may include developers who understand some components better than others. In other words, there always must be someone who can help and give advice on how to properly apply a component.
Which one is better?
Almost always feature teams perform better than component teams. Reduced need for communication means a lot!
However, sometimes feature teams are not enough. Highly specific components often require a dedicated team that consists of narrow specialists. E.g., it is always better having a dedicated team for AI components, because this domain is too specific for generalist developers. A more obvious example where component teams have no better alternatives — web and native teams. Web developers can rarely develop mobile/native software. Even though such tools like React Native seriously simplify cross-platform coding, there are still too many specifics when developing for a mobile/native.
I highly encourage you to try the feature teams approach. Though be careful, and don’t follow it blindly. Pick a team structure according to project goals, and don’t hesitate to try a hybrid approach. The best approach is the one which brings you results.
Originally published at https://ottofeller.com on June 17, 2019.
