Agile systems engineering is impossible. Or is it?

Anyone who regularly reads SE-Trends knows that I agile systems engineering feasible and sensible. But in practice, agile SE is not yet very widespread, and I keep quoting the same case studies, such as SpaceX and WikiSpeed. This raises the question: Are these the exceptions that prove the rule, or trendsetters?

To get a better understanding, in this article I present the results of Ronald Carson (Boing)who does not believe agile SE is possible. This paper was written in 2014 (according to Wiley). However, the paper itself states "2011-2013." This as context to classify the state of agile SE when the paper was written.

I would be very happy to have a pro and con discussion in the comments section.

Agility for software only

Carson's paper was written seven years ago (2011). At that time, agile methods were established in software development and the first attempts to use them in systems engineering were underway.

To anticipate this: A central thesis of Carson is that agility only in software development works. He has recognized an important difference between hardware and software: Hardware is traditionally built and integrated iteratively. In software development, these activities take place continuously. Building happens in seconds or minutes and is usually carried out many times a day.

Agility has its place - but what is it?

Carson confirms that agile development can indeed be effective. Accordingly, one of the main findings of the paper is to classify when which approach is recommended.

He quotes the the following table from Wikipedia (slightly modified for the paper):

Suitability Factors	Agile	Plan-driven (Traditional SE)	Formal methods
Criticality	Low criticality	High criticality	Extreme criticality
Personnel	Senior developers	Junior developers	Senior developers
Dynamism	Requirements change often	Requirements do not change often	Limited requirements, limited features see
Size	Small number of developers	Large number of developers	Requirements that can be modeled
Culture	Culture that thrives on chaos (In Wikipedia: "responds to change")	Culture that demands order	Extreme quality

Carlson develops eight further criteria:

Gated development

Carson sees the concept of "gated development" as an important aspect that he misses in agile development. He freely admits that this serial approach can lead to the implementation of outdated requirements. Carson accepts this as a necessary evil, as he sees the practiced alternatives as either (a) no requirements or (b) spongy requirements. Both are rightly classified as worse alternatives. At this point, it is a pity that Carson does not examine any further alternatives, as these do of course exist!

Lack of maintenance of requirements

Another point of criticism is the lack of maintenance of requirements in the agile approach. Here too, he sees gating as an approach to prevent this. In classic SE, Carson sees prototyping, which is then properly implemented and documented at the next gate. Carson argues that agile development lacks the mechanisms that ensure a consistent system description. Carson rightly criticizes a number of practices that lead to problems, such as a lack of verification due to a lack of objective success criteria. However, he does not convincingly argue why these problems occur more frequently in agile development or are absent in traditional development.

Further points of criticism

Carson criticizes that "user stories" are not real requirements, that there is a lack of clarity. But here, too, Carson admits that there are techniques that can ensure precision, such as test-driven development.

He also sees a conflict of interest in the fact that designers and coders are the same person in agile development. This statement is somewhat surprising: although this is often practiced, it is not specified anywhere.

Finally, he criticizes the lack of a "damper" in agile development, which ensures that a clear direction is taken and maintained in development. He sees this as a risk factor for fixed-price projects in particular.

My opinion: Agile systems engineering is the future

I had already anticipated this: I don't share Carson's opinion and even consider agile SE to be forward-looking. But how do I explain Carson's objections? I think Carson's objections are valid - but the objections are general and have little to do with agility. The problems mentioned are real, but they also occur with other development methods. And they can also be easily prevented with agile approaches.

The problems Carson mentions are real, but have little to do with agility

The classic example is documentation. In the past, the cliché was that many developers used "agile" as an excuse not to document at all. Of course, this is not true: the Agile Manifesto says: "Working software more than comprehensive documentation." It does not say that documentation can be completely omitted.

I would even argue that agile working often reduces the risk of the problems mentioned: This is because agile working enables us to get early feedback on the current state of development and to intervene at an early stage when the first warning signs appear. Of course, this requires competent management, but this also has nothing to do with agility.

Conclusion: The paper would have been better called "Traps in system development". The problem areas exist. However, we have now learned how to deal with these problem areas: Both in traditional development and in agile systems engineering.

Photo by Vincent van Zalinge on Unsplash