Can Systems Engineering be Agile?

In response to my LinkedIn post regarding the release of my latest book Agile Model-Based Systems Engineering Cookbook, some respondents raised the question “Can systems engineering really be agile?” My off-the-cuff response of “well, duh” could use additional clarification. What do we even mean by the term agile in this context? What are the key practices that can make systems engineering agile? What is the relation between agility and model-based systems engineering (MBSE)? What benefits can be gained through the use of agile practices for systems engineering?

What’s the difference between systems engineering and software development?

The most fundamental different between systems engineering and software development is outcome. The outcome of software development is implementation; compiled code that runs on a computer in its operational environment. However, the outcome of systems engineering is specification; the definition of requirements, architectures, and hybrid designs with optimality trade-off decisions that cross engineering discipline boundaries. Only after such specifications are complete can the software development begin for systems.

There are other differences as well. Software is essentially infinitely malleable and may be refactored easily (for some value of the term “easily” at least). Systems in general, are not so flexible. They are constrained by physics and are often comprised of the contributions of many different engineering disciplines, of which software is only one. Refactoring the electronics means a recall. Refactoring the mechanics is likely to require a retooling of the manufacturing plant. This means that we invalidate the underlying agile software assumption of easy refactorability for systems specifications.

What do we mean by agile in the systems engineering context?

Almost all the literature on agile methods focuses on what it means for development of small software projects by small co-located teams. Sure, there is literature on scaling to bigger software projects, such as Disciplined Agile Delivery (https://disciplinedagileconsortium.org/Resources/Documents/BeyondScrum.pdf) and even some vague notions of how to apply it to things that aren’t strictly software in the Scaled Agile Framework (https://www.scaledagileframework.com/), but they are, let us say, “unsatisfying.” This doesn’t even address whether agile can be successfully applied to the development of safety critical systems – but that is fodder for a different discussion (spoiler: it can, but you must extend the methods to demonstrate meeting the objectives of the relevant safety standards).

To my mind, the core concepts of agile principles (https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/) of early and continuously delivering value to the customer, being responsive to change, incremental development, continuous testing, continuous integration, and customer involvement are just as applicable to systems as they are to software, even if how you apply those principles must differ.

However, the fact remains, as mentioned above, that systems engineering is not a kind of software development. If anything, the opposite is true. Systems, in general, are not infinitely malleable like software. They must be manufactured, unlike software. They are subject to the constraints of physics. They often require a broad set of engineering skills in a number of different engineering disciplines. In many ways, software development is merely a highly constraint subset of systems engineering.

To be clear, when I talk about agile systems engineering, I mean developing systems

· Incrementally, with increasing maturity and completeness over time

· Using continuous verification and integration

· With strong customer involvement

One of the key concepts in agile software development is that even though the software is developed incrementally, the developers are never more than minutes away from demonstrating that what they have so far is correct. This is achieved with practices such as test driven development and continuous integration.

To implement such an idea in systems engineering, models are absolutely critical; document-based approaches can only be imprecisely verified through inspection and review and cannot be formally validated or tested. However, properly constructed models can be.

Just using models isn’t enough, any more than just writing code in a high-level programming language isn’t enough. The models must be syntactically well-formed, semantically correct and solve the right problem. In that, software and systems are the same.

There’s a Law of Douglass that states “All good models are falsifiable”. This means that good models make assertions of truth and if these assertions are wrong, there is a means by which this can be easily demonstrated. We do this by creating computable models. Computable models can not only be inspected and reviewed; they can also be tested and, in some cases, formally verified with mathematics. Such models fit well into an agile lifecycle because they can be incrementally developed, continuously verified as they mature and broaden their scope, and the results of the computation can be used validate that they meet the stakeholder's need. Incrementally and continuously.

What are some key practices of agile systems engineering?

There are some agile software practices that can be used almost as is, such as

· Managing your backlog

· Incremental development

· Using metrics to guide project work

· Risk management

· Agile planning, such as

o Product Roadmap

o Release Planning

o Iteration Planning

· Effort estimation

· Work item prioritization

These topics take up the bulk of Chapter 1 of the Cookbook. But in addition, other practices must be extended or modified to be applied to systems engineer. Some of these include

· Functional analysis

· Trade studies

· Safety analysis

· Security analysis

· Test-Driven Modeling

· Cross-discipline architectural definition

· Physical interface definition

· Handing off to downstream engineering (including software)

These practices can be done in an agile way; in fact, they form the basis for most of the rest of the Cookbook.

What are the benefits of agile practices to systems engineering?

First and foremost, the primary benefit of agile methods to systems engineering is quality improvement. Another Law of Douglass says that “The best way not to have defects in your system is to not put defects in your system. “ Through the application of agile practices of modeling, continuous execution, continuous integration, and continuous customer involvement, we can proceed with a much higher assurance that we are creating the right system to meet the needs in the right way. Big Design Up Front and Big Bang integration at the end cause all kinds of problems that can largely be avoided through the judicious use of agile methods, ensuring that your systems engineering specifications are correct right now, even if they are incomplete.

Another benefit is the reduction of rework. Big Design Up Front means that an untested architecture is used as the scaffolding for design engineering. If later work finds that scaffolding lacking, then significant rework is required because of the baked-in dependencies. Incremental delivery removes most of this problem because the architecture is continuously being exercised to uncover defects and problems leading to their early discovery and repair.

Lastly, the fact that we deliver executable specifications means that we can exercise them early in either simulated or actual customer environments. Agile methods reduce the ”air gap” between requirements as-stated and functionality as-needed through early demonstration of validity.

Can systems engineering really be agile? Well, duh!