AIP Board mit Stories - wie agile Transformation gelingen kann

Wie agile Transformation gelingen kann.

Agile Projekte sind weit verbreitet und besonders Scrum ist in vielen Unternehmen im Einsatz. Dennoch ist ein gewisses Maß an Skepsis omnipräsent. Fast jeder hat eine Anekdote wie und warum Scrum, ein agiles Projekt oder die agile Transformation nicht funktioniert. Wir berichten daher gerne aus den eigenen Erfahrung, wie ein agiles Vorgehen bei uns selber gelingt.

Gute Gründe, warum es nicht klappt.

Als Scrum Master und Product Owner begegnen wir verschiedenen Gründen, die ein agiles Vorgehen wie z.B. Scrum behindern und uns vor Herausforderungen stellen. Drei wichtige Aspekte wollen wir in diesem Artikel näher beleuchten:

  1. Unternehmenskultur passt nicht zu den agilen Werten.
  2. Linienaufgaben passen nicht zur „reinen Lehre“.
  3. „Wasserfall-Einführung“ der Agilität.

Die Kultur und damit die Werte sind das Fundament auf dem ein Unternehmen gebaut ist. Wenn stundengenaue-Excel-Planung und individuelle Zielvereinbarungen das Vertrauen der Führungskräfte in ihre Mitarbeiter widerspiegeln, werden Rituale und agiles Mindset des Projektteams zum belächelten Parallel-Universum.

In Scrum-Schulungen lernen wir, dass sich ein gut funktionierendes Team komplett auf Projektaufgaben konzentrieren kann. Meistens sind Linientätigkeiten, die parallel zum Projekt erfolgen, tägliche Realität. Die geplante Zeit für das Projekt wird spätestens dann knapp, wenn das gesamte Team 90 Minuten auf eine Retro „verschwendet“.

Agiles arbeiten als Wasserfall-Projekt einführen klingt komisch – ist aber so. Von „ganz oben“ wird SAFe®, SCRUM oder KANBAN als neues Vorgehensmodell ausgerufen. Benefits wie schnellerer ROI, reduziertes Risiko und höhere Qualität sind in greifbarer Nähe. Aber zunächst wird die neue Organisation über Monate und Jahre ins letzte Detail konzipiert anstatt sie agil zu verproben. Das Ergebnis: Große Erwartungshaltung, schnelle Ernüchterung und fehlende Glaubwürdigkeit.

Potentiale abrufen.

Als Applied Innovation Partner investieren wir stark in neue Themen. Das Versprechen eines schnelleren ROI und einer verlässlichen Qualität ist für uns daher sehr attraktiv. Daher haben wir uns entschieden, das zu machen, was wir empfehlen – den Innovationsprozess agil zu gestalten.

AIP Team Planning 2 - Aufgaben zu Stories werden abgeleitet

Unser Ansatz dabei:

  • Nordstern vor Augen haben.
  • Ehrlich sagen: Dafür habe ich keine Zeit.
  • Knallhart fragen: Macht das Sinn, oder kann das weg?

 

Werte bieten eine Orientierung – wenn es die Eigenen sind.

Für uns war es wichtig zu definieren, wer wir als Company sein wollen. Daher haben wir für uns intern, und für das was wir auf dem Markt anbieten wollen, ein gemeinschaftliches Zielbild entwickelt. Wir nennen dies unseren Nordstern.

Gerade als Beratungsunternehmen wäre es für uns verlockend sich darauf zu konzentrieren was uns kurzfristig Geld einbringt. Damit wäre der entscheidende Fokus auf die Evolution der AIP vertan. Die kontinuierliche Weiterentwicklung ist aber das, was es uns ermöglicht unseren Kunden die Qualität und Innovationsimpulse zu bieten, die sie von uns gewohnt sind.

Mit unserem Nordstern, verfügen alle über einen Kompass, der es im Tagesgeschäft ermöglicht, die Orientierung zu behalten und sicherstellt, dass wir an den Dingen arbeiten, die langfristig wichtig sind. Und von der Aushilfe bis zum Geschäftsführer arbeiten wir auf das gleiche Ziel hin.

Seien wir mal ehrlich: Zeit ist immer knapp.

Linientätigkeiten, die parallel zu Innovationsthemen laufen, gibt es bei uns im Überfluss. Über 60% unserer Arbeitszeit sind wir im Kundeneinsatz.

Wir lösen das Problem, indem wir in unserem Planning alle vier Wochen offen kommunizieren und festhalten:

  • Wie viel Zeit hatte jeder für die Arbeit an den Zielen des letzten Sprints eingeplant?
  • Wie viel Zeit wurde tatsächlich investiert?
  • Wie viel Zeit kann man für den nächsten Zyklus zusagen?

Diese 10-minütige Methode hilft uns mit einer realistischen Kapazitätsplanung in die Auswahl der Themen für den nächsten Sprint einzusteigen.

Wir ermitteln unsere Velocity aus dem Verhältnis der abgearbeiteten Story-Points und der tatsächlich eingesetzten Kapazitäten. Multipliziert mit den Plan-Kapazitäten wissen wir, wie viele Story Points wir in den nächsten Zyklus mitnehmen können.

Work in Progress.

Bei der Umstellung auf ein agiles Vorgehen war uns klar: die Veränderung der Organisation kann aufwändig und riskant sein. Als mittelständiges Unternehmen versuchen wir dieses Risiko zu managen.

Daher haben wir uns entschieden mit Scrum in einer MVP-Version (Board und Weekly) zu starten. Seitdem entwickeln wir unseren agilen Ansatz kontinuierlich weiter.

Das Scrum-MVP bestand aus den generellen Meetings und unserer „Themen“ an einem Board. Nach und nach haben wir mithilfe von Feedback innerhalb der Retros

  • Rollen und Aufgaben,
  • Werkzeuge und Meetings,
  • unsere Inhalte

angepasst und erweitert.

Ein großer Vorteil des agilen Vorgehens: Das Systems wächst an konkreten Bedarfen. Die logische Konsequenz ist eine hohe Akzeptanz der Veränderungen.

Rollen und Aufgaben.

Durch den Ansatz von „inspect and adapt“ formen wir den Prozess nach unseren Bedürfnissen. So wurden beispielsweise

  • trotz drei Geschäftsführer ein Product-Owner etabliert,
  • seine Rolle geschärft und
  • die Aufgaben des Scrum Masters verändert und auf Personen aufgeteilt.

Werkzeuge und Meetings.

Unser rudimentäres Board ist mit unseren Ansprüchen an die zu visualisierenden Dinge gewachsen. Mittlerweile hat es durch unsere Erfahrungen inzwischen einen guten Reifegrad erreicht.

Beim Sprint-Planning setzen wir nach einem anfänglichen kreativen Chaos inzwischen mehr auf eine stärkere Formalisierung. 

Ein Daily hat sich bei unserer Auslastung als nicht zielführend erwiesen. Stattdessen treffen wir uns verbindlich in einem Weekly, In dem sich Remote-Kollegen aktiv einbinden.

Die Art wie wir unsere Ergebnisse im Sprintreview evaluieren, variiert. Mit dem „Fishbowl“, TRIZ, 1-2-4-All, u.v.m. haben Techniken aus Liberating Structures Einzug in Sprint Reviews und Retros gefunden. Aber auch hier wird geschaut: Welches Werkzeug kann ich für welches „Problem“ sinnvoll einsetzen?

Eine entscheidende Rolle hat bei uns die Retrospektive eingenommen. Ein Meeting, dass im Projektalltag oft vernachlässigt wird (und auch bei uns zu Beginn wurde), ist professionell aufgezogen vom „schon wieder eine Stunde weg“ zum „wahrscheinlich wertvollsten Meeting des letzten Jahres“ mutiert.

Machen wir die richtigen Dinge?

Gerade in einem komplexen Umfeld ist die wichtigste Frage für uns: Wie priorisieren wir unsere Arbeit richtig? Unser Ansatz ist es knallhart nach ROI zu kalkulieren. Stories und Epics werden in ihrem Business Value von den Geschäftsführern bewertet. Im Anschluss erfolgt die Bewertung der Komplexität als Proxy für Aufwand durch das Team. Damit ermitteln wir einen Quotienten, der unser Backlog an Themen ordnet.

Wichtig: die Bewertung erfolgt immer wieder. Neue Erkenntnisse und veränderte Rahmenbedingungen führen dazu, dass sich früher geschätzte Werte verändern. Das hilft uns auf Veränderungen schnell und zielgerichtet zu reagieren.

Ein Gerüst, an dem unsere Firma wachsen kann.

Ob wir neue Vergütungsmodelle für den Omni-Channel-Vertrieb entwerfen oder unsere eigene Reisekostenabrechnung optimieren – mit der AIP-Agile-Adaption stellen wir sicher, dass wir Projekte und Ergebnisse realisieren, die uns weiterbringen und an denen das gesamte Team teilhaben kann.

Wenn wir uns in diesem Framework regelmäßig fragen

  • „Welches Problem wollen wir gerade lösen?“ und
  • „Macht es Sinn wie wir es gerade tun?“

sind wir gespannt, wie sich unser Ansatz noch verbessern lässt. 

Auf jeden Fall bietet uns dieses Framework das Gerüst an dem unsere Firma wachsen kann.

 

AIP Product Owner schreibt Business Value auf Stories während Magic Estimation.

Jan Witlatschil
jw@aip.consulting
+49 171 283 29 88