Lean Coffee – der Koffeinkick für Ihre Meetings

Morgens, halb zehn in Deutschland. Ein freundlicher Blick von Kollegen, ein leckerer Cappuccino und eine quadratische Waffel mit Milchcreme, Schokolade und Haselnüssen. Großartig – ich bin dabei!
Morgens, halb zehn in Deutschland. Für die meisten in den Büros zwischen Flensburg und Füssen bedeutet dies eher Regelkommunikation, Statusmeeting oder Abstimmungstermin. Im besten Fall gibt es eine Agenda, die dem Termin eine Struktur geben soll – ziemlich fremdbestimmt, aber immerhin. Im schlimmsten Fall gibt es keine Agenda, die Teilnehmer kommen unvorbereitet und einige sind erst Minuten nachdem die Türe geschlossen wurde wirklich präsent.
Wenn das die Realität ist, warum dann nicht damit umgehen? Warum nicht den Meetings eine Struktur, eine Agenda geben in dem Moment, in dem sie gebraucht wird? Zu Beginn! Lean Coffee bietet dafür ein großartiges Format: Einfach, pragmatisch und effektiv. Morgens um halb zehn, nachmittags um vier, am späten Abend, am frühen Morgen und jederzeit dazwischen.

Was Sie für ein effektives Kaffeekränzchen brauchen

Für ein Meeting im Lean Coffee Format benötigen sie nur Post-its, Stifte und einige Teilnehmer. Zuerst werden drei Spalten auf den Tisch gelegt. Links „Themen“, in der Mitte „In Diskussion“ und rechts „Erledigt“. Schon steht die äußere Struktur. Wie das Ganze noch besser geht, kommt in einigen Zeilen.
Im zweiten Schritt erhalten die Anwesenden fünf Minuten Zeit, um ihre Themen, die bei diesem Termin besprochen werden sollen, niederzuschreiben. Nach Ablauf der fünf Minuten werden diese Themen in die Spalte „Themen“ gelegt und nach Inhalten geclustert. Anschließend wird abgestimmt. Jede Person erhält fünf Stimmen und vergibt diese als Punkte (engl. Dot-Vote) auf die Themencluster. Nun werden die Themen oder Themencluster entsprechend der Anzahl der Punkte von oben nach unten in der Spalte „Themen“ priorisiert.

Diskutieren in der Timebox

Das wichtigste Thema wird anschließend direkt in die Spalte „In Diskussion“ gezogen und besprochen. Um die Diskussionen kurz zu halten, werden feste Zeiträume verwendet. Die erste Runde dauert acht Minuten. Nach Ablauf der acht Minuten stoppt der Moderator die Diskussion und fragt, ob noch weitere Zeit benötigt wird. Die anwesenden Personen entscheiden per Mehrheitsentscheid – Daumen hoch oder Daumen runter (engl. Roman-Vote). Senkt die Mehrheit den Daumen, dann ist die Diskussion zu dem Thema beendet und das Post-It wandert in die Spalte „Erledigt“. Gehen die Daumen der Mehrheit nach oben, gibt es Zusatzminuten – nämlich vier. Nach den vier Minuten wird die Prozedur wiederholt und es werden noch zwei Minuten, eine Minute und… dann hoffe ich für Sie, dass die Diskussion ein Ende findet.
Die Unterbrechung der Diskussion nach Ablauf der Timebox ist der kritischste Moment beim Meeting im Lean Coffee Format. Respektieren Anwesende die Timebox nicht, sprechen weiter, möchten nur noch diesen einen letzten Aspekt einbringen, dann verliert das Format seine Kraft und seine Effektivität. Diese wenigen Sekunden Selbstdisziplin sind die neuralgischen Momente, in denen sich entscheidet, ob das Lean Coffee in ihrem Team ein Erfolg wird oder ob es wie bisher weitergeht.
Persönlich finde ich das Lean Coffee Format super! Richtig gut wird es, wenn noch zwei weitere Spalte hinzukommen: „Aha-Effekte“ und „Aufgaben“. Diese beiden Spalten werden mit etwas Abstand rechts von „Erledigt“ angefügt. In „Aha-Effekte“ kommen die neuen Erkenntnisse, die Geistesblitze und neuen Perspektiven, die sich während des Austauschs ergeben haben. Und wenn Aufgaben entstehen, finden diese ihren Platz in To-Dos.

Ein Format, das alle einbezieht

Auf den ersten Blick ist es bereits ein tolles Format. Wenn man noch tiefer blickt, entfaltet es seine wahre Schönheit. Alle Teilnehmer werden gehört, Hierarchiestufen werden aufgehoben, Beiträge kommen gleichermaßen von extrovertierten Personen wie introvertierten, es spielt keine Rolle, ob die Person ein Junior ist oder bereits viele Jahre Berufserfahrung hat, und wortstarke Personen haben keinen Vorteil gegenüber denen, die eher leise Töne anschlagen. Allein die Qualität und Relevanz der Beiträge ist entscheidend und das Team erhält ein großes Stück Selbstorganisation und Demokratie. Gleichzeitig können Führungskräfte (lateral wie funktional) trotzdem Themen, die ihnen wichtig sind, einbringen. Die Spalte „In Diskussion“ trägt dazu bei, den Fokus zu halten. Das aktuelle Thema ist transparent und plakativ, wodurch abschweifende Diskussionen leicht identifiziert werden können. Und am Ende des Termins kann über ein Foto sehr schnell protokolliert werden. Testen Sie hierzu die kostenlose App „Office Lens“ von Microsoft. Diese App bearbeitet die Bilder automatisch auf optimale Lesbarkeit und schneidet sie entsprechend zu.
P.S.: Lassen Sie uns wissen, wie das Lean Coffee bei Ihnen aussieht. Für die ersten fünf Posts auf den Accounts von borisgloger bei Facebook oder Twitter oder per Mail mit einem Bild von Ihrem Lean Coffee gibt es eine kleine Überraschung und diese quadratischen Waffeln mit Milchcreme, Schokolade und Haselnüssen.

Wohnung putzen mit dem Minimum Viable Product

„MVP“ – Minimum Viable Product – ist ein verbrannter Begriff. Er wurde missbraucht, um eine Brücke zwischen dem klassischen und dem agilen Projektmanagement zu schlagen. Arbeitspakete des Projektablaufplans werden kurzerhand zu MVPs umgetauft – so wirkt alles schon viel agiler. Dabei wird jedoch eines vergessen: Ein MVP ist ein Produkt, das mit seinen Eigenschaften bereits die minimalen Anforderungen des Kunden abdeckt. Ein Produkt, das in sich geschlossen ist und einen Mehrwert bietet. Etwas, das schon verkauft werden könnte und wofür der Kunde bezahlen würde. Wenn der Kunde beispielsweise sagt, er möchte von Punkt A zu Punkt B gelangen, dann ist ihm mit einem Reifen nicht geholfen. Dazu benötigt er schon ein Fortbewegungsmittel, das seiner wichtigsten Anforderung – der Fortbewegung – genügt. Aufbauend auf diesem MVP können anschließend weitere Anforderungen hinzugefügt werden – der Kundennutzen wächst und ein neues MVP entsteht. Trotzdem fällt es vielen schwer, die Übertragung aus der klassischen Welt mit ihrer Meilensteinplanung hin zur Customer Journey mit MVPs und einem Releaseplan nachzuvollziehen. Für den Ausbruch aus diesen eingefahrenen Denkmustern braucht man manchmal aber nur einen kreativen Ansatz, um den Zusammenhang klarer zu machen. Was eignet sich dafür besser als eine alltägliche Situation?

Putzen Sie Ihre Wohnung – MVP 1

Angenommen, der Wohnungsputz wird hauptsächlich von Ihrer Partnerin oder Ihrem Partner durchgeführt. Stellen Sie sich vor, sie wollen ihr oder ihm diese Aufgabe nun einmal komplett abnehmen. Wo fangen Sie an zu putzen? Welche Räume nehmen Sie sich vor? Und die wichtigste Frage: Wie viel müssen Sie putzen, damit sie oder er zufrieden ist, Sie aber nicht mehr als nötig gemacht haben? Dafür ist für Sie wichtig zu wissen, was der „Putz-Standard“ bei Ihnen zuhause ist. Die Mindestanforderungen Ihrer Partnerin oder Ihres Partners an den Wohnungsputz sind ein wichtiger Teil der Vorbereitung. Sinnvoll ist es außerdem, die Aufgaben zu sammeln, die in der gesamten Wohnung regelmäßig anfallen. Diese Aufgaben können gut den jeweiligen Räumen zugeordnet werden. So entsteht eine in Rubriken strukturierte Sammlung wie „Wohnzimmer“, „Küche“, „Bad“ und „Schlafzimmer“. Diese Rubriken können Sie mit Themenklammern gleichsetzen, also sogenannten Epics.
Wenn Sie nun also wissen, dass Ihre Partnerin oder Ihr Partner glücklich ist, wenn in jedem Raum gewisse Aufgaben erledigt sind, so ergibt sich für Sie eine Anzahl an Aufgaben, die in Summe das MVP ergeben. Nach der Erledigung sämtlicher Aufgaben, die zur Erfüllung des MVPs beitragen, kann das Ergebnis vorgeführt werden. Sie werden recht schnell merken, ob Ihre Überraschung geglückt ist und Sie alle Anforderungen erfüllt haben!

Stellen Sie sich vor, die Schwiegermutter kommt zu Besuch – MVP 2

Nun ist also Ihre Partnerin oder Ihr Partner durch dieses MVP zufrieden gestellt. Was passiert allerdings, wenn sich spontan die Schwiegermutter mit einem Besuch ankündigt? Dann muss das ursprüngliche MVP ein bisschen erweitert werden. Und zwar um genau die Aufgaben, die dabei helfen, auch die Schwiegermutter zufrieden zu stellen. Die Anforderungen aus dem ersten MVP bestehen weiterhin, es gibt jedoch Aufgaben, die es ergänzen. Das Gesamtpaket ergibt dann ein neues MVP.
Die gleiche Vorgehensweise kann auch in der Produktentwicklung angewendet werden. Auch dort sollte angestrebt werden, mit einem ersten Produkt, das dem Kunden einen Mehrwert bietet, den Markt bedienen zu können. Somit kann erstes Kundenfeedback frühestmöglich in die nächste Iteration einfließen. Außerdem lassen sich mit diesem Ansatz Fehlinvestitionen vermeiden und somit das Risiko minimieren, indem früh erkannt wird, ob eine Weiterentwicklung des MVP rentabel ist und welche Funktionalitäten vom Kunden überhaupt gewünscht und bezahlt werden.
Allgemein ist, wie auch beim Wohnungsputz, dabei zu berücksichtigen, wer die Zielgruppe des Produkts ist. So können Unternehmen entlang der Customer Journey ein Produkt entwickeln, das die rentabelsten Funktionalitäten enthält und die Kundenbedürfnisse befriedigt. Im Gegensatz zur klassischen Produktentwicklung setzt der Cashflow hierbei wesentlich früher ein, die Reaktions- sowie Entwicklungszeiten sind kürzer und der Kunde steht im Zentrum der Überlegungen. Der Trick ist also eine geänderte Perspektive auf die Produktentstehung.

Magic System Mapping oder "How to make toast"

Ein und dasselbe Thema – viele Sichtweisen und Wissensstände. So sieht es oft in einem Team aus, bevor es an die Entwicklung eines Produkts geht oder ein bestimmtes Problem gelöst werden soll. Mit „Magic System Mapping“ lassen sich individuelle Sichtweisen und Standpunkte, die es innerhalb einer Gruppe zu einem Thema oder Problem gibt, zu einem Gesamtbild zusammenführen.
Magic System Mapping beruht auf ähnlichen Prinzipien wie Magic Estimation: non-verbale Kommunikation wird visualisiert. Ich habe diese Methode schon für unterschiedliche Zwecke verwendet:

Wie funktioniert Magic System Mapping?

Um die Methode zu erklären, beginnt man mit einer einfachen Design-Übung, die je nach Gruppengröße 10 bis 15 Minuten dauert. Ausgedacht hat sich das ganze Tom Wujec, Businesss-Visualisierungs-Pionier und Mitgründer der Singularity University, der die Hintergründe fabelhaft in einem TED-Talk vorstellt.

Was man dafür braucht
Anmoderation der Aufgabe

Die Teilnehmer werden begrüßt, anschließend kündigt ihr an, dass ihr mit ihnen jetzt eine viertelstündige Design-Aufgabe mit anschließender Reflexion durchführt. Dazu bittet ihr die Anwesenden, in den nächsten fünf Minuten auf Post-its aufzuzeichnen, wie sie Toast machen. Dazu gibt es drei Regeln:

  1. Jeder macht die Aufgabe im ersten Schritt für sich.
  2. Nur ein „Toastmachschritt“ auf je einem Post-it.
  3. Das Ganze ist kein Kunstwettbewerb.

Optional könnt ihr noch erwähnen, dass zehn Post-its pro Person ein guter Anhaltspunkt für die Granularität der einzelnen Schritte sind. Falls noch nicht geschehen, könnt ihr jetzt die Post-its austeilen.

Review der Toast-Modelle

Nach Ablauf der drei Minuten bittet ihr einen Kollegen damit anzufangen, seine Toastmachschritte auf der freien Wandfläche von links nach rechts aufzuhängen. Dann geht es weiter mit der nächsten Person, er oder sie hängt sein Toastmodell darüber oder darunter. Falls er oder sie ähnliche Schritte hat, können sie unter bzw. übereinander angeordnet werden. Das Ganze wiederholt ihr, bis jeder sein Toastmodell geteilt hat.
Nachdem alle ihre Modelle aufgehängt haben, könnt ihr die Teilnehmenden fragen, was ihnen an den unterschiedlichen Modellen auffällt. Zum Beispiel: Wie komplex oder simpel sind die jeweiligen Modelle, werden dabei Personen oder keine Personen gezeigt? Diese Phase könnt ihr kurz halten. Zwei bis drei Wortmeldungen aus der Gruppe genügen.

Magic System Mapping

6 verschiedene Toast-Modelle im Vergleich

Zusammenführen der Toast-Modelle

Im letzten Schritt geht es darum, eine Synthese zwischen allen Toastmodellen herzustellen. Hier ist als Anforderung: Im finalen Bild darf es keine Duplikate mehr geben und es muss eine Reihenfolge erkennbar sein – und das Ganze soll ohne verbale Kommunikation gelöst werden. Im normalen Arbeitskontext kommt Letzteres auch häufig vor: Beispielsweise bei der Priorisierung von Anforderungen oder dem Treffen von Entscheidungen, ohne dass das Team mit den Stakeholdern sprechen kann.
In diesem Prozess werden sehr schnell unterschiedliche Sichtweisen und auch Konflikte in der Gruppe deutlich. Ziel ist es, eine Einigung zu finden und das im Gesamtmodell abzubilden. Schweigen ist hierbei Gold Wert. Interessanterweise funktioniert das ohne verbale Kommunikation deutlich schneller als mit.
Als Zeitvorgabe bieten sich für diesen Schritt fünf Minuten an.

Magic System Mapping

Das zusammengeführte Toastmodell ohne Duplikate in einer Reihenfolge

 

Reflexion

Nachdem die Gruppe ein Gesamtbild erarbeitet hat, gibt es erst einmal eine Runde Applaus. Den Reflexionsprozess kann man mit den folgenden zwei Fragen an die Gruppe starten:

Häufig berichten die Teilnehmenden, dass ihnen die Übung gezeigt hat, wie eingeschränkt ihre eigene Sichtweise auf ein Problem ist und wie unterschiedlich die Denkweisen von verschiedenen Personen sein können. Dieser Punkt wird häufig mit unterschiedlichen Expertisen und Spezialisierung in Verbindung gebracht. Einige Personen sind Spezialisten für einzelne Teilbereiche des Prozesses, die sie besonders stark ausdetaillieren – beispielsweise wie ein Toaster funktioniert – und andere beginnen den Toastprozess beim Weizenkorn, das gesät und bewässert wird. Nur durch die Synthese entsteht ein gesamtes System.
Als weiterer Punkt kommt in der Reflexion oft auf, dass unterschiedliche Perspektiven im System sichtbar gemacht und berücksichtigt werden können. Etwa die Tatsache, dass manche Menschen ihren Toast mit Butter essen und andere das niemals tun würden. Im Toastmodell werden die unterschiedlichen Belegungspräferenzen häufig durch übereinander hängende Post-its dargestellt.
Eine weitere Erkenntnis der Übung ist: Abgebildete Systeme bestehen immer aus Knoten und Verbindungen, die eine Logik herstellen. Die Übersetzung in BPMN-Sprache wäre: flow-basierte Objekte wie Ereignisse oder Aktivitäten und verbindend strukturierende Elemente wie Kanten/Assoziationen oder Gateways.

Anwendung im realen Kontext

Nach der Trockenübung mit dem Toastbeispiel könnt ihr euch eurem tatsächlichen Thema oder Problem zuwenden. Der Ablauf ist am Anfang analog zum Toastbeispiel:

  1. Startet mit eurer Fragestellung – falls sie noch zu grob ist, nehmt euch etwas Zeit, um sie in der Gruppe genauer zu spezifizieren
  2. Sammelt in der Gesamtgruppe die Knotenpunkte
  3. Entwickelt ein Gesamtbild/System in der Gruppe und stellt die Verbindungen her
  4. Verfeinert das System in der Gruppe
  5. Verfeinert das System weiter …
  6. … und weiter

Je mehr Runden ihr in die Verfeinerung des Systems steckt, umso klarer wird das System für die Beteiligten. Im Zuge dessen werdet ihr auf immer feingranularere Probleme oder Abhängigkeiten stoßen, für die es Lösungen zu finden gilt.
Mein Tipp für diese Phase: Teilt euch in Kleingruppen auf und arbeitet einzelne Teile eurer Systems genauer aus. Nehmt euch dafür je nach Größe und Komplexität des Themas 30 bis 60 Minuten Zeit. Danach stellt jede Kleingruppe ihre Ergebnisse vor, sie werden diskutiert und anschließend in das System eingebaut.
Wie viel Zeit ihr für diesen Prozess benötigt, hängt von der Komplexität eurer Fragestellung ab. Ich beginne meistens mit einer dreistündigen Session, in der am Anfang Zeit für die „How to make Toast“ Übung ist. Am Ende wird besprochen, wie an den Ergebnissen weitergearbeitet wird. Ich habe aber auch schon mehrtätige Off-Sites in diesem Stil organisiert.

Eine abschließende Bemerkung

Das Feedback der Teilnehmenden war bisher immer positiv. Die Methode hat nur einen Haken: Das erarbeite System ist eine Momentaufnahme – abhängig von den Beteiligten, und es hat nur Gültigkeit, solange man in der Gruppe zusammenbleibt. Durch den iterativen Ausarbeitungsprozess hat eine Verständigung auf Begrifflichkeiten und Regeln für das System stattgefunden. Ein Außenstehender kann das Abgebildete nur mit Hilfe von guter Dokumentation verstehen.
Das ist aber auch für die Teilnehmenden wichtig: Ab dem Moment, an dem sie den Raum verlassen, machen sie neue Erfahrungen, führen Diskussionen mit Kollegen oder haben Ideen, die Auswirkungen auf das System haben. Was kann man dagegen machen? Man muss den Prozess regelmäßig wiederholen, um ein längerfristiges Alignment herzustellen und das System an die aktuellen Gegebenheiten anzupassen. Am Ende ist es die Auseinandersetzung mit dem richtigen Personenkreis zu einem Thema, was uns am Ende erfolgreich macht. Die Visualisierung ist dabei nur ein Hilfsmittel. In diesem Sinne wünsche ich euch viel Erfolg und Spaß beim kollaborativen Visualisieren.

Ressourcen

Templates zu verschiedenen Themen:
DrawToast
Mural – ein gutes Tool für kollaboratives Visualisieren
Originalartikel erschienen im ProjektMagazin – verwendet mit freundlicher Genehmigung.
Foto: CC0 Creative Commons – pixabay, pexels

Agiles Testen: Mehr Effizienz durch die Testpyramide

In meinem Beitrag „Was agiles Testen nicht ist und was es ist“ habe ich darüber geschrieben, dass Funktionalitäten in einem Sprint fertig getestet werden müssen, um am Ende des Sprints funktionierende (Teil)Produkte liefern zu können. Das kann herausfordernd sein: Man muss frühzeitig wissen, was man testet, die notwendige Infrastruktur muss zur Verfügung stehen und vor allem muss es schnell gehen – denn die Iterationen sind kurz, sehr viel kürzer als wir es aus klassischen Projekten gewohnt sind.
Mike Cohn hat schon vor einigen Jahren die Testpyramide vorgestellt, die uns zeigt, wie das Testen effizient gestaltet werden kann:

Mit dieser Taktik lässt sich die Qualität des Produkts am effizientesten erhöhen und es kann sichergestellt werden, dass am Ende des Sprints funktionierende Software potenziell geliefert werden kann.

Bild: Copyright Mike Cohn, Constanze Riess

Mut zum Spiel – im Unternehmen!

Als Abwechslung zu monotonen Meetings werden in Unternehmen regelmäßig mehrstündige und sogar mehrtägige Workshops abgehalten. Aus meiner Sicht wird dabei in den seltensten Fällen das volle Potential dieser Workshops ausgeschöpft. Zwar wird viel auf Flipcharts und Post-its festgehalten, nachhaltig wirken die gewonnenen Erkenntnisse jedoch nur, wenn der Moderator es schafft, Emotionen zu wecken. Spiele lösen bei jedem Menschen im Kindesalter die größten Emotionen und damit auch die nachhaltigsten Lernschritte aus – daher nutze ich diesen Effekt gerne für erfolgreiche Workshops im Business-Kontext und kann es wärmstens empfehlen.

Welche Voraussetzungen sind nötig, um agile Spiele im Unternehmen anwenden zu können?

  1. Vertrauen in den Moderator

    In den meisten Unternehmen sind Spiele weit davon entfernt, das Medium der Wahl zu sein. Im Gespräch mit Kunden, Bekannten und Freunden begegnet mir regelmäßig der Zweifel, ob Spiele wirklich zielführend für die Kommunikation zwischen Erwachsenen sind. Meine klare Antwort darauf ist: Ja, sie sind es!
    Vor allem für unternehmensinterne Moderatoren ist es wichtig, ihre Kompetenzen zunächst durch unkonventionelle Methoden unter Beweis zu stellen. Ob man vorab durch die Visualisierung eines Meetings oder durch die Einführung kreativer Retrospektiven geglänzt hat: Das alles ist für die initiale Unterstützung der Teilnehmer und für die Umwandlung von Skepsis in Begeisterung entscheidend.

  2. Wahl des richtigen Spiels

    Für einen Moderator ist es essentiell, das Ziel des Workshops vor Augen zu haben und es vorab mit den Stakeholdern oder Teilnehmern abzustecken. Ist das Ziel einmal definiert, empfiehlt es sich, in der Literatur (z. B. Gamestorming: Ein Praxisbuch für Querdenker, Moderatoren und Innovatoren) oder auf einer der zahlreichen Internetseiten (z. B. Agile Games oder tastycupcakes.org) nach geeigneten Spielen zu suchen. Bevor das Spiel der Wahl mit den Teilnehmern erprobt wird, gibt es noch die beiden folgenden Punkte zu beachten:

    a) Gute Einschätzung der Teilnehmer

    Wenn ich die Teilnehmer nicht kenne, mache ich mich über sie schlau. Wenn ich sie kenne, ist es umso einfacher einzuschätzen, wer von ihnen ein potentieller Unterstützer und wer ein Skeptiker sein wird. Wenn ich mir vorher diese Gedanken mache, kann ich später im Spiel die Rollen so verteilen, dass die positive Energie der Unterstützer im Spiel verstärkt wird. Für den Umgang mit Skeptikern kann ich empfehlen, vorab im Zweiergespräch die Zielsetzung und die Vorgehensweise des Spiels zu erläutern, um Diskussionen vor dem Spiel gering zu halten. Vor allem, wenn es sich um Führungskräfte handelt, die starken Einfluss auf ihre Mitarbeiter haben, kann dieser Widerstand verheerend auf die Zielerreichung wirken.

    b) Sehr gute Vorbereitung

    Wenn man in einem Unternehmen Spiele zum ersten Mal anwendet, ist eines der schlimmsten Szenarien, dass die Teilnehmer keinen Mehrwert darin erkennen. Jeder weitere Versuch, Spiele einzusetzen, wird dann zu einem Hindernislauf. Hier hilft die ständig wachsende Agile Community, die in Meetups neue Spiele mit motivierten Teilnehmern erprobt und mit ihnen in einer Retrospektive analysiert, welche Erkenntnisse jeder Teilnehmer für sich und ggf. für sein Unternehmen gewinnen kann. In Frankfurt bietet dafür die von Ellen Hermens und Sieglinde Fritz initiierte „Agile Game Night“ ein geeignetes Forum, das wir vom borisgloger-Team in Frankfurt unterstützen und mitorganisieren. Mit der Epic Bedtime Story haben wir im Juni diese Meetup-Reihe gestartet und damit ein Spiel erprobt, das die Vorteile eines gemeinsamen Teamraums verdeutlichen soll. Die dabei entstandene Geschichte von „Pachito, die kleine Zitrone“ war ein Erfolgserlebnis für die Teilnehmer und hat im Anschluss für angeregte Diskussionen und zahlreiche Erkenntnisse gesorgt. An Kreativität, Motivation und vor allem Spaß hat es dabei definitiv nicht gemangelt. Und für die Zukunft bleibt in Erinnerung: „Die Geschichte von Pachito hätten wir sicherlich besser abstimmen können, wenn die räumlichen Barrieren nicht gewesen wären.“

  3. Mut zum ersten Schritt im eigenen Unternehmen

    Bevor Spiele in einem Unternehmen zum ersten Mal eingesetzt werden, muss jemand den ersten Schritt wagen und sich vor Augen halten: „Keine Chance ohne Risiko.“ Bei guter Vorbereitung bleibt das Risiko gering. In jedem Fall gilt: Wir können und müssen mehr im Arbeitsalltag spielen, um nachhaltig miteinander zu kommunizieren, Ideen zu entwickeln und um mehr Spaß an der Arbeit zu haben.

Ich für meinen Teil wage diesen ersten Schritt bei meinen Kunden gerne und freue mich über Interessenten und Spielbegeisterte, die sich mit meinem Kollegen Christian Böhmer und mir bei der Agile Game Night in Frankfurt auf Experimente mit Lego, Buntstiften, Spielkarten, Knete etc. einlassen möchten. Daher mein Appell: Wagt den Schritt, kommt vorbei und macht mit!

Foto: CC0 Creative Commons – pixabay, PublicDomainPictures

Was die Position des Scrum-Teams vor dem Taskboard über das Team aussagt

„Leistet mein Team gute Arbeit?“ Eine Frage, die viele Führungskräfte in Unternehmen umtreibt, wie zahlreiche Anfragen nach Projektbesuchen und Assessments beweisen. Doch braucht es Fragebögen, Interviews oder stundenlange Post-Mortems, um eine Antwort zu finden? Die Frage lässt sich häufig mit einer scheinbar einfachen Methode beantworten: durchs Beobachten.
Wenn ich zum ersten Mal ein Team besuche, das bereits agile Arbeitsweisen wie Scrum oder Kanban nutzt, achte ich bewusst und unbewusst auf viele kleine Hinweise, um eine Hypothese über den Teamerfolg und das Verhalten des Teams und des Unternehmens zu bilden. Ich versuche bewusst, nicht in Aktionismus zu verfallen und sofort alles auf links zu drehen. Denn es gibt Gründe, warum die Menschen so arbeiten, wie sie es gerade tun. Es geht also nicht darum, nach wenigen Tagen einen detaillierten 12-Punkte-Aktionsplan zu haben, sondern ein tiefes Verständnis für die Arbeitsweise der Menschen im Unternehmen zu entwickeln.
Erfahrungsgemäß ist die Stehung, das Catch Up, Stand Up oder Heads Up, oder wie auch immer Sie das tägliche kurze gegenseitige Update im Team, also das Daily Scrum, bezeichnen, eine tolle erste Möglichkeit, um diese Beobachtung durchzuführen. Neben dem üblichen Teilnehmerkreis, der Dauer und der Häufigkeit des Dailys sagt die Position der Teammitglieder vor dem Taskboard sehr viel über die Kultur und den Teamspirit aus.
In den zahlreichen Unternehmen und Projekten, die ich gesehen habe, zeichneten sich einige Muster immer wieder ab. 12 davon zeige ich Ihnen hier. Zur Erklärung: Der orange Kreis ist der ScrumMaster, Gelb symbolisiert die Teammitglieder, in Grün sehen sie den Product Owner und blau ist der Manager.

Muster 1 – das einsame Taskboard


Niemand kommt zum Daily. Man hat sich zwar die Mühe gemacht, die Arbeit sichtbar zu machen, doch das Hilfsmittel wird nicht genutzt. Wahrscheinlich wird das Taskboard nicht als hilfreich erachtet. Offensichtlich sind Zusammenarbeit und Koordination in diesem Team nicht notwendig.

Muster 2 – die Leere


Kein Taskboard, keine Gespräche, kein Treffen. Ob das besser oder schlechter ist, als das „einsame Taskboard“ sei mal dahingestellt.

 

Muster 3 – kein Taskboard


Das Team unterhält sich mehr oder weniger strukturiert. Das ist ein guter Anfang. Der Hauptzweck des Meetings – die kurze, zielgerichtete Unterhaltung zwischen den Teammitgliedern funktioniert. Ein Taskboard kann helfen, diesen Austausch zu fokussieren und zu strukturieren.

Muster 4 – das Zentrum

Die Teammitglieder berichten an den ScrumMaster. Der ScrumMaster steht viel zu sehr im Fokus und verhindert, dass sich die Teammitglieder offen und ehrlich austauschen. Das Team hat den Nutzen des Dailys für sich selbst wahrscheinlich noch nicht erkannt. In besonders schlimmen Fällen fragt der ScrumMaster die Teammitglieder einzeln ab und verlangt eine Rechtfertigung, wenn etwas nicht klappt. Selbstorganisation muss hier noch beigebracht werden.

Muster 5 – das alternative Zentrum


Die Teammitglieder berichten an den Product Owner. Ein Wort – Micromanagement. Anscheinend vertraut der Product Owner dem Team nicht ausreichend. Der ScrumMaster scheint auch schwach zu sein.

Muster 6 – die spanische Inquisition


Product Owner und ScrumMaster sitzen hinter einem Schreibtisch vor dem Taskboard und erwarten den Bericht der Teammitglieder. So ziemlich das Schlimmste, was einem Team passieren kann. Noch schlimmer wäre es nur mehr, wenn die Teammitglieder mit verbundenen Augen vor einer Wand stünden.

Muster 7 – das Meeting


Offensichtlich ist die alte Meetingkultur noch tief verankert. Die Teammitglieder sitzen an den Tischen. Im „Idealfall“ klappt jeder noch seinen Laptop vor sich auch und tippt wild vor sich hin. Es geht um Anwesenheit, nicht um Ergebnisse. Langeweile ist vorprogrammiert, Leidenschaft werden wir in so einem Meeting vergeblich suchen. Kann noch gesteigert werden durch das nächste Muster.

Muster 8 – das Klassenzimmer


Ähnlich wie „Das Meeting“, zusätzlich können sich die Teammitglieder jetzt nicht mehr in die Augen schauen. Auch hier arbeiten eher Fachexperten in einer Arbeitsgruppe. Zusammenarbeit gibt es hier wahrscheinlich nicht.

Muster 9 – der Experte


Das Daily findet ausschließlich mit dem ScrumMaster und dem „einzigen Teammitglied, das sich wirklich auskennt“ statt. Ab und zu gibt es auch mehrere Experten, die jedoch getrennt voneinander befragt werden. Die restlichen Teammitglieder werden ignoriert. Teamzusammenarbeit und Austausch wird man in diesem Team vergeblich suchen.

Muster 10 – noch ein alternatives Zentrum


Die Teammitglieder berichten an den Manager – Micromanagement in Vollendung. Der Product Owner ist entweder entmachtet oder nicht da.

 Muster 11 – der Lonesome Rider


Der ScrumMaster macht das Daily mit sich alleine, weil er das Team nicht braucht, um Transparenz zu stiften. Er weiß Bescheid (oder meint Bescheid zu wissen), was im Team gerade läuft. Hat den Sinn des Dailys komplett verfehlt. Offensichtlich hat der ScrumMaster auch wenig Respekt vor den Fähigkeiten der Teammitglieder. Eine alternative Interpretation ist, dass keines der Teammitglieder zum Daily kommt, weil sie den Mehrwert und Sinn nicht sehen. Vergleichbar mit Muster 1 und 2.

Muster 12 – der Reporter


Der ScrumMaster berichtet direkt an den Manager. Teammitglieder werden komplett außen vor gelassen – entweder, weil der ScrumMaster die Teammitglieder als nicht fähig genug einstuft oder diese keine Lust auf das Meeting haben. Vertrauen und Identifikation mit dem Produkt, das entwickelt wird, wird man hier vergeblich suchen.

Die Kraft des Taskboards nutzen: Wie macht man es besser?

Idealerweise stehen alle Scrum-Teammitglieder – also Entwicklungsteam, Product Owner und ScrumMaster – gleichberechtigt vor dem Board. Die Teammitglieder erzählen sich gegenseitig von ihrem Fortschritt, der ScrumMaster moderiert, achtet in den Ausführungen des Teams auf Hindernisse und erzählt auch selbst von den Themen, an denen er arbeitet. Der Product Owner interessiert sich auch für den Fortschritt des Teams und berichtet von den Themen, die bei ihm passiert sind. So gefällt mir das.

Starten Sie an dieser Stelle ein kleines Experiment. Beobachten Sie bei nächster Gelegenheit das Verhalten Ihres Teams. Überprüfen Sie, ob sich der aus der Beobachtung ableitbare Zweck mit der Funktion deckt, die das Team erfüllen soll. Passt das Gesagte mit dem sichtbaren Verhalten zusammen? Damit wird die Beobachtung auch zur Strategiearbeit: Was haben wir uns vorgenommen zu tun und was tun wir tatsächlich? Beobachtung als bewusste Führungsaufgabe benötigt etwas Zeit und Kontakt ins Team, kann aber zur Rekalibrierung des Veränderungsbedarfs führen und zur Steuerung genutzt werden. Konkret könnte das bedeuten, die Beobachtung zu teilen und zusammen mit dem Team in Bezug auf den angestrebten Zweck zu reflektieren.
Kennt ihr noch weitere Muster? Ich freue mich über eure Kommentare.

"Und täglich grüßt das Murmeltier" – eine Retrospektive

Der Hintergrund

Ich begleite eine etwa zwanzigköpfige Gruppe, die sich alle drei Monate trifft, um zwei Tage zusammen zu liefern. Die Constraints? Fluktuation, Heterogenität, wer weiß, ob er beim nächsten Mal dabei ist? Getagt wird in – was sonst? – Tagungshotels. Sie kennen das: kilometerlange Flure, gemusterter Teppich. Der monotone Rhythmus aus Essen, Arbeitssession, Essen, Arbeiten. Tag für Tag.
Ich möchte den Fokus in der abschließenden Retrospektive auf ein „Was kann ich anders machen?“ lenken, weg vom verführerischen „Man sollte mal … jemand wird sicher beim nächsten Mal …“
Der immer gleiche Teppich, Fahrstuhl-Piepen, Kaffeemaschinen-Röcheln, die immer gleichen Hotelgeräusche … Was wäre, wenn nur ich etwas ändern könnte? Und da war sie: die Murmeltier-Retro.

Die Retro

Check-In

Herzlich willkommen zur Retro! Unsere heutige Check-in-Frage lautet: Wenn du jeden (!) Morgen vom gleichen Lied geweckt werden müsstest, welches suchst du dir aus? Bitte nehmt euch einen Moment Zeit, um diese schwerwiegende Entscheidung zu treffen und teilt dann reihum das Ergebnis dem Team mit*.
(Die Gruppe nennt ihre Wunsch-Lieder)
Cineasten oder Kollegen, die Anfang der 1990er bereits im kinofähigen Alter waren, ahnen es vielleicht schon: Unsere heutige Retro wurde vom Film „Und täglich grüßt das Murmeltier“ inspiriert. Wer von euch kennt den Film nicht?
(Vereinzelt werden Handzeichen gegeben und Stirnen gerunzelt.)

Worum geht es in dem Film?

Wir schreiben das Jahr 1993. Bill Murray war noch knackig und trat an, um die Welt inklusive der agilen Community an seiner zweitwichtigsten Lernerfahrung** teilhaben zu lassen. Bill Murrays Charakter Phil ist Reporter und wird nach Punxsutawney, Pennsylvania, geschickt, um dort live vom Murmeltiertag zu berichten. Dabei gerät Phil in einen 24-stündigen Zeit-Loop und wacht fortan jeden Morgen im gleichen Hotelzimmer auf. Es ist der gleiche Tag, der 2. Februar, es läuft das gleiche Lied im Radio – nur dass Phil, im Gegensatz zu euch, nicht das Glück hat, sich das Lied aussuchen zu können, sondern mit „I Got You Babe“ von Sonny und Cher vorlieb nehmen muss. Wieder und wieder. Egal, wie der Tag verläuft oder was Phil tut, er wacht wieder am 2. Februar auf.

Wie geht Phil damit um?

Er merkt, dass er als Einziger von der Zeitschleife weiß. Daraufhin beginnt er, dieses Wissen für sich auszunutzen – schließlich drohen ihm keine Konsequenzen für sein Verhalten! Mit der Zeit wird er ob der ewigen Wiederholungen depressiv. Eines Tages nimmt er den Toaster mit in die Badewanne – nur um am nächsten, äh, selben Morgen wieder von „I Got You Babe“ geweckt zu werden. Schließlich beginnt Phil, die geschenkte Zeit und seinen Wissensvorsprung zu nutzen. Er tut Gutes, verhindert zum Beispiel Unfälle in Punxsutawney, und lernt Neues. Mit der Zeit*** ändert sich sein Wesen und er findet ein romantisches Happy End, das für ihn auch den Ausbruch aus der Zeitschleife bedeutet.

Und was hat das mit uns zu tun?

Stellt euch vor, ihr erlebt den letzten Sprint wieder und wieder und … wieder. Beim ersten Mal haltet ihr es noch für einen Zufall, beim zweiten Mal versucht ihr, mit euren Kollegen darüber zu reden. Doch als wäre die Zeitschleife allein noch nicht skurril genug – keiner, dem ihr davon erzählt, glaubt euch! Jeder bemerkt als Einziger diese Wiederholungen!

Die Reflexion

Angesichts dieser Situation: Was machst du wieder so während des Sprints, da es gut funktioniert hat? Vielleicht sogar noch mehr davon? Und andererseits: Was machst du anders? Was verbesserst du?
Die Hypothese dahinter: Wenn du immer wieder die gleichen Ineffizienzen, Sackgassen oder Missverständnisse erlebst und es als Einziger merkst, erfindest du Interventionen, die du selbst bewirken kannst.
Bitte notiert eure möglichst konkreten Antworten auf Post-its. Anschließend vergemeinschaften wir die Ergebnisse und wahren dabei das Schneeflockenprinzip: Das heißt, dass die Punkte reihum auf zwei Flipcharts gesammelt werden, wobei keine Doppelungen vorgetragen werden.
(Nach Ablauf der Timebox stellen die Teilnehmer nacheinander ihre Beiträge zu den beiden Fragen „Was machst du wieder?/Wovon mehr?“ und „Was anders?“ vor. )

Die Erlösung aus der Zeitschleife

Herzlichen Glückwunsch, hiermit ist euer Bann gebrochen! Die Zeitschleife hört auf, endlich könnt ihr euch über das Erlebte austauschen.
Auf Basis der Erkenntnisse aus der Zeitschleife erarbeitet nun bitte im Pairing mit einem Kollegen Experimente/Maßnahmen, mit denen sich im nächsten Sprint die Zusammenarbeit verbessern lässt. Ein Experiment pro Post-it. Bitte schreibt eine konkrete Anleitung, sodass jedes Gruppenmitglied die Maßnahme pullen könnte. Wir sammeln die Ergebnisse danach wieder auf einem Flipchart mit zwei Spalten. Wer die Maßnahme selbst umsetzen möchte, schreibt bitte seinen Namen dazu und hängt das Post-it in die „committet“-Spalte. Wenn ihr die Maßnahmen anderen zum Pull zur Verfügung stellen möchtet, hängt sie bitte in das Feld „to pull“.
(Die Gruppe tauscht sich im Pairing aus und schreibt Post-its. Nach Ablauf der Timebox werden die gefundenen Experimente vorgestellt. Ein Teil wird direkt von den Autoren gepullt, ein paar weitere Maßnahmen werden nach der Vorstellung von Teamkollegen gepullt.)
Vielen Dank für eure Zeit! Die Frage zum Check-out lautet: Für welche konkrete Begebenheit im letzten Sprint (eine Geschichte, ein Kaffee, ein Tipp, ein Gespräch …) möchtest du danke sagen?

Es war spannend, diese Retro zu facilitaten und zu erleben, was passiert ist. Denn wer von uns kennt nicht das Gefühl, aus einer Situation nicht herauszukommen, in einem Teufelskreis festzusitzen und nichts tun zu können? Diese Retro gibt die Möglichkeit, aus diesem Horror-Szenario Chancen abzuleiten.
Probieren Sie es mal aus und genießen Sie so wie ich die veränderte Stimmung im Raum und die Experimente, die dort entstehen werden. Welche Experimente bringen Ihre Teams aus der Zeitschleife mit?

*Bei mir wäre es übrigens Bohemian Rhapsody 
**Wer dieses Sternchen nachliest, weiß die Antwort doch eh selber. 1984 kam folgende Erkenntnis
*** Grundsätzliche Wesenszüge verändern sich natürlich nicht von heute auf morgen. Es wird geschätzt, dass Phil mehrere Jahrzehnte in diesem Zeit-Loop verbrachte
Foto: CC0 Creative Commons – b_kowsky, pixabay

Das Impediment Board aus Sicht des Managers

Habt ihr euch als Manager schon mal gefragt, was der Nutzen eines Impediment Boards ist? Ein Impediment Board visualisiert Hindernisse, die euch oder eure Teams daran hindern, zu liefern. Das Board sollte möglichst öffentlich und für alle einfach einsehbar sein. Ideal ist daher ein haptisches Board, also eines zum Angreifen. Das stellt sicher, dass Probleme sichtbar bleiben, bis sie gelöst sind. Aber wie kann man sich so ein Impediment Board vorstellen? Die einfachste Variante sieht aus wie ein Taskboard. Es besteht von links nach rechts betrachtet aus drei Spalten: „Zu erledigen“, „In Bearbeitung“ und „Fertig“. Bei Bedarf kann ganz links noch eine Spalte mit „identifizierten Problemen“ hinzugefügt werden. Dort werden Hindernisse gesammelt, die entdeckt wurden und deren Beseitigung noch nicht vereinbart ist. Auch hier ist es sinnvoll, zu priorisieren.

Ziel ist, zu jedem Zeitpunkt einen Überblick darüber zu haben, wie weit die Beseitigung aktueller Probleme fortgeschritten ist. Das schafft

Das negative Gegenbeispiel wäre eine „Vorschlags-/Verbesserungsbox“, die sich „jemand“ von Zeit zu Zeit ansieht, und bei der unklar bleibt, ob und wann ein Problem angegangen wird. Das kann zu komplettem Frust und völliger Verweigerung führen („Hier ändert sich eh nie etwas“ oder „Mir hört ja eh keiner zu“).
Die Visualisierung kann euch helfen, Stück für Stück bessere Rahmenbedingungen zu schaffen – ganz genau das ist die Aufgabe des Managers. Der Aufwand, um das Board aufzubauen, ist sehr überschaubar; die einzige Voraussetzung ist, dass ihr wirklich an den hochkochenden Problemen arbeiten und sie lösen wollt. Das ist nicht immer selbstverständlich.
Man kann das Board dann noch beliebig ausbauen: Zum Beispiel mit einer Definition von „Problem gelöst“, mit einfachsten Kennzahlen, mit einer Einladung zur Beteiligung von Mitarbeitern/Kollegen, unterschiedlichen (Auswirkungs-)Klassen etc. Empfehlenswert ist jedoch, einfach anzufangen und bei Bedarf und stückweise Veränderungen am Board vorzunehmen.
Ihr seht, das Impediment Board ist ein ganz simples Hilfsmittel für die konsequente Beseitigung von Hindernissen. Probiert es aus! Wir freuen uns, wenn ihr eure Erfahrungen mit uns teilt.

Dieser Beitrag ist im Pair Writing mit Faruk Ince entstanden.