Ist agiles Systems Engineering möglich?

Kurze Antwort: auf jeden Fall! Abgesehen davon, dass es agiles Systems Engineering seit über 40 Jahren gibt (wenn auch nicht unter diesem Namen), so ist hier ein zweiter Punkt wichtig: Agilität und Systems Engineering sind zwei verschiedene Dinge, und daher gibt es kein entweder-oder.

Sich zwischen Systems Engineering und agilem Vorgehen zu entscheiden ist ähnlich, wie sich zwischen einer Autofahrt und einem Besuch im Museum zu entscheiden: Das eine ist ohne das andere möglich und beide können kombiniert werden.

Systems Engineering ist ein Ansatz, ein Ziel zu erreichen, nämlich ein komplexes technisches System zu entwickeln. Agilität beschreibt einen Weg um an ein Ziel zu kommen. Wenn man es so betrachtet, dann steht die Möglichkeit des agilen Systems Engineering außer Frage.

Standards und Vorgehensmodelle

Die Wirklichkeit ist leider nicht ganz so einfach: Denn die Felder, wo Systems Engineering zum Einsatz kommt, sind in der Regel stark reglementiert, sei es vom Gesetzgeber oder Auftraggeber. Autos, Flugzeuge und Züge müssen bestimmte Standards erfüllen, die sich oft in Vorgehensmodellen manifestieren.

Hier hängt es vom Detaillierungsgrad ab, wie agil entwickelt werden kann. Beispielsweise gibt die ISO 15288 lediglich einen Rahmen vor, der durchaus Freiräume für eine agile Umsetzung zulässt. Je spezifischer die Vorschriften werden, desto enger wird das Korsett. Das alte V-Modell (der Entwicklungsstandard, nicht das allgemeine Vorgehen) bspw. machte es schwer, agil zu arbeiten.

Eine wichtige Gruppe von Standards betreffen Sicherheit. Dabei ist die generische IEC 61508 dominierend, da von dieser viele andere abgeleitet werden.

Scrum und ISO 26262

Scrum ist ein recht weit verbreitetes agiles Vorgehen. Und die ISO 26262 ist die Ausprägung der IEC 61508 für Kraftfahrzeuge. Die Frage, ob diese miteinander vereinbart werden können, wurde gerade von Karsten Krennrich im HOOD Blog beantwortet. Sein Fazit: Es gibt zwar wenig Gemeinsamkeiten, aber das Potential ist da.

Ein Hauptansatz ist es, den Fokus von der Befolgung von Prozessen und Aktivitäten auf die inkrementelle Erstellung von Artefakten (Arbeitsergebnisse oder Inkremente) mit einer bestimmten Qualität zu richten. (Karsten Krennrich, HOOD GmbH)

Haben Sie schon mal agiles Systems Engineering betrieben? Wenn ja, dann würde ich mich freuen, wenn Sie Ihre Erfahrung in einem Kommentar teilen würden.

 

Dieser Artikel erschien zuerst bei se-trends.de.

3 Pingbacks/Trackbacks

  • Gast

    Ich habe agile Taktiken schon oft in großen Projekten eingesetzt – also gezielt, um kleinere Aufgaben besser bearbeiten zu können. Ob sich ein ganzes, sicherheitskritisches Projekt (wie eine Fahrzeugentwicklung) agil umsetzen lässt, wage ich aber zu bezweifeln.

  • Geoffrey A Shuebrook

    First, Apologies for my lack of mastery of the German language. I am limited to provide comment in English

    Second, Thank You Michael for your efforts in advancing the practice of Systems Engineering. Perhaps you should consider running for the Presidency of INCOSE, perhaps then I might re-join.

    „Scrum“ may provide agility, but I submit that it is not, in and of itself, Agile Development IAW the “Manifesto for Agile Software Development” & “Principles behind the Agile Manifesto”.

    I have read the „The Scrum Guide“ (http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf) numerous times and I suggest anyone reading this comment do the same. Careful reading of “The Scrum Guide” and the “Manifesto for Agile Software Development” & “Principles behind the Agile Manifesto” reveals the many harmonies and some discord (change). I would argue that one has a focus on managing the product’s technical development effort and the other on the technical efforts itself.

    Quoted from „The Scrum Guide“ –

    „Definition of Scrum

    Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

    Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.“

    „Scrum“ is much more about a process framework for and the quality of managing the technical development effort than it is about the quality of the technical effort. Though the Scrum framework does provide for enforcement of technical quality through „Transparency“, „Inspection“, and „Adaptation“. Scrum sets no explicit criteria for technical quality, but it does prescribe that there must be a „Definition of Done“ for each element of the „Product Backlog“, thereby enforcing technical quality via Scrum events. Everyone must read „The Scrum Guide“.

    My experiences in BIG defense oriented organizations is that most never read the book („The Scrum Guide“) and I’ve found this to be true in SMALL organizations as well.

    And „Yes“. I have participated in „Agile Systems Engineering“ but that was some 20 years ago and we didn’t know that our „SE Practice“ had the name „Agile Systems Engineering“.

    Best Regards,

    Geoff

    • Geoff,

      Thank you for your kind words. First, I agree that Scrum and Agility are not the same. However, I like the definition of Scrum from the Scrum Alliance: “Scrum is an Agile framework for completing complex projects”. Scrum is certainly striving to be agile,but by no means the only way to achieve it. Likewise, I can only agree to your distinction on “quality of managing the technical development” and “the quality of the technical effort”.

      In fact, you provided me with a great insight: It is a good explanation why Scrum works, even in the context of a constraining safety standard like ISO 26262. The analysis done by HOOD confirms that. Of course, that analysis has to be taken with a grainof salt, as it was the result of a workshop, not an actual project. It would be interesting to get an actual experience report. This would also be interesting for another reason: I have seen projects that claimed to be agile or claimed to use Scrum, but did in fact only use this as an excuse to skip writing documentation or to cut corners some other way.

      Last, I can only share your sentiment of having participated in agile Systems Engineering 20 years ago: I am really surprised that the hype has survived for so long: Not because it is bad, but because it is not new (as I wrote in http://se-trends.de/agile-systementwicklung-ca-1973/ ).

      – Michael

  • Pingback: Formal Mind - Why Paper Still Matters in the World of Models()

  • Pingback: Why Paper Still Matters in the World of Models – Formal Mind GmbH()

  • Pingback: Warum Fehlschläge wichtig sind - Systems Engineering Trends()