Skip to main content

Squads

Last post 06:34 pm December 7, 2019 by Simon Mayer
3 replies
04:24 pm December 7, 2019

We are the IT team for a fairly large company. At the moment, we have an infrastructure team, support team and development team



Our management want us to be more like Spotify and have feature teams made up of infra, Dev and support folk. The idea is that everyone is cross skilled in the different areas



Apparently Spotify and some others do this well with their squads made up of front end / backend developers, sysadmins and testers.



However, I don’t think Spotify support are arranged into squads. They are probably more traditional groups focusing on “run the company”  and the squads are more focused on new features



For example, if I log a ticket with Spotify I doubt that would get channeled to a squad



Is that correct ?


04:28 pm December 7, 2019

Just to be clear, the reason to be more like 'Spotify et al' is to reduce the hand off times between the different groups and encourage collaboration


05:13 pm December 7, 2019

Sounds like management is trying to standup a Development Team. Here is a quote from the Scrum Guide:

 

  • Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
  • Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
  • Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

 

Here is one approach I've seen.

Bugs or general support is handled by a separate Client Services or Helpdesk team and the only time they talk to the Development Team is if a ticket gets to a level three (that is, the Helpdesk staff is unable to diagnose or fix it).


06:34 pm December 7, 2019

I really don't think it matters what Spotify do. Your company is not Spotify.

The idea is that everyone is cross skilled in the different areas

Is the intention to have teams that have a combination of all of the necessary skills, and are more adaptable, or is the emphasis on every individual being cross-skilled? The latter can turn into a destructive obsession; specialists are sometimes valuable, and people who are first-class in all areas tend to be expensive and harder to hire or keep.

I'm not sure if anyone has challenged the management, but what you've described sounds like an attempt to emulate a fashionable company, rather than focusing on the problem they want to solve. If they can explain that problem, it might be possible to find an even better solution. If they can't, maybe they aren't ready to instigate such a dramatic change.

Bringing development teams closer to customer pain points can be a very smart thing to do, and it's likely to trigger some kind of response from the teams. But unless the reasons are clear, the chances of success will be greatly diminished.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.