At Øredev in Malmö, Sweden, earlier this month Catherine Powell spoke about Agile team structures. She gave us seven pointers to take into consideration when you are putting together an Agile team. Here are the seven things she suggested you consider.
Things to seek out
First, Catherine talked about three things to seek out.
Similar heartbeats
Teams work well when they have production timescales in common. By that, Catherine meant that individuals that deliver to similar work schedules can work well together in a team. If you have someone whose work tasks take three times as long as everyone else (even if they are being super-productive and it is not because they are lazy or slow), then they will fall out of step with the rhythm of the rest of the team. This will cause problems in the team, so it would be better to put that person somewhere else in a different team if possible, and keep the ones that deliver at a similar pace together.
Teams that can deliver on their own
This takes two parts. Agile teams work well if they can be self-managing. Even if the team does include a project manager (or someone taking on that role), there is still much to be said for a team that can deliver on their own and control their own workload. They can work in conjunction with someone taking the project management role, but in a very self-directed way.
Equally, the team needs to be made up of people who have the authority to be able to make decisions without having to involve too many other people. In this way they can work quickly and take decisions that move the project forward, so you avoid delays due to not having the right people on the team.
Opportunities to eliminate competition
Seek out opportunities to ensure that the team works well together without creating a sense of competition. You don’t want developers (or any project team member) having issues with other people on the team due to competition. Try to create a sense of team harmony and collaborative working with a common goal in mind.
Things to avoid
Second, Catherine talked about four things to avoid when putting together an Agile project team.
Us versus them
She recommended that project managers constructing Agile project teams avoid opportunities for an ‘us versus them’ environment. For example, don’t necessarily create a team of testers and a team of developers. Is there an opportunity for blended teams? "Don't create rivalries where they don't have to exist," she said and gave the example of team names. Teams called ‘Team Alpha’ and ‘Team Beta’ have rivalries and competition built into them before they even start. ‘Team Orange’ and ‘Team Blue’ are more neutral team names (if you must have team names at all) and so work to break down the us versus them environment.
Excessive change unless there is a strong push
Catherine suggested that excessive change was avoided unless there was a genuine business reason and a strong push to adopt new working practices. She said that change was good and that we should encourage change in teams, but that when it becomes excessive it means changing things about how the team works before they have had a chance to get used to the last set of changes. This can result in change overload and working practices on the project start falling apart.
Opportunities for blame
The sixth consideration for an Agile team was to avoid opportunities for blame. When something goes wrong, learn from your mistakes as a team but avoid pointing the finger at any one individual. After all, it is rarely one person’s fault, especially when the team is working collaboratively and errors could be picked up at any point through design, development, quality review, testing and implementation.
Isolating insecure resources
Finally, Catherine recommended that insecure resources are not put in teams by themselves. This could be someone who, for example, is relatively new to a testing role and is put alone in a team of developers. It would be more beneficial for them to work with another tester, at least until they grow in confidence. If you do have to have someone with a specialty in a team and they are the only person representing that speciality, make sure they are someone with experience and a robust constitution. If you can’t do that, at least keep an eye on them to ensure the team is not isolating them further and that their potential lack of confidence is holding back progress.