Dreimal so schnell!
"Michi - in meinen Teams gibt jeder sein Bestes, aber trotzdem werden wir immer langsamer. Wir brauchen Unterstützung." - Mein jetziger Kunde, Okt 22
Vier Monate später haben wir die durchschnittliche Durchlaufzeit der Vorgänge in der Entwicklung von 82,5 Tagen auf durchschnittlich 13,6 Tage reduziert. Das Ergebnis ist also noch besser als der Titel verspricht. Der Output, also die Anzahl der pro Monat abgeschlossenen Vorgänge, hat sich von ca. 75 auf ca. 130 vergrößert.
In diesem Artikel teile ich meine Einblicke aus dem Projekt. Der Artikel soll inspirieren und zeigen was möglich ist. Danke an das ganze Team dort, macht richtig Spaß mit euch!
Viel Spaß beim Lesen, ich freue mich über Rückmeldungen & Let's grow, Michael
Dreimal so schnell!
Vor ein paar Wochen war ich mit Freunden aus der IT beim Skifahren. Einer der Teilnehmer fragte mich abends bei einem Gespräch über unsere Berufe am Kamin: "Michi funktioniert das für jedes Unternehmen?" Ich entgegnete dort: "Ist die Frage relevant? Würde es nicht ausreichen, wenn es für dein Unternehmen funktioniert?"
Entscheidend in unsere Rolle als Führungskraft ist oft der Mut, um neue Wege einzuschlagen. Die Mitarbeiter meines aktuellen Kunden hatten diesen und es hat sich ausgezahlt.
Ausgangssituation Oktober 22:
 |
| Ausgangssituation, Oktober 22 |
Der Kunde hat zum Stichtag 31.10 eine durchschnittliche Durchlaufzeit der Anforderungen von 82,2 Tagen mit einer Standardabweichung von 124,6 Tagen. Das heißt von der Idee bis zur fertigen Umsetzung verstrichen manchmal 82 aber auch oft fast 200 Tage. Obwohl jeder sein Bestes gibt, wird wenig fertig. Deshalb beauftragt mich der Kunde ein IT-Mittelstandsunternehmen in der privaten Krankenversicherungsbranche im November.
Stand Februar 23:
 |
| Veränderter Zustand, Februar 23 |
Ungefähr vier Monate später, stehen wir nach ein paar Höhen und Tiefen bei einer durchschnittlichen Durchlaufzeit von 13,6 Tagen mit einer Standardabweichung von 22,6 Tagen. Es ist also aktuell üblicherweise Standard, dass in ca. 35 Tagen aus einer Idee fertige Software geworden ist.
Die Messgröße durchschnittliche Durchlaufzeit hat sich also um mehr als einen Faktor drei verbessert. Es hängt sicherlich stark von den Rahmenbedingungen ab welche Verbesserungen in einer solchen Zeitspanne möglich sind. Daher untertreibe ich hier lieber.
Welche Maßnahmen haben die größte Wirkung erzielt?
Ich kann nicht explizit messen, welche der Maßnahmen welche Wirkung hatte, da sie größtenteils parallel liefen, aber nach Reflexion und Rücksprache mit den Mitarbeitern vor Ort halte ich folgende Maßnahmen für die wirkungsvollsten.
Wir haben in einem sehr schnellem Tempo Scrum als Framework eingeführt und an unsere Bedürfnisse angepasst. Dabei haben wir diverse bestehende Meetings umstrukturiert und dadurch Freiräume für fokussiertes Arbeiten geschaffen. Ebenfalls haben wir Verantwortungen explizit und Arbeit transparent gemacht und dadurch z.B. diverse Schattenarbeiten (Support) sichtbar gemacht. Es gibt jetzt Prozess bei dem Supportanfragen über den Product Owner in das Backlog priorisiert werden, wodurch Entwickler fokussierter arbeiten können.
Wir haben durch Trainings zum Thema Definition of Ready klare Standards in den Anforderungen geschaffen, wodurch Anforderungen schneller und mit weniger Missverständnissen umgesetzt werden können. Die Entwicklung ist sicherlich auch mit Vorsicht zu genießen, da Vorgänge inzwischen zum Teil vielleicht auch kleiner geschnitten werden. Für diese braucht es daher weniger Zeit in der Umsetzung. Da die Zeit, die ein Vorgang für die reine Entwicklung braucht, sich vergleichsweiße geringfügig (20 - 30 %) verbessert hat halte ich diesen Effekt für vernachlässigbar.
Wir haben in einem sehr schnellem Tempo Scrum als Framework eingeführt und an unsere Bedürfnisse angepasst. Dabei haben wir diverse bestehende Meetings umstrukturiert und dadurch Freiräume für fokussiertes Arbeiten geschaffen. Ebenfalls haben wir Verantwortungen explizit und Arbeit transparent gemacht und dadurch z.B. diverse Schattenarbeiten (Support) sichtbar gemacht und durch einen Prozess über den Product Owner in das Backlog priorisiert, wodurch Entwickler inzwischen fokussierter arbeiten können.
Wir haben in diesem Zusammenhang auch kontinuierliches, tägliches Refinement mit dem Team eingeführt, wodurch Anforderungen insgesamt effektiver und schneller im Team entwickelt werden.
Durch regelmäßige Retrospektiven konnten wir wichtige Verbesserungen erzielen und ein Bewusstsein für Workflow und Zykluszeit im Team schaffen. Durch die Einführung von WIP-Limits wurde der Fokus der Entwickler und Product Owner durch weniger Kontextwechsel erhöht.
 |
| Entwicklung über die Zeit inklusive Rückschläge |
Wir haben regelmäßig Workshops durchgeführt, in denen die agile Reife des Teams gefördert wurde und dort ebenfalls Transparenz über den aktuellen Stand der Messgrößen geschaffen. Zusätzlich haben wir regelmäßiges Inspect & Adapt durchgeführt, um "Rückschläge" zu verstehen und daraus zu lernen und die Lernerfolge in den Teams zu teilen. z.B. mussten wir unser Produktziel im dritten Sprint verwerfen und uns auf ein anderes Ziel fokussieren - da die Stories für dieses Ziel bereits lange im Backlog angelegt waren, stieg die durchschnittliche Zykluszeit zwischenzeitlich wieder an. Dies ist ein weiterer positiver Nebeneffekt von Scrum: Fragen nach dem Produktziel werden regelmäßig gestellt und damit kann ein Kurs auch zu Gunsten wertvoller Produzktziele korrigiert werden.
Wir haben Mikromanagment schon fast ausgemerzt und es durch das Pull-Prinzip ersetzt: Zu Beginn war es üblich Entwickler Vorgangsgenau und langfristig über individuelle Roadmaps möglichst gut einzuplanen. Heute vertrauen wir auf einen Pull-Mechanismus und planen ca. ein bis zwei Sprints voraus. Hierdurch wurde auch viel Kapazität für Test und Anforderungsentwicklung frei, wodurch wir wiederum schneller geworden sind.
Mittels Kanban bzw. Flussanalyse wurde regelmäßig analysiert, in welchen Status Engstellen entstehen und wie sie behoben werden können. Zum Beispiel hatten wir erst eine Phase, in der Code Reviews drei bis vier Tagen gedauert haben. Nachdem wir hier durch verbesserte Kommunikation in den Teams ca. 0,5 Tage erreicht haben, kamen als nächste die Product Owner ins Visier. Denn diese brauchten für eine ähnliche Tätigkeit – den Test der Vorgänge - noch 2,5 Tage (und heute ca. einen Tag). Wichtig ist es solche Detailanalysen durchzuführen und dann mit den gemeinsamen Teams direkt ihre Kommunikationsmuster anzupassen. (Status sind Gutscheine für Kommunikation)
Und das war alles? Ich weiß es nicht, aber beim nächsten Kunden würde ich hiermit unter ähnlichen Rahmenbedingungen wieder beginnen. Der Erfolg der Maßnahmen hängt stark von den Ausgangsbedingungen ab.
Wie wir bezüglich Schnelligkeit weiter machen
Weitere Engpässe (z.B. Test, Anforderungsanalyse) haben wir bereits identifiziert und werden diese zeitnah beheben. Ich gehe davon aus, dass die folgenden Konzepte auch hier der Schlüssel zum Erfolg sein werden: WIP-Limit, explizites Verständnis und Anpassung des Workflows, Vereinbarung von Service Level Erwartungen und Retrospektiven.
Darüber hinaus werde ich mich anschließend auf die Varianz der Größe konzentrieren. Hier haben wir zwei Hindernisse identifiziert:
Stark unterschiedliche Größen der Vorgänge: Die Größe der Vorgänge variiert immer noch stark. Hier wollen wir mittels agile Estimation via Referenzstories, und klaren Regeln für Story Splitting ansetzen. Das Thema ist relevant, da sich mit einer kleineren Standardabweichung auch eine bessere Planbarkeit ergibt. Wir gehen davon aus, dass dies in unserem Umfeld zu glücklichen Kunden und Mitarbeitern führen wird. Wir stellen in diesem Zusammenhang auch fest, dass wir generell bei der Erarbeitung komplexer Themen methodisch noch viel besser werden können.
Waste im Prozess (Weitere Optimierung des Workflows notwendig): Über Analyse der Ausreißer wird schnell deutlich, dass zwar der Trend stimmt, aber immer noch fragwürdige individuelle Prozesse vorkommen. Die Antwort ist hier nochmal im Team das explizite Verständnis des Workflows zu fördern und hier insbesondere die Übergabepunkte und die Verwendung der Status noch einmal zu überarbeiten – ein paar Beispiele:
- Ein Vorgang lag 6w 3t 17h 29m in Blocked
- Ein Vorgang wurde 2w 4t 17h 37m entwickelt und dann in 26m wurde ein Review durchgeführt
- Ein Vorgang lag 7w 5t 56m in „Bereit zur Entwicklung“
Zur Klarstellung: Es kann natürlich immer sein, dass genau diese Fälle auch der Realität entsprechen und es einen Kontext gibt, in dem die Entwicklung hier wirklich gut gelaufen ist. Aber Beispiele wie die oben genannten sind für euch als Coach immer ein guter Ausgangspunkt, um im Detail zu verstehen, ob hier eine Verbesserung möglich ist. So lernen die Beteiligten direkt in der Kleingruppe, wie sie bei einem ähnlichen Entwicklungsprozess in Zukunft besser vorgehen können. Übrigens ist die Analyse der Ausreißer nach unten oft genauso spannend.
Auswirkung auf den Output
Der eine oder andere Manager wird sich fragen: Ok ihr habt eine niedrigere durchschnittliche Durchlaufzeit aber hat sich euer monatlicher Output (Anzahl der Vorgänge) gesteigert?
Die Tabelle zeigt die abgeschlossenen Vorgänge pro Monat für alle drei Produktentwicklungsteams. Der Trend sieht aktuell vielversprechend aus – bei einem „nachhaltigem Entwicklungstempo“ sind wir sicherlich noch nicht.
 |
| Entwicklung des Outputs |
Der Forecast wurde linear auf den Ultimo im Februar hochgerechnet. Bemerkenswert ist die Zahl, da zeitgleich auch einige umfangreiche Workshops (Zusatzaufwände) stattgefunden haben.
Anmerkung: Diese Zahlen sind mit Vorsicht zu genießen. Steigerungen können auch immer mit einem anderen Umgang z.B. von Sizing oder durch „Sichtbarmachen“ von Schattenprozessen beeinflusst werden. Eine Detailanalyse ergibt, dass die reine Entwicklungszeit – also die Zeit, in der die Vorgänge in Entwicklung sind, sich leicht (ca. 20 %) verbessert hat. Daher glaube ich, dass wir diesen Effekt noch vernachlässigen können. Auch die sichtbar gemachte Schattenarbeit hat einen Einfluss auf den Output, kann hier aber ebenfalls vernachlässigt werden.
Auswirkung auf den Outcome
Schnelligkeit darf nie das einzige Ziel sein. Ja, wir machen offensichtlich gute Fortschritte in der Entwicklung. Aber unser Produkt ist noch nicht produktiv auf dem Markt und liefert daher keinen Wert für unseren Kunden.
 |
| Entwicklung des Outcome |
Grund dafür ist unser aktuelles Produktziel - ein vertragliches Abnahmeziel mit dem Kunden, bei dem die Software erst nach einer bestimmten Menge an Features live geht. („Agiler Wasserfall“) Wir sind derzeit sehr optimistisch, dass wir dieses Ziel in den nächsten Sprints erreichen werden. Drückt uns die Daumen!
Ganz fair ist diese harte Bewertung nicht - eines unserer Teams schafft technische Grundlagen für die anderen Teams und beseitigt technische Schulden - das entspricht ganz unserer Definition von Wert. Live sind wir trotzdem noch nicht.
Wie geht es jetzt bei euch im Unternehmen weiter?
Wenn du dir jetzt die Frage stellst, ob diese Ideen in jedem Unternehmen funktionieren, empfehle ich mit einer einfacheren Frage zu beginnen: Kann es bei euch funktionieren? Was hält dich davon ab es in deinem Unternehmen auszuprobieren? Wie es weiter geht, liegt vor allem an euch. 😊
Ihr wollt schneller werden oder interessiert euch für eines der genannten Themen? Kontaktiert mich gerne. Ab März ist ein zweiter agile Gardener in meinem Team, der euch dabei auch konkret helfen kann. Kommt bei Fragen gerne auf uns zu.
Viel Spaß dabei & Let's grow,
Agile Gardener Michael
www.agilegardeners.de
Kommentare
Kommentar veröffentlichen