Scrum Roles: The Scrum Team

Last week I wrote about how Agile project management methods compare with traditional, waterfall-style methods. This week I’d like to start looking at Scrum – our favoured Agile methodology – and the most sensible way to begin is to talk about the different roles in Scrum, starting with the Scrum team.

Here I’m talking about the Scrum team minus the ScrumMaster and the Product Owner, whose roles I’ll be looking at separately. Schwaber and Sutherland’s definitive Scrum Guide refers to the ‘Development Team’ but, since not all the team members will necessarily be developers, we’re going to drop the prefix.

Indeed, within a Scrum team members are not assigned distinct roles. Instead the team is cross-functional. While it will be made up of people who, when working under a traditional development methodology, might be developers, testers or UX designers, in Scrum it is the team that is responsible for completing all work, not individual members. The team decide among themselves how the work is split up – the team is self-organising.

In each sprint the team is working together to produce an incremental version of the product – ideally a version that can be released but certainly a working version that is potentially shippable.

Who are the Scrum team?

The Scrum team will be made up of individuals possessing all the skills needed to turn the Product Backlog into a working increment of the product. So depending on what the team’s actually building it might consist of people who are normally developers, testers, business analysts, UX designers, copywriters, content managers etc

Within the Scrum team there is no hierarchy and there are no sub-teams, so nobody takes responsibility for different aspects of the work – the team as whole is responsible for delivering the increment of the product at the end of each sprint. Because the items in the product backlog are ordered, the team will be attacking the highest value items first and so, in theory, the team is always maximising value for the customer/business.

The Scrum team in practice

Scrum teams don’t just spring into being overnight.

In reality the transition from a traditional approach to one which uses the Scrum framework is a learning process for all involved. Even ScrumMasters with decades of experience will still have to learn how best to coach and protect a new team. Scrum is, after all, just a framework; a framework which places emphasis on individuals and interactions – which will never be the same in any two teams, organisations or projects.

This is why the framework builds in a certain number of interactions as a baseline – the sprint planning meeting, the daily scrum, the sprint demo and the sprint retrospective. It is mainly through these meetings that the team self-organises by setting a sprint goal, determining which user stories can be delivered within a sprint, agreeing to deliver them, splitting them into tasks, apportioning them to individuals and then reviewing what was done and how it could be improved.

As the product moves through successive iterations, getting closer to the product vision with each increment, so should the team incrementally improve its way of working – albeit with mistakes along the road.

Scaling Scrum teams

The cross-functional, self-organising model for Scrum teams naturally starts to break down when they get too large. The number and length of meetings (not to mention the size of meetings rooms) required to manage the processes of a huge team starts to edge out the time actually spent turning the backlog into product.

For this reason, large production teams are usually organised into a number of Scrum teams, each of which is part of a team of teams. In this scenario sometimes multiple teams work from a single backlog which is generally preferable although I have seen multiple teams working on a single platform using multiple backlogs.

The Scrum teams are often coordinated by a Scrum of Scrums meeting, which is attended by one representative from each Scrum team.

Common Scrum team pitfalls

Agile emphasises individuals and interactions over processes and tools and Scrum uses a framework of meetings to encourage such interactions between individuals. Attending the meetings is therefore essential for the team to work together effectively.

Scrum has a reputation for too many meetings but to bandy about such an accusation is often to disregard how much essential work is actually done in those meetings, removing the need for excessive processes, documentation and time-sucking emails.

There should also be plenty of informal communication as and when needed during a sprint. This is why Scrum works best when teams are co-located.

It’s also important for the motivation of Scrum teams to feel like they’re making progress. If the task board doesn’t change for a number of days it can feel like things have ground to a halt and can seriously damage communication.

While a single individual can remain buoyant over the course of a large task, a team’s morale can quickly collapse. Stories then should be broken up into tasks that are small enough for progress to be apparent at each day’s daily Scrum.

When working with teams new to Scrum I work out some simple principles for maximum size of a story that can come in to a sprint and maximum size of any single task.