• Home
  • Agile
  • Agile SE Part Five: Agility on Large, Complex Programs

Agile SE Part Five: Agility on Large, Complex Programs

Posted by Benjamin Schwartz on 4 March 2023

Table of Contents

Putting it all together

In this series we’ve introduced agile concepts, requirements, contracting, and digital engineering (DE) for physical systems. These things are all enablers to agility, they don’t make a program agile per se. The key for agility is how the program is planned and functions prioritized.

Agile program planning

A traditional waterfall program is planned using the Statement of Work (SOW), Work Breakdown Structure (WBS), and Integrated Master Schedule (IMS). This basically requires scheduling all of the work before the project starts, considering dependencies, key milestones, etc. Teams know what to work on because the schedule tells them what they’ll be working on when. At least in theory.

Just because you make a good plan, doesn’t mean that’s what’s gonna happen.

Taylor Swift

As noted in part three of this series, this approach tends to result in cost and schedule overruns, as well as systems that don’t fully meet the mission need. It’s not that planning is bad, far from it! It’s just that planning a multi-year, multi-billion dollar program down to the day and dollar and expecting to meet that plan is foolish and hubristic. Especially because the people making the plan can’t possibly understand all of the details, intricacies, and risks. They account for these unknowns with management reserve and slack in the schedule, but often that’s not enough.

Agile programs don’t even try to plan a set scope, schedule, and budget. Instead, planning is conducted recursively and hierarchically based on time horizons. Executive leaders set long-term strategic plans which are broken down to roadmaps, PI plans, and detailed sprint plans. The number of levels depends on the size of the effort; this works for enormous enterprise-level portfolios down to small scrum teams. Check out the Scaled Agile Roadmap article for more details on how roadmaps are developed across multiple time horizons.

Traditional planning is built around meeting the requirements. In an Agile program without fully-defined requirements, how will the developers know what they’re supposed to be building and if they’re building the right thing? Enter:

The Product Owner(s)

The role of the Product Owner is to bring the vision to the development teams and ensure that the work being done provides customer value. This includes providing strategic guidance, defining the work to be done, prioritizing the team backlog, and validating product demos. Depending on the way the program is organized, these could be customer representatives or customer proxies.

Sometimes a team lead serves as the product owner or the team doesn’t have a formal product owner relationship. Both of these are huge mistakes! A team lead should focus on ensuring their team has everything necessary to get the job done, and done right. The product owner brings the understanding of customer value and makes sure the right thing is done. Without a product owner, the team lacks the connection to and coordination with the larger objectives of the program.

On a large program, there are likely multiple product owners organized into a Product Owner’s Office, similar to (or perhaps part of) a Chief Engineer’s Office. Together, they decompose the vision for the program to the individual scrum team levels to ensure the development is all working towards the intended goal.

The product owner role is essential for agile development; in the place of traditional up-front requirement development, this role champions the user and mission needs. As mentioned previously, Agile doesn’t do away with requirements entirely, it just shifts their authoring closer to where and when the work happens. Agile requirements typically take the form of “user stories”, a description of the functionality the user needs and why. This helps the development team understand and meet the context of the need. Tons of bits have been written on user stories so I won’t worry about the specifics here. For now, let’s take a look at how those stories get written and met.

Cross-functional development teams

Agile teams are cross-functional. This is key because it means the full scope of development happens within the team, rather than depending on messy cross-team collaboration and handoffs. With the guidance of the product owner, the team understands the user needs and the full mission context. They participate in the full scope of research, design, build, test, and deploy. The rationale and mission context for a requirement won’t get lost because the development team is involved in the process, so they understand the drivers behind the features they’ll be implementing and demonstrate how the solution meets the need.

The team is also involved in the user evaluation of the solution, so that if something is not quite right they can see and explore the impact directly, rather than rely on reports and second-hand information. You can see how that works for a specific product, but what about for systems engineers where the results are less tangible?

The Agile Systems Engineer

I believe this is one topic that is under-developed in existing Agile systems approaches. The role of the systems engineer isn’t any less important in Agile. In fact, it may be even more important. Systems engineering is essential to bring together all of the work the development teams are doing into an integrated whole. That involves operations concept development, trade studies, architecture development, modeling, interface management, integration, test, and so much more.

The model that I find most effective is a central systems engineering organization with individuals deployed to support cross-functional development teams. In fact, I think this is a good model for all teams on the project. The central functional organization provides deep reachback support, surge capability, standardized approaches, training and development, and quality control while individuals from various functional teams form the cross-functional development teams.1

So, what does Agile Systems Engineering look like? First, it’s architectural and systems runway. Systems engineers have to understand the upcoming features on the roadmap and anticipate the implications for systems engineering. Stakeholder needs have to be further decomposed, trades have to be conducted and decisions made, system components have to be modeled, interfaces have to be defined, etc. The systems engineer is also responsible for ensuring that all compliance requirements and lifecycle considerations are identified and flowed down appropriately.

Then, it’s definition and decomposition of verification and validation (V&V) criteria for each element being developed. Agile software development relies heavily on acceptance testing; defining the tests up-front ensures the developer knows exactly what their deliverable needs to do. This approach isn’t as standardized in other disciplines, but it should be! Defining acceptance criteria, based on the V&V approach as much as possible, ensures that each piece of the development is contributing to the overall success of the system. Overall V&V should be based on stakeholder needs and V&V for subsystems, components, etc. should flow from there.

Another aspect of the systems engineer’s role is documentation of interfaces, architecture, decisions, etc. In a DE environment, this means maintaining the model for accuracy and detail. Systems engineering typically also leads and supports technical reviews and other processes to ensure the overall quality and suitability of the system. Finally, systems engineering is responsible for integration, verification, and test (IV&T) processes.

In short, the systems engineering effort on an Agile project implements the SE Vee iteratively to ensure the success of the integrated system.

Conclusion

The purpose of this series was to thoughtfully discuss Agile systems engineering approaches for large, complex systems. My goal was to cut through the buzzwords and naysayers to get to practical, value-added methods. We discussed “Cargo Cult Agile”, defining stakeholder needs and value, contracting for agile development, digital transformation, and implementation concepts.

This series wasn’t meant as a “how-to”, there are plenty of resources and coaches out there. Rather, it was to describe how these approaches—which clearly were built for software—can be used successfully across all types of system development. I’m interested in your thoughts, feedback, and personal experiences. How can we improve the practice of systems engineering in an agile, digital engineering context? Share in the comments below.

Footnotes:

  1. The alternative is a bunch of functional teams blindly handing things off to each other, which I previously wrote about.