5 Team structures for Agile teams

Catherine Powell presenting at Oredev

Catherine Powell presenting at Oredev

Catherine Powell, principal at Abakas, a Boston based firm, spoke about agile team structures at Øredev, the software development conference in Sweden at the end of last year. She provided 5 sample team structures as examples that we could use them putting together Agile project teams of our own.

1. Team generalist

In this team, “anybody can pick up any task at any time,” Catherine said. This works most effectively on a well understood project and with people who are good in diverse roles. “The people are hard to find and kind of expensive,” she said. It works well if you avoid groupthink: no ‘us versus them’ because there is no ‘them’. This approach is hard to scale and works best in small companies with passionate people.

2. Team specialist

“Everyone on the team has a different specialty,” Catherine said. This gives you high quality software, tests and data analysis but in her experience project managers don’t find this structure easy to work within because there is no predictability. You often end up with resources with nothing to do. She said that specialist teams miss their Sprint target on 70% of sprints. “If you can avoid this level of specialty, avoid it,” she advised. It works most effectively with larger teams, and if you have to have this structure she recommended that you put in place some cross-training to minimise the periods where some team members are really busy and others have nothing to do.

3. Team relay

“This is common for teams that are transitioning to scrum,” Catherine said. It is seen in companies who are trying to move from the waterfall philosophy to an agile mentality. She recommended that this type of team do some test sprints where the sprints are broken down by discipline. Long-term, all this structure and approach to sprints does is extend the delivery timescales.

4. Team biathlon

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.

5. Team handoff

In this final team structure, the work is handed off between teams over time. You hand off the product from team to team. This works well when scrum is in use over the whole organisation. For example, the product is designed by one team and given to another team to do the implementation and installation. This is an organisational level team model and so it would work effectively in companies used to doing things in an agile way.

Your team

“Ask questions about your own organisation as that is key to a successful agile team,” Catherine said. “Everything you read is generic, so it is only kind of like your organisation.” Find out what you want from your team. “What is that shared goal?” she said. “How much can we change and still be agile?” She recommended building your agile team to meet you own organisational needs and to change whatever you wanted in order to achieve that.

Have you ever put together an agile project team? Which of these models was it most like, or did you come up with something totally different?


  1. John Goodpasture says

    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.

  2. says

    Project teams are the heartbeat of project management.  Interesting view on the breakdown of the different types of agile teams. Thanks for sharing

    • says

      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.

  3. Ella Mapple says

    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
    courses. I would personally suggest Agile Expert
    Certified course or Scrum
    Master Certification
    to you.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>