Agile Teams: Roles & Structures That Work
(This post contains affiliate links. Read my full disclosure.)
It’s different to predictive project management — where you know what you are building and are planning how to get there — because when you work with
You aren’t always sure of the destination, and that’s why
So why are they different? In this article we’ll look at what makes up an
What is an Agile Team?
An
It’s almost easier to think of
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 Team Roles
As an
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
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.
Product owner. I see this role as most aligned to a project sponsor on a non-
Team member. In an
Tester. As much
As
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
- 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.
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
1. Generalist Agile Team
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.
If your
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
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.
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
5. Agile Product Sub-Team
In a large organization, you may well find this
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
If you aren’t feeling like your
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
Lack of
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.
Your Agile Team Structure
Ultimately, as an
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:
An agile process tends to focus on iterations, and client
feedback, to allow for the inevitabilty of changing requirements whereas a
waterfall process tries to define all requirements up front, and tends to be
inflexible to changing requirements. You can learn more about agile and scrum
by referring to some free resouces (http://www.scrumstudy.com/free-resources.asp)
provided by scrumstudy or by attending any agile scrum
certification courses. I would personally suggest Agile Expert
Certified course or Scrum
Master Certification to you.
Interesting view on classification of teams. Thanks for sharing.
You’re welcome! Glad you found the article interesting.
Project teams are the heartbeat of project management. Interesting view on the breakdown of the different types of agile teams. Thanks for sharing
Teams are so important to projects. You could adapt these suggestions here to any teams, I don’t think they need to be particularly agile to benefit from these structures as you could put them to use in other environments as appropriate.
I don’t see where Powell reconciled these structures with the “theory of the case” for agile, to wit: a team has a characteristic — a parameter — called velocity that is a measure of its productivity in a time box (even if time boxes per se are implemented). Velocity is a rate. If you switch the participants around by means of any of these five structures, you’ve pretty much nullified the idea of a team parameter since it’s a team in word only.