Experience in Launching Feature Teams: From Chaos to Speed

4 min read3 days ago

Imagine your team is tasked with a project crucial to achieving business goals. The new functionality should bring additional revenue to the company. Everything is at stake: ambitious targets, high expectations, and the hopes of the business. However, despite all efforts, months into the project, it is still far from completion.

This is where our story begins. It’s about how we drastically increased our team’s speed without increasing its budget.

The Problem

At the project’s inception, everything seemed logical and organized:

The project’s priority was clearly outlined.
A project manager was appointed.
An architect took charge of technical decisions.
The team began executing tasks.

The business stakeholder regularly met with the project manager and architect, who then passed tasks to the product owner. The product owner planned iterations, and the team worked on tasks in sequence. Occasionally, other teams were involved when tasks overlapped with their areas of responsibility.

However, after one, two, and three quarters, it became apparent: the project was moving too slowly. Despite efforts, completed tasks, and production releases, the business stakeholder still couldn’t leverage the new functionality to generate revenue. The problem was clear: we needed to significantly improve efficiency.

Analysis

We started by identifying the root causes and here’s what we found:

Lack of direct communication between the business stakeholder and the developers. This prevented developers from understanding the business context and the stakeholder from understanding the complexities of implementation, resulting in less effective solutions.
Team’s lack of focus. Developers were overloaded with tasks from other stakeholders, hindering focus on the main project.
Inefficient processes. Poor planning, lack of thorough grooming, and irregular retrospectives were stalling the team.
Dependency on other teams. Development was frequently delayed due to waiting for external contributions.
Huge tasks in the project. Instead of implementing minimal viable functionality to test hypotheses, the project consisted of massive, complex tasks to build an enormous solution.

The Solution

We made a bold decision: to create a feature team — a temporary, cross-functional team focused on a single project. To achieve this, we implemented the following principles:

Focus on one project. We selected key developers and testers from different teams. This allowed us to concentrate solely on the project, eliminating unnecessary distractions. Of course, reallocating resources required approvals from top management and explanations to other stakeholders whose projects temporarily lost part of their teams. But a clear focus on company priorities convinced everyone involved.
Team autonomy. The feature team consisted of specialists from all necessary areas: developers, testers, and experts on adjacent products. This ensured tasks were completed within the team without waiting for external contributions. While some team members may have been underutilized at times, this approach maximized speed.
Iterative development. We shifted from a project-based approach to short iterations. The team regularly presented intermediate results to the stakeholder, received feedback, and adjusted course. This allowed us to adapt the backlog to current priorities and deliver business value even before the full development was complete.
Backlog based on hypotheses. Instead of working on long-running tasks, we focused on smaller tasks aimed at quickly testing hypotheses. The architect helped design and monitor solutions to minimize technical debt and prevent future issues.
Release management. We empowered the feature team to independently release updates. This removed delays caused by dependencies on other teams and allowed for rapid changes in the product. This was challenging: we had to negotiate with product owners whose releases were previously under their full control.
Direct communication. We organized regular meetings between the stakeholder and the team. This helped developers understand business objectives better, while the stakeholder gained insight into technical constraints, leading to more realistic solutions. We also had to overcome a language barrier since developers and business stakeholders spoke different “languages” and used different terminology.

Results

Once the feature team was up and running, we had the project manager assume the role of Scrum Master, setting up processes, synchronizations, and regular retrospectives.

Within a few iterations, the team released the first solution for the stakeholder.
The stakeholder launched the first experiment, which brought in additional revenue.
In one quarter, the team completed more tasks than in the previous few.
In the same quarter, all hypotheses from the stakeholder’s backlog were unlocked — either successfully tested or planned for experimentation.

Additionally, we regularly collected feedback from team members, and here’s what they noted:

Deep understanding of business needs. Direct communication with the stakeholder provided clarity.
Flexibility. Rapid response to changing priorities accelerated work.
Speed. The stakeholder noted the increased speed of launching experiments and the team’s reaction time.
Job satisfaction. The new format improved team dynamics and relationships, with no one wanting to return to the previous setup.

Conclusion

Feature teams proved to be an effective tool for accelerating work on high-priority projects. They require careful preparation, resource coordination, and new approaches to processes, but the results are worth it. In our case, this format enabled the team to quickly adapt to business needs, while the stakeholder shifted from a project-based approach to an iterative one, achieving goals that once seemed out of reach.

We decided that feature teams would remain a temporary format, used only for key tasks. This approach allows for flexible resource redistribution while maintaining overall balance and avoiding overloading the organization with unnecessary changes. It was a challenging but extremely valuable experience that will definitely be used in the future.