Engineering and Manufacturing Development (EMD) Phase
Agile Fundamentals Overview
Agile Glossary
MATERIEL SOLUTION ANALYSIS (MSA) PHASE
Materiel Development Decision (MDD)
Analyze Requirements
Analysis of Alternatives (AoA)
Develop Acquisition Strategy
Market Research
Cost Estimation
Risk Management
TECHNOLOGY MATURITY AND RISK REDUCTION (TMRR) PHASE
Milestone A
Mature Requirements
Competitive Prototyping
Systems Engineering
Mature Acquisition Strategy
Contract Preparation
Risk Management
Request for Proposal
ENGINEERING & MANUFACTURING DEVELOPMENT (EMD) PHASE
Milestone B
Manage Program Backlogs
Release Execution
Manage Contracts
Metrics
Scaling Agile
Scaling Agile
While Agile works best with small, self-organized, co-located teams, some mid-to-large programs will apply Agile using multiple teams, parallel developments, and multiple contractors. Larger programs may have to use more of a hybrid approach with traditional development methods. Adapting Agile practices to larger projects requires sound engineering and management discipline to ensure successful integration of multiple smaller development efforts to support the objectives of the larger project. Simple designs, architectures, processes, and requirements enable multiple teams to achieve epic goals and deliver capabilities.
Guiding Principles for Scaling Agile
- Align tools, processes, standards, metrics, and terms across teams as much as possible
- Minimize impediments for teams to regularly deliver capabilities
- Decentralize most decisions to small, empowered teams
- Coordinate/orchestrate smaller efforts instead of managing it all as one large program
- Use retrospectives and continuous process improvement to retain Agile practices
A program with multiple development teams requires coordination across teams beyond the daily team meetings. This could occur by having the scrum masters of each team meet daily or as needed based on the level of integration – in a meeting otherwise referred to as a scrum of scrums. Other functional experts will likely need to meet across teams to coordinate on architecture, testing, costs, resources, performance, and other integration touch points. This, in turn, may require staff at a level above the teams to facilitate coordination and integration and take responsibility for enterprise designs, architectures, processes, metrics, and artifacts. The project team must tailor each of these engineering efforts to ensure appropriate use of rigorous methods without introducing heavyweight processes that would negate the benefits of an Agile approach.
Large Agile programs must have clear structure that defines the mission and business environment to guide the partitioning of the larger scope into development efforts of 12 months or less and possibly into multiple parallel development efforts. As previously noted, a technical architecture should frame the separate development efforts and ensure that individual products can operate in the target environment.
Agile emphasizes speed and responsiveness to changing user needs over highly detailed up-front definition of the system architecture. Each program must include periodic evaluation of the evolving technical architecture to ensure that the overall system continues to reflect sound engineering principles such as extensibility, supportability, and scalability.
Integration of multiple, smaller development efforts requires a disciplined approach that begins with high-level “roadmaps” describing the planned evolution of the larger system as exemplified by the Scaled Agile Framework phrase “architecture is intentional, design emerges.” As individual development efforts complete their tasks, testing must ensure that the separate components align with the roadmap and conform to the overarching technical architecture. The following items represent additional risk areas related to managing large-scale, multifaceted IT programs using an Agile methodology:
- Cost Estimation. When multiple teams work in parallel to complete an effort, estimating costs can become complicated, as the teams estimate and accomplish their tasks at different rates. Program managers must understand the estimation processes the teams use and how they relate to the overall cost of the program.
- Architectures. Although the Agile approach centers on delivering capabilities rapidly, program managers cannot ignore significant underlying architectural requirements. Short-term planning to meet iterative capabilities can result in tightly coupled architectures that impose heavy costs if the program must add new capabilities down the line. Especially when a project involves cross-cutting requirements such as security, performance, and availability, program managers must ensure that the developer devotes time early in the project to designing an infrastructure that can support iterative development and overarching quality attributes.
- Communication. Agile practices require close and constant communication among all stakeholders. If multiple teams are working on a project, the amount of communication needed increases per the formula n(n–1)/2, where n is the number of teams. Program managers must consider how to expedite communications, especially when the teams are geographically dispersed.
- Software Code Integration. Continuous integration involves frequent end-to-end builds of the changing code base, which becomes especially critical when the software development effort increases in scope and requires multiple systems to interact in order to meet the end user’s needs. Program managers should ensure their programs use the appropriate development and test tool environments, version control, and change management mechanisms to incorporate continuous integration into the development effort.
- Testing. Agile emphasizes the importance of performing tests early and continuously throughout the software development life cycle. In addition to unit and acceptance testing, regression testing is critical to delivering shorter and more frequent iterations. As each change is introduced, programs should perform regression testing to ensure the integrity of the overall system. Automated test tools are critical in the Agile environment.
- Requirements Derivation. Larger scale programs naturally include many requirements that may become backlogged. Program managers and product owners should define implied requirements, prioritize quality and architecturally significant attributes, and place high priority on requirements that support end-to-end capabilities. They should then review the activities backlog periodically and ensure that items are addressed in priority order.
The following are leading commercial methodologies to scale Agile. There are many common themes and approaches, yet each would need to be tailored for the unique government – contractor relationship in federal acquisition. In future AiDA releases, we will highlight a few examples of government applications of these methods for their environment.
Scrum of Scrums
Scrum of Scrums
A technique to scale scrum up for multiple teams working on the same product, allowing teams to discuss progress on their inter-dependencies, focusing on how to coordinate delivering software, especially on areas of overlap and integration (Wikipedia). 72% of respondents to a recent VersionOne survey use Scrum of Scrums to scale agile within their organizations. See more details from Scrum Inc.
Scaled Agile Framework (SAFe)
SAFe is a knowledge base of proven success patterns for implementing Lean-Agile software and systems development at enterprise scale. It provides comprehensive guidance for work at the enterprise Portfolio, Value Stream, Program, and Team levels. See more at Scaled Agile Framework and the video below.
LeSS (Large Scale Scrum) Framework
LeSS provides two different large-scale Scrum frameworks. Most of the scaling elements of LeSS are focused on directing the attention of all of the teams onto the whole product instead of “my part.” Global and “end-to-end” focus are perhaps the dominant problems to solve in scaling. The two frameworks – which are basically single-team Scrum scaled up – are:
- LeSS: Up to eight teams (of eight people each).
- LeSS Huge: Up to a few thousand people on one product.
See additional details at LeSS and introduction video below.
Disciplined Agile Delivery (DAD)
Strategic agility at scale refers to the application of Agile and Lean strategies across your entire organization. From an IT point of view this includes the majority, if not all, of your IT delivery teams as well as the IT-level teams support activities such as enterprise architecture, operations, support (IT help desk), portfolio management, IT governance, and other topics. From an enterprise point of view this includes all divisions and teams within your organization, not just your IT department. See additional details at DAD.
References:
- Agile Architecture: Strategies for Scaling Agile Development by Scott Ambler
- Scaling Agile for government, Deloitte, Jun 2017
- Five Perspectives on Scaling Agile, Will Hayes, SEI, Feb 2017
- 10 Recommended Practices for Achieving Agile at Scale, Spruce Project, SEI, Aug 2015
- Comparing Scaling Agile Frameworks, Matthew Heusser, CIO.com
- Scaling Agile Software Development, Disciplined Agility at Scale, By Scott W. Ambler and Mark Lines
- Strategies for Scaling Agile Software Development, IBMdeveloperWorks
- Scaling Agile Methods by Donald Reifer, Frank Maurer, and Hakan Erdogmus, IEEE, 2003
- Scaling Software Agility: Best Practices for Large Enterprises by Dean Leffingwell
- Five Success Factors for Scaling Agile by Robert Holler and Ian Culling
- Enabling Incremental Iterative Development at Scale by Neil Ernst, Stephany Bellomo, Robert Nord, Ipek Ozkaya of SEI
- Bring Agile to the Whole Organization, Jeff Gothelf, HBR
- How to Make the Whole Organization Agile, Steve Denning, Forbes
- Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum,
- Leading Agile
- Scaling Agile the Easy Way, Arlo Belshee
0 Comments