Sub-teams in Developer Team

Hi Diego!

It is ok to have testers, analysts and so on in Development Team, but as we know from Scrum Guide

- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis;

It means (and I agree with this) that this is in general this is a bad practice to have sub-team because in future it will separate them from another members of a team. In my team we have 2 developers, 1 analyst, 2 testers but there is no any sub team.

So as a Scrum Master I will remove sub teams and ask a Team to work as one Team. 

So as a Scrum Master I will remove sub teams and ask a Team to work as one Team. 

Orkhan, I don't intend to be critical, but that advice is a bit simplistic, and not indicative really of what a Scrum Master should do.

Yes, sub-teams are a "bad smell" in Scrum, especially if those sub-teams are reinforced by the work items refined with and provided by the Product Owner.

The issue is, how do you get such a group of individuals to work as a cohesive team, and not simply as a "working group".

There isn't a magic wand that the Scrum Master can wave to get desired behavior.   In fact, the Scrum Master has very little authority with the rest of the Scrum Team, outside of identifying and making visible poor practices like sub-teams within a Development Team.

So what can a Scrum Master do in such a situation?

A few suggestions:

1. In refinement, guide the Development Team and the Product Owner to not split work by subject matter expertise, but by business value.   There are many very good resources on the internet around good splitting practices.   One practice I support is to try and create/refine each backlog item as customer-facing (external or internal).   That way, everything needed to deliver that item is a task under it (i.e. - development, testing, etc)
2. Continue to guide the "team" around their collective responsibility for delivery.   There is no "us" and "them" within a Development Team in Scrum - there is only a "we".   Try at every available opportunity to reinforce their team ownership of their sprint forecast and Sprint Goal
3. Encourage cross-training of skill sets within the team as opportunities become available.   Silos of work within a Development Team just creates bottleneck risk and sub-optimizations that can derail high performance.

Good luck.

Timothy, it is ok :) thanks for your detailed answer. 

What would you do as Scrum Master?

I think it would be useful to have clarity over what problem the arrangement is meant to solve.

I agree with Tymothy! 

In the best scenario all the test should be automated. 

It's very beautiful in theory but in practice it always happens. 

In my opinion, you can't tell the team how to self organize itself. It will happen, and it's normal. The great problem there is the PO creating specific requirements for an sub team. This acknowledge the team division and could create communication and collaboration problems in a long therm context. 

As the SM you should always guide the teams to work together as a team, so everyone is responsible for the increment and not only the develop or test team.

I have the same issue with one of my teams.

A team of 9 devs, some remote. Team is an 3 teams that were combined to 1 6 months ago.

I have tried swarming, knowledge transfers, writing stories as business value but to little avail m I would say 4 devs will swarm the other 5 wait for work which touches their area of expertise. As a scrummaster I cannot assign work .

Immediate management, these devs managers, don't really believe in swarming, they see it as a productivity reducer.I know short term thinking and I explain this but the message is lost.

My next step was to break the team in 2 in order the improve to the swarming but I'm unsure

Any advice?

IMO, i do not think we need a sub-team of developers to do testing. All should help in testing or providing high quality in every items they are delivering.

I am assuming that you are in "Waterfalling sprints" since not all are doing testing.

I have tried swarming, knowledge transfers, writing stories as business value but to little avail m I would say 4 devs will swarm the other 5 wait for work which touches their area of expertise. As a scrummaster I cannot assign work .

Immediate management, these devs managers, don't really believe in swarming, they see it as a productivity reducer.I know short term thinking and I explain this but the message is lost.

What do they think when they see 5 people waiting for work?

My next step was to break the team in 2 in order the improve to the swarming but I'm unsure

You can expect people to copy, or reflect, the values of those who "manage" them. If collaboration is poorly valued, team members are unlikely to value it no matter how their teams are sized.

My advice is to focus on transparency, including over the waste that is currently being incurred. In agile practice the first step is usually to expose the problem, and then gauge the extent of any appetite for solutions. A more collaborative approach -- such as swarming -- might then promote self-organization and reduce dependencies on managers, including yourself. Remember that it should not be your responsibility to merge or break up teams at all.