People who are new to Agile often ask the same questions. Two of the most common are ‘What are the roles on an Agile team?’ and ‘What is the team structure?’. The answer to these questions depends on several factors, most notably the size of the team involved. The Agile team structure for a group of 15 or less would be different than that of 50 or more.
However, it is also important to realise that while there is a general team structure for every size of business, each company is different and will need to tailor this structure to their needs. That being said, if you feel like you have to stray too far from the Agile structure to meet your team’s needs, then you may not have fully relinquished traditional IT roles and you may be putting your adoption of Agile at risk.
Agile team approaches can vary but can be loosely categorised in five ways:
This is an Extreme Programming idea that involves having the required amount of skills to get things done in the team. It is based on the idea that everyone in the team has the required skills for testing, database and user interface. With a whole team approach, you do not rely on external experts or reports to get results.
These are people who have more than one technical specialty with a good general knowledge of software and the business in which they work. These generalising specialists also need to be keen to acquire new skills in these and other areas. If your team consists of people who have one key IT skill or rely on traditional IT training, then they need to be prepared to work towards a more general set of goals.
One of the key benefits of the Agile team structure is that it is very stable. Agile understands that team dynamics and personnel change over time and that adaptability to these changes is built into the system. If someone in the team is taken off to work on another project, the true Agile team can simply absorb this loss and carry on. Traditional IT teams often agonise over this kind of thing much more severely.
Within a small Agile team, you can expect there to be several key roles. These are the team leader, team member, product owner and stakeholders. But remember that these roles are not formal positions. They are fluid and can evolve over time. At any given point in a project, each role could be filled by one or more different people in the team.
There may also be a small cast of supporting players who include technical experts, domain experts and independent testers.
When the team’s size swells to 20 or more people, then you may need to alter your approach. The fundamentals remain the same, but you may need to organise into a group of smaller teams based around the above small-team approach. At this scale, you will then need an architecture owner and integrator to bring all the various teams together to work as one unit.