3

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?

Improve this question

4 Answers 4

Reset to default
1

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.

Improve this answer
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.

Improve this answer
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.

Improve this answer
1

It looks like the Product Owner has not created a Product Vision for the end product that is being worked towards. This would be a good starting point to get everyone to share a common view.

Secondly, I agree with @Daniel, having 4 identical Stories for each is a red flag and does not make for a common Product Backlog. Have just one Story for each feature and get each mini-team of 2 to complete their tasks then meet up and share progress and any impediments. Doing this twice a day should enable them to stay on the same page and be more ready to help each other out should the need arise.

For this to work the Story will need to have well-defined acceptance criteria; not just as questions to ask, but taking into account each of the 4 platforms being developed against. It is almost like making sure (testing) that a web page's features work the same way in different versions of Windows and in different web browsers for each version.

The main thing is to give them all a set of common values which pull them all together to achieve the same goal.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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