Agile Team
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.
Agile Team Roles
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.
1. Scrum Master/Team lead
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.
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
Tester. 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.
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 part of a team that supports several agile teams.
Agile team structures
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. If your agile team is small, the project doesn’t require too much in the way of specialist expertise in any domain 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.
Specialist teams work most effectively with larger team sizes — more towards the 20 people end of the spectrum rather than 5 or 6 people.
3. Transitioning Agile team
Moving to any new way of working is a learning curve. You’ve got to help the team adopt new ways of working.
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. It sounds difficult and it is. Managing team also very difficult.
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 agileteams 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. Overall program structure was managed with a waterfall methodology. It sounds messy, but it worked!
Agile project management challenge
- 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 team with the wrong team 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. It help to follow agile methodologies.
- Structure for your Agile team. Scrum Master, it’s up to you to set the the structure for your Agile team that works the best. 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.