Component vs feature team

> 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

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?

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?

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

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

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.

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.

> 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?