Comparison between Component and Feature Based Agile Teams

Background

For more than past 3 years I have been part of Agile teams. I have worked with distributed as well as co-located teams. During this time I had experience in developing the software using both component based as well as feature based products and services. These days Most of the organizations  have teams in different geographic locations. There are different ways of structuring teams in such scenario. In this post I’ll try to share my views on Component based and Feature based Agile teams.

Component Based Agile teams

I have been saying this repeatedly to my colleagues that Agile is a change in mindset about the way we develop software. For people who are born and brought up in traditional waterfall software development model it become difficult to adjust to agile very easily. We can design a system into various layers like backend or Database layer, middle tier or services layer and front end or user interface layer. In a component based team structure each of these layers will be developed by a team. As a result you might have 3 separate teams working on 3 different layer of an application.

We have been following this approach for one of our recent projects. On one hand it makes life easier by allowing a team to work within its own boundaries and finish the tasks quickly. This also allows good utilization of resources as people with specialized skills like UI development or middle tier development can work on their primary skills.

The biggest problem I have experienced with this approach is that it increases dependencies among teams. For every instance of a collaboration between two tiers of an application there is an additional overhead of communicating between teams. If both the teams are working at same velocity it might not cause much problems but very rarely does it happen in real life projects that way. Dependencies start increasing and might affect work of both the teams. This can have adverse effects on the overall release dates of the project.

Lot of time is spent in identifying and resolving the dependencies. Since both the teams are developing independently, there are greater risks at the time of integration. Additional efforts are required to resolve any of the integration issues that might arise after integrating various layers or modules.

In our case the different teams were based in different locations. Working hours are different for different teams due to different time zones. On many occasions as much as half a day is wasted one of the team is not available for clarifications on some critical items.

Feature Based Agile Team

As compared to the above approach, there can be an alternate way of structuring teams based on features. In this case one team can work on developing the complete feature end to end. As an example, there can be a team working on processing the online orders from a website to the distribution centre of a retail organization.

The same team would work on the web site portion which will communicate to the service layer and process some data into the backend systems. Since only one team is working on the complete feature they will have the freedom to decide on the design on each layer and can implement the functionality much faster as compared to a component based team.

Having a single team implement the complete feature end to end also enables the organization to reduce technical debt. As all the teams will be well versed with all the technologies as well as design and architecture of the system. Knowledge will not be residing in silos. Any team can work any layer for future development which also helps in team building and better collaboration.

There might be problems in this approach as well. One potential problem could be that two features share a common database object or a service layer functionality. And in that case there is a chance that both teams might be stepping on each others feet.

Conclusion

Having experienced the pain of component based Agile development team I would like to try the feature based approach to see if it suits better to the distributed development model that we follow in our organization. The biggest advantage I see in feature based approach is the enhanced collective code ownership. It will also help all teams to understand the overall picture of how their work fits into the larger systems.

Share: