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
In this article:
- What is an Agile Team?
- Agile Team Roles
- Agile Team Structures
- 1. Generalist Agile Team
- 2. Specialist Agile Team
- 3. Transitioning Agile Team
- 4. Parallel Agile Team
- 5. Agile Product Sub-Team
- Agile Project Management Challenge #1: It doesn’t feel right
- Agile Project Management Challenge #2: Team size
- Your Agile Team Structure
What is 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. They people who need to make the decisions are part of the team. Agile works for today’s projects.
Agile Team Roles
Team lead. If you are using the
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
Product owner. I see this role as most aligned to a project sponsor on a non-
Team member. In an
Tester. As much
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.
Agile Team Structures
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.
In this team, everyone changes jobs per sprint. Everyone writes code, then everyone moves to test it. This set up 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
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
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
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
Pin for later reading: