Hard specialization on the team

I'd wonder if work is being pushed, rather than pulled, if there is a feeling of being "overwhelmed". I'd also wonder about teamwork. Regardless of whether the Product Backlog is in the right order, what Sprint Goals are being agreed? Do we have a jointly agreed Sprint Goal commitment, every Sprint, which all team members - Windows and Mac - collaboratively focus on?

Hi, Alec!

Considering what you are issuing, it seems that the team composition does not fit with the current product strategy.

• Would it be helpful to bring transparency about the actual product vision and product strategy? Can you facilitate any workshop about these topics?
• Can you gather some metrics for the items related to Windows vs the items related to Mac (for instance, the cycle time)?
• Can you show to the team and the organization if those metrics fulfil the current product strategy?

I hope these ideas would help you to move your team and the organization into action.

Thanks for your responses gentlemen, 

Ian, as for "overwhelmed", I think I used the wrong word. Devs are free to choose whatever amount of work they feel they can complete during the sprint. And we always agree on 2 sprint goals - one for Windows and one for Mac.

Gonzalo, in terms of cycle time, development is faster on Mac, as historically this platform has no pressure from product side and therefore has little tech debt. Windows development is 2-2.5 times slower due to a lot of tech debt and way more users + context switching of a single Win  developer.

As for facilitating workshop to make transparent product vision and strategy, do you have something specific in mind ? Would be happy if you advised some techniques for that.

From what you describe, it doesn't sound like you have one product and one team, but two products that are being managed as one and built by a team that is really two teams. From what you describe, there doesn't seem to be many (if any) dependencies between the Windows application and the Mac application, so it's not clear why you wouldn't want two Product Backlogs so you can prioritize the work.

I don't understand the hesitance to cross-train the people. I don't see what that has to do with "preserving the expertise". Most developers that I know (myself included) like to learn new tools and technologies. It tends to increase our value, even if we tend to favor one particular technology or stack. But by not creating a team of cross-functional individuals, your other option would be to look at it as two teams building two products.

If you start looking at it as two products, then I think you'll begin to see a lot of the problems. Does it really make sense to have a product supported by 1 development specialist and 0.5 QA specialists? It seems like people and skills may be missing from the organization. If you aren't going to cross-train, perhaps you should hire people to fill out the team to build the Windows application and a team to build the Mac application.

we always agree on 2 sprint goals - one for Windows and one for Mac.

Doesn't that always mean there is no Sprint Goal at all?

The Scrum Guide says: "The Sprint Goal is the single objective for the Sprint."

Doesn't that always mean there is no Sprint Goal at all?

The Scrum Guide says: "The Sprint Goal is the single objective for the Sprint."

Have to agree. Just got misdirected by another quote "The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals." What kind of goals the Scrum Guide is referring to?

Hi again, Alec!

It seems that your team and your organization needs a deep reflection on what your current product is. 

Is Instagram for Android a different product than Instagram for iOS and a different product than Instagram's web page? Or are they the same product with three different versions for three different platforms?

Considering your description, it seems that you have one product (your app) and a product strategy that should prioritize Windows as the main channel. The fact is that your team’s skills and composition cannot afford that strategy, so the strategy gets adapted to the team and not the other way round. That is probably the reason why you have two sprint goals (one for Windows and one for Mac), because if there would be only one that would fully suit the Product Strategy one part of the team would be unable to work on it.

As a Scrum Master your goal should be to show the team and the organization their contradictions. A simple workshop to bring transparency to your Product Strategy would be to fill together with the team and the Product Owner a business model canvas: https://en.wikipedia.org/wiki/Business_Model_Canvas

After having this conversation, analyze with the team and the organization if your metrics suit or not the actual Product Strategy. If that wouldn’t be the case, and they would feel prepared, inspect together which actions should be taken. Nevertheless, the first step should always be to have transparency about what is happening. Inspection without transparency is useless!

I Hope this post would be of any help!

What kind of goals the Scrum Guide is referring to?

There ought to be a Sprint Goal and a Product Goal for example. There could be others, but the goals that are chosen should give the team a reason to work together rather than on separate initiatives. Hence a Product Goal should give the team a sense of direction over multiple Sprints.