Skip to main content

Component vs feature team

Last post 04:40 pm June 16, 2016 by Ian Mitchell
8 replies
04:57 am June 8, 2016


Do we have a scenario where in we have to have a component based team, feature level team may not be the best fit for the situation?

Assuming an organization is working on a mobile app that should be released on iOS and Android both. They have recruited four developers for each platform and formed two teams (2 iOS + 2 Android) and has started sprinting. There are two architects one each for iOS and Android.

For a selected PBI there may be less work in iOS and more in Android, how would you handle it? The developers are reluctant to learn about iOS/Android and vice versa. How to best optimize architect's time, shall we keep them 50% in each team?

Their DoD says a PBI should work on iOS and Android both, assuming it is done for iOS and PO wants to release it then what?


06:15 am June 8, 2016

> Do we have a scenario where in we have to
> have a component based team

There's no scenario in Scrum where you would *have* to have a component based team, if that team is to deliver an increment which is usable and thus feature complete.

> feature level team may not be the best fit for the situation?

Feature teams are good Scrum practice, and implementing Scrum well requires deep and pervasive change. Therefore a feature based team is rarely "the best fit for a situation" and we should not expect it to be so. Rather, it is the situation that must be changed in order to support feature based teams and to leverage their benefits.

See the LeSS site for a good treatment of this topic:

https://less.works/less/structure/feature_teams.html


07:19 am June 8, 2016


Assuming a product has to be developed for iOS and Android both that means every feature should work on both the platform.

However the code base is different and there is no requirement of releasing at the same time i.e. if a feature is Done for iOS, let's release it. We will release the Android version later.

So shall we still keep a mix team of iOS and Android or separate teams one each for iOS and Android?


08:00 am June 8, 2016

Regardless of how different the code bases are, what the release schedule is, or whether there are one or multiple teams for one or more products, why would a component team be needed in the situation you describe? Why would any team need to focus on something other than feature delivery for a particular product line?


08:01 am June 8, 2016


Let me clarify - Does it make sense a team focus on iOS product line and the 2nd team focus on the Android version?


03:23 am June 10, 2016

I had very similar situation some time ago. A mobile team started as one and consisted of iOS, Android and Web Developer (for mobile Web). They needed to align frequently, on daily basis, as they were working on common ground and were making architectural decisions that were affecting all 3 platforms. After couple of months they started to de-sync. Mobile Web was the fastest, then Android, and iOS being the slowest. It was caused both because of skills and technology stack. Additional devs were hired to join and 1 team split into 3. There was a QA guy who was on both (iOS and Android) teams to make sure features look the same. (Mobile Web moved into different direction).

Having only 2 people on the team was painful sometimes. It just took 1 person to get sick and weekly plan was already deprecated. But it was still better than having 1 big team where technical issues were different. After a while more people were hired and sensibility to absence issue was mitigated.

To sum up - in our case it made sense. Factors to consider:
- is feature parity between platforms a must?
- are you planning to expand teams?
- difficulty in recruiting devs familiar with both Android and iOS


06:09 pm June 12, 2016

I think it might be beneficial to define the terms. When you say component team, what qualities are you describing? When you say feature team, what qualities are you describing?

For example:

When I refer to component teams, I'm generally speaking of teams divided by code layer - you have a team for the data layer, you have a team for the middleware, you have a team for the front-end. However, I have seen the term defined as teams that work on an individual component of a product - a view in Spotify - which may cross the various layers.

When I refer to feature teams, as a UX professional, I'm referring to something a user trying to accomplish.

I would contend that, in your example, have an iOS team and an Android team is neither a feature nor a component team - they are "platform" teams - each dedicated to developing code for a specific platform.

As a professional developer, I would say - if the product is the same, with different platforms - the features are probably the same (or similar) and relatively easy to port between languages. Separating the teams based on platform could cause an increase in bifurcation of code - whereas having the developers for both platforms (at the very least) speaking to, and reviewing, each other's code could reduce this.

I developed an app for iOS and Android. We were on the same team. We reviewed each other's code. For some features it took him longer to develop - that was not an impediment for him nor me - in those cases, when he took on the next feature, I already had the "case study" for how to implement it; thereby, reducing his development burden. In a couple of cases, he was able to do the same for me.


03:57 pm June 16, 2016

I am definitely for feature teams but I also understand that we need to promote self-organizing teams. So, in this scenario, what if the teams think component based structure works well for them? What should the Scrum Masters do this in such a case? Keen to hear as many thoughts as possible.


04:40 pm June 16, 2016

> I also understand that we need to promote self-organizing teams.
> So, in this scenario, what if the teams think component based
> structure works well for them?

The Scrum Guide says: "Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness."

A team may therefore self-organize in terms of feature delivery, or component delivery, or something else again. But which structure is the most *likely* to demonstrate "optimal efficiency and effectiveness" in an empirical manner, through the delivery of usable and feature-complete increments?


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.