One (mobile app) scrum team - multiple OS?

> Having taken responsibility for one single scrum team...

What evidence do you have that this group of people function as a Scrum Team, or indeed as a team at all? Do they have a shared goal which would cause them to work together in such a way, and to deliver an integrated product increment? Do their specialisms constrain collaboration?

Hi,

just reading the headline I would say: Yes, no problem. Just add all the target OS to your definition of done or at least to the acceptance criteria of your stories and you will be fine.

Looking at the expertise of the team members the question could be: How do you deliver if your Windows guru is absent? If you have the situation of subteams just focussing on their OS you might have an issue and should try to ramp up that they can work in the other OS area, too.

How to brigde the gap bewtween PO and the team?

From my personal experience: You have to ensure that frequent and high quality communication between the team and the PO is happening/possible. After knowing each other in person I found video conference meetings can be productive. That implies that the PO has to join the dailies and grooming meetings from time to time and should be there in all plannings, reviews. Another recommendation: Include the off-shoring situation in the retros.

Cheers
Joerg

Hi Ian,

Thanks for the response.

In answer to your question - absolutely none. The above description is the as-is configuration for the team at the point of handover.

In truth, everything you've mentioned was the motivation for my question.

For me there are a couple of different approaches, and I'd be keen to float these ideas for discussion:

(I think it's important to mention I'm yet to get a clear picture of skill sets (any language cross-over, pairing to date, other specialisms etc) and general understanding of agile across this team.)

In terms of options:

- The team focus on a single product at a time(for example iOS app) and working cross-functionally to deliver slices of value. Essentially treating iOS, Win, Android as separate products and working on them sequentially in priority order. The team are fully empowered.

- Each OS is tackled simultaneously and the team delivers a vertical slice of value which cuts through iOS, Android and Windows per increment. This isn't scrum, and I feel would effectively force a cadence/alignment. The team would be spread thin and continually context switching (particularly UX/Arch).

Welcome inputs.

Thanks,
Anthony

Posted By Joerg Karlinger on 20 Apr 2016 03:09 AM
Hi,

just reading the headline I would say: Yes, no problem. Just add all the target OS to your definition of done or at least to the acceptance criteria of your stories and you will be fine.

Looking at the expertise of the team members the question could be: How do you deliver if your Windows guru is absent? If you have the situation of subteams just focussing on their OS you might have an issue and should try to ramp up that they can work in the other OS area, too.

How to brigde the gap bewtween PO and the team?

From my personal experience: You have to ensure that frequent and high quality communication between the team and the PO is happening/possible. After knowing each other in person I found video conference meetings can be productive. That implies that the PO has to join the dailies and grooming meetings from time to time and should be there in all plannings, reviews. Another recommendation: Include the off-shoring situation in the retros.

Cheers
Joerg

Hi Joerg,

This would be difficult, as you'd be asking a single team (of 7) to deliver value (stories) across multiple languages (e.g. Java, Objective C), disciplines and against specific OS constraints.

I feel this would bog the team down and in the event there's no crossover in skills/specialisms, create multiple bottlenecks, dependencies and single points of failure. Unfortunately on the face of it the team is not big enough to cope with the above.

I have to point out I will of course be posing this exact question to the team - however this change really has only just happened so we are very early days!

> The team focus on a single product at a time(for example iOS app)...

In a Scrum Sprint, a Development Team will work with one Product Owner in order to meet a shared Sorint Goal and deliver an increment of one product. The work they plan into their Sprint Backlog will therefore be drawn from one Product. Backlog. They must indeed focus on a single product at a time.

However, there's nothing to stop a team from working on different products each Sprint, drawing work from different Product Backlogs and potentially working with different Product Owners. Some teams alternate between products each Sprint. However, a team must provide a potentially releasable increment of each product at least once per month. This implies that if they alternate between 2 products, each Sprint must not exceed 2 weeks in length.

I would recommend to speak to your PO, what is his business need? Does he want all OS support simultaneously or he has a preference for iOS or Android?

Or if your PO wants at-least two OS then divide the team into two Scrum team.

Somehow working on all OS may result in sub-teams within the Scrum team. Focus on the 'T' shape skillset where a team member is expert on one of the OS but can work on other OS too, if required.

For improving the collaboration, keep a good travel budget.

Posted By Ian Mitchell on 20 Apr 2016 08:09 PM
> The team focus on a single product at a time(for example iOS app)...

In a Scrum Sprint, a Development Team will work with one Product Owner in order to meet a shared Sorint Goal and deliver an increment of one product. The work they plan into their Sprint Backlog will therefore be drawn from one Product. Backlog. They must indeed focus on a single product at a time.

However, there's nothing to stop a team from working on different products each Sprint, drawing work from different Product Backlogs and potentially working with different Product Owners. Some teams alternate between products each Sprint. However, a team must provide a potentially releasable increment of each product at least once per month. This implies that if they alternate between 2 products, each Sprint must not exceed 2 weeks in length.

This is a really interesting idea, and not one I'd considered at all. Thanks Ian.