Direkt zum Hauptbereich

Dreimal so schnell!

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“ 
Bei einer durchschnittlichen Zeit von inzwischen ca. 13,6 Tagen – wirken diese extremen Ausreißer stark auf unseren Durchschnitt und die Varianz. 

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

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Selbstbewertungsfragen für den Alltag in Arbeitsgruppen aus Sicht von Mitarbeitenden

Welche Fragen können wir Mitarbeiter:innen stellen, um herauszufinden, ob agiles Arbeiten wirkt? Es gibt bereits eine Menge an Fragebögen. Aber ich bin nicht immer zufrieden damit.

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Microsoft Lists: mit Forms und Power Apps komfortabel mobil arbeiten

In meinem Kundenkreis sind viele Menschen, die den Arbeitsalltag nicht vorwiegend auf dem Bürostuhl sitzend verbringen, sondern "draußen" unterwegs sind. Vielleicht in Werkstätten oder im Facility-Management. Es ist so wichtig, dass die Schnittstellen zu den Abläufen im Büro gut abgestimmt sind. Microsoft 365 hat so einiges im Baukasten, man muss es nur finden und nutzen.  In diesem Artikel spiele ich ein Szenario durch, das auf Microsoft Lists, Forms und - für die Ambitionierteren - Power Apps setzt.

Wie Agilität den Kundennutzen steigert - Einige Argumente für Berater:innen

In Zeiten wirtschaftlicher Unsicherheit fragen sich viele, ob agile Beratung noch eine Zukunft hat. Die Antwort liegt in der konsequenten Orientierung am Kundennutzen. Qualität setzt sich durch, wenn sie messbare Verbesserungen bei Umsatz, Kosten und Leistungsfähigkeit bewirkt, anstatt sich in Methoden und zirkulären Fragen zu verlieren. Dieser Artikel zeigt, wie agile Beratung nachhaltige Veränderungen in Unternehmen schafft und warum gerade jetzt gute Berater:innen gebraucht werden, um Organisationen widerstandsfähiger zu machen.

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.

Warum eine Agile Transformation keine Reise ist

Die agile Transformation wird oft als eine Reise beschrieben. Doch dieser Vergleich kann viele Unternehmen in die Irre führen oder Bilder von unpassenden Vergleichen erzeugen. Transformationen sind keine linearen Prozesse mit einem klaren Ziel, sondern komplexe und dynamische Entwicklungen. Dieser Artikel zeigt, warum Agilität kein Weg mit einem festen Endpunkt ist.

Warum bringen Warum-Fragen so wenig?

Frust! Wieder gibt's am Ende des Meetings keine Lösungen, sondern nur Diskussionen darüber, wer was warum verbockt hat. Wieder geht nichts voran. Warum passiert uns das immer wieder? (Ha! Da ist sie wieder, die Warum-Frage.)