Agile Coaching-Tipps von it-agile (2)

Von Henning Wolf, Februar 2016

Schon vor einiger Zeit hatte ich in einem Projekt mit einer großen Produktentwicklung zu tun - knapp 100 Developer in 10 Teams. Es gab grob eine fachliche Zuordnung der Teams zu bestimmten Modulen des insgesamt schon sehr großen Softwaresystems (Java). Immer mal wieder tauchte das Problem auf, dass es Anforderungen gab, für die bestimmte Ecken des Systems geändert oder erweitert werden mussten, mit denen sich nur wenige Developer auskannten. Das machte die Entwicklung langsam, weil um diese Abhängigkeiten von einigen Spezialist:innen herum geplant werden musste. Uns schien es zumindest auf Teamebene sehr klar, dass etwas unternommen werden muss. Und leider war auch klar, dass es Geld kosten würde bzw. erstmal noch langsamer macht. Ein Okay des Managements war also unumgänglich. Uns war aber auch klar, dass wir dafür genauer benennen können müssen, wo das Problem liegt und woran man erkennne würde, dass es besser geworden ist.

Deshalb haben wir das aktuelle Architekturbild hergenommen und eine Abfrage unter allen 100 Developern gemacht, wie gut sie sich - in Schulnoten ausgedrückt - in den jeweiligen Teilen des Systems auskennen. Dazu haben wir uns eine Farbmarkierung ausgedacht, wie wir welches Modul in Abhängigkeit von der Durchschnittsnote (oder Anzahl Leuten, die besser als 4 vergeben haben) einfärben.
Das Bild war nicht ganz so erschreckend, wie wir gedacht haben, zeigte aber klare Hotspots, an denen dringend mehr Know-how aufgebaut werden musste. Das war über die Visualisierung (ähnlich nebenstehend) auch für Manager leicht nachvollziehbar.

Zudem konnten wir nach einiger Zeit die Umfrage erneut durchführen und die Verbesserungen über die Zeit beobachten.

Von Henning Wolf, März 2016

Ein it-agileKollege hat bei einem unserer Kunden folgendes erlebt:
Der Kunde stellt ein Produkt her und hat seine Produktentwicklung in Teams organisiert, die jeweils für die Entwicklung bestimmter fachlicher Aspekte des Produktes zuständig sind. Alle Teams hatten damit zu kämpfen, dass es sehr viele Stakeholder gab mit sehr vielen (bestimmt guten) Ideen. Da waren die Fachabteilungen, das Marketing, der Kundenservice und auch noch die anderen Teams. Das führte zu sehr langen Listen von Wünschen, was die Teams erledigen sollten, vielen Umprioriserungen auf dieser Liste und vielen Nachfragen, wann denn mit bestimmten Features zu rechnen sei.

Du kannst dir vielleicht vorstellen, dass all diese Wunschlisten, Umpriorisierungen und Nachfragen weder das Team schneller noch die Stakeholder glücklicher gemacht haben.
Eines der Teams hat deshalb für sich beschlossen, dass es so nicht weitergehen könne. Sie haben im Entwicklungstakt von zwei Wochen ein offenes Priorisierungsmeeting anberaumt. Zu diesem Meeting waren alle Stakeholder und letztlich alle in der Firma herzlich eingeladen. Das Team hatte die Erfahrung gemacht, dass es sinnvollerweise nicht an mehr als 2-3 neuen Features gleichzeitig arbeiten kann und noch nie mehr als 6 neue Features in zwei Wochen fertiggestellt hat. Beim ersten Priorisierungsmeeting war der Entwicklerraum voll mit Stakeholdern und das Team erklärte seine neuen Spielregeln: Keine Liste mehr, hier und jetzt wird über die zwei Sachen entschieden, die wir definitiv als erstes bearbeiten und mit sehr hoher Wahrscheinlichkeit in zwei Wochen fertig haben. Zusätzlich nehmen wir gerne noch 3 weitere Themen mit und beginnen mit denen, wenn es geht. Wenn nicht, bringen wir die Themen ins nächste offene Priorisierungsmeeting wieder mit und müssen gemeinsam neu entscheiden.

Was sich im Folgenden entspann, war eine sehr nützliche Diskussion der Stakeholder untereinander, welches Feature für das Unternehmen am wichtigsten sei. Das war für die ersten 2 bis 3 Features meist einfach zu entscheiden. Und insbesondere war es für die Stakeholder einfacher zu entscheiden als für das Entwicklungsteam.

Diese Art der Priorisierung war für die Stakeholder eine Umstellung, aber insgesamt ist sie sehr erfolgreich. Ich habe letzte Woche mal nachgefragt, das Team macht es heute noch genauso. Es ist eines der erfolgreichsten und beliebtesten Teams, weil es sehr zuverlässig liefert. Dank der offenen Priorisierungsmeetings sogar zuverlässig das wichtigste, was gerade ansteht.

Mein Kommentar: So ist es clever! Die Stakeholder erkennen so, dass es nicht primär am Entwicklungsteam liegt, wenn sie etwas nicht (jetzt) bekommen, sondern an den anderen Stakeholdern und unternehmensweiten Priorisierungen. Zudem müssen sie sich selbst darum kümmern, dass ihre für sie und das Unternehmen wichtigen Themen erledigt werden. Das hält sie vermutlich auch davon ab, sich parallel noch mehr Dinge auszudenken. Oder die neuen Ideen dann auch schon selbst als ihre neuen allerwichtigsten Themen mitzubringen.
Ich weiß aber auch, dass du jetzt vielleicht denkst, dass das so bei dir und eurer Konstellation leider nicht möglich ist. Das glaube ich auch. Gleichzeitig solltest du aber die Anregung mitnehmen, darüber nachzudenken, wie die Stakeholder untereinander ihre Prioritäten im Sinne des Gesamtinteresses selber abgleichen können. Zudem würde ich dir empfehlen, nicht der Verwalter von Stakeholderideen zu werden. Das sollten und können sie gut selber erledigen.

Von Alex Bepple, April 2016

Die Bereitschaft zu Agilität war da, es war auch schon mit einer an Scrum angelehnten iterativen Entwicklungsweise gestartet worden. Da stellte sich sehr schnell die Frage, wie wir mit dem Aufwand für das Testen umgehen wollen. Immer nur manuell testen und das in so kurzen Zyklen, das ist keine Lösung. Es war also klar: Wir müssen etwas in Richtung Testautomatisierung tun. Aber was genau und womit beginnen? Darüber gab es in vielen Meetings sehr viele Ideen, viele Diskussionen. Es wurden viele Probleme identifiziert und Spekulationen darüber angestellt, warum und ob eine Lösung überhaupt funktionieren könnte. Zudem begannen Gespräche damit, welche Voraussetzungen erst geschafft werden müssten, bevor man damit beginnen könnte.
Da habe ich mir einen der Entwickler geschnappt, der sich mit dem System und den Gepflogenheiten des Hauses gut auskannte und mich mit ihm abends verabredet. Zu zweit haben wir den ersten Test binnen knapp zwei Stunden automatisiert.

Dieser erste Test hat die Diskussionen total verändert. Schluss mit der Theorie! Es gab einen ersten konkreten Bezugspunkt, es gab keine Ausreden mehr, was man noch klären müsste und bedenken sollte. So ging es los mit der Testautomatisierung.

Dabei will ich gar nicht behaupten, dass es immer so glatt laufen wird. Es hätte natürlich schiefgehen können. Aber dann hätten wir jedenfalls gewusst, welche Bedenken stimmen und mit welchen Problemen wir uns wirklich beschäftigen müssen. Ich habe mir trotzdem gemerkt, dass ich langwierige Diskussionen lieber in die Richtung lenken will, den ersten kleinen Schritt zu machen, auf dessen Grundlage wir besser weiterdiskutieren können.

Von Doreen Timm, Mai 2016

Die Situation war so: Wir waren ungefähr in der Mitte des Sprints, ich habe als Scrum Master ein Daily Scrum moderiert. Bei uns nimmt natürlich auch der Product Owner am Daily Scrum teil. Es kam zwischen den Developern und dem PO zu einem lautstarken Streit über ein Feature. Den Developern ging es um die Ausprägung des Features, die technische Umsetzung und die dahinterliegende Architektur. Schnell schlugen die Wogen hoch: Ist das Feature so überhaupt sinnvoll? Was daran schafft denn dem Kunden Wert?

Dabei war bei diesem schnellen Schlagabtausch zu spüren, dass der Druck im Team hoch ist. Alle waren einerseits auf der Suche nach einer schnellen, knackigen Lösung, andererseits wurde bald schon nicht mehr nur dieses eine Feature, sondern das ganze Sprintziel infrage gestellt. Diese Eskalation im Daily Scrum ereignete sich in nicht einmal 10 Minuten. Ich habe schließlich als ScrumM aster interveniert und die Hektik und den Druck aus der Diskussion genommen. Dazu habe ich das Sprintziel auf ein Flipchart geschrieben und jeden im Team reihum gebeten, dass er in seinen Worten beschreibt, was das für ihn bedeutet, während alle anderen aufmerksam zuhören. Das fühlte sich für die meisten erst wie ein Rückschritt an, weil die Geschwindigkeit aus der Diskussion raus war. Darüber konnten wir aber sehr schnell feststellen, dass es zu der Frage Einigkeit gab, die den Konflikt ausgelöst hat. Mental hatten wir uns alle auf eine längere Diskussion eingestellt, waren aber schon nach einer Viertelstunde damit durch. Gemeinsam erstaunte uns, wie gut es uns getan hat, das Tempo und den Lösungsdruck aus der Diskussion zu nehmen. Nur so konnten wir zu einer neuen, besseren Lösung für unser Problem gelangen. Herrlich, wenn man mit der Entdeckung der Langsamkeit neue Optionen schafft.

Von Henning Wolf, Juni 2016

Kurt Lewin hat einmal gesagt: „Es gibt nichts Praktischeres als eine gute Theorie.“ Darüber sprachen wir letzte Woche, als ich an der Denkwerkstatt Komplexithoden mit Niels Pfläging teilgenommen habe. Wir haben über viele der guten Anregungen aus dem Buch Komplexithoden diskutiert und kamen bei Problembeschreibungen oder Herausforderungen immer wieder darauf, wie schwer es ist, einen systemischen Blick zu behalten. Das soll für unseren Zweck hier erstmal nicht mehr bedeuten als die Einsicht, dass in Organisationen das meiste zu beobachtende Verhalten am System und seinen Regeln, Prinzipien, Bedingungen liegt, nicht an den Menschen selbst. Je nach Autor liegt der direkt den Menschen zuzuordnende Anteil der Probleme bei 1 % bis max. 15 %. Diese Erkenntnis muss sich in unseren Lösungen und Veränderungen widerspiegeln.

Ich weiß nicht, wie es dir damit geht, aber ich neige schon dazu, Leute als Problem zu sehen. Ich denke Sachen wie „der kann das nicht“, „die versteht das nicht“ oder “die beiden sind da eine Fehlbesetzung“. Ich könnte sogar recht haben, es nützt mir nur wenig. Denn ohne die systemische Sicht kann ich dem Problem nicht auf den Grund gehen: Was in unserem System hat dazu geführt, dass die Situation so gekommen ist, wie sie gekommen ist? Dem kann man sich z. B. mit der „5-Why-Methode“ nähern, also so oft „Warum“ fragen bis man bei der Wurzel des Übels angekommen ist. Dadurch wird man Spielregeln oder Rahmenbedingungen des Systems verändern und so personenunabhängig die Organisation besser machen.

Deshalb sind Theorien so nützlich, weil sie uns zwingen, den Schritt heraus zu machen. Das System von Außen zu beobachten. 

Von Henning Wolf, Juli 2016

Stellen wir uns folgende Situation vor: Wir haben zwei Teams, die ungefähr dasselbe leisten können und aktuell mit unterschiedlichen Projekten betraut sind. Jetzt kommt ein neuer Kunde und wir wollen auch diesen bedienen. Technologisch und fachlich ist der Rahmen für den neuen Kunden derselbe, den unsere beiden Teams verwenden und gut beherrschen.

Ansatz 1: Lösung
Ich bin persönlich ein großer Freund stabiler Teams. Als Manager bin ich froh, dass die Teams gut funktionieren. Ich will sie deshalb nicht auseinanderreißen. So entscheide ich, dass eines der Teams den neuen Kunden übernimmt. Ich vermute, dass perspektivisch die aktuellen Aufgaben von Team 2 weniger werden, weil deren Produkt im Produktlebenszyklus weiter ist. Ich gebe deshalb Team 2 den neuen Kunden. Die sind vermutlich nicht begeistert und fühlen sich ungerecht behandelt, aber mit gutem Zureden werden sie das schon machen. Im Hinterkopf merke ich mir, dass Team 2 bei mir etwas gut hat und die nächste Belastung für Team 1 reserviert ist.

Ansatz 2: Problem und Rahmen
Ich spreche mit beiden Teams (oder Teamvertreter:innen). Ich gebe ihnen das Problem. Zudem setze ich einen möglichst klaren Rahmen für die Lösung, z. B. Teamstabilität. Ich stehe bereit, um Lösungsvorschläge zu diskutieren, vielleicht behalte ich mir sogar vor, am Ende die Entscheidung zu treffen. Aber ich erwarte mindestens einen Vorschlag, wie wir den neuen Kunden bedienen können.

Diskussion
Ich persönlich neige zu Ansatz 1, weil ich ungeduldig bin und mich für wirklich schlau halte und tolle Ideen habe. Dafür erlebe ich aber auch, dass Ansatz 1 zu weniger Verantwortungsübernahme für die Lösung führt. Und jede ungeklärte Detailfrage zur Lösung wieder bei mir aufläuft.
Deshalb weiß ich, dass es wirklich schlau wäre, wenn uns öfter Ansatz 2 gelingt. Denn er birgt die Chance, dass wir auf bessere Lösungen kommen, weil die handelnden Personen selbst (in unserem Fall die Teammitglieder der beiden Teams) Wissen und Ideen haben, die ich nicht hatte. So könnte die Lösung sein, dass der Schmerz geteilt wird. Vielleicht verantwortet Team 2 heute eine gemeinsame API der beiden Teams, die Team 1 übernimmt, wodurch zumindest etwas mehr Freiraum für Team 2 entsteht, um den neuen Kunden zu bedienen.
Es ist nicht leicht, den Rahmen ausreichend gut zu beschreiben. Entweder man vergisst Wesentliches oder macht ihn so eng, dass die Lösung alternativlos wird. So bietet es sich vielleicht an, dass man zusammen eine Lösungsdiskussion führt und die entstehenden Lösungen mit ihren Konsequenzen gemeinsam durchdenkt. Dabei ist es wichtig, dass man Ideen, die auf den ersten Blick absurd scheinen, nicht zu früh ausschließt.

Das Tolle an diesem Tipp: Ich habe dir damit nur ein Problem und einen Rahmen gegeben, die Lösung für dich/euch musst du selber finden.

Von Wolfgang Wiedenroth, August 2016

Auf dem Kanban Leadership Retreat Anfang Juli in Barcelona habe ich eine tolle Umfragetechnik gelernt, die ich gerne mit dir teilen möchte. Es geht um die Frage, ob unser angebotener Service (oder unser Produkt, unsere Entwicklung, Schulung etc.) eigentlich seinen Zweck erfüllt. In der Kanban-Welt sprechen wir von „fit for purpose”.

Um den Stand der Fitness herauszufinden, hilft uns meist eine rein quantitative Aussage wie eine Schulnote wenig. Deswegen sammeln wir an zwei Stellen auch qualitative Daten: 1. Was war denn eigentlich der Zweck? 2. Wie kam es zur Beurteilung, dass dieser Zweck eben so erfüllt wurde und nicht besser oder schlechter.

Die Umfrage sieht wie folgt aus:
a) Zu welchem Zweck hast du [diese Schulung besucht | dieses Produkt verwendet | an diesem Meeting teilgenommen | diesen Newsletter gelesen]?
b) Wie gut wurde dieser Zweck erfüllt:
5 – vollständig erfüllt und sogar übertroffen
4 – vollständig erfüllt
3 – im Wesentlichen erfüllt, ein paar kleinere Bedürfnisse nicht erfüllt
2 – wesentliche Bedürfnisse nicht erfüllt
1 – wenig, etwas wert, aber die meisten Bedürfnisse nicht erfüllt
0 – nichts Nützliches, für den Zweck ungeeignet
c) Wieso hast du bei b) genau diese Antwort gegeben?

In der Auswertung fasst man die Werte wie folgt zusammen:
5 und 4 – für den Zweck angemessen
3 – neutral
2, 1, 0 – für den Zweck unangemessen

Die Ergebnisse werden als ein sogenannter Box-Score notiert, also z. B. [75 - 10 - 15] (18/20) mit der Bedeutung, dass 75 % gesagt haben, dass der Service für den Zweck angemessen ist, 10 % neutral und 15 % den Service für nicht angemessen halten. Dahinter steht, dass 18 von 20 Befragten eine Antwort gegeben haben.
Der Vorteil des Box-Score gegenüber einem Durchschnitt liegt auf der Hand, wenn man folgende Werte vergleicht: [50 - 0 - 50] und [0 - 100 -0]
Beide ergeben einen Druchschnitt von 0, aber das Ergebnis mit 50 %, die es für den Zweck angemessen halten ist vermutlich besser. Man könnte daraus z.B. auch schließen, dass man die 50% der unzufriedenen Kunden zukünftig nicht mehr bedienen sollte.

Man könnte die Umfrage noch so erweitern, dass mehr als ein Zweck angegeben werden kann. So erhält man noch detailliertere Ergebnisse.

Von Stefan Zumbrägel, September 2016

Mein Team arbeitete in einem skalierten Umfeld mit weiteren Teams in einer Multi-Projekt-Umgebung. Alle Teams waren Komponententeams mit jeweils etwas Grundwissen über die anderen Komponenten. Dadurch waren die Teams trotz der bestehenden Abhängigkeiten in der Lage, zu einem gewissen Grad autonom zu arbeiten. Innerhalb ihrer Komponente waren die Teams für den kompletten Prozess bis zu Produktivsetzung und den anschließenden Support zuständig.

Da die Komponente meines Teams eine sehr zentrale in dem System war und sich einige Teammitglieder zudem in den bestehenden Communities of Practice engagierten, kam es immer wieder vor, dass Personen aus anderen Teams oder aus dem Linienmanagement mit Fragen an einzelne Teammitglieder herantraten. Dies war im Projektumfeld und im Unternehmen die Kultur und hat zunächst aus Sicht des Teams kein Problem dargestellt.

Mit der Zeit wurden diese Anfragen aber mehr und wurden bald vom gesamten Team als Störung empfunden. Es war schwierig, im Pair Programming oder allein über einen längeren Zeitraum konzentriert an den Sprintinhalten zu arbeiten.

Das Team war in einer Zwickmühle. Man wollte auf der einen Seite die Teams unterstützen, aber selber konzentriert arbeiten. So entstand die Idee Team-Sprechzeiten in Anlehnung an Öffnungszeiten bei Behörden einzuführen. Nur in dieser Zeit stand das Team für Anfragen von außerhalb zur Verfügung. Es wurde eine Stunde pro Tag angeboten. Außerhalb dieser Zeiten wurden Anfragen freundlich, aber bestimmt abgewiesen. Konkret haben wir Schilder an den Türen mit den Sprechzeiten angebracht und zum Teil das Telefon auf den Scrum Master weitergeleitet.

Als Scrum Master war ich gerade in der ersten Zeit stark gefordert, das Team bei der Aufrechterhaltung dieser Regel zu unterstützen. Zum einen moralisch, zum anderen vor allem in der Argumentation mit und gegenüber den anfragenden Personen. Diese „Pförtnerrolle“ war nach einer Eingewöhnungszeit nicht mehr notwendig.

Das Ergebnis war sehr positiv. Wenig überraschend: Das Team konnte in der ungestörten Zeit viel effizienter und stressfreier arbeiten. Die Anzahl der Anfragen ging stark zurück. Es wurde nicht untersucht woran das lag, die Vermutung ist aber, dass selber Lösungen gefunden oder Anfragen gebündelt wurden und damit besser beantwortet werden konnten. Außerdem gab es viel positive Resonanz für die konsequente Umsetzung. So kam aus anderen Teams die Rückmeldung, dass es so zwar einen kleineren Zeitraum gibt für Fragen, dafür aber auf jeden Fall jemand da ist und sich Zeit für die Anfrage nimmt.

Von Wolfgang Wiedenroth, Oktober 2016

Es geht um ein Adminteam mit elf Teammitgliedern, die mit Kanban und einem physikalischen Kanban-Board arbeiten. Schon auf den ersten Blick kann man am Board die vielen roten Post-its sehen, die wir als Markierung für geblockte Tickets benutzt haben. Wir haben außerdem eine gemeinsame Regel festgelegt, dass wir auf die Blocker den Grund für die Blockade schreiben. Dies hat uns erlaubt, systematisch auszuwerten, wo die Blocker herkommen und was sie bewirken. Wir hatten in vier Wochen 86 Blocker, die in Summe zu 516 Tagen Blockzeit geführt haben!

Diese Blocker haben wir dann nach Art und Gründen geclustert, was zu sehr nützlichen Erkenntnissen darüber geführt hat, welche typischen Ursachen zugrunde liegen. Dabei hat es sehr geholfen, sich auf die größten Cluster mit den meisten und längsten Blockaden zuerst zu stürzen und dafür Verbesserungsmaßnahmen zu finden. Das hat in der Folge zu deutlich weniger Blockaden und besseren Durchlaufzeiten geführt. Bei einem der großen Cluster hat eine Besprechung mit einem der Abteilungsleiter geholfen: In den nächsten Wochen waren schon prompt und ohne großen Aufwand ein Drittel weniger Blocker aus diesem Bereich, weil dort die Prozesse entsprechend verändert werden konnten.

Von Claudia Reitenbach und Peter Rößler, November 2016

Du hast dein Meeting vorbereitet und überlegst, wie du methodisch vorgehen willst. Prima! Im Meeting erklärst du der Gruppe, was als Nächstes passiert und willst anschließend den Startschuss zu einer Aktivität geben. Du richtest Dich an die Gruppe: „Könntet ihr vielleicht dazu bitte aufstehen?“. Die Reaktion: Stille. Kaum einer rührt sich oder die Gruppe reagiert nur zögerlich. Kennst Du das auch?

Ein einfacher Tipp, der Klarheit und Orientierung schafft: Mache ganz konkrete und direkte Ansagen an die Gruppe. Kein „vielleicht“, kein „könntet“ , kein „würdet“ oder sonstige Abschwächungen, sondern ein klares „Steht jetzt bitte alle auf!“ (evtl. unterstützt mit einer passenden Geste). Beobachte doch mal in deinem nächsten Meeting, wie klar deine Moderation ist. Für viele fühlt es sich oft erstmal befremdlich an, so direkt und forsch zu sein. Du wirst aber schnell merken, dass es der Gruppe ungemein hilft, klare Ansagen zu bekommen. Wenn es dir schwerfällt, die konkreten Ansagen im Meeting zu finden, schreibe dir die Ansagen in der Vorbereitung auf oder übertrage sie in deinen Ablaufplan der Moderation. 

Von Stefan Zumbrägel, Dezember 2016

Mein Team arbeitete in einem Konzernumfeld gemeinsam mit anderen Teams an einem großen Programm. Das Team war sowohl für die Entwicklung neuer Funktionen als auch für den Support von bestehenden Funktionen verantwortlich.
In dem Programm gab es die Vereinbarung, dass Supporttickets in bestimmten Zeiten bearbeitet werden mussten, unabhängig von der Sprintplanung.

Die Supporttickets wurden von meinem Team am Sprintboard transparent dargestellt und im Daily, wie Tasks aus den Storys, gezogen und geplant. Allerdings führte das zu einer Fragmentierung des Teams, die sich vor allem darin zeigte, dass die gemeinsame Arbeit an Storys sehr stark zurückging. Es gab keine Zeit, in der das gesamte Team gleichzeitig an den Storys arbeitete. Das erschwerte das Pair Programming sowie Rückfragen an andere Teammitglieder, da diese evtl. mit einem Supportticket an einer ganz anderen Stelle unterwegs waren und sich jedes Mal wieder in die Story hineindenken mussten.

Das Team war damit sehr unzufrieden. Vor allem weil es das Gefühl hatte, viel Zeit mit Warten oder Umdenken zu verbringen. Es fühlte sich zwischen den verschiedenen Erwartungen von außen und von sich selbst zerrieben.

Die Lösung des Dilemmas wurde unter dem Titel „Storyblocker“ entwickelt. Zunächst einmal war das ein simpler Eintrag in allen Kalendern der Teammitglieder am Vormittag zwischen Daily und Mittagessen. Damit einher ging die Vereinbarung des Teams, in dieser Zeit ausschließlich an Storys zu arbeiten. Somit waren in dieser Zeit alle Teammitglieder gedanklich mit Storys beschäftigt. Pair Programming konnte in dieser Zeit gut gemacht werden und Rückfragen konnten gut beantwortet werden, da alle gedanklich schon in den Storythemen steckten.

Damit konnte das Team einen deutlich höheren Fokus erreichen. In einem ersten Rückblick gab das Team an, dass sich auch die Bearbeitung der Supporttickets schneller anfühlte, da es weniger Störungen durch Rückfragen zu Storys gab.

Auch als Scrum Master und Product Owner haben wir uns an diesen Blocker gehalten. Termine für Refinements oder Arbeitstermine mit dem Team zu bestimmten Themen wurden bewusst außerhalb des Storyblockers gelegt. Das Team war mit dem Blocker so zufrieden, dass sie jeglichen Versuch, in diese Zeit etwas anderes zu legen, sehr kritisch hinterfragt und im Zweifelsfall abgelehnt haben. Erfreulicherweise hat sich dies sogar auf das Linienmanagement ausgewirkt.