Als ich 1992 meinen Abschluss als Diplom-Ingenieur Elektrotechnik gemacht habe war es üblich, in einem Entwicklungsprojekt die Produktanforderungen in einem Lastenheft zu spezifizieren. In diesem Dokument werden alle Anforderungen an das zu entwickelnde Produkt vom Auftraggeber aufgelistet.
Die Entwicklungsabteilung leitet daraus ein Pflichtenheft ab, welches als Grundlage für die Realisierung dient. Für größere Projekte sind das sehr umfangreiche Dokumente, die das Produkt bis ins Detail exakt beschreiben sollen. Die Produktentwicklung kann somit komplett eigenständig vom Entwicklungsteam durchgeführt werden. Erst nach Fertigstellung des Produktes, wird es dem Auftraggeber zur Abnahme vorgestellt.
Diese Vorgehensweise, heute als Wasserfallmodell bezeichnet, hat sich bei vielen Entwicklungsaufgaben bewährt und wird auch heute noch in vielen Bereichen eingesetzt.
Für unsere schnelllebige Welt, die in immer höherem Tempo neue Märkte mit neuen Anwendungen erschließt, kommt dieses Modell aber an seine Grenzen.
Meine Erfahrungen mit dem Wasserfallmodell sind zwiespältig. Kleinere Projekte oder Projekte in einem technischen Umfeld, in dem man sehr große Erfahrung besitzt, lassen sich mit dieser Methode erfolgreich und effizient umsetzten. Aus meiner Sicht ist hierbei wichtig, dass Auftraggeber und Entwickler:innen eine hohe technische Kompetenz im betreffenden Fachgebiet besitzen und die Aufgabenstellung mit einer gemeinsamen Fachterminologie auf Augenhöhe beschreiben können. Probleme treten auf, wenn diese technische Klärung nicht satt findet und sich beide Parteien auf ihr Verständnis des Lastenheftes verlassen.
Das Motiv hierfür ist oft die Bequemlichkeit: Auf umfassende Diskussionen zur finalen Klärung von offenen Detailfragen wird verzichtet. Auf Seiten des Auftraggebers erhofft man sich, durch „weiche“ Formulierungen Hintertüren offen zu lassen. Auf Seiten des Auftragnehmers will man eine zugesagte Auftragsvergabe nicht durch intensives Nachfragen gefährden.
Beide Seiten interpretieren „weiche“ Formulierungen im Lastenheft in ihrem jeweiligen Interesse, welches meist sehr unterschiedlich, wenn nicht sogar konträr ist. Das Ergebnis sieht oft so aus, dass der Auftraggeber das fertige Produkt zurückweist, da er sich eine andere Umsetzung vorgestellt hat und der Auftragnehmer behauptet, dass das Produkt genau der Beschreibung im Lastenheft entspricht.
Der darauffolgende Streit über die richtige Interpretation ist unter Umständen langwierig und mit teuren Nachbesserungen verbunden, die für beide Seiten Zeitverlust und zusätzlichen Aufwand bedeuten. Oft werden auch „faule“ Kompromisse akzeptiert, die den wirtschaftlichen Erfolg des Produktes mindern oder komplett in Frage stellen.
Ein weiteres Risiko entsteht, wenn sich Anforderungen oder Rahmenbedingungen während der Entwicklung ändern. Werden diese Änderungen nicht berücksichtigt, entspricht das Produkt am Ende der Entwicklung nicht den aktuellen Marktanforderungen. Werden sie nachträglich berücksichtigt ist oft unklar, wer die hierfür entstehenden Kosten trägt.
Viele Projekte im Bereich der Automatisierungstechnik habe ich in diesem Spannungsfeld erfolgreich realisiert. Obwohl ich mich im Wesentlichen im Bereich Maschinen- und Anlagenbau und auf Ingenieursebene bewegt habe, war die saubere und umfassende technische Klärung vor dem Entwicklungsstart immer eine Herausforderung und deren Qualität stark von den jeweils beteiligten Kolleginnen und Kollegen sowie den Mitarbeitenden auf Kundenseite abhängig.
Sätze wie „Das muss doch mit dabei sein, obwohl es nicht explizit beschrieben ist. Das ist doch Stand der Technik.“ oder „Wenn der Kunde das zusätzlich gefordert hat, ist doch klar, dass das mehr kostet.“ haben des Öfteren meinen Blutdruck steigen lassen.
Und dass, obwohl auf beiden Seiten Expertinnen und Experten in einem bekannten technischen Umfeld tätig waren.
Ausgangssituation
2019 habe ich mich entschlossen ein Start-up im Bereich der industriellen Wägetechnik zu gründen. In den Jahren davor habe ich auf vielen VDMA-Veranstaltungen die Herausforderung Industrie 4.0 kennengelernt und große Chancen für eine IoT-Cloud zur Vernetzung von Industriewaagen gesehen. Ziel war es, eine IoT-Cloud-Plattform aufzubauen und zu betreiben, um sie Waagenanwendern für eine monatliche Gebühr zur Nutzung zur Verfügung zu stellen.
Damit werden Anwender:innen von der eigenen Entwicklung einer IoT-Plattform entlastet, können sich auf ihr Kerngeschäft konzentrieren, aber gleichzeitig die Vorteile der Digitalisierung nutzen. Da ich keine eigenen Ressourcen für eine solche Produktentwicklung hatte, war von Anfang an klar, mit externen Partnern für die Entwicklung der Software zusammen zu arbeiten.
Ich startete damit die Spezifikationen für die IoT-Cloud-Plattform und ein hierfür passendes IoT-Gateway detailliert in Form eines Lastenheftes niederzuschreiben. Obwohl ich mich als IT-affin bezeichne, kam ich hier an meine Grenzen.
Die Problematik bestand darin eine Anwendung zu beschreiben, für die es noch kein Beispiel gab und auch die konkreten Bedürfnisse der Anwender noch nicht bekannt waren. D.h. es galt ein neues Produkt für einen neuen, sich schnell ändernden Markt, auf Basis neuer, sich ständig weiterentwickelnden Softwaretools und Cloud-Technologien zu bauen. Das entspricht einer komplexen Gleichung mit mehreren Unbekannten. Diese schwierigen Rahmenbedingungen werden aktuell durch den Begriff VUCA (Volatility, Uncertainty, Comlexity, Ambiguity) beschrieben.
In der Diskussion mit möglichen Anbietern wurde klar, dass meine Spezifikationen entweder zu unspezifisch für eine konkrete Umsetzung waren oder für eine technisch optimale Lösung zu detailliert. Außerdem beruhten die Use-Cases auf vagen Annahmen.
Die eingehenden Angebote waren daher entweder sehr teuer (Sicherheitsaufschlag) oder ich wurde von den Anbietern darauf hingewiesen, die Entwicklung mit agilen Methoden, wie Scrum, umzusetzen: Das ist im Bereich der Softwareentwicklung Standard und die Lösung für die genannten Probleme.
Scrum ist ein Framework für die Entwicklung komplexer Produkte anhand einer formulierten Vision. Die Anforderungen werden aus Sicht der Anwender:innen beschrieben und in einem Product Backlog aufgelistet. Diese Anforderungen werden Stück für Stück in 4-wöchigen oder kürzeren Sprints umgesetzt. Nach jedem Sprint wird das Ergebnis mit dem Auftraggeber besprochen und so sichergestellt, dass die Entwicklung das Projekt im Sinne des Auftraggebers umsetzt.
Das Product Backlog wird dabei an sich ändernde Rahmenbedingungen angepasst oder anhand der im Projekt gewonnenen Erkenntnisse weiterentwickelt. Mit dem kontinuierlichen Austausch nach jedem Sprint wächst im Projektverlauf das gemeinsame Verständnis für das Produkt. Zusätzlich erhält der Auftraggeber die Möglichkeit die Anwender:innen mit ins Boot zu holen und frühzeitig ein Feedback über die Akzeptanz der Umsetzung zu bekommen.
Damit hatte ich aber zu Anfang meine Probleme. Der Charme des Lastenheftes ist die vermeintliche Sicherheit, dass der Auftragnehmer ein fest definiertes Produkt zum vereinbarten Preis liefert. Wenn er das nicht tut, muss er nachbessern oder ich bekomme mein Geld zurück. Im Gegensatz hierzu wird beim agilen Projektmanagement mit einer einfachen Produktbeschreibung, dem Product Backlog, gestartet und man überprüft in kurzen Zeitabständen, ob die Ergebnisse mit den Erwartungen übereinstimmen.
Weiterhin kann mit wachsenden Erfahrungen das Product Backlog während der gesamten Produktlebenszeit dynamisch angepasst werden. Die Fragen, die sich mir stellten, waren: Bekomme ich zum vereinbarten Preis ein fertiges Produkt oder nur ein Fragment? Wer haftet für eine unvollständige oder fehlerhafte Entwicklung? Ist Scrum nicht nur eine Methode, mit der sich die Entwickler:innen vor ihrer Verantwortung drücken?
Die Spezifikation für eine Cloud-Anwendung, für die es noch kein existierendes Beispiel gibt, in Form eines detaillierten Lastenheftes niederzuschreiben, hat sich als zu aufwendig und never ending story erwiesen. Das Gleiche galt für die hierzu benötigte Hard- und Software eines IoT-Gateways.
Warum waren meine bis dahin so erfolgreichen Methoden in diesem Fall nicht zielführend? Schlicht und ergreifend, weil ich von der zugrundeliegenden Technik zu wenig wusste, um die erforderlichen Entwicklungsarbeiten eindeutig beschreiben zu können. Weil die Anforderungen der Anwender zum damaligen Zeitpunkt nicht detailliert bekannt waren und die Softwareentwickler:innen von wägetechnischen Anwendungen keine Ahnung hatten. D.h. eine Klärung der Spezifikation auf Augenhöhe war nicht möglich.
Damit wäre die Sicherheit eines Lastenheftes sehr trügerisch gewesen. Die Chance, dass meine Anforderungen, die ich zum Start des Projektes formuliert hatte, in einem vertretbaren Kostenrahmen zu einem erfolgreichen Produkt führen würden, war gering. Dies hat die spätere Umsetzung auch deutlich gezeigt.
Entscheidung für einen agilen Entwicklungsprozess
Bei dieser Ausgangslage war ein agiles Projektmanagement alternativlos. Ein nicht vollständiges oder über den Entwicklungszeitraum veraltetes Lastenheft bietet keine Sicherheit für ein funktionierendes und für die Anwender:innen attraktives Produkt. Also habe ich die Vorschläge der Softwareentwickler:innen akzeptiert und eine Softwareentwicklung auf Basis von Scrum beauftragt.
Die „Spezifikationen“ wurden in Form von User-Stories niedergeschrieben. Der Aufwand für die Umsetzung der User-Stories wurde geschätzt und bildete die Grundlage für das Angebot, auf dem mein Auftrag basierte. Mein anfängliches Misstrauen wurde berücksichtigt, in dem wir eine Sprintdauer von 2 Wochen vereinbarten. So hatte ich immer einen guten Überblick in welche Richtung die Entwicklung ging und ob sie meinen Vorstellungen entsprach.
Gleichzeitig konnte ich die Anwendung in einem frühen Stadium bereits potenziellen Nutzern vorstellen und die Akzeptanz des Entwicklungsergebnisses anhand deren Feedback überprüfen. Natürlich war die Umsetzung auch in diesem Fall nicht problemlos. Für mich bestand der Stress, alle 2 Wochen das jeweilige Inkrement zu begutachten, zu testen und den Entwickler:innen Feedback zu geben. Es gab des Öfteren unterschiedliche Interpretationen, wie die User-Stories umzusetzen waren, die geklärt werden mussten.
Durch die kurze Sprintdauer konnten auseinanderlaufende Vorstellungen schnell synchronisiert werden. Der Entwicklungsfortschritt war transparent und nach und nach konnte – auf Augenhöhe – eine gemeinsame Vorstellung des Produktes entwickelt und umgesetzt werden.
Mit den einzelnen Inkrementen erhält man schon im Projektverlauf wertige Produktversionen und bekommt einen aktuellen Überblick über folgende Punkte: verbrauchtes Budget, Produktwertigkeit, noch offenes Budget, noch zu realisierende Features. Die Chance, am Ende des Prozesses ein wertiges Produkt zu erhalten, war deutlich größer als in einem Wasserfallmodell. Voraussetzung hierfür ist allerdings, dass man seine Verantwortung in diesem Prozess wahrnimmt und einen intensiven Austausch zwischen Auftraggeber und Auftragnehmer während der Entwicklung pflegt.
Fazit
Agiles Projektmanagement nach Scrum ist auf keinen Fall eine Abkürzung oder eine Vereinfachung des Entwicklungsprozesses. Es ist eine Methode, die die Entwicklung von hoch innovativen Produkten für zukünftige Märkte ermöglicht und ein hohes Maß an Verantwortungsbewusstsein, Abstimmung, Kommunikation, Entscheidungsfreudigkeit und Konfliktlösungskompetenz benötigt.
Lässt man sich darauf ein und nutzt die Vorteile von Scrum konsequent, so kann man damit flexibel und vor Allem sehr schnell neue Produkte in den Markt bringen und kontinuierlich an die Bedürfnisse anpassen. Der Erfolg hat mich so begeistert, dass ich eine Ausbildung zum Scrum Master gemacht habe und so in zukünftigen Projekten Scrum noch besser nutzen oder Scrum-Teams bei ihrer Arbeit unterstützen kann.
Ausblick und Empfehlung
In der Softwareentwicklung sind agile Methoden, wie beispielsweise Scrum, etablierte Standardwerkzeuge. In traditionellen Industrien, wie dem Maschinen- und Anlagenbau beherrscht oft noch das Wasserfallmodell das Bild. Da auch in diesen Bereichen der Innovationsdruck immer höher wird und der Softwareanteil zunimmt, muss man sich auch dort mit agilen Vorgehensweisen beschäftigen.
Schlagwörter wie IoT, künstliche Intelligenz, Industrie 4.0 usw. sind bezeichnend für diesen Trend und eindeutig im VUCA-Umfeld angesiedelt. Will der Maschinen- und Anlagenbau in diesem Umfeld bestehen, muss er in der Lage sein, agile Methoden für seine Entwicklungsprojekte zu nutzen. Da der Fachkräftemangel in diesem Bereich hoch ist, wird es immer wichtiger, Projekte auch mit externen Partnern zu managen.
Bevor Sie im Rahmen neuer Geschäftsmodelle Digitalisierungsprojekte im VUCA-Umfeld umsetzen, z.B. IoT-Plattformen bauen oder Machine Learning Algorithmen implementieren, machen Sie sich mit Scrum vertraut. Scrum Master oder Scrum Coaches erläutern Ihnen die Vorgehensweise und deren Vorteile. Oder nehmen Sie an einem Scrum-Training teil, um einen fundierten Einstieg in das Thema zu bekommen.
Wenn Sie einen Ansprechpartner suchen, der beide Welten (Wasserfall und Agil) kennt, sprechen Sie mich an. Gerne unterstütze ich Sie dabei Ihre Vorgehensweise in eine agile Methodik zu überführen.
