Agile Teams: Roles & Structures That Work

Agile methods need Agile teams — teams that think differently and work in ways that support responsive delivery. An agile mindset, and a set of shared values, principles, and often Agile tools, help Agile teams succeed.

So why are agile teams different to other types of ‘classic’ project team? In this article we’ll look at two things:

1. The different roles you’ll find in an Agile team
2. The team structures you can set up to help make your agile team a success.

Whether you are starting work in an agile environment for the first time or just looking for ways to make your team more effective, I’ve got you covered!

What is an Agile team?

An Agile team is a cross-functional group of people that is self-contained to the point that the people in the group can deliver the product (or the next iteration of it) without needing to draw on skills outside the group.

It’s almost easier to think of Agile teams by virtue of what they are not. Agile teams aren’t simply a project team made up of various different people from different areas of the business — although that would be a good definition for a team working in a predictive or waterfall environment.

Agile teams aren’t solely developer resources. They aren’t a matrix team either.

Agile teams are dedicated groups of people who (if you want them to do their best work) don’t move between products or teams just because there’s a demand in a different area of the business this week. Therefore they become a close-knit and trusted group of colleagues, finding a working rhythm for deliveries.

You might hear them called squads.

Together, they are a “whole team”. They don’t need anyone or anything else to get things done. This is particularly important when it comes to decision-making. The people who need to make the decisions are part of the team. Agile works for today’s projects.

According to the State of Agile 2021 Report, 66% of agile teams use Scrum, but that isn’t the only option. As we’ll see below, agile teams can be set up in a variety of ways and they can use a range of methods.

Why does agile need specific team structures?

Agile project management is a way of managing work that delivers iterative, incremental benefits.

Agile is different to predictive project management — where you know what you are building and are planning how to get there — because when you work with Agile methods, you adapt as you go, choosing the features to build that are based on business need and that make the most sense for the next iteration or sprint.

While the Product Owner (more on that role later) will have an overall vision, you aren’t always sure of the destination for a project when starting something new.

That’s why Agile methods like Scrum, Scrumban, and Kanban are great for delivering projects with high uncertainty or where the exact product spec is still being worked out as you go.

Agile is often considered an emerging trend in project management, despite it being around for many, many years!

OK, on to the different roles you typically find.

3 Core Agile team roles + a couple of other roles

As an Agile development team has to be “everything,” it’s important to have the right roles in the group.

The most common Agile team roles are:

1. Scrum Master/Team lead

If you are using the Agile method Scrum, then this role will be the Scrum Master. The point of the role is to facilitate the team.

The Scrum Master (or team lead) is responsible for finding resources for the team and ensuring team members are protected from office politics and the like, allowing them to get on and do great work. The Agile Alliance defines the role like this:

“The scrum master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use.”

The scrum master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use.

2. Product owner

They are the person representing the interests of the client/stakeholder – literally the person who owns the product that the agile team is changing or making.

I see this role as most aligned to a project sponsor on a non-Agile project. It is different, but if you are trying to learn agile ways of working coming from a waterfall/predictive/linear background then it’s a good starting point for thinking of the kind of decisions and vision setting this role would do.

3. Developers/ Team member

In an agile development project, this role would normally be someone in a programming or software development role.

However, as Agile is now commonly found in many teams out of IT, it could mean anyone who has something valuable to bring to the team that helps get the deliverables completed.

Other agile roles

There might be other roles you need within the Scrum team or squad too. These include:

Tester. As much Agile work is still carried out in the IT domain, software testing is still a big part of Agile teams.

Testers may be responsible for managing the software that runs automated code testing as well as working with end users to get feedback on usability.

Even in non-software teams, you may want someone who can act as a tester to run through processes, test training materials and so on.

As Agile projects are delivered incrementally, testing is really important. You need to regression test what you’ve already delivered to ensure your latest iteration doesn’t break something by mistake, for example. It’s a very responsible role!

On larger teams or specialist products you might also have:

Subject matter experts in technical or other domain areas. They might not be with the team the whole way through. Instead, they may drop in as needed in order to support the core team. For example, you might need a UX designer, an interface expert, a graphic designer, a content editor.

These roles might be permanently embedded in a squad or team if the need is great enough, or it might make more sense to have them float between teams supporting where they need to.

Architect. The role of the system architect is to ensure the solution is fit for purpose and fits within the rest of the enterprise architecture.

Architects may be attached to a squad or be part of a team that supports several agile teams.

And contrary to what you might have heard, you can have someone in a project management role on an Agile team.

Regardless of the roles you have in the team, it’s worth documenting them in a roles and responsibilities document.

Agile team structures

Here are 5 agile team structures that you could use when putting together your own teams.

1. Generalist Agile team

As you’d expect from the name, in a generalist Agile team, anybody can pick up any task at any time.

This team structure works most effectively on a well-understood project and with people who are good in diverse roles.

However, you have to find the right people to make this work: multi-passionate, dedicated people who can turn their hand to anything. Plus you need a project that can cope without very specific subject matter expertise. Not everyone on the team can be a tax expert or a specialist data protection analyst.

If your agile team is small, the project doesn’t require too much in the way of specialist expertise in any domain (that you don’t have in the team) and you’ve got passionate people, then this can be a great, self-motivated and driven team.

Try this team structure in small teams as it is hard to scale.

2. Specialist Agile team

In a specialist team, everyone on the team has a different skill set. This gives you high-quality software, tests, and data analysis because the people doing those roles are skilled in those areas.

However, you might find it difficult to work with this structure because there is no predictability. You often end up with resources sitting around waiting for their next task.

Catherine Powell, principal at Abakas, a Boston-based firm, speaking at the Oredev software development conference in Sweden, said that specialist teams miss their Sprint target on 70% of sprints. “If you can avoid this level of specialty, avoid it,” she advised.

Specialist teams work most effectively with larger team sizes — more towards the 20 people end of the spectrum rather than 5 or 6 people.

You can minimize the downtime for team members by cross-training them. Then hopefully you can smooth out their less busy times and they can help keep the project moving forward.

3. Transitioning Agile team

Everyone has to start somewhere. When a team is transitioning to an agile method like Scrum, you may want to set your team up to support that transition.

Moving to any new way of working is a learning curve. You’ve got to help the team adopt new ways of working.

You can manage the workload of a transitioning team by, for example, running sprints by discipline. So your testing becomes a sprint. It’s not pure Agile, but it’s a way of helping teams more used to waterfall/predictive methodologies get to grips with the language, practices and ceremonies of Agile.

However, long-term, all this structure and approach does to sprints is extend the delivery timescales.

4. Parallel Agile team

In this team, everyone changes jobs per sprint. Everyone writes code, then everyone moves to test it. This setup is good for cross-training, but you have cross-sprint release cycles.

If it sounds difficult to manage then that’s because it can be! There are easier ways to set up your team, but if you have reason to do it like this (for example, your experienced Agile team needs a new challenge, or there’s a particular reason to work with a client in this way), then, by all means, give it a go.

5. Agile product sub-team

In a large organization, you may well find this Agile team structure. It’s where the Agile team is actually a self-contained unit of a larger team.

Your team will have responsibility for a specific area of work, but the overall deliverable itself is made up of several sub-areas. All the agile teams work together, each in a particular area, to contribute to the bigger picture.

You’ll also find that the work is handed off between teams over time. Your team finishes something and that product (or sub-product) goes on to the next team.

This works well when a method like Scrum is in use over the whole organization. For example, the product is designed by one team and given to another team to do the implementation and installation.

This is an organizational level team model and so it would work effectively in companies used to doing things in an agile way.

However, it can also work where the Agile team is a sub-team of a not-so-Agile project team.

I’ve known predictive programs being run with Agile sub-teams doing software development, while the overall program structure was managed with a waterfall methodology. It sounds messy, but it worked!

---

If you aren’t feeling like your Agile team is really working in the best possible way, it’s possible that your Agile project team doesn’t fit into one of those 5 structures.

Let’s look next at some of the challenges that you might be facing on your team.

Agile project management challenge #1: It doesn’t feel right

And that might be perfectly OK. However, to see the benefit from being Agile, it definitely helps to have project teams that are self-managing and have many of the features that I’ve described above.

The fewer external dependencies the team members have on the rest of the business (or other teams) the easier it is for them to operate independently and do their job in the most agile way they know-how.

Lack of Agile culture is a core reason why Agile teams don’t feel that agile. If your agile methodology doesn’t feel as if it is working, maybe it’s time to take a look at your team structure.

Agile project management challenge #2: Team size

The second challenge might be that your Agile team is the wrong size.

When your team gets too big (i.e. more than 20), it’s helpful to break the team down and have several teams working.

You’ll need to split the deliverables so that each team has something discrete to work on. This is easily achieved with user stories and backlog grooming.

One of the responsibilities of the team leads then becomes to coordinate with other team leads, making sure the whole product hangs together.

Your Agile team structure: it’s up to you

Ultimately, as an Agile team lead or Scrum Master, it’s up to you to set the structure for your Agile team that works the best.

All the structures and roles above are general, and agile is an adaptive approach. So adapt it. There are a variety of methods out there. Make it work for your organization and your project.

Listen to the team, what they need and how you can deliver it. Draw on their expertise. And keep changing things up until you find a way to make your agile team work for everyone on it.

Read next: Is hybrid right for your team?

Pin for later reading: