Höhepunkte der Lean Kanban Central Europe 2019 (LKCE19)

Die weltgrößte Kanban-Konferenz habe ich diesmal als rasender Reporter begleitet (Alt-Deutsch für Live-Blogger).

Die zweitägige Konferenz war eine bunte Mischung aus Vorträgen und Fallstudien mit vielen bekannten Gesichtern aus der Kanban-Gemeinschaft.

Neben den derzeit angesagten und vielfach repetierten Modellen wie Kanban Maturity Model (KMM) oder Fit for Purpose gab es ein paar interessante Glanzlichter, die ich hier näher beleuchten möchte.

Agiles Portfolio als Marktplatz

In der Marktwirtschaft regeln Angebot und Nachfrage die Preisgestaltung. Was wäre, wenn wir auch innerhalb von Unternehmen den Start neuer Produkte und Projekte von Angebot und Nachfrage regeln lassen?

Patrick Steyaert stellte ein Modell vor, das die Projektpriorisierung über Marktmechanismen löst: Interne Kunden bieten um Lieferanten, die umgekehrt versuchen das besten Angebot zu kriegen.

Auf einem Kanban Board kann das dann wie folgt aussehen:

Upstream fragen interne Kunden sogenannte Tokens an (z.B. Entwickler mit bestimmten Fähigkeiten). Downstream werden Tokens bereitgestellt. Sind alle Tokens für eine Anfrage vorhanden, kann ein Projekt gestartet werden. Gibt es mehrere Möglichkeiten, wählen Kunden die günstigste und Lieferanten die lukrativste.

Möglicherweise ist es sinnvoll eine Weile zu warten, um ein besseres Matching zu erreichen. Steayart sagt, dass hier die Liquidität ein Anzeichen für Agilität ist: Je dringender man Geld braucht, um so unflexibler wird man im Matching Prozess, weil Lieferanten das erstbeste unterbezahlte Projekt nehmen müssen oder Kunden mit dem Preis hochgehen müssen, weil sie nicht länger warten können.

Motivation durch Kanban

Intrinsisch motiviert für eine Tätigkeit sind wir nur dann, wenn uns die Tätigkeit selbst Spaß macht. Wenn wir durch Anreize von Außen motiviert wurden, ist diese Motivation extrinsisch.

Maren Baermann zeigte in ihrer Präsentation, dass der Übergang von extrinsisch nach intrinsisch durchaus fließend sein kann. Dieselbe Tätigkeit kann je nach Kontext mehr oder weniger intrinsisch erfüllend sein, beispielsweise die Tätigkeit einer Reinigungskraft in einem Büro oder einer Kinderklinik.

Es gibt Möglichkeiten den intrinsischen Aspekt von Motivation zu stimulieren, in dem man eine Arbeitsumgebung schafft, welche die psychologischen Basisbedürfnisse Autonomie, Kompetenz und soziale Beziehungen fördert. 

Richtig angewandt kann Kanban diese drei Bedürfnisse adressieren. So erlaubt z.B. die Visualisierung des Status Quo auf Kanban Boards, dass kompetente und autonome Entscheidungen getroffen werden können. Gemeinsame Diskussionen und Retrospektiven erhöhen die sozialen Beziehungen.

Live Streaming

Die Kanban User Group Hamburg hat einen Live-Stream von der Konferenz aufgenommen. Alexander, Per und Urs haben zahlreiche Interviews geführt, die man auch nachträglich abrufen kann, um die Konferenz nochmal Revue passieren zu lassen:

• Tag 1: LINK
• Tag 2: LINK

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Nordstern Board – True North visualisieren

Schon die Wikinger haben den Polarstern zur Navigation genutzt. Agile Teams können das jetzt auch ;-).

Nordsterne helfen selbst-organisierten Teams ihre Fähigkeiten im Sinne der Organisation zu verbessern. Im Gegensatz zu klassischen Unternehmenszielen wie „Steigerung des Umsatzes um 20%“ oder „Verdopplung der Page Impressions“ fokussieren Nordsterne auf die Fähigkeiten der Organisation bzw. deren Mitarbeitern und Teams. Beispiele für Nordsterne aus der Praxis:

• Jede Tätigkeit ist wertschöpfend
• Jeder macht Vertrieb
• Zero Bugs
• Alle Teams sind vollständig autonom

Wie man schnell erkennt, sind Nordsterne in der Regel nicht erreichbar. Aber sie geben eine Richtung vor, mit der Mitarbeiter das eigene Handeln verändern können. Orientiert sich ein Team z.B. am Nordstern „Jede Tätigkeit ist wertschöpfend“ und stellt in der Retrospektive fest, dass sehr viel Zeit im letzten Sprint durch wiederkehrende manuelle Schritte beim Deployment verschwendet wurden, könnte eine Maßnahme für den nächsten Sprint sein, diese Schritte zu automatisieren. Solche konkreten Maßnahmen nennt man Target Conditions. Sie sollen nach wenigen Wochen, z.B. nach einem Sprint erreicht werden und überprüfbar sein.

Bei Tchibo haben wir im Rahmen eines Pilot-Teams Nordsterne eingeführt und dafür neben unserem Kanban-Board ein eigenes Nordstern-Board erarbeitet.

Norstern Board

Ziel dieses Boards ist es, nicht nur die Team-bezogenen vier Nordsterne dauerhaft transparent gegenüber Teammitgliedern und Stakeholdern zu machen und für den nötigen Fokus darauf zu sorgen, sondern auch den Fortschritt im Sinne eines Information Radiators zu verdeutlichen.

Der Aufbau des Boards folgt einer einfachen Tabelle, bei dem jede Zeile für einen der vier Nordsterne des Teams steht; damit folgt das Prinzip einer Swimlane-Logik und wird zusätzlich durch eine Farb-Codierung unterstützt, denn jeder Nordstern hat seine eigene Farbe. Die Spalten der Tabelle auf dem Board folgen einer Ableitung der Demig-Kreis Phasen „Plan-Do-Check-Act“:

• Plan: Die Plan-Spalte beinhaltet jeweils eine oder mehrere Target Conditions, die sich das Team in zweiwöchigen Iterationen passend zum Nordstern selbst-organisiert ableitet.
• Do: Die Target Conditions werden in die Do-Spalte gezogen, sobald die Arbeit an der Maßnahme beginnt. In einigen Fällen entstehen aus einer Target Condition auch zusätzliche kleinere Tasks, die ebenfalls in der Spalte sichtbar gemacht werden können.
• Check: Am Ende jeder Iteration findet als Teil der Reflexion eine Überprüfung hinsichtlich der Erreichung der Target Conditions durch das Team statt. In Abhängigkeit der Ergebnisse werden in dieser agilen Zeremonie dann auch gleich die Target Conditions für die nächste Iteration festgelegt (Act).
• Progression: Anstatt einer Spalte „Act“ hat sich das Team für eine ergänzende Spalte „Progression“ entschieden. Anhand von gemeinsam im Team verabschiedeten Metriken zur Messung, wird der Fortschritt in Richtung der Nordsterne transparent, fördert Commitment und Zusammenarbeit.
  Als zusätzliche Information werden auf dem Board der übergeordnete Arbeitsauftrag des Teams sowie die Erreichungsgrad der Target Conditions über alle Iterationen hinweg dargestellt.

Fazit:

Für das Team hat sich das zusätzliche Board als hilfreiches Tool zur konsequenten Navigation gen Nordsterne gut etabliert. Regelmäßig sind wir am Board folgende Fragen durchgegangen:

• Was haben wir zuletzt erreicht?
• Was wollen wir als nächstes erreichen?
• Stehen unsere Maßnahmen immer im Fokus unseres übergeordneten Arbeitsauftrages?

Durch die physische Visualisierung und die ritualisierte Auseinandersetzung des Teams mit den Fragen finden agile Werte wie z.B. Transparenz, Kollaboration, Workflow, Verbesserung und Vereinbarung praktischen Einzug bei Tchibo.

Theda Howaldt ist Agile Coach bei Tchibo

 

 

 

 

Holger Tewis ist Agile Enterprise Coach (Freiberufler)

Struktur eines agilen Transitionsteams

Die Durchführung einer größeren organisatorischen Veränderung kann von einem Transitionsteam begleitet werden, das die Transition vorantreibt und für eine Umgebung sorgt, die im Sinne der Transition erwünschte Muster verstärkt. Im Zuge der agilen Transition der Web Development Abteilung bei Goodgame Studios durchlief unser Transitionsteam verschiedene Organisations-Formen, über die ich hier berichten möchte.

Ende 2014 hat sich Goodgame Studios (im Folgenden GGS) entschieden die Software-Entwicklung im zentralen Bereich Web Development auf agile Vorgehensweise umzustellen (Scrum/Kanban). Mit dem Mandat des CTO haben wir dazu von Anfang an ein Team etabliert, das diesen Prozess begleiten und vorantreiben sollte.

Um gleichzeitig als Vorbild zu dienen, haben wir uns entschlossen dieses Transitionsteam auf agile Art zu organisieren und uns am Scrum-Framework orientiert. Als Produkt des Transitionsteams betrachteten wir die vollständig agilisierte Abteilung, auf die wir uns in wertschaffenden Sprintinkrementen zubewegen wollten. Zu besetzen waren nun die drei Rollen Scrum Master (bzw. Agile Coach), Product Owner und Team. Product Owner wurde der Abteilungsleiter, Scrum Master eine erfahrene externe Coachess und das „Dev“-Team setzte sich zusammen aus Führungskräften und Vertretern der einzelnen Positionen (Projekt Manager, Produkt Manager, Entwickler).

Wir begannen mit einer Sprintlänge von zwei Wochen, wobei wir Sprintplanung, Review und Retro komplett am Mittwochnachmittag durchführten. Standups gab es zwei die Woche, am Dienstag und Donnerstag. Transitions-Backlog und Sprint-Backlog haben wir nicht als physisches Board aufgesetzt, sondern in Jira, vor allem um den auf dem GGS-Gelände weit verteilten Entwicklungsteams einfachen und transparenten Zugriff zu gewährleisten.

Nachdem wir dies circa ein halbes Jahr ausprobiert hatten, stießen wir auf eine Reihe von Problemen:

• Das Transitionsteam konnte nicht alle Entwicklungsteams gleichzeitig adressieren, so dass sich manche Teams vernachlässigt fühlten, insbesondere da wir öffentlich versprochen hatten, dass das Transitionsteam für die ganze Abteilung da sein würde.
• Parallel zum Transitionsteam trafen sich wöchentlich die Teamleads des Bereichs und verfolgten eine eigene Agenda, die zum Teil im Widerstreit mit den Zielen des Transitionsteams stand. Obwohl in beiden Teams der Abteilungsleiter als Product Owner fungierte, gab es immer wieder Alignment-Schwierigkeiten zwischen den beiden Führungsteams.

In Summe gab es Entwicklungsteams, die gar nicht adressiert wurden und dann wiederum solche, die von beiden Führungsteams mit z.T. widersprüchlichen Zielen angesprochen wurden.

Um dieses Problem zu lösen, schwenkten wir um auf das von uns sogenannte Flower-Modell:

Dazu ordneten wir die ganze Abteilung in drei Cluster, aus denen Product Owner (PO), Teamlead (TL) und Agile Coaches (AC) der Entwicklungsteams ein für ihren Cluster verantwortliches Transitionsteam bildeten (POTLAC). Das alte Transitionsteam, verwandelte sich in eine Art Product Owner Team und entsandte Delegierte als Transitions-Product Owner in die drei POTLACS. Die Treffen der Teamleads wurden abgeschafft.

Die POTLACS führten 4-Wochen-Sprints durch, jeweils um eine Woche versetzt, so dass sich das Transitions-Product-Owner-Team in der 4. Woche mit Koordinationsthemen beschäftigen konnte.

Mit dem Flower-Modell schafften wir es tatsächlich, näher an die Teams heranzurücken. Nur die 4-wöchigen Sprints fühlten sich zu lang an. Dieses Problem lösten die Teams unterschiedlich: Einer der Cluster entschloss sich auf Kanban umzustellen. Statt längerer Scrum-Meetings alle 4 Wochen führte dieses Team tägliche Standups durch, zu denen der Product Owner bei Bedarf dazustieß und im Anschluss Stories priorisieren bzw. abnehmen konnte. Der freigewordene Meeting-Slot am Mittwoch ermöglichte den anderen beiden POTLACS auf 2-Wochen-Sprints zu wechseln.

Retrospektiv betrachtet lag die größte Herausforderung beim Aufsetzen der Struktur des Transitionsteams darin, ein für die Größe der zu agilisierenden Abteilung angemessenes Alignment zu finden. Das Spannungsfeld sah dabei ähnlich aus wie Henrik Knibergs Autonomy/Alignment Matrix:

Das Management strebte Quadrant A an, also hohes Alignment bei hoher Autonomie der Teams. Im Laufe der Zeit wurde aber immer wieder darum gerungen, was das bedeutete.

Für einige Teams sah es so aus, als wäre man zu weit in Quadrant B gerutscht, da die Arbeit mit dem Transitionsteam zusätzlichen Aufwand erzeugte, der als Overhead oder gar Micro-Management wahrgenommen wurde. Neben den Transitions-Meetings waren dies vor allem vorgeschlagene Standards (z.B. ein einheitliches Format für Roadmaps), für die manche Teams keinen direkten Mehrwert zu bekommen glaubten.

Aus Perspektive des Managements sah es gerade am Anfang so aus, als rutschten die Teams zu stark in den Quadranten C, zum einen weil sie unterschiedliche Schwerpunkte bei der Agilisierung setzten, zum anderen weil manche Teams in der ursprünglichen Aufstellung des Transitionsteams unter dem Radar flogen.

Lean/Kanban Games – Teil 2

Neben dem Push & Pull Game hat die Limited WIP Society Hamburg einige weitere Lean/Kanban Games gespielt, darunter das Name Game, das die Nachteile von Multitasking und Context Switches sichtbar macht:

Hier nur das Executive Summary:

1. Schreibe 5 Namen auf, alle gleichzeitig, d.h. erst alle ersten Buchstaben, dann alle zweiten usw. Miss wie lange es pro Name dauert und die Gesamtzeit.
2. Dann schreibe die 5 Namen nacheinander und miss wieder die Zeit.
3. Vergleiche die Ergebnisse und diskutiere

Ein ausführliche Beschreibung gibt es z.B. hier: LINK

Das Sixes Game soll die Auswirkungen von übertriebenen Sicherheitspuffern in Schätzungen von Projekten sichtbar machen. Auch dieses Spiel skizziere ich hier nur grob. Es gibt ein ausführliches Paper dazu: LINK

Jeder Teilnehmer übernimmt ein Teilprojekt, dessen Dauer davon abhängt, wann er mit einem 6-seitigen Würfel eine 6 würfelt. Für jeden Wurf dauert das Projekt einen Tag. In einem Testprojekt lässt der Moderator alle ein paar Mal würfeln, um ein Gefühl für die Wahrscheinlichkeiten zu kriegen.

Dann geht es los. Ein wichtiges Projekt für den besten Kunden steht an und die Spieler sollen sich auf eine Anzahl Tage einigen, die jedes Teilprojekt maximal dauert (MAX TAGE). Die dem Kunden kommunizierte Gesamtdauer beträgt dann:

PROJEKT GESAMTDAUER = ANZAHL TEILPROJEKTE * MAX TAGE

In dieser Runde dauert jedes Teilprojekt also mindestens MAX TAGE. Wenn nur ein Teilprojekt länger braucht, verlängert sich auch die Gesamtdauer.

In der Diskussion danach sollte die Gruppe feststellen, dass viele Spieler wesentlich früher fertig sind und Zeit geblockt haben, die sie eigentlich nicht brauchen. Die Frage ist, wie man die Projekte organisiert, damit einerseits genügend Puffer da ist, aber andererseits zuviel Pufferzeit nicht die Gesamtdauer übertrieben aufbläst.

Eine Lösung des Problems, mit 25% kürzerer Projektdauer bei 95% Erfolgswahrscheinlichkeit, kommt aus der Theory of Constraints: Die geschätzten Sicherheitspuffer werden für jedes Teilprojekt halbiert und die Hälfte der gestrichenen Summe für länger laufende Teilprojekte am Ende des Gesamtprojekts hinzugefügt. Wenn also die Schätzung mit Sicherheitspuffer für 10 Teilprojekte bei 16 Tagen liegt, gibt man den Projekten nur 8 Tage und fügt dafür am Ende (10*8)/2=40 Tage als Puffer für Teilprojekte im Verzug hinzu.

Die statistischen Hintergründe dazu findet man in dem genannten Paper.

Bei der Durchführung mit der Limited WIP Society, haben wir natürlich auch dieses 95% sichere Projekt gerissen – Murphy lässt grüßen ;-).

Push & Pull Game – Lean/Kanban Games Teil 1

Hafenblick, kühle Getränke, schöne Menschen – die limited WIP Society traf sich diesmal bei IT-Agile.

Das Thema waren Lean/Kanban Games und die möglichen Spiele füllten schnell das Board. Da die Beschreibung etwas länger geworden ist, teile ich sie in zwei Beiträge auf (Teil 2 HIER).

Papierboote falten als Push/Pull-Game 

Beim Push/Pull-Game geht es darum die Unterschiede von Push und Pull-Systemen sichtbar und fühlbar zu machen. Dabei übernimmt jeder Teilnehmer unterschiedliche Verarbeitungsschritte auf einer Art Fließband. Wir haben Papierboote gefaltet, aber beliebige Varianten sind denkbar (z.B. Cup Assembly).

Als Material braucht man:

• Einen großen Tisch
• einen großen Stapel weiße DINA4-Zettel
• ein paar gelbe DINA4-Zettel
• zwei Stoppuhren bzw. Smartphones mit Stoppfunktion

Wir waren 5 Spieler mit folgenden Schritten (bei mehr oder weniger Spielern, einfach die Schritte weiter aufteilen bzw. zusammenfassen):

1. Spieler: Papier vom Stapel nehmen, einmal in der Mitte falten und für den nächsten in der Mitte anfalzen
2. Beide Ecken umknicken, als würde man einen Flieger bauen wollen.
3. Unterkanten auf beiden Seiten nach oben klappen und die überstehende Ecke auf einer Seite nach innen umklappen, so dass ein Hut entsteht.
4. In den Hut greifen und zum Quadrat umklappen. Dann die unteren Ecken hochklappen und zum Schiff auseinanderziehen.
5. Der fünfte Spieler nummeriert die Boote und schreibt die Ankunftszeit auf. Achtung: Spieler 5 und der Moderator müssen zu Beginn synchron eine Stoppuhr starten.

Wem das zu wenig visuell ist, möge sich folgendes Video zu Gemüte führen:

Es lohnt sich übrigens, die Spieler einen Probelauf durchführen zu lassen, bevor es richtig losgeht!

Als erstes haben wir im Push-System gearbeitet, d.h. jeder Spieler hatte einen beliebig großen Puffer vor bzw. hinter sich. Nach wenigen Minuten hatten sich so zwischen einigen Spielern große Warteschlangen gebildet.

Nach 2:30 Minuten gibt der Moderator einen gelben Zettel in die Queue. Achtung: Wenn sich die Puffer sehr schnell füllen, lieber etwas früher den gelben Zettel hineingeben.

Ist der gelbe Zettel durch den Prozess durch, kann das Spiel gestoppt werden.

Am Ende sollte Spieler 5 eine Übersicht über die Ankunftszeiten erstellt haben:

In unserer Gruppe entwickelte sich der Durchsatz in Richtung 4 Schiffe pro Minute. Ich selbst war an Position 4 und hatte eine recht komplexe Aufgabe, so dass sich mit der vor mir anwachsenden Queue auch der gefühlte Druck erhöhte. Gerne gesehene Kommentare von den Spielern links und rechts waren: “Ach bei dem staut es sich ja wieder mal” oder “Den müssen wir auswechseln.” Sowas kommt in realen Projekten natürlich niemals vor ;-).

Als das Spiel gestoppt wurde hatten wir etwa ein Dutzend unfertige Schiffe als Waste in den Puffern liegen.

Dann haben wir die Pull-Variante gespielt. Hier ist der einzige Unterschied, dass jeder Spieler ein Pufferlimit von 1 hat, d.h. er darf erst mit dem nächsten Papier anfangen, wenn der auf ihn folgende Spieler seinen Zettel angenommen hat.

Nach kurzer Zeit wartete die gesamte Prozesskette darauf, dass ich mit meinem Schritt fertig wurde, was gefühlt noch schlimmer war, als nur die Queue anwachsen zu sehen.

Auch bei der Pull-Variante ging der Durchsatz auf ca. 4 Schiffe pro Minute zu.

Der Waste waren die 4 unfertigen Schiffe bei den vier Faltern.

Nun betrachteten wir die Durchlaufzeit anhand des gelben Schiffes in beiden Varianten. In der Push-Variante hatte das Schiff eine Durchlaufzeit von 1:53 Minuten, in der Pull-Variante nur 1:07, da es nicht in vollen Queues warten musste.

In der anschließenden Diskussion sprachen wir darüber, dass man im Pull-System die Slacktime natürlich statt für Nörgeleien dafür nutzen sollte den Teammitglieder zu helfen bzw. kreative Verbesserungsvorschläge zu erarbeiten, die den Engpass verringern.

Variante: einen zweiten gelben Zettel reingeben um zu zeigen, dass sich die Durchlaufzeit im Push-System mit der Zeit vergrößert.

Dank an Frank und Florian für Fotos und Ergänzungsvorschläge!

Das derzeit beste deutsche Kanban-Buch* wurde übrigens von Florian übersetzt.

Kurzbeschreibungen für Name Game und Sixes Game in Teil 2.