„Entwickeln Sie Ihre technischen Systeme auch schon agil?“ – In den vergangenen 2-3 Jahren beobachten wir als SOPHISTen bei unseren Kunden einen Trend, dass Züge der agilen Softwareentwicklung Einzug in die Entwicklung von technischen Systemen (Systems Engineering) halten. Die Werte und Prinzipien des Manifests für agile Softwareentwicklung sind, sofern man den Begriff „Software“ durch „System“ ersetzt, grundsätzlich unabhängig von der Art des zu entwickelnden Systems. Aber was macht Systems Engineering agil? Oder anders formuliert: Was bedeutet agiles Systems Engineering? Da die Literatur bisher keine Definition oder eine Bedeutung liefert, haben wir als SOPHIST uns eine eigene Interpretation überlegt:
„Agiles Systems Engineering ist die bedingungslose Ausrichtung aller Entwicklungstätigkeiten in allen an der Entwicklung beteiligten Gewerken über den gesamten Lebenszyklus des zu entwickelnden Systems an den dynamischen Bedürfnissen des Marktes.“
In dieser „Definition“ sind sowohl Aspekte aus dem Manifest für agile Softwareentwicklung [1], Grundsätze des Systems Engineering nach INCOSE (vgl. [2]) sowie Gedanken der Systemtheorie nach Niklas Luhmann [3] enthalten und umfasst 3 wesentliche Aussagen:
- Tue nichts, was nicht unmittelbar zur Entwicklung des Systems beiträgt.
- Richte diese Tätigkeiten an der Dynamik des Marktes aus, in dem das System platziert werden soll.
- Betrachte alle an der Entwicklung des Systems beteiligten Gewerke über den gesamten Lebenszyklus des Systems.
Der erste Punkt resultiert aus einer Beobachtung unserer Kundenprojekte, in denen häufig Tätigkeiten durchgeführt werden, die lediglich einen Selbstzweck erfüllen und die nur durchgeführt werden, weil ein Framework, eine Richtlinie oder ein Prozessvorgabe diese einfordern, ohne ein konkret vorliegendes Problem in der Entwicklung zu lösen. Ein Beispiel dafür ist die Bewertung von Reifegraden von Entwicklungsprozessen anhand vorgegebener Referenzmodelle wie z.B. Automotive SPICE. Eine solche Bewertung leistet keinen direkten Beitrag zu der erfolgreichen Entwicklung des Systems und bindet meist sehr viele Ressourcen von den an der Systementwicklung beteiligten Personen. Die Aufmerksamkeit richtet sich nach innen in das Unternehmen, der Blick für den eigentlichen Zweck des Systems und für die potenziellen Kunden und Wettbewerber rückt in den Hintergrund. Die Frage, welche Tätigkeiten des Referenzmodells tatsächlich notwendig sind, wird häufig vernachlässigt.
Wird der Markt fokussiert, kommt der zweite Punkt zum Tragen. Ansätze der agilen Entwicklung sind speziell für eine hohe Dynamik des Marktes (z.B. in Form von einer hohen Frequenz an geänderten Anforderungen) ausgelegt. Fällt diese Dynamik eher gering aus, müssen keine speziellen Maßnahmen oder Strukturen in der Systementwicklung definiert werden. Diese Maßnahmen würden wiederum dem Selbstzweck dienen und kein echtes Problem des Marktes adressieren. Ein Beispiel sind kurze Releasezyklen, um möglichst schnell auf geänderten Anforderungen des Marktes reagieren zu können. In einem trägen Markt mit nur wenigen Wettbewerbern treten zwar auch geänderte Anforderungen auf, allerdings ist die Änderungsfrequenz deutlich geringer als in einem Markt mit vielen Wettbewerbern.
Der dritte Punkt unterscheidet die System- von der reinen Softwareentwicklung. Im Systems Engineering sind typischerweise viele verschiedene Gewerke wie Elektronik, Software, Mechanik, Hydraulik, etc. an der Systementwicklung beteiligt, die alle einen Beitrag für das Gesamtsystem leisten. Essenziell für eine erfolgreiche Systementwicklung ist die systemische, ganzheitliche Betrachtung all dieser Gewerke. Denn nur wenn deren Zusammenspiel definiert und eine Integration möglich ist, wird das System alle gestellten Anforderungen des Marktes erfüllen können. Zudem erhält die Betrachtung des gesamten Lebenszyklus des technischen Systems mehr Bedeutung, da beispielsweise die Hardwarebestandteile gewisse Einschränkungen z.B. für die Wartung, Updatefähigkeit und Entsorgung mit sich bringen. Diese Einschränkungen und deren Auswirkungen müssen wiederum in den anderen Gewerken berücksichtigt und deren Tätigkeiten bei Bedarf daran ausgerichtet werden.
Zugegeben, die zu Beginn dieses Artikels formulierte Frage impliziert, dass moderne Systementwicklung nur agil funktionieren kann – „Wer heutzutage erfolgreiche Systementwicklung betreiben möchte, muss agil arbeiten!“. Viel wichtiger ist die Frage, ob der Kontext ihres Unternehmens überhaupt eine agile Systementwicklung erfordert. Nur wenn Sie die konkreten Probleme des Marktes identifiziert haben, können Sie passende Lösungen z.B. aus dem Methodenkoffer der agilen Softwareentwicklung auswählen und in Ihrer Umgebung zweckmäßig einsetzen.
Sie fragen sich, welche Probleme wir typischerweise in unseren Kundenprojekten antreffen und welche Lösungsansätze uns geholfen haben? Dann besuchen Sie einfach unser neues Training „Agiles Systems Engineering“, in dem Sie typische Probleme und mögliche Lösungsansätze aus dem Systems Engineering erfahren und mit unseren Experten diskutieren können.
Literatur:
[1] Beck, Kent M.; Beedle, Mike; Bennekum, Arie van; Cockburn, Alistair; Cunningham, Ward; Fowler, Martin; Grenning, James; Highsmith, Jim; Hunt, Andy; Jeffries, Ron; Kern, Jon; Marick, Brian; Martin, R. C.; Mellor, Steve J.; Schwaber, Ken; Sutherland, Jeff; Thomas, Dave. „Manifesto for Agile Software Development“. Verfügbar unter: agilemanifesto.org (aufgerufen am 16.08.2022).
[2] Walden, David D.; Roedler, Garry J.; Forsberg, Kevin; Hamelin, R. Douglas; Shortell, Thomas M. (2015): Systems engineering handbook: A guide for system life cycle processes and activities. 4th edition.
[3] Luhmann, Niklas (1984): Soziale Systeme. Grundriß einer allgemeinen Theorie.
Weitere Beiträge aus dieser Blogserie finden Sie hier: