Warum ist mein Releasetrain so langsam?!

Agiles Arbeiten nach Scrum oder Kanban allein beschleunigt die digitale Produktentwicklung noch nicht. MVP-Denken und agile SW-Entwicklungspraktiken sind weitere Erfolgsfaktoren.

Silbernes Fraktal

In der digitalen Produktentwicklung haben in den vergangenen Jahren immer mehr Unternehmen damit begonnen agile Methoden einzuführen. Scrum– und Kanban-Teams sind bereits State-of-the Art geworden. Vielerorts sind skalierte agile Methoden wie SAFe, LESS oder Nexus im Einsatz. Mit der Skalierung des agilen Arbeitens und der damit verbundenen nie dagewesenen Transparenz kommen aber auch Fluch und Segen gleichermaßen in die Unternehmen. Denn häufig wird plötzlich deutlich, dass die Organisation scheinbar viel zu langsam ist, um die angeblich so wichtigen Anforderungen für den Markt in der zur Verfügung stehenden Zeit und den zur Verfügung stehenden Ressourcen (Mitarbeiter oder Budget) umzusetzen.

Agiles Arbeiten

Nun muss man dem agilen Arbeiten zunächst einmal zugutehalten, dass die Transparenz über die Geschwindigkeit sehr schnell vorliegt. Idealerweise bereits nach rund einem halben Jahr (SAFe Nomenklatur: 3 Programm-Inkremente) kann die Geschwindigkeit einer skalierten agilen Organsiation mit recht guter Genauigkeit bestimmt werden.

Somit bestehen meist gute Chancen, den Nutzen des Programms bis zum Programmende oder noch früher einzufahren. Dazu muss aber verstehen was gerade in Dysbalance ist. Eines ist sicher: die agile Arbeitsweise allein ist es nicht!

Lean Prinzipien

Um den Ursachen näher zu kommen, müssen wir uns noch einmal auf die Grundfeste des agilen Arbeitens besinnen. Agile Methoden beruhen auf den Lean Prinzipien nämlich der Vermeidung von nicht notwendigen Tätigkeiten (Waste) und der konsequenten Verbesserung und damit Automatisierung (Digitalisierung) von sich wiederholenden manuellen Tätigkeiten.

In unseren Beratungs- und Transformationsprojekten stellen wir immer wieder fest, dass sich die Unternehmen auf der Reise in die agile Arbeitswelt zu stark auf die Prozesswelt fokussieren. Scrum-Master, Kanban-Master und Agile Coaches werden rekrutiert und die Mannschaften werden in den entsprechenden Prozesskompetenzen von Scrum bis SAFe geschult und für viel Geld zertifiziert. Neben dem agilen Mindset werden zwei weitere wesentliche Kernkompetenzen des agilen Arbeitens aber kaum bis gar nicht entwickelt:

  • MVP-Denken
  • Agile Softwareentwicklung

In der Folge führt dies zu der oben genannten Dysbalance und der damit verbundenen scheinbar langsamen Produktentwicklung .

Minimalistisches Denken

MVP-Denken nennen wir die Fähigkeit einer Organisation minimalistisch zu denken und zu handeln. Dabei bedeutet MVP „Minimal Viable Product“ also ein minimal überlebensfähiges Produkt, das außer dem Kernnutzen zunächst einmal keine weiteren Funktionalitäten besitzt.

Als Beispiel möge ein Webshop dienen, dessen Kernfunktionalität der Verkauf von Waren oder Dienstleistungen ist. Ein MVP eines Webshops besitzt genau nur diese Funktionalität: Ein Kunde kann eine Ware auswählen und kaufen. Der Webshop hat als MVP noch kein schickes Design, keine zig verschiedenen Bezahlmöglichkeiten, keine Retoure-Funktionalität oder ähnliches. Aber ein Shop-Betreiber kann seine Waren oder Dienstleistungen verkaufen.

Diese Denkweise ist essenziell für den Erfolg in unserer heutigen schnelllebigen digitalen Welt und daher auch eine Kernkompetenz für agile Organisationen insbesondere aber für alle Produktmanager und Productowner.

Modernes Softwareentwicklungs Know-How

Unter agiler Softwareentwicklung verstehen wir ein ganzes Kompetenz- und Toolset, mit dem der hoch komplexe Prozess der Softwareentwicklung bis auf den kreativen Teil, nämlich die Umsetzung menschlicher Ideen in Computercode, vollkommen automatisiert wird.

Eine moderne agile Softwareentwicklung sollte skizzenhaft wie folgt aussehen:

  • Das Scrum-Team bespricht die Userstories mit dem Product-Owner
  • Auf Basis der Definition-of-Done und der Akzeptanzkriterien der Userstory werden für die Userstory Testfälle programmiert – sogenannte Unittests. (TDD – Test Driven Development)
  • Erst danach beginnt die Programmierung der eigentlichen Funktionalität der Userstory. Das entstehende Modul wird laufend gegen die Unittests getestet.
  • Alle Programmierarbeiten werden durch Entwicklerpärchen durchgeführt. Damit entfällt der nachgelagerte Review-Prozess. Ferner ist damit das Wissen um den Code immer auf mindestens zwei Köpfe verteilt. Das hilft beim Ausfall eines Entwicklers.
  • Es existiert mindestens eine Integrationsumgebung, eine Demoumgebung und eine Produktionsumgebung. Der Zusammenbau des Systems auf den verschiedenen Umgebungen, das Testen und der Transport von einer Umgebung zur nächsten Umgebung funktioniert regelbasiert und vollautomatisch.

Agil ist nicht Scrum

Wenn die Organisation diese Kernkompetenzen der agilen Softwareentwicklung beherrscht wird sie effizienter. Sobald eine Funktionalität oder eine Userstory fertig programmiert ist und sämtliche Fehler beseitigt sind, kann diese Funktionalität sofort dem Kunden zur Verfügung gestellt werden. Damit können Unternehmen Time-to-Market Zeiten erreichen, die nur noch von der Komplexität der Funktionalität abhängen. Time-to-Market von wenigen Tagen können erreicht werden. Langwierige Testphasen und vierteljährliche Releases gehören damit der Vergangenheit an.

Agiles Arbeiten ist nicht nur Scrum! Beim agilen Arbeiten gilt es das Spannungsfeld aus Prozess (z.B. Scrum), Fachlichkeit (MVP) und SW-Entwicklung (Automatisierung) zu beherrschen. Nach dem Hype um Scrum und SAFe sollten sich die Unternehmen nun wieder auf den Kern ihrer Produkte fokussieren und Kompetenzen und Tools im Bereich der Softwareentwicklung deutlich verbessern. Dann wird aus dem Release-Bummelzug ein Release-Schnellzug.


Sie haben Fragen oder Anregungen zu den oben genannten Themen dann schreiben Sie uns:
infod-centurio.de
Wir freuen uns auch wenn Sie unsere Beiträge in Ihren sozialen Netzwerken teilen. Vielen Dank dafür.