Agilität muss man aushalten können – Szenen aus der Praxis

1. Sackgasse Selbstorganisation – wenn keiner pullt

Auch bei borisgloger consulting richten wir den Blick regelmäßig nach innen. Retrospektiven sind für uns ein fester Bestandteil, um gemeinsam herauszufinden, mit welchen konkreten Maßnahmen wir Verbesserungen herbeiführen können. Mit zwei weiteren Kollegen übernahm ich die Planung einer dieser Retrospektiven. Die Wahl fiel auf ein Format, bei dem das Team in zwei Gruppen aufgeteilt wird, die sich am Ende die erarbeiteten Ergebnisse gegenseitig vorstellen. Warum? Weil man bei diesem Format gleich zweimal Feedback bekommt: einmal in der Teilgruppe und danach beim Vorstellen und Challengen der Ergebnisse am Ende.

Alle waren mit dem Ergebnis zufrieden. Zuletzt sollten noch die zuständigen Kollegen gefunden werden, die die erarbeiteten Maßnahmen dann angehen und umsetzen würden. Die Frage „Wer kümmert sich drum?“ stand im Raum. Schweigen. Auch nach einer Weile gab es kein „hier“ zu hören. Selbst in selbstorganisierten Unternehmen ist das nicht unbedingt überraschend. Dennoch, für einige im Team war das höchst unbefriedigend. Die Gründe für die Zurückhaltung sind vielseitig: Die eigene Priorisierung der Aufgaben, wichtige andere Commitments am gleichen Tag etc. Wie schafft man es trotzdem, die Verantwortung zu verteilen? Das Pull-Prinzip, nach dem wir arbeiten, fordert, dass die Arbeit im agilen Kontext freiwillig gezogen und eben nicht angeordnet wird.

Option A: Vielleicht werden die definierten Maßnahmen später gezogen oder auch gar nicht, wenn anderes einfach höher priorisiert ist.
Option B: Der ScrumMaster weist daraufhin, dass die Aufgabe auch gemeinsam übernommen werden kann und motiviert dadurch neuere Teammitglieder, den Sprung ins kalte Wasser zu wagen.
Option C: Der Product Owner priorisiert diese Aufgabe höher und vermittelt damit, dass die Aufgabe wichtig ist und gezogen werden sollte.

Wenn Teams mit Scrum zu arbeiten beginnen, ist das freiwillige Pull-Prinzip oft schwierig zu akzeptieren oder schwer nachvollziehbar. Ist es nicht viel einfacher, Aufgaben direkt zu verteilen anstatt zu warten? Das wäre am Anfang tatsächlich einfacher. Nur, ist es eine nachhaltige Alternative, die Aktivitäten per Ansage zu verteilen? Wie groß ist dann die Wahrscheinlichkeit, dass sie mit der notwendigen Motivation und Konsequenz umgesetzt werden? Was bleibt dafür im Gegenzug liegen? Hier braucht es Mut, unterschiedliche Optionen auszuprobieren und darauf zu vertrauen, dass die Teammitglieder eine Lösung finden werden.

2. Commitment muss gelernt werden

Gleiches Thema, anderes Setting. Ich hatte zu einer teamübergreifenden Retrospektive eingeladen. Es sollten Vertreter von zwei Teams geschickt werden. Ich erhielt die Zusage aller Kollegen und bereitete die Retro vor.

13:59 Uhr am Tag der Retro – Wir warteten auf vier Teilnehmer. Dafür hatte ein Team noch weitere Kollegen mitgebracht. Enttäuscht über das Nichterscheinen der Kollegen schlug jemand vor, die Retro abzusagen oder zumindest dafür zu sorgen, dass aus jedem Team gleich viele Personen am Meeting teilnehmen würden, damit es gerecht blieb. Das kam für mich nicht in Frage.

Ich konnte die anderen überzeugen, die Retro genau mit jenen Personen durchzuführen, die gekommen waren – ein Grundsatz, der auch im Open Space Format Anwendung findet. Mit der Aussage „Diejenigen, die kommen, sind die richtigen“ haben wir unsere Retrospektive durchgeführt und sogar die Timebox eingehalten. Es kamen tolle Ergebnisse dabei heraus und das Meeting war ein voller Erfolg!

Auch hier waren die Beteiligten erst unzufrieden mit der Situation. Und auch in diesem Fall spielt das Prinzip der Freiwilligkeit eine Rolle. Im „Open Space“ kennt man zudem das Gesetz der zwei Füße, das besagt, dass jeder nur dann erscheint, wenn er oder sie etwas lernen oder einen Beitrag leisten kann. Das war in diesem Meeting der Fall.

Agilität braucht viel Geduld und Durchhaltevermögen. Die Beteiligten dürfen die Prinzipien selbst in schwierigen Situationen nicht fallen lassen, auch wenn es Zeit braucht, bis alle an Bord sind und die agilen Werte und Prinzipien leben können.

Bis dahin gilt: In solchen Situationen muss man Agilität einfach mal aushalten können.

Foto: CC0 Creative Commons – pixabay, Pexels

Scrum Meetings – Retrospective

The final meeting within the Scrum framework is called the Retrospective. The key is to review the last iteration and determine how we can improve during the next one as a team.  
Are you curious to find out how to do a Retrospective efficiently? Watch my how-to video to find out! 

"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

Scrum4Schools an der Hochschule München: Im Review und in der Retrospektive voneinander lernen

Die neuen Abläufe in Prof. Holger Günzels Kurs Agile Management for Entrepreneurs an der Hochschule München haben sich mittlerweile eingespielt. In diesem Semester erarbeiten seine Studierenden die Studienarbeit mit Scrum4Schools. In Woche 3 dieses Kurses hat die Gruppe beschlossen, das wöchentlich stattfindende Review anders zu gestallten. Als Hauptveränderung haben sich die Studierenden darauf verständigt, die Ergebnisse jeder abgeschlossenen User Story ausgedruckt mitzubringen. Ziel war es, den kommunikativeren Austausch in der Gesamtgruppe zu fördern und mehr Feedback einzuholen. Davor hatte das Review der einzelnen Gruppen eher den Charakter eines Vortrags.

Woche 4 – voneinander lernen

Das veränderte Review

In dieser Woche läuft das Review bedeutend reibungsloser und lebendiger ab. Die Studierenden haben pro abgeschlossener User Story maximal zwei Powerpoint Slides vorbereitet. Sie haben diese ausgedruckt mitgebracht und zu Beginn der Stunde an einer der Wände im Seminarraum befestigt. Das Review beginnt. Die gesamte Gruppe formiert sich halbkreisförmig um die Ergebnisse des ersten Studierendenteams. Die Aufgabe bestand darin, herauszufinden, wie man die agile Kultur in einem großen traditionellen Automobilkonzern aktivieren kann. Während der Kurzpräsentation der Wochenergebnisse notieren viele der restlichen Studierenden ihr Feedback auf Post-its. Nach der Präsentation entsteht schnell ein Gespräch über die Lieferung. Es gibt viel positives Feedback, aber auch Ideen, wie das Team die einzelnen Punkte noch präzisieren kann sowie Anregungen zu hilfreichen weiterführenden Materialien.
Die Zeit für das Feedback ist aufgrund der acht Studierendenteams begrenzt. Diejenigen, die nicht mehr zu Wort kommen, kleben ihre Feedback-Post-its einfach zu den präsentierten Slides. Prof. Günzel ist mit den Veränderungen zufrieden: „Die Studierenden haben sich gegenseitig deutlich mehr Fragen gestellt und Feedback gegeben. Und auch zeitlich lagen wir sehr gut. So hatten wir nach dem Review genug Zeit für die Retrospektive in den einzelnen Teams.” Das Feedback von den Studierenden ist ebenfalls positiv. „Im Nachgang an den Kurs haben mir einzelne Studierenden erzählt, dass sie die Vorzüge des gegenseitigen Lernens durch diese Form der Präsentation sehr zu schätzen wissen“, sagt Prof. Günzel.

“Die Studierenden haben sich gegenseitig deutlich mehr Fragen gestellt und Feedback gegeben.”

Wann ist etwas fertig?

Mittlerweile haben die Studierenden vier Wochen an Ihrem „Produkt“ gearbeitet. Ergebnis des Kurses soll neben der schriftlichen Studienarbeit, die im Nachgang an die letzte Seminarstunde vollständig abgeschlossen wird, eine managementtaugliche Präsentation sein. Darin sollen die Studierenden ihr jeweiliges Thema ausarbeiten und präsentabel genug für einen Management-Pitch darstellen. Die Qualität der Ergebnisse der einzelnen Studierendenteams geht laut Prof. Günzel stark auseinander: „Viele Teams haben bereits die richtigen Inhalte auf ihren Folien. Aber die Form ist noch nicht für den Kontext ‚Management’ geeignet. Das fängt bei der Gestaltung der Folie an, hat aber auch viel mit der sprachlichen Ausarbeitung und präzisen Darstellung der Punkte zu tun.“
Für Prof. Günzel sind die im Review präsentierten Folien von einigen Teams noch keine abgeschlossenen und fertigen Teillieferungen des Endprodukts. Genau darin liegt aber die große Stärke von Scrum: Kontinuierlich fertige und potentiell auslieferbare Teilergebnisse zu produzieren. Entwicklungsteams, die neu mit Scrum zu arbeiten beginnen, müssen das in den ersten Sprints zunächst einmal lernen. Genauso ist es bei den Studierendenteams. Dabei hilft es, dass einzelne Teams genau das schon tun und ziemlich gute Ergebnisse im Review präsentieren. Das hilft auch den anderen Gruppen. Sie können voneinander lernen und der Qualitätsanspruch der gesamten Gruppe steigt kontinuierlich in jeder Seminarstunde.

Scrum fördert den Austausch und motiviert

Scrum fördert den Austausch und motiviert „Und das ist toll zu sehen“, findet Prof. Günzel. „Die Studierenden arbeiten engagiert mit und lassen sich auf das Experiment ein.“ Die Anwesenheit ist freiwillig, denn an der Hochschule München gibt es seit einigen Jahren keine Anwesenheitspflicht mehr in den Kursen. „Besonders in Modulen mit der Prüfungsform Studienarbeit müssen sowohl das Veranstaltungskonzept als auch die einzelnen Veranstaltungen stimmen – ansonsten kann es auch schon mal passieren, dass von 30 Studierenden nur fünf an der Stunde teilnehmen.“ Das war jedoch in diesem Seminar noch nicht der Fall. Prof. Günzel führt es auf die Interaktion mit ihm und auf die wesentlich intensivere Interaktion zwischen den Studierenden zurück. Jeder bekommt in jeder Seminarstunde kontinuierliches Feedback aus mehreren Perspektiven und entwickelt damit Stück für Stück die eigene Studienarbeit. Das motiviert offensichtlich. Wir sind auf die Endergebnisse gespannt.

Scrum4Schools an der Hochschule München: Auch Professoren lernen immer wieder dazu

Es sind noch gute zehn Minuten bis zur nächsten Seminarstunde von Prof. Holger Günzels Kurs “Agile Management for Entrepreneurs”. Rund die Hälfte der Studierenden sitzt bereits in verschiedenen Ecken des großzügigen Hörsaals, der wegen der flexiblen Gestaltungsmöglichkeiten auch „Lehrraum der Zukunft“ genannt wird. Die Studierenden diskutieren angeregt und geben ihren Präsentationenden letzten Schliff für das gleich stattfindende Review der letzten Studienarbeitsiteration. Die Gruppe arbeitet in diesem Semester mit Scrum4Schools.

Woche 3 – Verbessern und optimieren

Arbeiten mit dem Taskboard – Transparenz entsteht

Mittlerweile befinden wir uns in der dritten Woche des wöchentlich stattfindenden Seminars. In der letzten Woche hat der erste Sprintwechsel, bestehend aus Review, Retrospektive und anschließendem Planning stattgefunden. Diesmal wirkt alles schon etwas eingespielter und die Präsentationen der inhaltlichen Konzepte der einzelnen Studierendenteams nehmen Gestalt an. Jedes Team hat im Review 10 Minuten Zeit, um seine aktuellen Ergebnisse zu präsentieren und Feedback einzuholen.
Die meisten Teams zeigen zum Start der Präsentation ihr Taskboard. Auf dem Taskboard ist auf einen Blick transparent, an welchen User Stories (=Teillieferungen des fertigen Produkts) das Team in der vergangenen Woche gearbeitet hat und welcher Studierende welchen Task (= Aufgabe) dabei übernommen hat. Um auch zwischen den Seminarstunden den Arbeitsfortschritt zu sehen, nutzen die meisten Gruppen ein digitales Board. Dazu bietet sich beispielsweise das frei verfügbare Programm Trello an.

Kontinuierliches Feedback statt Stress vor der Abgabe bringt bessere Ergebnisse

Die Studierenden aus den anderen Teams füllen während jeder Kurzpräsentation der verschiedenen Gruppen den im ersten Termin gemeinsam erstellten Feedbackbogen aus. Auch Prof. Günzel gibt nach jeder Kurzpräsentation eine Rückmeldung, worauf die jeweilige Gruppe sich noch stärker fokussieren kann – allerdings haben die meisten Teams die Aufgabenstellung richtig verstanden und arbeiten in die richtige Richtung. Bei manchen Teams gibt es mehr Feedback von Mitstudierenden und von Prof. Günzel. Sie sind bei der Bearbeitung der Aufgabenstellung nicht konkret genug geworden und müssen ihr Konzept nochmals überarbeiten. Prof. Günzel ist begeistert von dem Ansatz: „Normalerweise kommen die Studierenden – wenn überhaupt – wenige Tage vor der Abgabe zu mir, um sich Feedback für ihre Arbeiten einzuholen. Dann ist es meistens schon viel zu spät. Über die Arbeit mit Scrum gibt es kontinuierliches Feedback. Und das nicht nur von mir, sondern auch von anderen Studierenden.“

Verbesserung des Prozesses – wie ein effizienteres Review aussehen kann

Das Review und die anschließende Diskussion nach jedem Team haben länger gedauert als geplant. Wertvolle Zeit ging auch durch das Umstecken der Laptops zwischen den einzelnen Präsentationen verloren. Die Seminarstunde ist inzwischen fast zu Ende und Prof. Günzel bittet die Teams, die letzten fünf Minuten für eine kurze Retrospektive zu nutzen. Die Teams analysieren in der Retrospektive, wie sie ihre Zusammenarbeit in der kommenden Woche verbessern können. Er selbst reflektiert, was im Review passiert ist. Die Präsentationen, die die einzelnen Teams gezeigt haben, erinnerten ihn eher an klassische Seminarvorträge. Es gab viele PowerPoint-Folien und zum Teil waren die Folien auch noch nicht ganz fertig. Prof Günzel erinnert sich an das Ziel des Reviews: Das Einholen von Feedback zu abgeschlossenen Teilergebnissen.
Er hat eine Idee, wie er in der kommenden Woche das Review besser gestalten kann, und gibt seinen Studierenden drei Punkte mit:

  1. Im nächsten Review dürfen nur noch abgeschlossene User Stories vorgestellt werden.
  2. Pro User Story dürfen maximal zwei Folien erstellt werden, die die Studierenden ausgedruckt mitbringen und zu Beginn der Stunde an der Wand befestigen. Im Review geht dann die gesamte Seminargruppe von Teamwand zu Teamwand.
  3. Die Studierenden schreiben ihr Feedback zu den einzelnen Präsentationen auf Post-its und geben sie den einzelnen Gruppen mit.

Prof. Günzel erhofft sich dadurch einen reibungsloseren Ablauf des Reviews. Es geht ihm aber vielmehr darum, dass ein kommunikativerer Austausch in der Gruppe entsteht und die Studierenden sich gegenseitig mehr Feedback geben. Er ist gespannt, ob es funktionieren wird.
Die Erlebnisse von Prof. Günzel in seiner Reviewstunde zeigen, dass es kein Patentrezept dafür gibt, wie man Scrum4Schools am besten einführen sollte. Das Rahmenwerk muss immer auf den jeweiligen Kontext wie beispielsweise die Lernaufgabe und die zur Verfügung stehende Zeit angepasst werden. Dabei ist jeder gefragt. Und es braucht immer eine gewisse Zeit, bis eine Gruppe den optimalen Modus für sich gefunden hat. Grundvoraussetzung dafür ist die Bereitschaft, neue Dinge auszuprobieren und den eigenen Prozess kontinuierlich zu verbessern.

Scrum4Schools an der Hochschule München: Die Agilität erwacht

„Die Woche war viel zu schnell um“, „Das hatte ich anders verstanden“ oder „Wir sind fast fertig“. Das hört man von Scrum-Teams schon mal am Tag vor dem Review und somit am Ende eines Entwicklungssprints. Aber nicht nur dort, sondern auch in einer Wirtschaftsvorlesung von Prof. Holger Günzel an der Hochschule München. Er möchte nämlich mit seinen Studentinnen und Studenten in den nächsten sechs Wochen Scrum4Schools als Rahmenwerk für die Ausarbeitung von Studienarbeiten einsetzen.

Woche 2 – Definition of Done und die erste Lieferung

Der Ablauf

Zu Beginn des Sprint Plannings hatten die Studentengruppen eine Definition of Done erarbeitet. Dieser zufolge sollten sie die ersten relevanten Lieferungen, wie eine Agenda oder eine Literaturrecherche von drei relevanten Texten, bereits nach der ersten Woche abgeben. Prof. Günzel hat an alle Studierenden Bewertungsbögen ausgeteilt. Darauf finden sich zum einen die festgelegten Akzeptanzkriterien sowie die allgemeinen Constraints des Produktes Hausarbeit. Ziel ist es, dass jeder Studierende zu jeder Zeit die Bewertungskriterien für die Abschlussnote kennt und diese im Review für das Feedback zu den anderen Lieferungen nutzen kann.

Das erste Review

Jede Gruppe bekommt eine Timebox von 10 Minuten. Die erste Gruppe präsentiert. Die Zuhörer können auf ihrem Bewertungsbogen nur wenige Punkte abhaken und geben kräftig Feedback, was sie sich für die nächste Iteration vorstellen könnten. Prof. Günzel hält sich im Hintergrund. Die zweite Gruppe präsentiert. Anstatt inhaltliche Lieferungen zu präsentieren, hat diese Gruppe die Aufgabenstellung für sich neu geschrieben und vorher abgestimmte Rahmenbedingungen außer Kraft gesetzt. Sie haben ihre Arbeit nicht nach der Herangehensweise von Scrum strukturiert, sie haben auch kein Taskboard und damit einhergehend keine bewertbare Lieferung. Die Zuhörer sind irritiert und finden keine passenden Checkpunkte auf ihrem Feedbackbogen. Prof. Günzel muss eingreifen und erläutert erneut den Kontext sowie die Aufgabenstellung. Erst jetzt versteht die Gruppe, was das eigentliche Ziel ihrer Aufgabenstellung ist. Alle atmen auf, es sind ja noch fünf Wochen Zeit. Gut, dass es das Review gibt und sie somit schnell Feedback erhalten haben.

Die erste Retrospektive

Die Gruppen sitzen wieder beisammen und versuchen, auf ihre gemeinsame erste Woche zurückzublicken. Was ist uns bereits sehr gut gelungen? Wo können wir vielleicht noch etwas besser werden, damit wir nächste Woche wieder so gutes Feedback bekommen? In jeder Gruppe werden relevante Veränderungen identifiziert und in kleine Maßnahmen heruntergebrochen. Prof. Günzel beobachtet, dass sich jeder ein bis zwei Verbesserungen am Taskboard notiert.
Hier zeigt sich wieder einmal sehr schön: Man kann noch so viel vorab über die gemeinsame Zielstellung sprechen – erst beim Umsetzen kommen die Fragen und man erkennt, ob man den Kunden wirklich verstanden hat.

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.