Large agile teams that are organized into a “team of teams” have several supporting structures. These structures are:
- The Product Coordination Team
- The Product Management Team
- The Architecture Team
- The Independent Testing/Integration Team
- Putting it all Together
The Product Coordination Team
The purpose of the Product Coordination Team is to ensure that team management issues, such as budgeting, reporting, scheduling, and people management issues are addressed in a timely and proactive manner. This team is sometimes called a Team Lead team, a Program/Project/Portfolio Management Office/Team, or simply a Management team. Responsibilities of these team may include negotiating dependencies between sub-teams, coordinating the release schedule, and initiating or closing sub-teams (these sorts of activities are captured in the Program Management process blade). It may also include ensuring that people are successfully on boarded (added) to sub-teams, off boarded (transferred) from sub-teams, and provided opportunities to grow/learn (these sorts of activities are captured by DAD’s People Management process blade). And of course the Product Delivery team will monitor and help facilitate solutions to any problems that arise between people on different sub-teams.
Figure 1 depicts a common structure for a Product Delivery team. It shows that the Team Lead from each delivery (sub-)team is a member of the Product Delivery team. It also indicates that this team is led by someone in the role of Program Manager, although this role could also be Portfolio Manager or Product Delivery Lead/Manager depending on the scope of the team. As with all agile teams the Product Delivery team will self organize. We’ve seen several strategies implemented, the Scrum-of-Scrums (SoS) strategy described earlier being a common one. However, we’ve also seen some Product Delivery teams choose to meet on a weekly basis for an hour to discuss common issues, supported by ad-hoc meetings between Team Leads to address specific issues between their teams as needed. And of course your Product Delivery team may choose to evolve their strategy as they learn and as their situation changes.
The Product Management Team
The purpose of the Product Management team, sometimes called a Product Owner team or Product Ownership team, is to manage requirements across sub-teams. This includes developing and evolving a vision for the program or portfolio, prioritizing work within the overall program, determining which sub-team will implement a given requirement, and managing dependencies between requirements being implemented by different teams. These activities are described in greater detail by the Product Management process blade (TBD). For now, please read The Product Owner Team.
Figure 2, which is similar to Figure 1, describes an organization strategy for an agile product management team. It shows that the Product Owner from each delivery team is a member of the Product Management team. This team is lead by someone in the role of Chief Product Owner, sometimes called a Product Manager or Director of Product Management. In smallish Product Management teams the Chief Product Owner is often a Product Owner on one or more delivery teams as well. The Product Management team will self organize, determining how they will work together. We’ve seen Product Management teams meet for thirty to sixty minutes each day to coordinate their work and we’ve seen other teams meet for a few hours weekly to do so. It’s also common for a Product Management team to meet on a regular basis with key stakeholders so as to identify new incoming work and to negotiate the priorities for the work in an open manner. We’ve seen this occur on a weekly, bi-weekly or monthly cadence in various organizations.
What Figure 2 does not show is that many Product Management teams include business analysts (what DAD would consider a Specialist role) and Domain Experts. Agile business analysts will support Product Owners that find themselves working at scale, often assisting them when stakeholders are geographically distributed, in situations where the problem domain is complex and requires deep analysis, or in regulatory situations requiring greater levels of requirements documentation. Domain experts are often called in on an as-needed basis to help Product Owners to work through complex domain issues.
The Architecture Team
The purpose of the Architecture Team is to formulate an architectural strategy at the program or enterprise levels; to communicate that strategy to their customers (both IT and business stakeholders); to evolve the strategy over time based on their learnings working with development teams and other stakeholders, and to resolve any architecture-level technical issues (such as evolving interfaces or changing underlying technical infrastructure) that arise over time. This team is also sometimes called an Architecture Owner team, Agile Architecture team, or even Enterprise Architecture team. A more detailed description of the activities this team may choose to perform as captured by DAD’s Enterprise Architecture process blade.
Figure 3, similar to Figures 1 and 2 before, show how Architecture teams can be organized. You see that the team is led by a Chief Architecture Owner, sometimes called a Chief Architect or Chief Enterprise Architect. The Architecture Owners from each delivery team should be members of the Architecture Team, so that they can share their learnings with others, get help from their colleagues as needed, and negotiate changes to architectural aspects of the solutions that they are working on as their overall strategy evolves. The Chief Architecture Owner will often be an Architecture Owner on one or more delivery teams. As with the other leadership teams, the Architecture team will self organize. We’ve seen teams that meet once a week for an hour, some teams that meet bi-weekly, and some teams that meet monthly. It is common for Architecture Owners to request an ad-hoc meeting of all or a subset of the Architecture Team to discuss an architecture issue that has become critical for them.
Figure 3 represents an architecture team for a program, or large agile team. In very large organizations we’ve seen the overall architecture team organized into a hierarchy. In one large financial institution, effectively a federation of financial companies around the world, there was an architecture team at the overall corporate level, one for each major division, and where needed one for each major program.
The Independent Test/Integration Team
As we mentioned earlier, the two primary reasons why agile teams become large are that they are addressing great domain complexity, great technical complexity, or both. One implication of this is that their testing efforts will reflect this complexity, the more complex something is the harder it is to test, and to deal with that complexity the team may decide to adopt the practice of parallel independent testing. As you can see in Figure 4, the basic idea is that each development sub-team will still test to the best of their ability but that more complicated efforts, such as end-to-end integration testing, be performed by a testing sub-team. This testing sub-team will support all of the development sub teams, pulling in the working builds from each development sub team, integrating those builds into a single pre-production test sandbox, and then they try to find potential defects which then get reported back to the appropriate development sub-teams. These potential defects are treated like new requirements by the development sub teams in that they are prioritized, estimated, and addressed appropriately. Although Figure 4 shows that one build/release is being provided by each sub-team each iteration, it is common for teams to provide several builds each iteration – this cadence is something that the development sub-teams would need to negotiate with the Independent Test/Integration Team.
Figure 5 depicts a potential team structure for an Independent Test/Integration Team (ITIT). Note that this sort of team is sometimes called an Integration Team (as in SAFe), a Quality Assurance Team (a more traditional name), or simply a Test team. As you see in Figure 5 the ITIT typically has a Team Lead, one or more Independent Testers, and zero or more Integrators. The Team Lead is typically a senior tester who has both testing and leadership/management responsibilities. The Independent Testers often focus on the more skillful forms of testing, including pre-production integration testing, exploratory testing (something that the development sub teams can and should be doing as well), security testing (this can require expensive testing tools and security expertise), and usability testing to name a few. Someone in the integrator role will do the work necessary to integrate the various builds from each sub team and in effect will perform installation testing while doing so. We’ve seen small ITITs of one person who performed both testing and integration (remember, Team Lead, Independent Tester, and Integrator are roles, not positions or people). We’ve also seen larger ITITs with five or six people (remember, the vast majority of the testing is still being done within the development sub-teams).
Independent testing and integration isn’t reserved to large teams. We’ve seen small and medium-sized teams in the regulatory space that are supported by ITITs. This occurs because some regulations, particularly those in the life/health-critical space, require independent testing. This doesn’t mean that all testing must be independent, a common misconception within waterfall teams, but it does mean that some testing must be independent. The approach to independent testing that we summarize here is one way to push this sort of testing earlier in the lifecycle, thereby reducing the average cost of fixing potential defects.
Putting it all Together
Figure 6 depicts the same large-team structure of Figure 7 from the point of view of the various sub-teams. As you saw in Figures 1 through 3 people on each of the N delivery teams in the roles of team lead, product owner, and architecture owner will also be members of the Product Delivery, Product Management, and Architecture Teams respectively. Each of these teams will self organize and coordinate their activities as they feel appropriate. The delivery/development sub-teams are also supported by the Independent Test/Integration Team that is performing the more complex forms of testing that would otherwise be left to the end of the lifecycle.
Now that we understand how to organize the coordination and leadership structure around delivery/development sub-teams it is appropriate to discuss strategies for organizing the sub-teams themselves.