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

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

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.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.