The whole is greater than the sum of its parts.
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.
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.
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.
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.
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.
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
© 2010-2013 Leffingwell, LLC. All rights reserved.