2

I am the Agile Coach for a team which comprises of 4 completely different platforms (iOS, Android, Javascript, Windows) each with 1 or 2 engineers. There are 2 automated/manual testers in total and 1 PO.

All 4 platforms work from precisely the same backlog of user stories (we have separate identical user stories for each platform.

Currently we have a single kanban board in Jira pulling data from 4 different projects. We have a swimlane for each platform but share WIP limits, standups, retro's and demos.

Current problems:

  • Different platforms switch off during stand-ups since they only care about their platform
  • Different platforms don't work with other platform team members since they only care about their own platform
  • There is no team cohesion across platforms just silos
  • Team members don't help team members on other platforms
  • There is no technical leadership across all the platforms

The question is, should these platforms bit split into 3 different teams or what technique could I use to fix this?

0

Unless you can provide a single Sprint Goal that allows all of the engineers to focus on a single outcome that is relevant for everyone there is little value in having a single team.

If you only have 2 people in a team then the overhead of Scrum and other agile practices are a little redundant. Just have them split into teams of two and figure out how to fulfill the backlog from their platform/product.

If however if you can have a single unified goal then they should care about each other's work at the Daily Scrum. This will give them back focus, and allow them to work together, rather than separate.

2

It sounds like the team has far too much pull and the PO not enough.

The team having 4 identical backlog items is a big red flag. If you are starting with one and then splitting it for them, it's just enabling the behavior. Leave it as one and the team as a whole either finishes it or doesn't. Sometimes at first the teams can stay silo'd and move forward on collective backlog items effectively, but it's an almost impossible set of coincidences needed to keep that equilibrium. As soon as someone goes on vacation or one platform hits a snag, the need for cross-discipline team members becomes readily apparently. From here, you can coach the team on whatever path forward (and there are many) works for them to resolve it.

A word of warning as you venture into this though: I've run into a lot of developers who resist this because they don't want to be a jack-of-all-trades and that is a completely reasonable opinion. As much as it is unreasonable of the developers to think they can learn one skill and make the company cater to that silo, it is equally unreasonable for the company to think everyone should develop all skills. You want enough overlap that the team isn't skills-fragile. Exactly how much overlap that is will be different for every team and the scrum master should help them find it, not force them into it.

1

Don't talk about boring technical stuff in the daily. Talk about the process and the blockers and the product etc. Demand that team members respect each other for 15 minutes each day by actively listening to each other.

Its still all the same product right, and the same organisation, and the same process, you are still using the same backend or API, so 90% of what is discussed in the daily should be interesting for everyone. Platform specific stuff can be mentioned and should still be listened to but this should only be 10%.

And because you want these UIs to be working in a similar way across platforms that should be discussed as well, so more like 95% common stuff, 5% platform specific.

It makes sense that specialists dont work that closely with each other if they are developing separate front ends so dont expect to much of that though. Actually scratch that they should be working closely together to make sure the UIs dont diverge too much and work roughly the same across platforms.

Try and be a bit more product focused than platform focused. Include the back-end and business guys in the team.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.