Component Team vs Feature Team in a Nutshell
As your startup grows, the talk of how to scale effectively becomes inevitable. Your product has successfully attracted a lot of new users, and you want to sustain the growth by enhancing the features and even adding new ones. This means more work and responsibilities for the development teams, and also a change in the organizational system.
Now, how should you reorganize?
There are two approaches to organizing your team: the component team and the feature team. Both teams have their own benefits and drawbacks, which will be explained in the next section.
Understanding component team and feature team
Let’s assume you are a developer for a digital bank, and your Product Owner (PO) prioritized the following items in the Product Backlog:
- View total cash account balances
- View transactions list
- View total investment in mutual funds from 3rd party application
- Show percentage interest gained from mutual funds
How will your team do the task? Here are two possibilities:
Scenario 1:
At the start of sprint planning, your team picked three high-priority items. You realized that you needed two new microservices: one to retrieve account balances and transactions from the bank’s core banking system (CBS) and another to retrieve total investment and percentage interest gained from a third-party application.
This meant that you had to collaborate with other component teams: the CBS component team and the partnership component team.
You discussed the new requirements with those teams and received assurances that these micro-services would be delivered by the middle of the sprint, allowing them to integrate before the end of the sprint. Your team began working on the UI design and was able to create a mock screen in the mobile app with some dummy cash account balances.
During the process, you were suddenly informed that the CBS team had a production bug! They deprioritized the microservice work and you had to wait until the second half of the sprint. At the same time, the partnership component team encountered some complexities while developing the microservice. Under the pressure and nearing the deadline, the teams were having daily back-and-forth discussions, as well as heated arguments.
Because you can’t work on the other items, you took item 4 from the backlog and began working on the UI design half-heartedly, as this item was also dependent on the result from other component teams.
The CBS team finally said that they would not be able to deliver the microservice during the current sprint and that it would have to wait until the following sprint. As for the partnership team, their microservice was ready for integration on the last three days of the sprint. However, the integration process was ridden with numerous issues.
At the end of the sprint, you had mock UIs for items 1, 2, and 3 of the backlog with dummy data, as well as a half-baked UI for item 4. All the team members were frustrated with how the sprint went by and the customer feedback. They were tired of waiting and back-and-forth coordination, instead of doing real work. There was very little new learning for them.
Scenario 2:
Similar to Scenario 1, your team also needed two new microservices. However, this time your team was the one developing the microservices, taking responsibility for the end-to-end story.
The team started to create a mock screen in the mobile app with some dummy cash account balances. Then, it was time to build the microservice. Except for one team member, nobody else in the team had worked on CBS in the past. The only person who had knowledge of CBS then conducted multiple knowledge sharing sessions for the rest of the team.
Of course, the team slowed down considerably while trying to learn and make changes to CBS. But in the end, the team managed to pull off the new micro-service, and the first backlog item was done.
During the last three days of the sprint, the team focused hard on the second item. They could leverage the UI design that they had used for previous backlog items, and also enhance the same microservice to fetch the transaction list. This way, they were able to finish the second backlog item within the sprint. When the sprint ended, the team managed to finish only two backlog items out of the three that they had originally forecasted.
However, the team was happy that they learned something new about CBS in the sprint. They also increased team bonding while learning a new skill together.
Component Teams vs Feature Teams
Scenario 1 serves as an example for the Component Team, where each team is responsible for one system component. There is, for example, a team that works on the frontend, one that works on the backend, and another one that works on the database. The three teams operate independently, which frequently results in team interdependence.
Rather than delivering value to the end-user, the teams spend a lot of time discussing dependencies and testing behavior across components. These elements are utterly unimportant from the perspective of the buyer.
Component Team also means a lot of work in progress (WIP) items are being done at the same time. In the queueing theory, we have Little’s law that proves increasing the average amount of WIP will increase the average time for each work item to be completed (Lead Time). Working as a Component Team increases the amount of time it takes to deliver.
Scenario 2, on the other hand, serves as an example for the Feature Team, where each team is confident enough to complete an end-to-end story. Of course, the team’s core purpose should always be to provide customer value; not only to distribute responsibilities and resources.
It may appear tough at first because each team member is supposed to be knowledgeable about various components. However, as they work on the story, they will come into contact with various components and gain experience understanding them until they are confident enough to do a story with a variety of components
There is a common misconception that every member of a Feature Team must be familiar with the entire system. In fact, not so, because the whole team is required to implement the entire customer-centric feature. When requirements do not correspond to team skills, learning is ‘forced,’ breaking the overspecialization constraint.
Each member of a Feature Team will gradually increase their expertise over time, until a full team of multi-discipline experts is in place, all of whom can work on multiple items at the same time.
Imagine it like this: Component Team is analogous to cutting a cake horizontally where each slice consists of only one layer (ex. only cake, cream, or topping). Feature Team, on the other hand, is similar to cutting a cake vertically, where each slice has multiple layers instead of just one.
So, back to the question, how should you reorganize your team?
If you want a team that can take on customers’ requirements from concept to implementation, the Feature Team is unquestionably a better option. But how should you start one?
Following the Shu-Ha-Ri principle, it is advised to begin with small products with a single team and to internalize the stance and principles of agility. Then, with Vertical Component Teams, you can take on larger products and gradually develop them into Feature Teams.
Like what you are reading? And are you up for building a system or digital product completely from scratch? Then grab your spot in our team!
