At Novoda, we pay close attention to what’s going on in terms of development and process best practices. In 2012 Spotify popularised the feature team approach, and from that point the idea has been revised, rebuked and modified. Throughout this post we will talk about our own experience with feature teams, based on what we achieved working with various partners, including SoundCloud and ImmobilienScout.
A feature team is a long living team rather than a task-force, which disbands after the work has been completed, aiming to complete many end-to-end customer features one by one. The knowledge needed to deliver a full stack feature is distributed within the team by pairing between the different platform specialists.
Such a team works cross-functionally and across different components. It should cover all responsibilities needed in order to ship a specific feature.This multi-disciplinary team will include product owners, user experience and visual designers, quality assurance and developers. They own a feature from the beginning to the end: defining, prototyping, implementing and shipping it.
The opposite of a feature team would be a component team. Usually discipline-fixed. These teams are focused on a specific component that is reused among features, like the persistence, and usually don’t change their scope.
Quite frequently a “mobile platform team” is completely segregated between designers and developers working in separate time frames and areas. Designs are done completely up front and there are usually once or twice a week catch-ups between designers and developers. In such a setup the feedback cycle between developers and designers is more than one week. This communication issue is multiplied by the fact that designers and developers are working separately in different rooms. Such a team setup could work at a small scale, when there is not enough manpower to form teams around single features,
but becomes less and less manageable with a growing number of people and teams. Furthermore technical limitations are discovered too late, leading to unnecessary loops in the delivery process.
How can we migrate these disparate platform teams towards more in sync and communicative feature teams?
Split the platform teams into smaller feature teams. This enables the teams to focus on features and the necessity of a closer collaboration with designers becomes obvious because the feedback cycle becomes shorter. At this point it's worth reviewing the seating arrangements to bring the team closer together and organize planning and review meetings together with developers and designers.
Create teams that can manage themselves and work on their feature set independently across the different platforms. Such teams should include platform specialists, designers and a feature owner. From now on each team should follow its own agile process including storyboards and ceremonies.
One of the challenges in a feature team setup is how to deal with cross-boundary functionality like persistence. There should be an understanding of core components among the feature teams, which should be developed by the feature teams as needed. Working on features as well as doing cross-boundary refactorings locally enable the feature teams to evolve the application architecture very effectively without blocking other teams.
There can be an incorrect assumption and false hope to create a team responsible for core components. This is not advised as it will lead to knowledge silos around the core of a system, contrary to the idea of a feature team.
A core team acting vertically on the full tech stack will most times operate in maintenance mode rather than working on real customer requirements.
In a more traditional team setup, collaboration between different development teams as well as between designers and developers tends to be complicated or non-existent. Traditional communication can be time consuming, since dependencies between components require additional planning effort because teams are separated.
When a feature is developed across multiple teams, no one feels responsible for the whole feature, but only for their part. And if a fundamental problem arises it’s not clear which team is responsible for addressing it. This can cause unnecessarily long release cycles and reacting quickly to a change in requirements is not possible.
Furthermore, designers and product teams tend to do too much up-front work in such setup. Work that is very likely to be wasted effort due to changing requirements or technical limitations discovered during the development phase.
When organised by feature, the team is able to solve problems by themselves.
Forming smaller teams focussing on features leads to closer, more frequent communication between the different parties (developers, designers, product owners, etc). This has multiple observed benefits:
Focussing on a Minimum Viable Product (MVP), driving the iterations using Key Performance Indicators (KPI) and user feedback instead of Feature creep.
Working with MVP/native prototypes allows a team to quickly gather user feedback and to verify the effectiveness of a feature. This can be achieved by using A/B Testing and feature toggles.
A feature team can start working behind a feature toggle allowing the teams to work efficiently without blocking a potential release. This means the application is always releasable and the features being developed can immediately be merged into the codebase without affecting productivity. When the feature is ready, it can be enabled for a small percentage of users to be compared with KPIs in order to validate the assumptions.
A real life example would be a task to add a new way of signing in on the mobile client. In a platform or component driven team setup the mobile team would implement just their part. But what about the server side? Is everything needed for this task ready? Would that break? This information is needed as it blocks the progress and that’s not something a single person might be able to figure out on their own.
With feature teams there is no need to chase the person down from the backend team who had implemented it server side. Instead the feature team being responsible for this part would deal with this request. Since the sign-in is their domain, this task would never be blocked by other work on the backend, because the team focus only on this part of the stack.
Multiple teams working on the same product (and possibly the same codebase) brings the question of scalability. How can teams be flexible enough to modify their structure as needed or form new teams for new features?
The team structure should support as many small and focused teams as possible.
There is no need for a hard limit on the number of teams. To support concurrent feature development and to facilitate scaling, the application should be split into modules based on domain concepts, once these separate concerns have been identified.
Modular separation enables higher throughput for the feature teams that will be able to work safely on different pieces of the app at the same time without major side-effects. These modules should also have smaller local components with single responsibilities. This allows fewer dependencies between modules, so changes in a module can be done without minimal impact in other areas of the product.
Having backend and frontend teams separated causes several problems. It leads to teams
focusing more about the platform they own instead of a feature across boundaries.
The communication among teams is more difficult and can be even counterproductive in case the teams do not share the same domain language.
Instead, the backend specialists should be encouraged to work closely with frontend and mobile specialists, ideally sharing the same office space. Involvement in regular standups is key to effective communication, so these should be considered mandatory for the whole team. Pairing sessions between specialists can help identify issues early on and encourage discussion to find solutions that work for everyone.
Pairing also encourages the knowledge transfer between platform specialists which will in the end lead to full stack developers. This people are then capable of moving to other teams as needed.
When backend and frontend devs are in the same team, they mostly care more about each others’ boundaries and support each other, for example by writing tests. Integration tests written by the frontend team could be used as well by the backend team as part of their release process. When they are different teams, on the other hand, it is easier to blame the other team when something is broken.
The transition towards feature teams, especially in an environment with entrenched legacy processes, takes time, effort and requires two important things: an extensively planned migration and long-term commitment at all levels of the organisation.
Processes need to be aligned, teams need to be split up and reformed — from a physical point of view as well as from a logical one, product needs to be on board, pressure to ship needs to align with the workload. Everyone needs to embrace the change long enough to allow it to work.
Closer collaboration allows individuals and teams to rapidly react to change and will shorten the time to market. If you believe in empowering those with the knowledge to make an impact and enabling teams to master their skills, whilst setting visionary and achievable goals then feature teams are the most favourable setup for your technology company.
We plan, design, and develop the world’s most desirable software products. Our team’s expertise helps brands like Sony, Motorola, Tesco, Channel4, BBC, and News Corp build fully customized Android devices or simply make their mobile experiences the best on the market. Since 2008, our full in-house teams work from London, Liverpool, Berlin, Barcelona, and NYC.
Let’s get in contact