AAS Best Practices:
1. Use Scrum of Scrums carefully when coordinating multiple teams. Scrum is the most often used Agile method in today’s environment, and primarily involves team management practices. In its simplest instantiation, a Scrum development environment consist of a single Scrum team with the skills, authority and knowledge required to specify requirements, architect, design, code, and test the system. As systems grow in size and complexity, the single team mode may no longer meet development demands. If a project has already decided to use a Scrum-like project-management technique, the Scrum approach can be extended to managing multiple teams with a “Scrum of Scrums,” a special coordination team whose role is to (1) define what information will flow between and among development teams (addressing inter-team dependencies and communication) and (2) identify, analyze, and resolve coordination issues and risks that have potentially broader consequences (e.g., for the project as a whole). A Scrum of Scrums typically consists of members from each team chosen to address end-to-end functionality or cross-cutting concerns such as user interface design, architecture, integration testing, and deployment. Creating a special team responsible for inter-team coordination helps ensure that the right information, including measurements, issues, and risks, is communicated between and among teams. But care needs to be taken when the Scrum of Scrums team itself gets large to not overwhelm the team. This can be accomplished by organizing teams—and the Scrum of Scrums team itself—along feature and service affinities. We further discuss this approach to organizing teams in our Feature-Based Development and System Decomposition practice. Such orchestration is essential to managing larger teams to success, including Agile teams.
2. Use an architectural runway to manage technical complexity. Stringent safety or mission-critical requirements increase technical complexity and risk. Technical complexity arises when the work takes longer than a single iteration or release cycle and cannot be easily partitioned and allocated to different technical competencies (or teams) to independently and concurrently develop their part of a solution. Successful approaches to managing technical complexity include having the most-urgent system or software architecture features well defined early (or even pre-defined at the organizational level, e.g., as infrastructure platforms or software product lines).
The Agile term for such pre-staging of architectural features that can be leveraged by development teams is “architectural runway.” The architectural runway has the goal of providing the degree of stability required to support future iterations of development. This stability is particularly important to the successful operation of multiple teams. A system or software architect decides which architectural features must be developed first by identifying the architecturally significant requirements for the system. By initially defining (and continuously extending) the architectural runway, development teams are able to iteratively develop customer-desired features that leverage that runway and benefit from the quality attributes they confer (e.g., security).
Having a defined architectural runway enables technical risks to be uncovered earlier, thereby helping to manage system complexity (no late surprises). The consequence of uncovering underlying architectural concerns such as security, performance, or availability late—that is, after several iterations have passed—often is a significant rework rate and schedule delay. Delivering functionality is more predictable when the infrastructure for the new features is in place so it is important to maintain a continual focus on the architecturally significant requirements and estimation of when the development teams will depend on having code that implements an architectural solution.
3. Align Feature-Based Development and System Decomposition. A common approach in Agile teams is to implement a feature (or user story) in all the components of the system. This gives the team the ability to focus on something that has stakeholder value. The team controls every piece of implementation for that feature and therefore they do not have to wait until someone else outside the team has finished some required work. We call this vertical alignment because every component of the system required for realizing the feature is implemented only to the degree required by the team.
However, system decomposition could also be horizontal, based on the architectural needs of the system, focusing on common services and variability mechanisms promoting reuse.
The goal of creating a feature-based development and system decomposition approach is to provide flexibility in aligning teams horizontally, vertically, or in combination, while minimizing coupling to ensure progress. Although organizations create products in very different domains (embedded systems to enterprise systems) similar architecture patterns and strategies emerge when a need to balance rapid progress and agile stability is desired. The teams create a platform containing commonly used services and development environments either as frameworks or platform plug-ins to enable fast feature-based development.
4. Use quality-attribute scenarios to clarify architecturally significant requirements. Scrum emphasizes customer-facing requirements—features that end users dwell on—and indeed these are important to success. But when the focus on end-user functionality becomes exclusive, the underlying architecturally significant requirements can go unnoticed.
Superior practice is to elicit, document, communicate, and validate underlying quality-attribute scenarios during development of the architectural runway. This becomes even more important at scale when projects often have significant longevity and sustainability needs. Early in the project, evaluate the quality-attribute scenarios to determine which architecturally significant requirements need to be addressed in early development increments (see architectural runway practice above) or whether strategic shortcuts can be taken to deliver end-user capability more quickly.
For example, will the system really have to scale up to a million users immediately, or is this actually a trial product? There are different considerations depending on the domain; for example, IT systems use existing frameworks, so understanding the quality-attribute scenarios can help developers understand which architecturally significant requirements might already be addressed adequately within existing frameworks (including open-source systems) or existing legacy systems that can be leveraged during software development. Similarly, such systems have to deal with changing requirements in security and deployment environments that necessitates architecturally significant requirements to be top priority when dealing with scale.