Is Scrum applicable for your team?

Before adopting Scrum, it is important to ask if Scrum is applicable for your team. As with any approach, Scrum should not be used as a one-sized fits all. Abraham Maslow observed – “If all you have is a hammer everything looks like a nail.” 

Scrum was designed for a team working on a project/product. Its inspiration lies in The New New Product Development Game which we highly recommend reading whether you are doing Scrum or not.

The reality is, however, that one should not be looking at Scrum or Kanban as a choice. One can learn from both. The biggest difference between Kanban and Scrum has more to do with their general approach. Kanban is an approach to apply flow and doesn’t require any specific roles nor does it require advance planning or iterations.  Scrum has the requirement of having cross-functional teams and planning sprints. This, by the way, doesn’t mean you have to start with cross-functional teams, but it is designed for them.

Deciding whether to use Scrum should be a two-step process. The first is if it is generally applicable – that is, you have a team working on a project. This enables the potential use of the core Scrum practices of the sprint and cross-functional team.  The second is if the framework fits your culture.

Step 1: Is there a fit?

Can the team considering it’s adoption it plan ahead? Several types of teams can’t plan ahead. These include certain shared services teams and maintenance teams. In this case a flow model, such as Team Agility or Kanban, is more desirable.

Are cross-functional teams possible and financially desirable? Even if you don’t have cross-functional teams, you can likely make them more cross-functional than they currently are. In any event, people who are needed for more than one team can either be shared or have their own kanban board to manage the demand for them.

Trying to apply Scrum to organizations where these conditions don’t apply means that the organization must change to fit Scrum. This is sometimes a good thing and sometimes there are better ways to achieve agility. One shouldn’t be looking for change itself, but rather one should be looking for what works. Remember, different is not always better but better is always different.

In tabular form:

Team Type (a team is a group of people working together towards a common goal) Is Scrum Applicable?
Mostly maintenance team If the maintenance is just as things come in, probably not. If it’s a maintenance team that can plan what it does, likely so.
Shared services team Usually best to use Kanban
Team that can’t plan their work Usually best to use Kanban
Team where creating at least close cross functional teams is either not possible or doesn’t make financial sense No
Mostly independent development team Yes

Step 2: If there is a fit do we want to use Scrum?

When you have cross-functional (or at least semi-cross-functional) teams that can plan their work Scrum is often a good fit. This is the situation for most teams.  But the compelling reason to use Scrum has to do with whether it’s a good fit for the organization’s culture and level of team discipline.

One challenge with fitting a culture is if people are attached to the labels of their job description. Many companies don’t have career paths for Scrum Masters or developers (i.e., not differentiating between programmers and testers).  However, this isn’t a big problem – just keep your old titles.  A compelling reason to use Scrum is often if there is a strong need for breaking work down into smaller pieces. Scrum forces this with its time-boxed sprints. Some people believe Scrum is a requirement if you want to be able to calculate velocity, but Kanban allows for the through its use of cadence as well as Scrum (see Creating the Beat for the team).