Scaling Agile for Government

Building a successful Agile model

Successfully building software through Agile relies on three elements. First, a clearly defined set of business problems and a vision of what’s needed to solve those problems are important. Second, because business leaders and technologists generally bring different perspectives and working styles to the task, steps should be taken to ensure their viewpoints are integrated. Third, the creation of the solution should be an evolving journey between the business side and the technology side who collaborate to constantly redefine the best available outcome as quickly as possible. As a result, while there are various “flavors” of Agile that employ various methods and implementation approaches, they all share certain characteristics, including:

• Delivering capability in short, “time-boxed” iterations
• Encouraging continuous learning and embracing the inevitable changes in requirements that result through the process
• Driving an active partnership between the government agency, relevant IT groups, and vendors to co-create the best possible outcomes within time and budget constraints

These Agile characteristics can challenge traditional government systems, particularly on larger projects. Some of the key challenges that typically need to be addressed in scaling Agile include:

1. Multiyear road maps with many sub-tasks
2. Governance
3. Cross-team dependencies/coordinating multiple work communities
4. End-to-end functionality

Below we discuss the four key challenges and strategies to address them:

Multiyear road maps with many sub-tasks

One of the most challenging aspects of Agile at scale may be the need for multiyear road maps in light of an uncertain, evolving future end state.

With the help of multiyear road maps, project leads can help teams remain on track to deliver business value, constantly refining the product’s next minimum viable product (MVP) release.  Implementations should inform long-term business and product road maps while maintaining basic Agile principles, including the ability to adjust the end vision as new information comes to light during the build. Building a strong roadmap requires an in-depth understanding of users’ needs, regulatory drivers, and business goals, all while incorporating known dependencies and constraints. It’s important to review and refine quarterly, considering new insights, end user pain points, and legislative mandates.

Governance

Large-scale Agile implementations involve multiple Agile teams from disparate functions, often in dispersed locations. These resources are often pulled together from various organizational entities, all of which could have a stake in their use. In scaled Agile, it is critical to coordinate these teams under some form of common governance and strong leadership via the governance framework is critical.

Multiple Agile coaches and product owners should regularly convene in a “scrum of scrums” to facilitate cross-community communication and provide fast decisions. The Agile community of leaders provides a forum for communicating across teams, reporting, and consolidating tracking. Organizations that embrace cross-functional collaboration and transparency into progress not only maintain confidence in the solution throughout delivery, but they also establish the ability to quickly identify, react to, and truly adopt change.

This provides a more integrated and up-to-date message framework that allows senior management and interested stakeholders to receive real-time updates about progress during and after attending in-progress product demonstrations of working system capabilities. The regular cadence of demonstrations, along with direct two-way executive and business stakeholder communication and velocity reports from user and technical story completion rates, becomes the primary metric for quantifying progress, and it helps to build confidence that the project is on track.

Cross-team dependencies/coordinating multiple work communities

Often, a team requires completed components from another team before proceeding further. The ordering of the sprints becomes important, but there should be a balance between flexibility and adherence to the overarching plan.

In Agile at scale, project leaders need to keep an eye on the big picture while the teams absorb themselves into sprints. The most common approach is to divide groups of teams into an “initiative” and multiple initiatives into a project. With different teams working on different features, someone has to ensure that the user interface—the overall “look and feel” of the various components—is eventually consistent. There is a particular risk here that user experience (UX) teams can get ahead of back-end services to the point that expectations held by the product owner are not achievable. Sometimes, addressing cross-team dependencies simply requires diligent communication and frequent validation through demos that exercise slices of functionality. Consistent connectivity has become increasingly critical in the hybrid work environment. Each Agile team typically holds a brief (usually 15–30 minutes) daily morning planning session to identify the work completed on stories and tasks, work planned for that day, and what blockers are impeding their progress. This information can then be fed up to a regular feature of scaled Agile where all of an initiative’s Agile coaches meet for a “scrum of scrums” to discuss progress, blockers, and needs.

End-to-end functionality

Traditional Agile relies on functional and unit testing within sprints as well as other quality control processes. In Agile at scale, an additional testing layer is recommended, which provides end-to-end product testing to identify issues between distinctive components built by Agile teams. The increasingly closely aligned practice of “DevOps” and micro-segmentation architecture are natural partners of Agile management and enable teams to increase velocity. Micro-segmentation significantly contributes to Agile velocity through increased automation and scalability opportunities, primarily by decoupling the key DevOps concerns of infrastructure and security, and also promoting location and application architecture independence. The goal is to write good code quickly and receive feedback often. Agile at scale is something of a balancing act that avoids overly prescriptive top-down standardization and allows rapid adoption of best practices, but without creating a free-for-all atmosphere. Agile at scale may require more guardrails than a smaller project; however, providing latitude for innovation within reasonable boundaries is important.

When multiple teams are building a large system, it is imperative that the approach accommodate end-of-sprint demonstrations that exercise real capability and functionality (albeit incomplete) from the beginning. This favors an approach where vertical (through the tech stack) slices of functionality are sequenced instead of building the system up in layers from the bottom. When teams are taking an idea and decomposing it, knowing where and how to start can be difficult. Mapping the idea through user flows and segmenting the flows into vertical slices of logical groupings allows teams to build across architectural layers while realizing value faster. Delivering in vertical slices also facilitates the ironing out of kinks related to build, promotion, provisioning, and configuration that are sometimes ignored and can lead to surprises at the end, which is the antithesis of Agile.

Written By: Zach Arbuckle, Subha Babu, Aaron Druck, Todd Engle, Kevin Savage, Angela Walker, Debbie Sills, and John O'Leary