team

Agile Team Structure – Part 1

In this series of articles we look at the different ways that you can structure your teams in order to help you succeed with agile software delivery. All information in these articles is from my personal experience, you may find you have different experiences, but hopefully it’ll give you something to think about when deciding how to tackle your backlog with agile teams. Note – this isn’t a “how to set up your teams” article, this is the personal journey I’ve been on, and how I have arrived at the setup I currently have. Enjoy the read!

The development team

The fundamental building block is the development team. In order to work effectively, you should try and expand in units of teams, a team is made of the following roles:

Scrum Roles

A single Scrum Master is responsible for promoting and supporting Scrum within the team, the Product Owner is there to prioritise the backlog; to make sure we are always working on the most valuable things. You may require any combination of UX (User Experience) or UI (User Interface) designers, software developers or QA (Quality Assurance) testers. A scrum team is typically between 3 and 9 people, and should have everything they need in order to build a working increment of software.

Deploying your team(s)

Your teams need something to work on! My teams work on an audio product available on iOS and Android, and a website to promote the brands. We had 4 teams working on everything our department was responsible for, they were set up as platform specific teams:

  • Websites team – responsible for everything on our websites including the CMS (content management system) that provides all the content for them
  • Android team – responsible for developing our Android apps
  • iOS “Yin” team and the iOS “Yang” team; responsible for developing our iOS apps

We had twice the number of iOS developers because at the time, iOS app development was more lucrative.

Like many companies, we also had a shortage of Scrum Masters, Product Owners and QA specialists. This meant that these roles were shared across teams; so a single Scrum Master (me) across 4 teams; 2 x Product Owners across 4 teams, and 3 x testers across 4 teams.

Platform Based Scrum Teams

You may also notice that the UX / designers are missing. That’s because they had their own team:

UX / Design team

Having designers set up in a centralised, agency style setup, caused it’s own problems whereby features were being designed independently to the product backlog (not ideal and something I’ve helped to fix now).

Scrum Meetings

Each team held it’s own set of Scrum meetings:

If you are the Scrum Master in this situation, you have many meetings. It also caused a few problems with Product Owner‘s time, and of course any QA’s split across teams.

The Pros

  • It’s easy to understand exactly which team is working on which product; as it’s a one to one mapping
  • This setup creates great groups of specialists learning off each other in the same team
  • It can create healthy competition between teams building the same feature, but on different platforms.

The Cons

  • This set up causes dependencies between teams. For example, what if both the iOS and Android teams rely on a backend change that’s being made by the websites team.
  • The features available on each platform can vary wildly, especially if you have more iOS developers than Android developers ๐Ÿ˜‰. This might be fine for you, but it’s something to be aware of.
  • There are lots of meetings for you if you are working on multiple teams

Summary

After reading this, I hope you can see that this isn’t the answer on how to set up your own teams and distribute the work between them. Each company will have it’s own unique way of doing it. This was the first step on my journey as a Scrum Master to setting up our development teams. In the upcoming articles, you’ll see what I moved on to next.

Stephen Waring
Stephen Waring

I’m an enthusiastic and energetic Scrum Master who loves everything about Agile!