The whole is greater than the sum of its parts.

—Aristotle, Paraphrased from Metaphysics [1]

System Team

Definition: The System Team is a specialized Agile team that assists in building and supporting the Agile development environment, including developing and maintaining the Continuous Delivery Pipeline. They may also support the integration of assets, end-to-end solution testing, DevOps mindset and practices, deployment, and release on demand.

Details

The growing complexity of modern software systems can dramatically affect the speed, quality, and flow of delivering value to customers. The most defining characteristic of today’s infrastructure is that it’s “diverse to a fault” [2]. It’s easy for developers to lose focus,  splitting their time between managing the issues associated with highly complex software development toolchains and delivering customer value.

Moreover, everyone has a cognitive limit to how much information they can hold in their minds at any moment. The primary reason to have a System Team is to increase the ART’s speed, quality, and productivity without jeopardizing the team’s ability to deliver new solution value. Agile Teams have an ever-increasing workload. Besides creating new solution value, teams are expected to continuously test, deploy, release, and even operate Solutions. To be more efficient and have economies of scale, the ART may need the help of a System Team so that they can focus most of their time on solution development.

The System Team accelerates the ART’s velocity and reduces the cognitive load on development teams by building and maintaining the Agile development environment infrastructure, for example:

  • The creation and maintenance of a Continuous Delivery Pipeline toolchain. This toolchain encompasses continuous integration, automating builds (including verification testing), deployment, and release.
  • Creating platforms and environments for development, user acceptance testing, solution demonstration, deployment, and production.
  • Facilitating the technical elements of collaborating with third parties like hosting and data service providers.
  • Ensuring the ART has an intentional architecture for the infrastructure and that teams use standard tools and DevOps practices.

Responsibilities

Figure 1 illustrates the System Team’s five primary areas of responsibility. However, it’s important to note that while these responsibilities are highlighted here, the System Team and Agile Teams share them. Otherwise, the System Team can become a bottleneck, and the Agile Teams will not be fully capable of full end-to-end value delivery. The following sections describe each of these areas.

Figure 1. The System Team’s primary areas of responsibility
Figure 1. The System Team’s primary areas of responsibility

Note: The need for a dedicated System Team may decrease as the ART automates the CDP toolchain and learns how to deliver value independently and together. Over time, the knowledge from the System Team gets dispersed to the ART, and teams begin to have collective ownership of their broader responsibilities. For larger solutions, however, it’s more likely that specialty expertise remains with one or more System Teams, as described in the section on Solution Trains below.


Building Development Infrastructure

A robust technical infrastructure supports high ART velocity, so the System Team may:

  • Create and maintain the CDP toolchain – this includes automating continuous integration, builds and verification testing, deployment, and release tooling
  • Create platforms and environments – creating environments for development, solution demos, and user acceptance testing in the cloud or on-premises
  • Facilitate the technical aspects of collaboration – act as the liaison with third parties, such as data, service, suppliers, or hosting providers

Supporting Solution Integration

Complex solutions also require that the System Team supports solution integration, which may involve the following activities:

  • Version management – determine and help maintain decisions and policies for version control and management
  • Create and run integration scripts – create and run solution-level build and integration scripts or manually integrate where automation does not yet exist
  • Attend various sync events – most work for the System Team comes from other Agile Teams, so various sync events (for example, PO, coach, architecture, or team syncs) help them keep pace with the needs of the train before this work becomes a critical emergency

Assisting with End-to-End Testing

The System Team may also perform some testing duties that support Agile Teams:

  • Create newly automated test scenarios – Many teams may not have the infrastructure or knowledge to test functionality end-to-end. Systems Teams provide the environments to help teams create automated tests to support new or existing functionality. They may even write some of the more complex test scenarios.
  • Provide datasets – create re-usable test data and maintain it under version control.
  • Organize and manage test cases – organizes test cases designed by individual teams into ordered test suites, prioritize time-consuming tests, and improve testing infrastructure.
  • Perform manual testing – assists teams in performing manual testing for complex scenarios (such as end-end and exploratory tests) and some cross-system Features where automation is not yet feasible.
  • Conduct systems integration testing – assist the development team in verifying the integration between different systems. They test various integrations that form the end product, including integrations between software components and between software and hardware.
  • Create smoke tests – help create build verification tests to enable developers to verify their builds quickly and independently.
  • Test solution performance – helps create and run tests for NFRs (for example, security, reliability, performance, and usability) and assists System and Solution Architects identify system shortfalls and bottlenecks.

Supporting System and Solution Demos

The ART conducts a System Demo at the end of each iteration, testing and evaluating the complete solution in a production-like environment (often Staging) to receive feedback from stakeholders and test the solution in an environment where the infrastructure and data closely match production. Similarly, the Solution Demo presents the combined development efforts of multiple ARTs and Suppliers to deliver value to Customers and other stakeholders.

The System Team supports ARTs or Solution Trains to plan, prepare and conduct System and Solution demos:

  • Planning demos work with the Agile Teams to define what they will demo at the end of each iteration and prepare the needed environments and infrastructure.
  • Integrating assets – support the integration of assets and artifacts from Agile Teams.
  • Performing end-to-end solution demos – assist Product Managers, Product Owners, and others in running demos, predominantly end-to-end scenarios.
  • Set up and test the demo environment – prepare the technical environments needed to demo the new solution functionality reliably. Also, each new solution increment may require the System Teams to add extensions to the demo environment, including new interfaces, third-party components, simulation tools, and other environmental assets.

The System Team often helps trains make the necessary investments (in DevOps, CDP, etc.) to allow the system demo to happen in a timely cadence.

Facilitating Releases

The System Team supports ARTs and Solution Trains to plan, prepare, deploy, and release solutions. Activities can include the following:

  • Release governance – assists ART stakeholders with planning, managing, and governing solution releases. They also help Agile Teams ensure they meet any regulatory, industry, or other relevant standards and compliance.
  • Prepare for releases – package and deploy solutions as part of DevOps and CDP activities. This includes using various techniques such as feature toggles to switch features on and off.
  • Release solutions – helps the train release the solution to end users all at once, incrementally, or to different customer segments.
  • Stabilize and operate – collaborates with operations to ensure the solution works well from a functional and Nonfunctional Requirements (NFR) perspective.
  • Measure – helps the train instrument and quantify if the newly-released functionality provides the intended value, and assesses the health and efficiency of the CDP.
  • Learn – helps collect feedback from various sources and prepare for the next loop through the CDP.

The System Team in Solution Trains

For large, multi-ART Development Value Streams that need the constructs of the Solution Train, System Teams are essential for supporting larger-scale integration and release challenges. Depending on the scope and complexity of the development value stream, there are three main patterns for structuring the System Team:

  1. One System Team per ART that coordinates the solution integration and validation
  2. A System Team for the Solution Train and individual System Teams for each ART
  3. One System Team for the entire Solution Train, which can fulfill their responsibilities for all of its ARTs

The decision regarding which organizing pattern to use depends on the context. Factors include the ART structure within the Development Value Stream, the solution’s architecture, branching and integration policies, system testability, and development infrastructure.

Balancing Solution Integration and Testing Efforts

The System Team can never be the entire solution to the CDP tooling, infrastructure, and integration challenges. They need collaboration with other Agile Teams, aligned to a shared vision, to implement DevOps and the CDP. Efficient solution development requires sharing knowledge, best practices, and common infrastructure and tooling to help reduce complexity.

Maximizing ART velocity involves creating the optimal balance between Agile Teams and System Teams, as Figure 2 illustrates. With maturity and automation, the optimum point for integration responsibility shifts to the left, where the teams can reach higher degrees of autonomy and responsibility.

Figure 2. The optimum balance of integration effort
Figure 2. The optimum balance of integration effort

Learn More

[1] Aristotle. Metaphysics. Translated by W.D. Ross. CreateSpace Independent Publishing Platform, 2012.

[2] O’Grady, Stephen. The Developer Experience Gap. RedMonk, October 6, 2020. Retrieved October 10, 2023, from https://redmonk.com/sogrady/2020/10/06/developer-experience-gap/

Last update: 10 October 2023