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.

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.

Scrum Meetings – Daily (Scrum)

A very important meeting is the Daily, where teams come together for 15 minutes every day, to discuss next steps on how to reach their sprint goal. It is no longer just about what have I done yesterday, what will I do today and what impediments are in my way…  
Find out how this meeting has evolved from its origins to a new agile version in my how-to video.

Scrum Meetings – Sprint Planning #1

In this video I talk about the Sprint Planning #1 meeting, which is used to create a common understanding and a mutual agreement on what the team will accomplish. Further I explain why it is essential to decompose all user stories based on five critical aspects. 
Curious? Then come and join me in my agile how-to video! 

Die Retrospektive: Maßnahmen einfach tracken

Donnerstagnachmittag, Retrospektive bei einem Automotive-Kunden. Der Gong schlägt, die Timebox ist vorbei. Ich blicke überrascht auf die Resultate: Viele Vorschläge, aber keine wirklich konkrete Maßnahme. Vor allem keine, die man in einem Sprint umsetzen könnte.
Was nun? Klassische Frage: Halte ich die Timebox? Nach dem Prinzip: „Schade, schön wäre es gewesen. Learning fürs nächste Mal.“ Oder fokussiere ich mich auf den Zweck des Meetings: Wir wollen unseren Prozess verbessern. Ich entscheide mich für den Zweck und gebe uns noch einmal 10 Minuten.
10 Minuten später.
Nachdem wir kurz in eine offene Diskussion zurückgefallen sind, haben wir zwei konkrete Maßnahmen abgeleitet. Ich lasse das Meeting abschließend bewerten und beende es. So weit so gut, das Meeting war erfolgreich. Wie geht es nun weiter?

Leichen vergraben?

Ich habe mir vorgenommen, alles gut zu dokumentieren. Auch wenn das Fotoprotokoll wahrscheinlich eine Leiche im SharePoint bleibt. Was mich eher beschäftigt ist: „Was waren eigentlich die Maßnahmen der Retrospektive einen Sprint zuvor?“ Ich kann mich nicht daran erinnern und noch schlimmer, eine Abfrage hat es auch nicht gegeben. Das muss besser werden, denke ich mir. Diesmal tracke ich die Maßnahmen effektiv.

Noch ein Board?

Ich dachte erst an Continuous Improvement Board (CIB). Klasse Idee, oder? Ich verhandle mit mir selbst: „Viel Platz für viele Maßnahmen. Werden die auch alle umgesetzt in einem Sprint? Naja vielleicht brauchen sie ja mehrere Sprints. Aber dann sind die Maßnahmen einfach nicht konkret genug. Ein weiteres Problem beim CIB: Es ist ein weiteres Artefakt. Ich hänge es gleich neben die wenig beachtete Definition of Ready und die kaum benutzte „Waste-Wall“.

Oder einfach nur ein Task?

Die besten Lösungen sind die einfachsten. In einem früheren Team hatte ich am Taskboard eine eigene Swimlane mit dem Namen „Kaizen“. Das war gut, aber ich suche die Herausforderung: Geht es noch einfacher? Ohne Verlust von Effektivität? Ich entscheide mich dafür, Tasks zu erstellen. Simpel, nachvollziehbar und transparent. Weiterer Vorteil: Die Maßnahmen werden nun täglich im Daily mitverfolgt, und zwar instinktiv.
Mein Learning: Die einfache Lösung ist oft weniger intuitiv, aber durchdachter als die komplexe.

Video: Das Daily Scrum – reinvented

 
Mich hat lange Zeit die Frage umgetrieben: “Wie lässt sich die Zusammenarbeit in Teams noch besser synchronisieren?” Die Antwort ist ganz einfach: Aus Daily Scrums werden Mini-Reviews und aus diesen wird wiederum ein kontinuierliches gemeinsames Arbeiten an einer einzigen Sache. Dann braucht man keine Daily Scrums mehr und ist noch einmal wesentlich produktiver.
Im folgenden Video erkläre ich die Ideen dazu und dann liegt es an euch, es einfach zu tun.
Viel Spaß beim Abschaffen der Daily Scrums/Standups!
Boris
 

Video: Retrospektiven

 
Bei diesem Video werden sich in der Community der Retrospective Facilitators sicher viele Stirnen runzeln und agile Coaches werden mir sagen, wie falsch ich doch liege. Dennoch: Ich sage euch hier mal, wie ich über Retrospektiven denke.
Ich bin der Meinung: Viele von uns haben aus vielerlei Gründen die Retrospektiven zu einer neuen Kunstform erhoben und dadurch zu einem Selbstzweck gemacht. Ich möchte euch empfehlen, noch einmal darüber zu reflektieren, ob wir nicht wieder zur eigentlichen Idee zurückkehren und die lautet: einfache Retrospektiven durchführen – ohne viel Schnickschnack.
Im Video findet ihr meine Begründung dazu.
Boris
 

Video: Sprint Planning # 2

 
Meine Auffassung des Zwecks des Sprint Planning Meetings # 2 ist radikal. Vielleicht muss man zu den ersten Scrum Evangelisten gehört haben, um diesen radikalen Ansatz aufrecht zu erhalten, der quer zur Auffassung vieler anderer liegt.
Aus meiner Sicht geht es beim Sprint Planning # 2 um eine einzige Sache: Es soll die Frage geklärt werden, wie man innerhalb gegebener Parameter – Zeit, Geld, Technologie – eine agile Lösung findet. Oder anders gesagt: Wie kann man alles das liefern, was man im Sprint Planning # 1 versprochen hat? Auf diese Weise müssen Entwicklungsteams kreativ werden, sich neue Dinge ausdenken. Ja, das ist hart, aber es macht auch irren Spaß.
Viel Spaß beim Anschauen — Boris
 

Video: Sprint Planning

Was macht man in einem Sprint Planning # 1 und wie hängt es mit dem Backlog Refinement zusammen? Bitte nutzt dieses Meeting zur Analyse dessen, was der User tatsächlich braucht. Dann ist dieses Meeting nämlich produktiv und wertvoll – ansonsten ist es nur rausgeschmissene Zeit.
Mehr dazu in diesem Video.
 

5 Punkte für ein effektives Daily

Scrum ist ein hocheffizientes Rahmenwerk für die Produktentwicklung, sofern es richtig gelebt wird. Leider erleben wir zu oft das Gegenteil. Die Scrum Meetings werden prozessual etabliert, aber es fehlt am qualitativen Mehrwert, der durch die Meetings entstehen sollte.
Immer wieder sehen wir Dailys, in denen der ScrumMaster vor dem Board steht, als gelte es sein Heiligtum zu bewachen. Das Team hat im weiten Bogen um ihn herum Aufstellung bezogen und jede Person sagt einen Satz, ohne dass sich die Kärtchen am Taskboard bewegen. Fast alle Storys hängen in der WIP-Spalte und die Tasks bekommen trotz Bewegungsfaulheit keinen Punkt dafür. Der Product Owner vergibt bei Gelegenheit noch Aufgaben an einzelne Teammitglieder und fährt anderen Teammitgliedern über den Mund.
Ein so oder so ähnlich durchgeführtes Daily ist leider ein sehr ineffizientes Daily. Gut, immerhin ist das Daily als Meeting etabliert. Es wäre weitaus schlimmer, wenn das Meeting überhaupt nicht stattfinden würde. Da es stattfindet und das auf eine transparente Art und Weise, können wir anfangen, es in eine effektive Richtung zu lenken.

1. Daily als Ort der Kommunikation

Das Daily ist KEIN Statusreport für den Product Owner und auch nicht für den ScrumMaster. Das Daily ist da, damit sich das Dev-Team austauschen und koordinieren kann. Die Mitglieder des Dev-Teams sprechen miteinander und erklären sich gegenseitig, was sie machen, wo sie bei der jeweiligen Story noch Hilfe brauchen bzw. wo es sinnvoll ist, im Pairing zu arbeiten. Der ScrumMaster achtet darauf, dass das Ganze im zeitlichen wie auch menschlichen Rahmen bleibt und ist hellhörig bezüglich Impediments. Der Product Owner steht für Rückfragen zu den Akzeptanzkriterien zur Verfügung oder kann sich einbringen, wenn er das Gefühl hat, dass das Dev-Team über das Ziel der Akzeptanzkriterien hinausschießt.
Umsetzung: Der SM fordert die Teammitglieder auf, vor dem Taskboard zu stehen und stellt sich selbst mit den Product Owner in den Hintergrund. Wenn der ScrumMaster oder der Product Owner in den Mittelpunkt der Kommunikation rutschen, erklärt der ScrumMaster wiederholt, dass das Daily nicht dazu da ist, um ihn oder den Product Owner auf den neuesten Stand zu bringen. Das Daily dient dem Informationsaustausch zwischen den Teammitgliedern. Der ScrumMaster hält bei Bedarf wiederholte Mini-Workshops ab, um den Sinn eines Dailys zu erläutern und coacht bei Bedarf den Product Owner in seiner Rolle.

2. Das Herz des Dailys – Aufbau des Tasksboards

Ein Taskboard besteht aus drei Spalten: To do, Work in Progress (WIP) und Done – nicht mehr und nicht weniger. Die horizontalen Zeilen ergeben sich aus den Storys, wo die Tasks zugeordnet sind.
Umsetzung: Der ScrumMaster baut ein Taskboard auf. Unsere beliebtesten Hilfsmittel sind: Pinnwände oder Metaplanwände, die mit Kreppband oder Garn und Stecknadeln in die Bereiche aufgeteilt werden. Moderationskarten sind optimal für die Spaltenüberschriften und die Storys, während verschiedenfarbige Post-its und Stifte das tägliche Aktionsmaterial sind.

3. Die Fragen für das Daily

Man orientiert sich an den 4 Fragen:

Diesbezüglich gibt es mehrere Optionen. Entweder man geht diese Fragen pro Teammitglied oder pro Story durch. Ich persönlich präferiere letzteres: Letztendlich geht es darum, zu sehen, ob die Storys fertiggestellt werden können und nicht darum, dass alle Teammitglieder ausgelastet sind. Wer etwas Neues ausprobieren will, geht einen Schritt weiter und lässt die Teammitglieder herzeigen, was Sie bereits produziert haben, sodass jedes Daily zum Mini-Review wird.
Umsetzung: Der ScrumMaster achtet darauf, dass zu jeder Story/Person die Fragen beantwortet werden. Wenn etwas vergessen wird, erinnert er daran. Die Fragen auf Moderationskarten neben dem Taskboard aufzuschreiben, ist eine einfache und gute Erinnerungsstütze. Beim Mini-Review sorgt der ScrumMaster dafür, dass die Teammitglieder zwischen den Präsentationen zum Taskboard zurückzugehen, um es auf den neuesten Stand zu bringen. Der ScrumMaster sorgt dafür, dass die Timebox von 15 Minuten eingehalten wird, indem er die Leute daran erinnert, sich kurz zu halten bzw. eine Uhr mitlaufen lässt, die alle daran erinnert, wie viel Zeit noch übrig ist. Tipp: Es gibt Timebox-Uhren mit kleiner werdendem Zeitbereich zu kaufen.

4. Das Team bewegt sich, nicht der ScrumMaster

Das Team bewegt die Tasks über das Taskboard. Wenn ein Task done ist, sollte er auch wirklich done sein und nicht mehr zurückkommen. Dabei hat jeder Task ein Namenskürzel. Auch wenn wir Consultants als ScrumMaster arbeiten, können wir uns nicht immer merken, wer von uns welchen Task erstellt hat – mit Namenskürzel auf dem Task hat man aber immer eine Anlaufstelle, wenn man sich über Sinn und Zweck eines Tasks im Unklaren ist. Sollte sich ein Task nicht in die nächste Spalte bewegen, bekommt er jeden Tag einen Punkt und zwar von den Teammitgliedern. Der ScrumMaster achtet auf diese Tasks und fragt während oder nach dem Daily, ob es ein bestimmtes Impediment gibt, das die Fertigstellung des Tasks behindert, oder ob der Task einfach nur zu groß ist.
Umsetzung: Der ScrumMaster bittet die Leute, selbst die Tasks zu schreiben und zu bewegen und reicht dabei auch gerne die Stifte. Auch wenn es sich am Anfang unangenehm anfühlt: Der ScrumMaster bittet die Leute wiederholt höflich (oder auch direkter), die Tasks selbst zu schreiben, zu bewegen und Punkte zu machen. Irgendwann wird er es nicht mehr tun müssen, weil es die Leute selbst tun werden.

5. Flow

Es wird immer daran gearbeitet, so wenige Storys wie möglich offen zu halten und so wenige Tasks wie möglich in progress zu haben. Im Allgemeinen gilt es, sich immer in die Richtung des Optimums einer offenen Story zu bewegen und eine Taskanzahl in progress zu haben, die geringer oder gleich der Anzahl der Teammitglieder ist. Wir wissen alle, dass Multitasking ineffizient ist und wir wollen einen schnellen Feedback-Loop mit dem Product Owner erzeugen. Sobald eine Story abgeschlossen ist, nimmt der Product Owner sie ab bzw. gibt Feedback, warum sie nicht abgenommen werden kann.
Umsetzung: Der Scrum Master vereinbart mit dem Team ein WIP-Limit auf Story-Ebene oder gibt eines vor. Er sorgt dafür, dass das WIP-Limit eingehalten wird, indem er es nicht zulässt, dass weitere Storys eröffnet werden. Sobald eine Story fertig ist, sorgt er oder sorgen die Teammitglieder dafür, dass der Product Owner davon erfährt. Der ScrumMaster sorgt dafür, dass es bald Feedback gibt, ob die Story abgenommen wird oder was die Abnahme verhindert.
 
Es gäbe noch viel mehr dazu zu sagen, aber diese fünf Punkte sind für mich die Basis für jede weitere Aktion – sie erschaffen im Kern eine gesunde Daily-Kultur. Dabei ist es wirklich schwierig, diese Punkte alle im Kopf zu behalten und kontinuierlich zu kontrollieren. Es ist ein Idealbild, dem man sich im im Laufe der Zeit annähern kann. Im Laufe der Entwicklung des Scrum-Prozesses wird der ScrumMaster immer mehr seiner Verantwortung an die Teammitglieder abgeben, sobald er sieht, dass sie das Konzept verinnerlicht haben. Am Anfang jedoch muss er durch Vorzeigen, Vorleben und häufiges Erklären die Grundlage und das Verständnis für die Vorgänge schaffen, die für langfristige Produktivität sorgen.