What makes a team good at Scrum?

How can you tell if a Scrum team is doing well? Project outcome metrics and stakeholder satisfaction are very important for the business side of things, but for the team itself it’s also important that they’re good at doing Scrum.

This week’s paper describes a study that takes a closer look at the latter. More specifically, it empirically investigates the impact of team maturity, team composition, Scrum values, Scrum roles, and Scrum events on the perception of successful application of the Scrum framework.

An online survey was conducted among 182 Scrum team professionals at 22 Danish companies from different sectors. Many of the companies operate globally and are spread over several locations in Denmark and abroad.

The results are kind of exactly what you’d expect.

There is a moderate correlation between a team’s perception of its success and its maturity level. Teams that stay together over the years are more likely to become successful at applying the Scrum framework.

This might sound obvious, but the practical implication of this finding is that it’s not enough to simply learn Scrum through courses and certifications. Much of the required Scrum knowledge is gained through experience.

With regards to team composition, there are five variables that impact the perception of success:

1. fully allocated team members (side note: i.e. team members who do not spend part of their time on other projects)
2. stable Scrum teams with low turnover rates
3. teams with required skills and expertise to conduct work
4. agile training of team members, and
5. empowered Scrum teams who are self-managing.

The first four in particular are variables that can be directly influenced by the organisation, which is probably good news for managers. Interestingly, the researchers found that co-location does not appear to influence the perception of being successful at Scrum. In this sense, flexible hybrid (or even fully remote) teams are just as good as co-located teams.

The Scrum guide suggests that successful application of Scrum requires that people live and breathe five values: commitment, focus, openness, respect, and courage. These values are intangible and hard to influence from outside the team, but are very important nonetheless: results show that teams that are proficient in living these values are more likely to perceive themselves as successful at Scrum.

The Scrum guide additionally defines three main roles: developers, Scrum masters and product owners. The survey included questions about 22 variables related to the impact of Scrum roles on perception of success.

The results suggest that there’s no significant correlation between the strict application of roles as defined by the Scrum guide and being successful at Scrum. In practice, companies and teams often take a more pragmatic approach.

Nevertheless, the existence of the three major roles in a team does contribute to the successful application of the Scrum framework.

Some particularly important aspects for each role include the developers’ ability to adapt their plan towards the sprint goal on a day-to-day basis, the ability of product owners to prioritise work, and Scrum masters’ ability to ensure that all Scrum events take place.

There are also a few characteristics and responsibilities that affect how teams perceive their success with Scrum. Developers must have skills and expertise within their domain of work, product owners must have strong communication skills and business knowledge, while Scrum masters have to enable their team to improve practices within the Scrum framework and coach team members in self-management.

The final section of the survey covered the impact of various Scrum events on perception of success. Strictly following the four major sprint events (planning, daily Scrum, review and retrospective) appears to make teams perceive themself as being successful at Scrum. However, a more detailed analysis suggests that people mostly just care about whether events are held at the same time and place; in practice, teams often have their own implementations and risk ending up with a flawed ScrumBut process.