Scrum team organization – Feature teams or Component teams – Part 1

Scrum team organization - Component teams

There is a big ongoing debate within Agile/Scrum community on whether Scrum teams should be Feature based or Component based. I am currently experiencing this dilemma in my organization and would like to share my thoughts on this.

Feature teams are long lived, cross-functional, co-located teams with 7 to 8 members in a scrum team that completes many end-to-end customer features, one by one. These comprise of subject matter experts from various component areas e.g. UI, Middleware, Database designer, Architects, Business Analyst, Testers, Documentation etc. In short, a self sufficient team with no dependencies. By organizing teams in this fashion, feature teams can develop a thin slice (enough for one iteration) of customer valuable, end-to-end features at the end of each iteration.

The pitcure on the left is a over-simplified diagram of how a scrum based feature team will start executing priortized stories from overall product backlog. Each story, i.e. User Story f1.1, f1,2, … represents a thin vertical slice i.e. end-to-end incremental functionality delivered at end of each iteration. The picture shows that at end of iteration 2 feature f1 and f2 are complete.At end of iteration 3 feature f3 is complete and most likely this product can be shipped to customer. In most cases, your organization will have multiple feature teams and in that case, work allocation can be handled in many different ways. Ex. FT A can work on developing feature 1, FT B can work on developing feature 2 and so on. Other way would be in iteration 1, FT A works on story f1.1 and f1.2 as that’s their capacity and FT B can work on User Story F1.3 and other stories from feature 2. With this approach you can have customer shippable feature f1 at end of iteration 1.

Feature based teams can deliver thin slice of customer visible functionality one after the other at end of each iteration. This is possible because there is no dependency, delay or hand-off issues between teams.

Forming feature teams for an organization where everyone is co-located or at least in the same timezone seems practical. However for global teams, where expertise is spread throughout the globe, forming feature teams that develop thin slice of end to end functionality is a challenge. Forming a FT which spans multiple timezones violates most of scrum principles – as this team will have a difficult time self organizing for various reasons like culture, timezone differences, etc. This will have a negative impact on team’s velocity and their performance will suffer. In short, FT can’t scale in geographically dispersed large teams which is more or less a reality for all organizations.

In the next post, I will discuss component teams and present my view on how we can use hybrid approach that will allow scaling Agile software development in global teams.