The whole is greater than the sum of its parts.

–Aristotle

System Team Abstract

System solutions are built largely on the efforts of the Agile DBT teams—teams that have mastered the art of building quality working software within a short timebox. However, in the context of the program or enterprise, the DBT teams are not fully self-contained. Rarely is any one team capable of fully integrating and evaluating a full system solution. The bigger the system, the less likely this is. Moreover, during the transition to Agile, it is typically the case that additional infrastructure work is required to be able to pull software assets together frequently (hourly, daily, weekly), rather than once only at the end of a development cycle.

To accomplish this, an additional, specialized team is usually formed, called the System Team. The system team is often responsible for initially building some of the initial common development infrastructure and then moves on to other program level activities, including system-level continuous integration and end-to-end testing. However, these efforts should be shared between the system team and DBT teams; otherwise, the system team will become a bottleneck.

Details

Summary Role Description

The System Team is a program team that is responsible for providing assistance in building and using the development environment infrastructure—including Continuous Integration, build environments, testing platforms and Testing Automation frameworks—as well as integrating code from Agile Teams, performing end-to-end system testing, and demonstrating solutions to stakeholders at each iteration. This supports the teams and other stakeholders by providing quick feedback with respect to the efficacy and integrity of the evolving solution.

Responsibilities

The system team’s primary responsibilities are indicated below.

Building Development Infrastructure

Good infrastructure supports high program velocity; thus, the system team may:

Create and maintain infrastructure including continuous integration, automated builds, and automated build verification testing
Create platforms and environments for system demonstration, QA, and user testing, etc.
Create systems, utilities, and scripts to automate deployment
Facilitate the technical aspects of collaboration with third parties, such as data or service providers, hosting facilities, etc.

System Integration

Complex software systems also require that the system team do the following:

Determine and help maintain decisions and policies for appropriate program branching models
Run system-level integration scripts or integrate manually where automation is not possible or has not yet been applied
Assist component teams in defining inter-component interfaces
Attend other teams’ standups in support of daily activities.

End-to-End and System Performance Testing

The system team may also perform a number of automated testing responsibilities:

Participate in Release Planning and backlog grooming to define integration and testing Stories
Create new automated test scenarios
Extend test scenarios to larger data sets
Organize test cases designed by individual DBT-teams into ordered suites
Perform manual testing and run automated tests for new Features and stories
Prioritize time-consuming tests, refactor and run reduced test suites where applicable
Assist DBT-teams in creating reduced test suites that they themselves can run
Test system performance against NFRs and assist system architects in identifying system shortfalls and bottlenecks

System Sprint Demo

At the appropriate time during every sprint, the teams need to demonstrate the current, whole system solution to stakeholders in a System Sprint Demo. The system team typically helps stage this demo, and helps assure that demo environments are adequate to the challenge of reliably demonstrating new system functionality.

Balancing System Integration and Testing Effort

Importantly, the system team is never the entire solution to the system problem. Indeed, merely because of its existence, the system team is not the only team that possesses knowledge about the entire system. Agile teams must also have a clear vision of the bigger picture of what they are creating. Otherwise, even local excellence on the part of Feature and Component Teams will not result in good economic outcomes. Effective system development occurs only when these practices are appropriately shared. For example, if only the system team is testing NFRs and individual teams don’t perform even lightweight performance testing, then the entire program velocity will be dragged down by the rework necessary to pass these critical quality tests. In a similar fashion, if Agile teams are not continuously integrating at least the immediate components they interface with, the integration effort by the system team will be a long and painful process. Maximizing program velocity requires a sense of balance, as Figure 1 illustrates.

Figure 1. The optimum balance in terms of the system integration effort between DBT-teams and the system team. With maturity and automation, the optimum point moves to the left.

Summary

The system team is one answer to the challenge of optimizing program velocity and is a critical element in the foundation for solution development and evaluation, as well as program performance improvement. Tight collaboration with other teams and stakeholders helps achieve higher program velocity and helps to find the right balance of effort, one where the system team is not a bottleneck and the Agile teams are not overwhelmed with system-level integration and testing.

Learn More

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley, 2011, chap. 4.

Last update 15 January, 2013