Ist agile Produktentwicklung und die Anwendung von Engineering-Praktiken ein Widerspruch, lassen sich diese vereinbaren oder ergänzen sich diese sogar? In diesem Artikel wollen wir dieser Frage nachgehen.
Engineering ohne Agilität
Im letzten Jahrhundert wurden viele Engineering-Praktiken erdacht, viele davon um komplexe Systeme und Abhängigkeiten innerhalb dieser System handhabbar zu machen, Wiederverwendung zu ermöglichen, komplexe Technologie zu kapseln und Machbarkeiten schnell und mit möglichst wenig Aufwand zu klären.
Dabei wurden hauptsächlich tayloristische Prinzipien eingesetzt (Trennung von Arbeit und Entscheidung), sowie durch ein falsch verstandenes Lean, rein auf Effizienz optimierte Vorgehen, bei denen jeder Arbeitsschritt nur einmal ausgeführt wird.
Dadurch entsteht im schlechtesten Fall ein wasserfallartiges Vorgehen, d.h. die rein plangetriebene Umsetzung von früh ermittelten Anforderungen, früh getroffenen Design-Entscheidungen, das Festhalten an Plänen und ein Änderungswesen, dass sich darauf konzentriert, wieder „im Plan zu sein“.
Günstigenfalls entsteht ein nicht ganz so strikter Plan, der an Meilensteinen durch Change-Management geändert werden kann, meist aber durch (zu) frühe konzeptionelle Entscheidungen nur suboptimale, oder immer wieder ähnliche Produkte hervorbringt.
Agilität ohne Engineering
Bei der Einführung von Agilität wird den Teams häufig suggeriert, dass Architektur und Design-Entscheidungen nun komplett im Team, d.h. von allen gemeinsam, getroffen werden. Das von agilen Protagonisten gerne geäußerte Statement, dass agile Architekturen im Team entstehen, soll dabei erst einmal heißen, dass sie nicht außerhalb des Teams entstehen sollen. Dies bedeutet aber nicht zwangsläufig, dass jeder im Team dabei gleichrangig mit entscheiden darf und soll. Das würde sich anderenfalls zwar für die Team-Mitglieder irgendwie gut anfühlen, würde aber zu schwammigen, demokratischen Design-Entscheidungen führen, die es allen irgendwie recht machen soll, oder es würde zu überhaupt keinen Entscheidungen führen.
Ein zweiter Aspekt ist, dass bei der rein benutzergetriebenen Entwicklung, die gerne im agilen Umfeld postuliert wird, zwar eine gute Lösung für die gerade betrachtete Nutzergruppe herauskommt, die Lösung aber für andere, schlecht repräsentierte Stakeholder oder in anderen Kontexten, suboptimal ist. In der reinen Software-Entwicklung lässt sich dies durch nachträgliche Refactoring-Maßnahmen leichter ändern als in der physischen Produktentwicklung, wo sich solche Design-Entscheidung wesentlich drastischer und langfristiger auswirken, bis hin zur kompletten Neuentwicklung.
Agilität braucht Engineering!
Obige Aussagen bedeuten, dass gerade bei komplexen physischen Systemen, Designentscheidungen gut fundiert und mit einem bewusst breiten Blick auf Stakeholder und die verschiedenen Anwendungskontexte, getroffen werden sollten. Und hier kommen nun wieder etablierte Engineering-Praktiken zum Einsatz, wie Anforderungserhebung und -analyse, Konzeptentwicklung und -bewertung, sowie Machbarkeitsstudien.
Um dies zu unterstützen, gibt es im P4-Framework geeignete Backlog-Element, die ein einfaches und schlankes Systems-Engineering fördern.
Für die Anforderungserhebung gibt es die folgenden Backlog-Elemente:
- Stakeholder-Bedürfnisse entsprechen Grundanforderungen der verschiedenen Stakeholder auf einer sehr hohen Flughöhe
- System-Features, bilden funktionale Anforderungen ab. Diese können durch User Stories und/oder Use Cases modelliert werden. Eine Gruppe von System-Features beschreibt als Feature-Set eine System bzw. eine Systemvariante, wenn in Plattformen und/oder Marktvarianten gedacht wird.
- Die Quality-Attributes entsprechen nicht-funktionale-Anforderungen (NFRs) die gegeneinander ausbalanciert werden müssen und die die System-Konzepte einschränken
- Constraints sind ebenfalls NFRs, die harte Randbedingungen darstellen und ebenfalls die System-Konzepte einschränken.
Durch Priorisierung der Anforderungen, d.h. Festlegung der „Wichtigkeit“ der Anforderungen durch Abwägen der Bedürfnisse der Stakeholder, können Systemkonzepte gut bewertet werden.
Auf der nächsten Ebene der System-Konzepte geht es darum, geeignete Lösungen zu finden, Varianten zu bilden und gegeneinander zu bewerten. System-Konzepte beschreiben Lösungsvarianten für ein Feature-Set, die durch die Entwicklungsarbeit soweit analysiert und verfeinert werden, dass durch ein Auswahl- und Ausschlussverfahren, die am besten geeignete Variante übrig bleibt und zur Marktreife weiterentwickelt wird.
Bewertungskriterien für System-Konzepte sind z.B.:
- Erfüllungsgrad der Anforderungen
- Entwicklungskosten gegenüber einer Nutzenbetrachtung (Gewinn, strategischer Nutzen)
- Vor- und Nachteile, sowie Risiken und Chancen
Dabei können verschiedene Engineering-Praktiken angewendet werden, wie …
- Morphologischer Kasten zum Finden von passenden Lösungsmöglichkeiten und Kombinationen
- System-Modellierung zur Visualisierung von Konzepten (z.B. durch SysML)
- Gewichtete Bewertungsmatrix, bei der den verschiedenen Bewertungskriterien unterschiedliche Prioritäten (Gewichte) gegeben werden und der Gesamterfüllungsgrad durch die Summe der gewichteten Einzelerfüllungsgrade ermittelt wird.
Auch beim Test-Engineering und der Integration haben sich etablierte Praktiken des Systems-Engineering bewährt. So werden durch das häufigere Bauen in der agilen Produktentwicklung mehr Tests notwendig. Daher ist Testautomatisierung eine nützliche, fast schon notwendige Disziplin. Weitere breite Felder mit hohem Potenzial sind z.B. Rapid-Prototyping und die digitale Simulation.
Wie viel Agilität geht, wie viel Engineering muss?
Es ist wichtig zu unterscheiden, welches Anwendungsgebiet wir betrachten. Wollen wir also z.B. eine Web-Seite bauen oder die Elbphilharmonie? Daraus ergeben sich Fragen nach mögliche Technologien, Lösungskonzepten (z.B. Baukästen, Plattformen) und deren Unsicherheiten, sowie der Klarheit der Anforderungen. Dies bezeichne ich als Development Complexity.
Ein weiterer Aspekt ist, wie viel Aufwand an Geld und Zeit benötigt wird, um ein Muster („Sample“), also ein Testobjekt zu generieren. Dies bezeichne ich als Realization Complexity.
Weitere Treiber
- der technologische Innovationsgrad: je unbekannter die Technologie ist, desto mehr muss ausprobiert und gelernt werden
- der anwendungsbezogene Innovationsgrad: Wird die Technologie von den Benutzern im Markt akzeptiert? Auch hier muss möglichst schnell zusammen mit dem Markt und den Nutzern gelernt werden
- das Wissen der Organisation und der beteiligten Teams in Bezug auf Technologie und Anwendung
- der Grad der Regulierung der Produktentwicklung: Die „Schärfe“ der Regeln äußert sich durch die Menge der Dokumentation, Nachweise und der Engineering-Praktiken, wobei auch die Regulierungsbehörden mittlerweile die Vorteile der frühen Tests der iterativ-inkrementellen und agilen Vorgehensweisen zu schätzen wissen
Ziele beeinflussen die Balance
Agilität fokussiert darauf, in schnellen Zyklen zu lernen und häufig Prototypen zu bauen. Mögliche Fehler werden bewusst in Kauf genommen, da auch aus ihnen gelernt wird.
Engineering fokussiert darauf, einen hohen Qualitätsgrad zu erreichen und dabei möglichst wenige Prototypen zu benötigen. Mögliche Verzögerungen werden bewusst in Kauf genommen.
Die Produktentwicklungsziele der Organisation entscheiden, wie die Balance zwischen Agilität und Engineering aussehen sollte. Dabei werden Kosten, Zeitbedarfe und die Produktqualität abgewogen.
Leider überwiegt heute meist noch der Glaube (oder die Hoffnung?), dass gute Ingenieurspraktiken mit wenigen Prototypen schneller und effektiver zum Ziel führen, als das bewusst häufigere Bauen von Prototypen mit einem iterativen Lernprozess von Technikern und Anwendern.
Wie sieht das in Ihrem Marktsegment und in Ihrer Organisation aus? Ich würde mich über Kommentare und eine Diskussion freuen.
[Titelfoto von freepik.com]