Note: This is the next in a continuing series of posts in the Agile Enterprise Big Picture series, whereby I’m attempting to capture the essence of enterprise agility in a single slide.
I noted the recent addition of the System Team to the Big Picture in my last blog post. While this would have been best explained back near the beginning when I described the agile development teams, we turn to it now for completeness of that thread. In this post, we’ll describe System Teams in the context of the Big Picture.
As we described in an early post, Agile Teams are the development/software production engine that creates the code. These are the Define/Build/Test teams of Chapter 9 of SSA and each has the requisite skills necessary to specify, design, code and test their component or feature of the solution.
I am reminded, however, that at the enterprise level these teams alone are unlikely to have all the capabilities or authorities needed to deliver the solution and there is typically one or more System Teams that complement the feature/component teams. These teams work on the same release train cadence as the agile development teams and they share the same mission. In practice, these System Teams typically have responsibilities including:
System-Level Continuous Integration
The larger the system, the less likely it is that the teams and their existing build and CM infrastructure environments can pull ALL aspects of the solution into place on their own. For example, one large scale system consists of four components: a thick Windows desktop client, a server, a separate server that provides interfaces and support to financial exchanges and lastly, a parallel web client/server application set. Each of these system components is built on somewhat differing underlying technologies and it is no small feat to pull these pieces together and run full system validation on a daily basis. So there is a separate system team (integration team in this case) dedicated to this purpose and they are integral to the process. The System Team leaders participate in the daily integration Scrums and also provide a central coordinating point for system level information.
System Quality Assurance
The same analogy applies to system level quality assurance. Running a full validation suite on the system described above takes a small but dedicated team who constantly updates the full system verification and test platforms, runs the validation and assures system level quality such as performance and reliability and conformance to industry compliance standards. In addition, that team can assume the responsibility for testing against the “matrix of death”, which is the umpteen odd variants that occur in the customers supported platform and application environments.
In addition to these common functions, I have seen System Teams take on two other functions as well:
Building Architectural Runway in Greenfield Applications
Building a new application in an agile manner still depends upon early build out of the architectural infrastructure. In some cases, this must be done before even a single feature can be laid in to provide user value. I described this in SSA with the following graphic.
In the agile project kick-start mode illustrated here, the first team builds the initial platform, (maintenance and ongoing development of which will eventually assumed by other teams) before the feature teams are added to the project. This can also facilitate a natural transition of resources to the new project as old projects are completed or new hires can be added to the new project over time.
Building Development Infrastructure for the Project
The transition to agile methods typically involves a significant investment in the environment to support configuration management, automated builds and deployment and automated build verification tests for an existing or greenfield project. This may involve analysis, procurement of tools and systems, deployment, scripting, ongoing maintenance etc. This is a complicated and technical task that takes time and typically, dedicated software development-capable resources. Building an initial infrastructure team that is integral to the system release train is one way to assure the commitment, visibility and accountability of those resources. More importantly, it helps assure that the job will actually get done, because the entire release train is dependent upon its success.
This post summarizes my view of the role of System Teams in the Big Picture. Of course, there is no one right way to do any of this and so comments are always very welcome.
In the next post, I’ll continue to discuss the organizational model of the Big Picture, when I describe the role of the Release Management Team.