Engineering-Bereiche stehen vor der kontinuierlichen Herausforderung, technologisch komplexe Entwicklungsvorhaben mit Geschwindigkeit, Flexibilität, Reaktionsfähigkeit und Kosteneffizienz zu beherrschen.
Parallel ist ein deutlicher Wandel zu folgenden Punkten zu erkennen:
Wir von newboxes stellen fest, dass die kombinierte Anwendung des bewährten Systems Engineering, einer modularen Systemarchitektur und agiler Frameworks wie SAFe® viele der oben genannten Herausforderungen löst.
Das Systems Engineering (SE) gibt die Prozesse sowie die Struktur vor, nach denen die interdisziplinäre und ganzheitliche Entwicklung erfolgt. Das Product Line Engineering definiert die „Architektur“ des Produktes, um ein hohes Maß an Wiederverwendbarkeit zu ermöglichen. Agile Prinzipien werden genutzt, um die Zusammenarbeit auf Team- sowie Organisationsebene zu gestalten.
Lesen Sie mehr zu unserem „Empowered Agile Systems Engineering“ Ansatz!
Das International Council on Systems Engineering (INCOSE) definiert SE wie folgt:
"Systems Engineering ist ein interdisziplinärer Ansatz und soll die Entwicklung von Systemen methodisch ermöglichen. SE fokussiert ein ganzheitliches und zusammenwirkendes Verständnis der Stakeholder Anforderungen, der Entdeckung von Lösungsmöglichkeiten und der Dokumentation von Anforderungen sowie das Synthetisieren, Verifizieren, Validieren und die Entwicklung von Lösungen. Das gesamte Problem wird währenddessen von der Konzeptentwicklung bis zur Systementwicklung betrachtet. Das Systems Engineering stellt hierfür geeignete Methoden, Prozesse und Best Practices bereit."
Im Vordergrund des SE steht der Systemgedanke unter Berücksichtigung des Gesamtproblems. Es bildet einen strukturierten Entwicklungsprozess vom Konzept- bis in die Betriebsphase und integriert dabei alle Disziplinen, deren Hierarchisierung und Zusammenspiel in der nachfolgenden Grafik veranschaulicht wird.
Um ein ganzheitliches und zusammenwirkendes Verständnis der Stakeholder sicherzustellen, wird häufig das V-Modell als Grundlage gewählt. Dies beinhaltet die technischen Prozesse vom Anforderungsmanagement bis hin zur Validierung. Flankiert werden die technischen Prozesse von Projekt-, Vertrags- und organisatorischen Unterstützungsprozessen.
Agility is an attitude and management skill set to betterlead an organisation for ever more complex and dynamic market conditions.
Unter dem Begriff „Agiles Arbeiten“ versteht man die Anwendung von agilen Methoden und Werkzeugen. Es geht dabei aber nicht nur um den Einsatz, sondern vielmehr um die grundlegende Fähigkeit, auf ein zunehmendes unsicheres und unvorhersehbares Umfeld reagieren zu können. Agile Arbeit gelingt also nur durch die Etablierung des agilen Mindsets.
Agile Werkzeuge auf Teamebene, wie z.B. Kanban, Daily oder die Retrospektive lassen sich unproblematisch in den Alltag integrieren. Entwicklungsteams können mit diesen Werkzeugen leicht agiles Arbeiten kennenlernen und erste Erfahrungen in der Arbeit mit agilen Werten und Prinzipien sammeln. Sie führen in der Regel zu schnellen Erfolgen und zu schrittweisen Verhaltensänderungen.
Was auf Teamebene bei den meisten Unternehmen gut funktioniert, sieht auf Unternehmensebene ganz anders aus. Um auch diese Herausforderung zu meistern, wurden Methoden wie das Scaled Agile Framework entwickelt.
Das Scaled Agile Framework (SAFe®) beschreibt die Implementierung von agilen Praktiken im gesamten Unternehmen. Es basiert auf Prinzipien, die darauf abzielen, das gesamte Unternehmen anzuregen dezentralen Entscheidungen auf Basis der übergeordneten Strategie zu treffen.
Bei SAFe® werden mehrere agile Teams, die ein Inkrement in kurzer Zeit selbstständig erarbeiten, in sogenannten Agile Release Trains (ART) zusammengefasst.
Auf der ART-Ebene werden Features vom Produkt-Manager verwaltet. Features sind größere Anforderungen, die sich in einem Zyklus von 2-3 Monaten (dem Product Increment) umsetzen lassen. Dabei handelt der Agile Release Train eigenverantwortlich und ist selbstorganisiert. Ein dezentraler Entscheidungsprozess, wie in den Prinzipien beschrieben, verhindert Verzögerungen durch hierarchische Genehmigungen.
Auf der Teamebene werden kleinere Anforderungen (Stories) betrachtet und in einem Zyklus von 1-4 Wochen, in Form eines Teilinkrements umgesetzt (klassisches SCRUM). Die Product Owner sind dabei die Hauptansprechpartner für die agilen Teams und bilden somit das Bindeglied zwischen Product Increment (PI) und den dazwischenliegenden Sprints der agilen Teams.
Unser Ansatz des „Empowered Agile Systems Engineering“ ist die Verbindung beider Welten. Während das Systems Engineering Prozesse und Strukturen zur Entwicklung von komplexen Systemen liefert, trägt das agile Framework SAFe® die Grundlage für die organisatorische Zusammenarbeit bei.
Das Empowered Agile SE zeichnet sich durch eine iterative Vorgehensweise aus, die insbesondere auf Technologien wie digitale Mockups, 3D Printing o.Ä. zurückgreift, um frühzeitig eine Verifikation und Validierung zu ermöglichen.
Die Rollen aus aus SAFe® und Systems Engineering müssen bei der Implementierung zusammengeführt werden. So kann z.B. die Rolle des Release Train Engineer aus dem SAFe® mit der Rolle System Architekten aus dem Systems Engineering vereint werden. Hier greift der Vorteil, dass die Rollen beider Modelle auf den verschiedenen Systemebenen schon in ihrer Ausrichtung nahezu identisch sind.
Für die Implementierung des Empowered Agile SE wird das Produkt - auch Solution genannt - nach SE Methoden in mehrere (n) übergeordnete Systeme und mehrere (m) untergeordnete Subsysteme gegliedert.
Auf der Solution- und Systemebene überwiegen vor allem die Prozesse und Methoden des Systems Engineering, während auf der Subsystemebene die agilen Methoden und Werkzeuge zum Einsatz kommen.
In jeder Ebene der skalierten Aufbauorganisation sind verschiedene Sichten beziehungsweise Detaillierungslevel des identischen System Backlogs (Liste anstehender Systemspezifikation) wie auch die jeweiligen Rollen und das umfassende Arbeitsmodell der Skalierung definiert.
Die Systemebene arbeitet in Drei bis Vier-Monats-Zyklen. Die Subsystem-Inkremente werden in Sprints von zwei bis vier Wochen umgesetzt. Der gesamte Entwicklungsrhythmus orientiert sich an diesen Vorgaben. Durch die parallelisierte und wiederkehrende Routine wird die kontinuierliche Freigabe von Subsystem-Inkrementen und darauffolgenden Systemiterationen als Minimal Viable Products erzielt.
Je nach Domäne nutzen die Teams auf unterster Ebene zur Bearbeitung ihrer Aufgaben aus dem Subsystem- oder Funktionsbacklog die verschiedenen Arbeitsmodi des Empowered Agile SE.
Ihr Fortschritt wird in einem Zyklus von drei bis vier Monaten mit der Programm- oder Systemebene synchronisiert und bewertet. Auch wird in diesem Zuge die Inkrementplanung der darauffolgenden Monate durchgeführt.
Um den vollen Mehrwert des Empowered Agile SE auszuschöpfen, bedarf es neben des agilen Arbeitsmodells auch einer entsprechenden Systemarchitektur, die sich agil verhält. Sie muss so gestaltet sein, dass auf Basis von geänderten Anforderungen und Rahmenbedingungen flexibel und wirksam Anpassungen in den Gestaltungen von Systemelementen und Funktionen vorgenommen werden können.
Was sind hierfür die entscheidenden Punkte?
Empowered Agile SE bietet ein hohes Potential, Entwicklungsaktivitäten noch wirksamer zu gestalten. Man sollte aber nicht versuchen, agile Praktiken wie SCRUM in eine Organisation zu drücken. Die notwendigen Veränderungen – wie oben beschrieben – können eine Organisation schnell sehr stark belasten.
Besser ist es, agile SE-Konzepte zu nutzen, um erkannte SE-Probleme zu lösen – also ein punktueller, zielgerichteter Einsatz. In bester Systems-Engineering-Manier gilt auch hier, dass zuerst die Anforderungen analysiert werden sollten, bevor eine Lösung gewählt wird. Das klare Problemverständnis erlaubt dann eine inkrementelle Umsetzung, unter Berücksichtigung der Firmenkultur, des Geschäftsumfeldes und des Entwicklungsprozesses. Unser Beratungsansatz zur Implementierung umfasst 4 Schritte: