So why are
- The different roles you’ll find in an
- The team structures you can set up to help make your
agileteam a success.
Whether you are starting work in an
What is an
It’s almost easier to think of
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 need specific team structures?
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
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.
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.
Agile team roles + a couple of other roles
The most common
1. Scrum Master/Team lead
If you are using the A
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
2. Product owner
They are the person representing the interests of the client/stakeholder – literally the person who owns the product that the
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
3. Developers/ Team member
There might be other roles you need within the Scrum team or squad too. These include:
Tester. As much
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.
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
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
As you’d expect from the name, in a generalist
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.
Try this team structure in small teams as it is hard to scale.
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.
Everyone has to start somewhere. When a team is transitioning to an
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
However, long-term, all this structure and approach does to sprints is extend the delivery timescales.
A full PMI-ACP exam prep course. Self-paced with video training modules, you'll quickly be on your way to your agile certification. We love this course from respected trainer Cornelius Fichtner and it's a cost-effective way to prepare for your exam. Upgrades available to add on the exam simulator and study guidebooks.
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 product sub-team
In a large organization, you may well find this
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
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
However, it can also work where the
I’ve known predictive programs being run with
If you aren’t feeling like your
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
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 project management challenge #2: Team size
The second challenge might be that your
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.
Agile team structure: it’s up to you
Ultimately, as an
All the structures and roles above are general, and
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
Read next: Is hybrid right for your team?
Pin for later reading: