Um das Thema individuelle Softwareentwicklung bzw. digitale Produktentwicklung nach Agilen und Lean Prinzipien ist in den letzten Jahren ein echter Hype entstanden. Jeder, der sich mit der Entwicklung von komplexen Softwarelösungen beschäftigt, nimmt für sich in Anspruch, dafür auch entsprechende Frameworks wie beispielsweise Scrum und Extreme Programming einzusetzen.
Für Nichtexperten sind das leere Buzzwords und wenig hilfreich, um das “Warum” zu verstehen, deshalb haben wir den wesentlichen Nutzen für Sie als den Kunden zusammengefasst.
Bei welchen Problemstellungen eignet sich agiles Vorgehen?
Bevor wir aber auf den konkreten Nutzen für den Kunden bei der Anwendung von agilen Frameworks bzw. Praktiken eingehen, möchten wir voranstellen, bei welchen Aufgaben bzw. Problemstellungen sich agiles Vorgehen besonders eignet.
Der Einsatz von agilem Vorgehen bietet sich insbesondere bei komplexen (im Gegensatz zu einfachen, komplizierten und chaotischen) Problem- bzw. Aufgabenstellung (siehe auch Stacey Matrix) an.
Um den Charakter eines Projektes einzuordnen sind folgende Fragestellungen hilfreich:
- Können wir davon ausgehen, dass die Umfeld- und Marktbedingungen während der Projektumsetzung stabil bleiben? In der Praxis nimmt man an, dass mit zunehmender Projektdauer die Wahrscheinlichkeit eines stabilen Umfeldes sinkt.
- Können wir das Verhalten der zukünftigen Anwender abschließend prognostizieren und sind wir daher sicher, dass wir die Motive, Wünsche und Präferenzen der relevanten “Buyer Personas” kennen?
- Haben wir umfassendes und abschließendes Wissen hinsichtlich der technologischen und fachlichen Anforderungen sowie Lösungen?
- Handelt es sich um eine Aufgabenstellung, die zwar herausfordernd ist, die wir aber als Organisation schon mehrmals gelöst haben oder handelt es sich um eine Aufgabe mit innovativem Charakter, bei der keine oder nur wenige Erfahrungswerte vorhanden sind?
- Ist regelmäßiges Feedback der Anwender im Zuge der Realisierung wesentlich für die Akzeptanz und den Nutzen des Produktes?
- Können wir davon ausgehen, dass es während der Umsetzungsphase zu keinen neuen Erkenntnissen kommt, die für den Wert des Produktes einzahlen? Sprich, ein nutzbringender Lerneffekt während der Umsetzung kann ausgeschlossen werden?
Die obigen Fragestellungen stehen im Kontext der grundsätzlichen Herausforderung im Zuge der Produktentwicklung:
“Wir entwickeln mit dem Wissen und den Thesen von heute das Produkt von morgen!”
Ein plakatives Beispiel einer komplexen Aufgabenstellung ist die Bekämpfung der Covid-19 Pandemie. Die Wirksamkeit der getroffenen Maßnahmen zur Kontaktbeschränkung hängen wesentlich vom Verhalten der Bevölkerung ab. Der Wirkungsgrad der einschränkenden und öffnenden Einzelmaßnahmen und deren Wechselwirkung sind nicht abschließend bestimmbar. In unseren Breitengraden verfügen wir über keine ausreichende Erfahrung bei der Pandemiebekämpfung. Das Corona Virus bringt laufend neue Mutanten hervor.
Welchen Nutzen hat der Kunde von agilem Vorgehen in der Softwareentwicklung?
Wenn wir also davon ausgehen, dass es sich bei dem konkreten Vorhaben um die Lösung einer komplexen Aufgabenstellung handelt, bringt die Anwendung von agilen Frameworks (z.B.: Scrum im Kontext der digitalen Produktentwicklung) folgende konkrete Nutzen für den Kunden:
1. Laufende Lieferung voll funktionsfähiger, getesteter Software Inkrement
Bei der agilen Produktentwicklung handelt es sich um ein inkrementelles, iteratives Vorgehen. Im “klassischen” bzw. Wasserfall orientierten Vorgehen werden hingegen die typischen Projektphasen (Konzeption, Design, Umsetzung, Test, Go-Live) zeitlich aneinandergereiht. Das Produkt wird damit am Ende der Umsetzungsphase als ein Lieferobjekt für den kundenseitigen Test zur Verfügung gestellt. Im Gegensatz dazu werden im agilen Vorgehen im Zuge der Umsetzung laufend (z.B. in 2-wöchigen Sprints) und frühzeitig voll funktionsfähige und getestete Software-Inkremente geliefert und laufend Feedback vom Kunden eingeholt. Mehr über den Vergleich Scrum vs. Wasserfall erfahren Sie hier.
Der Kunde gestaltet somit auch während der Umsetzungsphase das Produkt in fachlicher Hinsicht aktiv mit. Durch dieses Vorgehen ist sichergestellt, dass das Produkt ein Optimum, im Hinblick auf den Wert des Produktes, für den Kunden erreicht.
Siehe dazu auch Prinzip 3 der 12 Prinzipien des agilen Manifests:
Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate, und bevorzuge dabei die kürzere Zeitspanne.
2. Volle Transparenz während der Entwicklung
Durch das unter Punkt 1 dargestellte Vorgehen ist für den Kunden auch im Zuge der Umsetzungsphase volle Transparenz sichergestellt, denn der Kunde ist aktiver Akteur bzw. Beitragender (in der Rolle des Product Owners) auch während der Realisierung. Damit ist laufende Transparenz für den Kunden, nicht nur was den Entstehungsprozess des Produktes selbst betrifft, sondern auch hinsichtlich Projektfortschritt, Entwicklungsgeschwindigkeit (Velocity), Qualität und potentieller Herausforderungen im Zuge der Umsetzung gegeben.
Siehe dazu auch Prinzip 4 der 12 Prinzipien des agilen Manifests:
Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
3. Technische Exzellenz und gutes Design
In den agilen Frameworks gelten technische Exzellenz und gutes Design als nicht verhandelbare Größen. Die Qualität wird niemals kompromittiert und ist somit eine feststehende Größe. Praktisch macht sich das dadurch fest, dass beispielsweise nur vollständig getestete, frei von bekannten Fehlern und der “Definition of Done” entsprechenden Software-Inkremente als geliefert gelten. Eine Kompromittierung von Qualität, wie das in Projekten mit klassischem Vorgehen durchaus auch mal vorkommt, um beispielsweise Liefertermin oder Budget einzuhalten, ist bei professionellen agilen Umsetzungs-Teams ein absolutes No-Go. Das ist auch besonders wichtig bei der Modernisierung von veralterter Software und Legacy Systems. Technische Exzellenz und gutes Design ist in den agilen Frameworks derart tief verankert, dass sie als zentrale Merkmale dafür bezeichnet werden können.
Siehe dazu auch Prinzip 9 der 12 Prinzipien des agilen Manifests:
Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
4. Maximierung des Outcomes bzw. des Nutzens für Kunden und Anwender
Agile Frameworks unterstützen die Entwicklung eines “lightweight”, also eines möglichst leichtgewichtigen Produktes, dass den Geschäftswert maximiert bzw. das Verhalten des Anwenders maximal in Richtung Nutzenmaximierung verändert. Es gilt folgender Anspruch: “Outcome over Output over Input”. Zielsetzung ist also nicht mit einem gegebenen Budget maximal viele Features umzusetzen, sondern den Blick zentral auf die Nutzenmaximierung des Anwenders zu richten und dieses mit möglichst wenigen Features bzw. Funktionalität zu erreichen, was auch in der Regel zu einer Minimierung des Aufwandes bzw. des Budgets führt. Für Dienstleister gilt daher, dass nicht die Maximierung der Leistungsstunden das Ziel ist, sondern die Maximierung des Wertes für den Kunden.
Siehe dazu auch Prinzip 1 und 10 der 12 Prinzipien des agilen Manifests:
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software (Produkte) zufrieden zu stellen.
Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
5. Höchstmaß an Qualität und Vermeidung von technischen Schulden
Wie bereits unter Punkt 3 dargestellt ist das Kompromittieren von Qualität ein “Anti Pattern”, also ein Verhaltensmuster, das bei der Anwendung von agilen Frameworks einen Tabubruch darstellt und in seiner Konsequenz zu sogenannten technischen Schulden führt. Diese entstehen regelmäßig dadurch, wenn man bei der Umsetzung vermeintliche “Abkürzungen” nimmt. In der Praxis zeigt sich das beispielsweise durch mangelnde Code Qualität, fehlende kontinuierliche Unit- und Integrationstests, mangelnde Dokumentation, fehlende Coding Standards, fehlende Messung von Code Qualität (z.B.: keine Anbindung von SonarQube), unsaubere Architektur oder keine Zero Bug Policy.
Letzteres bedeutet nicht, dass keine Bugs also Fehler auftreten können, sondern, dass deren Bereinigung höchste Priorität genießt und somit gelöst werden müssen, bevor weitere Features implementiert werden. Unterlässt man das, führt jedes weitere Feature zu weiteren Fehlern und Extremfall zum Tod des Produktes.
Siehe dazu auch Prinzip 7 der 12 Prinzipien des agilen Manifests:
Funktionierende Software ist das wichtigste Fortschrittsmaß.
6. Laufende Kommunikation und Verbesserung auf Prozess- und Produktebene
Durch das iterative und inkrementelle Vorgehen entsteht ein Rahmen für eine laufende Kommunikation zwischen dem Kunden (in der Rolle des Product Owners) und dem Umsetzungsteam (intern oder extern), mit dem Ziel einer kontinuierlichen Verbesserung des Produktes selbst, aber auch der Zusammenarbeit zwischen Auftraggeber und Auftragnehmer.
Letzteres fußt auf der These, dass die Qualität der Zusammenarbeit und der entsprechenden Prozesse (z.B.: in Scrum die definierten Zeremonien und Artefakte) wesentlichen Einfluss auf die Qualität des zu entwickelnden Produktes haben. Der Anspruch der laufenden Verbesserung manifestiert sich durch das Prinzip “Inspect & Adapt”. Im Gegensatz zu einem nach traditionellem Vorgehen durchgeführten Projekt, bei dem in der Regel erst am Ende des Projektes ein Review bzw. eine Lessons-Learned-Sitzung zwischen Kunde und Umsetzungsteam durchgeführt wird, prüft (Inspect) das agile Team nach jedem Sprint, wo es steht, was erreicht wurde und wo Verbesserungspotenzial besteht. Sollte es Dinge geben, die zu verbessern sind, werden Maßnahmen zur Umsetzung entsprechender Veränderungen vereinbart (Adapt).
Siehe dazu auch Prinzip 8 und 12 der 12 Prinzipien des agilen Manifests:
Agile Prozesse fördern eine nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
7. Verringerung des Ausfallsrisikos
Die Bewältigung einer komplexen Problemstellung ist eine Teamsport Aufgabe. Dabei muss das Team “cross-funktional” aufgestellt sein, was bedeutet, dass alle Kompetenzen, die es dafür braucht, um ein Produkt Ende-zu-Ende zu entwickeln, wie Konzeption, Design, Frontend, Backend, Testing und DevSecOps, im Umsetzungsteam vorhanden sein müssen.
Darüber hinaus soll sich dieser Anspruch auch auf der Ebene der einzelnen Team Mitglieder widerspiegeln. Dies bedeutet, dass jedes Teammitglied im Idealfall alle geforderten Domänen zumindest soweit beherrscht, dass bei einem Ausfall eines anderen Teammitglieds, die Aufgaben soweit übernommen werden können, dass ein Stillstand des Projektes ausgeschlossen ist.
Ein Team, das aus einzelnen Experten für jeweils nur eine Domäne besteht, ist kein agiles Team. Sind die Teammitglieder “Full-Stack”, bedeutet das für den Kunden, im Falle eines Ausfalls eines Teammitglieds in der Regel nur, dass die Entwicklungsgeschwindigkeit in dem Zeitraum nicht weiter zunimmt.
Siehe dazu auch Prinzip 11 der 12 Prinzipien des agilen Manifests:
Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
8. Höchstmaß an Flexibilität und späte Änderungen
Das inkrementelle, iterative Vorgehen fördert einen kontinuierlichen Lernprozess, auch während bzw. im Zuge der Umsetzung. Änderungen bzw. Anpassungen der Anforderungen hin zum Optimum des Produktnutzens für den Anwender sind daher nicht nur möglich, sondern vielmehr erwünscht. Dies ermöglicht somit die Berücksichtigung von neuen Erkenntnissen während des Entwicklungsprozesses ebenso wie die Änderung der Priorisierungen von bereits definierten Anforderungen.
Siehe dazu auch Prinzip 2 der 12 Prinzipien des agilen Manifests:
Radikale Anforderungsänderungen sind selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
9. Der Kunde behält stets die inhaltliche Führung
Wie bereits unter Punkt 2 dargestellt, ist der Kunde zentraler Akteur auch während der Umsetzung und wird nicht erst am Ende mit dem “fertigen” Produkt konfrontiert. Im Zuge des agilen Vorgehens ist der Kunde für das “WAS” verantwortlich und behält daher auch während der Umsetzung die vollständige und laufende inhaltliche bzw. fachliche Führung.
Siehe dazu auch Prinzip 1 der 12 Prinzipien des agilen Manifests:
Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
10. 100% Fokus und Vermeidung von Verschwendung
Bei der Softwareentwicklung nach Lean Prinzipien ist einer der zentralen Forderungen die Vermeidung von Verschwendung. Auch hier gilt: weniger ist mehr. Ziel ist es, mit einem möglichst geringem Funktionsumfang ein Maximum an Geschäftswert zu schaffen. Darüber hinaus wird Verschwendung auch dadurch vermieden, dass das Umsetzungsteam exklusiv an der Entwicklung eines Produktes arbeitet um somit ein Höchstmaß an Effizienz zu gewährleisten. Der Vorteil für den ist Kunden, dass das Umsetzungsteam zu 100% fokussiert an der Entwicklung des Produktes arbeitet. “Rüstzeiten” durch ein ständiges Wechseln bzw. Eindenken von einer Aufgabe in eine andere, werden daher vermieden.
Abschließen möchten wir darauf hinweisen, dass der Nutzen bei der Anwendung von agilen Methoden im Bereich der Produkt- bzw. Softwareentwicklung nur dann eintritt, wenn die Frameworks in der betrieblichen Praxis auch tatsächlich umgesetzt und konsequent gelebt werden. Nicht überall, wo agil drauf steht, steckt dann auch tatsächlich agil drinnen. Hier ist insbesondere bei der Evaluierung von Entwicklungspartnern Vorsicht geboten.
Worauf Sie bei der Evaluierung Ihres Softwareentwicklungs-Partner achten sollten?
Die 10 wichtigsten Punkte für Ihre Entscheidung finden Sie hier!
