What Are Agile Methods and Why Should I Care?

Chapter 2 introduces agile methods and their application to systems engineering. Although agile methods arose in IT software development, they have begun to be applied——with good success—in other engineering disciplines as well. In order to understand how best to apply them to systems engineering, a good understanding of the basic agile concepts, methods, and approaches is necessary. This chapter outlines the Agile Manifesto and restates it to be more relevant to systems engineering, including identifying the important measure of success—verified engineering data. The benefits of agile approaches are explained with an emphasis on the difference it can make to systems engineers. Key methodological approaches—incremental engineering, dynamic planning, continuous verification (of engineering data), continuous integration, and so on—are all explained in the context of systems engineering.

The chapter highlights the key agile best practices for improving quality and efficiency in systems engineering and then outlines the Harmony Agile Model-Based Systems Engineering (Harmony aMBSE) process that integrates those best practices into a coherent approach.

Keywords

Agile; harmony agile MBSE process; agile best practices; agile systems engineering

Chapter Outline

Agile methods are largely a response to increasing regimentation of software development and work that was only tangentially related to the development of the software itself. It is also a reaction to the fact that despite the burden of this additional work, the quality of the software is low and the software far too often doesn’t meet the needs of its intended users. Although agile was originally conceived for small software projects, we will see that there is much to recommend it for other endeavors, including (and of great interest here) systems engineering.

From an overview perspective, agile methods are really about optimizing development along two dimensions—product quality and engineering efficiency. Many people think it’s about what you DON’T do—you DON’T plan, document, fill out paper work, design, analyze, or create requirements. In actuality, agile is more about what you DO and the order in which you do them. Agile methods are meant to be adaptive and responsive to different situations and changing needs using objective evidence to guide how work it done.

Put another way, it isn’t so much that you do different things when you do agile methods as much as the order and sequence of those things is changed. This facilitates early feedback as to the correctness and adequacy of the work and work products you create. For example, traditional methods1 do a “breadth-first” approach to creating work products and defer the verification of those work products at least until they are complete, and often much later. Agile, on the other hand, incrementally verifies the work products as they are being created. That provides more immediate feedback as to the correctness of the work product and how well your process is helping you achieve your engineering goals.

I liken the agile approach to dental hygiene. Imagine that you want to ensure your “tooth quality” by applying the “tooth brushing quality step.” Because you view this as important, at the end of every year, on December 31, you do a good and thorough job of brushing your teeth and verifying their quality, and then going to a dentist for tooth quality problem remediation. Much to your dismay, your tooth quality is pretty low and requires extraordinary measures (and no small amount of discomfort) to bring the quality up. That is how the traditional approach works with deferred verification.

Imagine instead performing this quality improvement and assessment step immediately after using your teeth (i.e., after meals). Through constant application of quality methods, the quality of your teeth remains high throughout the year. This is a more hygienic approach and avoids big quality problems more than identifying them late for defect removal. In either case, you’re performing quality assurance activities to both improve and verify quality but what is different is when those activities are performed. Agile methods perform quality assurance activities throughout the development of important work products rather than after they are completed. That is, when these activities are performed, we optimize defect avoidance rather than defect identification.

Oh, and Agilistas DO plan, document, fill out paper work, design, analyze, and create requirements. We’ll talk about how those activities can be done in an agile systems engineering environment in some detail in this book.

2.1 The Agile Manifesto

A good place to start to understand agile methods is with the agile manifesto.2 The manifesto is a public declaration of intent by the Agile Alliance, consisting of 17 signatories including Kent Beck, Martin Fowler, Ron Jeffries, Robert Martin, and others. Originally drafted in 2001, this manifesto is summed up in four key statements:

A thing to note about the manifesto is that it states an emphasis, not an exclusion. We emphasize working software over documentation, but that doesn’t mean that we don’t write documentation. We emphasize responsiveness to change over dogmatically following a plan, but that doesn’t mean that we don’t plan. The point is to pay more attention to the things that really matter. Paying attention to meeting the customer’s needs and creating correct software is more important than following the plan and writing the documentation, but it doesn’t mean that these other aspects don’t get any attention at all.

To support the statements of the manifesto, the Agile Alliance give a set of 12 principles. I’ll state them here to set the context of the following discussion: