Add to Google
Enterprise Agility-The Big Picture (10): The System Team
Posted on September 9, 2008 by Dean Leffingwell in Scaled Agile Framework/Big PictureNote: 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.
System Team Building Architecture in Early Iterations
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.
Summary
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.
I like the idea. Most of the Agile teams that I have worked on have had some fantastic programmers who were a little reluctant to leave the IDE. It was rare to find a developer who understood the ecosystem of that the code ran in, AND who wanted to come work with me on making business code run in it
On Continuous integration – This is so critical and it’s the first thing that many folks miss. People first have a hard time even investing in the concept of a dedicated team to focus on infrastructure. Second, they tend to leverage lower level developers to solve an architect type problem. In a healthy deployment of agile, we are fortunate that it’s quickly realized as an issue and addressed because as you highlight, everyone is dependent on them to succeed!
Only thing I would expand is that I believe “Agile Infrastructure” is a more appropriate definition. An Agile Infrastructure goes beyond just a successful build system. It includes automated deployment, automated smoke screen tests, documentation repositories, agile planning and tracking tools, etc. Basically anything that enables the team to successful iteration in a consistent and short duration manner!
On System QA – this team will struggle initially. Their first goal should be to be able to test the previous iteration’s components in an integrated fashion. As the agile release train matures, their goal should be able to test integrated code on a daily basis.
Mo
[...] agility in a single slide. In prior posts, we’ve discussed Agile Development Teams, Agile System Teams, Iterations , the Agile Product Owner, Backlog, User Stories and the Iteration Backlog the Release , [...]
[...] or the program or product manager, helps coordinate the delivery of the feature over time. The system team, or some like construct, performs end-to-end level testing of the new [...]