How to Build Your First Scrum Team

Building your first Scrum team is like doing anything for the first time: it gets easier the more you do it, but if you screw up the first time, you might never give it another shot.

I’d say it’s worth persevering, though.

It all starts with your readiness to adopt Scrum itself. By transitioning into a Scrum framework first, you have a strong foundation to build off of to make the workplace consistently rewarding for workers and can save your company a lot of wasted effort.

Let me explain. In this post, I’ll go over the basics about Scrum teams and how to set them up for success.

What is a Scrum team?

A Scrum team is a small group that works together toward a deliverable goal each sprint (typically one- to four-week periods). In software development, the work of a sprint is an incremental improvement that helps satisfy a user or product need.

In order to function, Scrum teams need to have the knowledge and the ability to tackle problems as they arise. To this end, Scrum teams must be:

Small. Teams should be capped at about five to 10 people. This includes all roles.
Self-organizing. Scrum teams are responsible for getting the work of the sprint done without outside help. Nor are they required to provide help to those outside the team.
Cross-functional. Members of a Scrum team have all the skills necessary to complete the work of the sprint.
Accountable. The entire team is responsible for the work of the sprint, regardless of an individual’s specific role.

Essentially, Scrum teams receive problems, turn them into sprint-sized projects, and solve them on their own. At the end of the sprint, a “done” project is delivered and the team moves on to the next sprint.

Scrum team roles explained

To understand how a Scrum team works within a company, it’s best to start by breaking down the various roles.

Each team is composed of a product owner, a development team, and a Scrum master.

The product owner is responsible for the product’s performance. By interfacing with stakeholders and the public, they figure out the improvements and fixes that end-users want to see, and add these “user stories” to the backlog. Managing this backlog to prevent redundant or unproductive work is one of the chief tasks of a product owner, who is ultimately responsible for deciding what to build.

The development team has to translate items in the backlog into problems they can solve. For example, say the user story is: we want to be able to see year-on-year breakdowns for data instead of just yearly. The team must figure out how to add this function quickly and elegantly, within the existing software architecture. Development teams have to figure out how to build it right.

The Scrum master is responsible for making sure the team is on target to hit their goal by the end of the sprint. They run Scrum meetings to diagnose problems the team is facing, remove impediments, and make sure the product owner has a reasonable idea of the team’s bandwidth. By ensuring projects are realistic and processes are working, Scrum masters help build it fast.

Thinking about the big picture, a Scrum team is the company’s quick response to unpredictable user stories. Once a platform or app goes live, thousands of users might push the product to its limits and demand new functions. No sooner have you released a product than you need to be ready to send updates back upstream.

Who should and should not have a Scrum team?

In a work environment where goals are stable and known in advance, Scrum may not be an effective structure. If it isn’t possible to break down tasks to the point where a small group can take on incremental improvements, it will be difficult to incorporate the Scrum framework productively.

If, on the other hand, your business needs fluctuate and require you to deliver constant improvements to your customers, Scrum works great. But before you decide whether or not to adopt it, you need to be honest with yourself.

Are you ready to entrust your team with its own self-regulation?

Are your employees ready to believe in and follow this new agile framework?

Ideally, unless you’re hiring, you already have people in mind to step into the classic developer, product owner, and Scrum master roles of a Scrum team. Can you count on the employees you have to take on that self-discipline? Some may not want the autonomy. Be choosy and take into account individual needs, especially for a pilot Scrum team.

Tip: Scrum teams don’t have to be collocated. Distributed teams can make use of tools for retrospectives and other Scrum functions to allow for continuous collaboration. So although it’s easier for all members of a Scrum team to be in the same place, it’s not a must.

Tips for building Your Scrum team

Much of the success of Scrum falls on the team’s shoulders. That’s what it means to be self-regulating after all. But at the same time, there are steps you can take to create the optimal working environment for your Scrum team to form, gel, and start down the road to generating useful work each sprint.

Here are a few tips I’ve picked up over the years for building a solid Scrum team:

1. Invest in your team’s preparation

How familiar are your employees with Scrum, kanban, and other process frameworks from the agile family? There is a chance that some team members have misconceptions about Scrum or worked at a company that failed to adopt it correctly.

Try cementing those principles by having the team attend a Scrum workshop or conference. Or by picking up the bill for your Scrum master to get certified. Not only will it fill in any knowledge gaps, but training will connect your people to the resources and experience of the larger Scrum community.

2. Dedicate time for the team to adopt Scrum

Making the switch to Scrum is not going to happen overnight. Regardless of whether you’re coming from kanban, lean, or something more traditional, there is no way your team will magically form up after a single Friday afternoon meeting.

Set aside a few days for people to learn and talk about Scrum principles. Yes, it’ll cost you time, but the team will recognize your investment. These early days are valuable for aligning the team.

3. Keep the small team together

Scrum values relationships over processes. It might seem logical to add more talent to a high-performing Scrum team, but too large a group strains these relationships. Similarly, pulling team members into other projects or responsibilities takes valuable energy away from the sprint.

These tips aside, no matter how well you support your team, there will be hurdles. Anticipate having to make adjustments.

And be sure to honor your team’s input. They need your trust. Empowered to make their own decisions, the team will have a much better time taking their own initiative.

Now let’s address a few ways your Scrum manpower might scale up or down.

Growing from Scrum team to multiple teams

So you can’t add more talent to your team. Then how do you grow?

You might find you need several teams. Maybe after a fresh round of funding, but maybe it becomes necessary on the fly.

For example, there might come a daily Scrum when a sprint becomes too complex to go around the whole room. Even in small numbers you don’t have enough time to address everyone’s concerns.

So can you divide the team?

Probably. Start by having the team think about it. They know their own processes and retrospective customs better than anyone. If they’re happy to restructure themselves, they’ll have the insight into how folks work together and how to split up the team effectively.

Tip: Though there are no “titles” in Scrum, there are specific roles to play. During this transition, make sure folks feel comfortable asking for what they want. Sometimes current team dynamics prevent transparency. Could you put the decision to an anonymous vote?

Scaling Scrum beyond individual teams

Once you have multiple Scrum teams in place, your organization will reach a new pace of development. If managing Scrum teams at multiple locations, especially globally, you’ll want to adopt agile principles beyond individual team level to sustain that growth.

Plus, larger companies tend to operate 12-18 months out, if not more. Incorporating customer feedback and preventing project overlap between teams while trying to scale Scrum on a multi-year timeline requires systematic workflows.

There are several such large-scale Scrum systems out there today, including:

Think of these process frameworks as extensions of Scrum. They support collaboration well beyond the team scope laid out in the standard Scrum Guide. Each framework takes a different approach to addressing the various problems that arise when a company has hundreds of Scrum teams completing sprints each week.

Getting from zero to one Scrum team

Still less concerned about scaling Scrum teams than about assembling your first? Remember, it’s supposed to be simple. And it can be with the right foundation.

The goal is to get more work done with less. That starts by recognizing how much you have already. Float the idea of starting a dedicated Scrum team with potential members. Who has extra bandwidth to put to good use? Who has experience to share?

And learn about Scrum yourself. Invest in a conference or Scrum certification to meet folks who successfully brought Scrum into their own companies. There’s no guaranteed roadmap, but the experience of others can pave the way.

When you build your team, we want to hear how it went! Share your advice in the comments below.