Roles on Agile Teams: From Small

to Large Teams
Search Home | Articles | Books | IT Surveys | Podcasts | Contact Us | Announcements | Site Map

Two common questions of people new to agile will ask include "what are the roles on an agile
team?" and "how do you organize an agile team?" The goal of this article is to address these
questions by examining how you would do so for a relatively small agile team, perhaps of 15 or
AdChoices
less people, and for a large agile team, perhaps of 50 people or more. For teams in between
these sizes you will need to tailor a solution somewhere in between.
Agile Method
The roles and organization structures described in this article are meant to be representative --
your approach may differ slightly because you are in a different situation. But, if you think that Agile Scrum
your approach needs to be significantly different then you likely haven't yet fully given up on the
thinking behind traditional IT roles and are likely putting your agile adoption at risk as a result.
Also, this article does not address enterprise-level roles.

There are several key differences between the agile approach to team organization and the traditional approach.

1. Agile teams are "whole teams". Whole team is an Extreme Programming (XP) practice that advises you to have sufficient skills within
the team itself to get the job done. The implication is that the development team has the requisite testing skills, database skills, user
interface skills, and so on and does not rely on external experts or teams of experts for these sorts of things.

2. Agile teams are formed (mostly) of generalizing specialists. A generalizing specialist, sometimes called a craftsperson, is someone
who has one or more technical specialties (e.g. Java programming, project management, database administration, ...) so that they can
contribute something of direct value to the team, has at least a general knowledge of software development and the business domain in
which they work, and most importantly actively seeks to gain new skills in both their existing specialties as well as in other areas, including
both technical and domain areas. Obviously novice IT professionals, and traditional IT professionals who are often specialized in just one
area, will need to work towards this goal. Generalizing specialists are the sweet spot between the two extremes of specialists, people who
know a lot about a narrow domain, and generalists who know a little about a wide range of topics.

3. Agile teams are stable. Agilists understand that changing team structures -- this iteration Sally is part of the team but next iteration she's
pulled off to help another team -- is detrimental to project success. We strive to keep our teams as stable as possible, a goal that is much
easier to achieve if people are generalizing specialists.

Small Agile Teams

There are several roles, which have different names depending on the methodology being followed, common to agile teams. Roles are not
positions, any given person takes on one or more roles and can switch roles over time, and any given role may have zero or more people in it at
any given point in a project. The common agile roles are:

• Team lead. This role, called “Scrum Master” in Scrum or team coach or project lead in other methods, is responsible for facilitating the
team, obtaining resources for it, and protecting it from problems. This role encompasses the soft skills of project management but not the
technical ones such as planning and scheduling, activities which are better left to the team as a whole (more on this later).
• Team member. This role, sometimes referred to as developer or programmer, is responsible for the creation and delivery of a system.
This includes modeling, programming, testing, and release activities, as well as others.
• Product owner. The product owner, called on-site customer in XP and active stakeholder in AM, represents the stakeholders. This is the
one person responsible on a team (or sub-team for large projects) who is responsible for the prioritized work item list (called a product
backlog in Scrum), for making decisions in a timely manner, and for providing information in a timely manner.
• Stakeholder. A stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the
"gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on
other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the
development and/or deployment of a software project.

Figure 1 overviews the structure of a small agile team. What you typically read about in the agile literature is how a team of developers, lead by
the team lead, works closely with a product owner to build a high-quality working system on an incremental basis. What you don’t hear about as
often is what I call the “supporting cast”:

• Technical experts. Sometimes the team needs the help of technical experts, such as build masters to set up their build scripts or an agile
DBA to help design and test their database. Technical experts are brought in on an as-needed, temporary basis, to help the team
overcome a difficult problem and to transfer their skills to one or more developers on the team.
• Domain experts. As you can see in Figure 2 the product owner represents a wide range of stakeholders, not just end users, and in
practice it isn't reasonable to expect them to be experts at every single nuance in your domain. As a result the product owner will
sometimes bring in domain experts to work with the team, perhaps a tax expert to explain the details of a requirement or the sponsoring
executive to explain the vision for the project.
• Independent tester. Effective agile teams often have an independent test team working in parallel that validates their work throughout the
lifecycle. This is an optional role, typically adopted only on very complex projects (or at scale).

Figure 1. Organization structure of a small agile team.

Figure 2. Product owner represent a range of stakeholders.

Large Agile Teams

When the size of an agile team gets to be around twenty or more you discover that you need to divide and conquer and
take a “team of teams” approach. The typical strategy is to organize your larger team into a collection of smaller teams,
and the most effective way to do so is around the architecture of your system,. Each subteam should be responsible for
one or more subsystems, enabling them to work as a small agile team responsible for delivering working software on a
timely basis. This strategy is often referred to as Conway’s Law after Melvin Conway who introduced it in the late 1960s,
and is one of several lean development governance strategies.

The additional roles on agile teams at scale include:

• Architecture owner. This person is responsible for facilitating architectural decisions on a sub-team and is part of
the architecture owner team which is responsible for overall architectural direction of the project. The architecture
owner leads their sub-team through initial architecture envisioning for their sub-systems and will be involved with
the initial architecture envisioning for the system as a whole (as part of the architecture owner team, see below).
Architecture owners are different than traditional architects in that they are not solely responsible for setting the
architectural direction but instead facilitate its creation and evolution.
• Integrator. The subteams are typically responsible for one or more subsystems, and the larger the overall team
generally the larger and more complicated the system being built. In these situations the overall team may require
one or more people in the role of integrator who are responsible for building the entire system from its various
subsystems. These people often work closely with the independent test team, if there is one, who will want to
perform system integration testing regularly throughout the project.
As Figure 3 indicates, on large agile teams you need to coordinate several critical issues:

1. Project management activities. At scale it isn’t sufficient to simply focus on project leadership and allow self-organization to address the
technical aspects of project management. This may work on the individual subteams, but across the entire project/program the technical
aspects of project management, such as dependency management, contract management, resource tracking, vendor management
become critical. The project management team of Figure 3, sometimes called the program management team, is comprised of the team
leads from the various subteams. Their goal is to coordinate the management aspects of the overall team. This team is likely to have a
short coordination meeting each day, referred to as a “scrum of scrums” in the Scrum methodology, where current status is shared and
issues are identified.

2. Technical/architectural issues. The architecture ownership team is comprised of the architecture owners from the subteams and is
responsible for architecture envisioning at the beginning of the project to identify the initial technical direction and provide a basis for
organizing the subteams. In the first week or so of the project (sometimes several weeks on more complex projects) their goal is to identify
the subsystems and their interfaces, a strategy called “managing to the seams”, reducing the coupling between subsystems and thereby
reducing the amount of coordination required by subteams. Once the interfaces are well defined it is possible for the individual subteams
to focus on implementing the innards of those subsystems. Throughout the project this team will meet on a regular basis to share ideas
and resolve technical issues, particularly those surrounding changes to the interfaces of subsystems. They may choose to meet daily, this
is particularly common at the beginning of the project, but as the architecture stabilizes it is common to see them meet once or twice a
week.

3. Requirements/product ownership issues. The product ownership team is comprised of the product owners of each subteam and is
responsible for coordinating the requirements effort across the subteams. They will need to negotiate requirements with the larger body of
stakeholders whom they represent and divvy them out among the subteams appropriately. They’ll also need to negotiate the inevitable
disputes between subteams as to who should do what and what a requirement actually means. They also manage the requirements
dependencies between subteams and strive to minimize overlapping work between subteams.

4. System integration. System integration is important for any size of project team, but it is often absolutely critical on large teams (which
often address complex problems). The complexities of large project often necessitate the addition of a system integrator, or several
(sometimes called build masters), to the team. System integration occurs throughout the entire agile life cycle, not just at the end of the
project during the system integration test phase of a traditional project. During the first development iteration, called the "Elaboration
phase" in the Unified Process, an important goal is for the subteams to create mocks of their subsystems according to the interface
specifications agreed to earlier . The goal is to do a complete, end-to-end build of the mocked out system to ensure that the subteams are
working to the same technical vision. You'll undoubtedly discover that you need to evolve the interfaces a fair bit at this point as you run
into technical issues that you hadn't thought through during Iteration 0. There are several advantages for making mockups of the
subsystems available early in the project. First, the individual subteams can now move forward on their own work with few dependencies
on the other subteams. Each team will evolve their subsystems throughout the project, replacing the mocked out portions of code with real
working code. These new versions are made available to the other subteams, who in turn will choose when they want to integrate these
new versions into their own environments. In my experience earlier is better than later but you want to wait until you know that new
versions are stable, one of the advantages of having an independent test team, until you integrate it into your own work. Second, your
independent testing team can now test against the entire build as they see fit. Granted, at first they only have mockups of the system but
they can at least start organizing their test framework(s) for the system at this time. Third, you can similarly put together your integration
framework to support your continuous integration efforts across the entire system as well as integration efforts on individual subteams.
Fourth, individual subteams will promote their code after they've tested it within their own environments. On large-scale agile teams these
new subsystem builds are often vetted by your independent testing team before they're made available to the other subteams, a process
that should be done quickly and often. The test team will often do a full system integration test, something that may be difficult for
subteams to do due to timing considerations (integration tests often take a long time to run) or due to resource restrictions (the test team
typically has a more sophisticated platform to test on). Subteams may choose to use pre-approved subsystems at their own risk,
depending on your organization's culture.

Figure 3. Organization structure of a large agile team.

I'd like to share some observations:

1. An interesting feature of Figure 3 is that two supporting cast members of Figure 1, an Agile DBA and a user experience expert, have
become members of the subteam. These roles are examples of a general need by some subteams to include some technical experts that
are specialized in a given activity. By organizing the teams around the architecture some subteams become focused on certain aspects of
the overall system and as a result it can make sense to include some "overly specialized" people to address the specific aspects of the
subcomponents being addressed by the subteam.

2. As the size of the team grows, there is very little difference in the day-to-day activities of developers. They are insulated from the
complexities of large teams by activities of the coordinators and may not even know that this is occurring.

Where Did All the Traditional Roles Go?

As you saw in Figure 1 and Figure 3 many of the traditional job roles, such as project manager, business analyst, and designer (to name a few).
The leadership activities of project manager are taken on by the team coach and many of the technical skills are performed by members of the
team through self organization. Agile analysis occurs, but instead of being performed by specialized business analysts it is instead taken on by
product owners (many BAs choose to transition to the role of product owner) and developers collaboratively. Agile design occurs, but instead of
being performed by a specialized designer it is instead performed by agile developers who may or may not be led by an architecture owner.

The point is that although the roles may have changed that the activities taken on my traditional roles are still occurring. This isn't completely
accurate, what's really happening is that the goals addressed by the activities taken on by people in traditional roles are now being addressed by
activities taken on by people in agile roles. For example, the details behind requirements are being explored but they're being done so in an agile
manner by product owners and developers instead of in a traditional manner by business analysts. This can be disconcerting at first, particularly
if it goes against the training and education which you've received over the years and more importantly against the belief system that you've built
up based on your traditional experiences. Moving to agile requires a paradigm shift, and part of that shift is the acceptance that the project roles
have changed (for the better).

What About Enterprise-Level Roles?

The focus of this article has been on the role and organization structure of agile delivery teams, not on the supporting enterprise-level roles such
as enterprise architect, enterprise administrator, or portfolio manager to name a few. As the Agile Process Maturity Model (APMM) points out, the
need to become effective at enterprise disciplines is an important scaling factor. The good news is that it is not only possible for people in
enterprise roles to become more agile it is both desirable and necessary. But these are discussions for other articles.
Suggested Reading

This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the
Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid
agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides
the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from
end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and
agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it
explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise
teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based
strategies to provide a coherent, end-to-end streamlined delivery process.

Are you being asked to manage a project with unclear requirements, high levels of change, and/or a team using Extreme
Programming or other Agile Methods? If you are a project manager or team leader who is interested in learning the secrets of
successfully controlling and delivering agile projects, then this is the book for you. From learning how agile projects are
different from traditional projects, to detailed guidance on a number of agile management techniques and how to introduce
them onto your own projects, we have the insider secrets from some of the industry experts – the visionaries who developed
the agile methodologies in the first place. Managing Agile Projects is edited by Kevin Aguanno, a noted speaker and educator
on agile project management, and includes contributions from many noted figures in the agile movement.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team
lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.

Copyright 2005-2012 Scott W. Ambler This site owned by Ambysoft Inc.