Scrum ist anstrengend!

… jetzt neu: auch für Auftraggeber. Aber der Reihe nach …

Die Vorgeschichte

Mitarbeiter von [netresearch]  haben an meinen Angeboten auf dem Agile Barcamp teilgenommen. Das gezeigte Ubongo Flow Game hat sie sehr angesprochen. Beim darauffolgenden Kontakt stellte sich heraus, dass wir uns bereits von vorherigen agiLE-Meetups kannten.
Außerdem hat das Unternehmen aktuell Bedarf an einem agile Coach. Und sie suchen gerade Scrum Master zur Verstärkung.

Die Idee

Gemeinsam kamen wir also zu dem Ergebnis, dass ich sie als agile Coach unterstützen könnte und auch die Scrum Master-Rolle auf Interim-Basis einnehmen kann bis die geeigneten Personen gefunden sind.

Das sollte aber keine 1:1-Entscheidung im stillen Kämmerlein werden. Vielmehr sollten Geschäftsführer und Führungsmannschaft entscheiden, ob sie mit mir zusammen arbeiten wollen. Ich sollte wiederum die Kollegen kennenlernen damit ich für mich entscheiden kann, ob ich die Aufgabe übernehme.

So kamen wir auf die Idee, das Spiel als Vorstellungstermin zu wiederholen.

Der Termin – jetzt wurde es ernst

Vor kurzem traf ich dann also auf die acht Unternehmensvertreter samt Geschäftsführer. Keiner kannte Ubongo wirklich, nur eine Person in dem Termin hat meinen Beitrag beim Barcamp erlebt. Das Unternehmen arbeitet nach Kanban im Support und nach Scrum in der Entwicklung. Beste Voraussetzungen also.

Ich erläuterte kurz das Spiel (“Aha, offline-Tetris!”). Das Team brannte darauf, anzufangen.

Im Wasserfall ging es los. Das Ergebnis war vorhersehbar. Im Wesentlichen sahen die Teilnehmer einem beim Arbeiten zu. Das Team hatte schon nach der ersten der zwei 3-Minuten Iterationen keine Lust mehr. Ich musste gut zureden, um überhaupt die Vergleichsbasis Wasserfall zu erarbeiten. Immerhin, 13 Wert-Punkte kamen dabei heraus.
Sie wussten halt alle schon, was man besser machen sollte…

Der Kanban-Durchgang war da schon besser und fühlte sich für das Team vertrauter an. Es wurde schon am Setup gedreht und ein wenig geschummelt. Sie hatten schnell erfasst, dass die Entwicklung zur Engstelle wird. Also haben sie (etwas an den Regeln vorbei), die Entwicklungsstation aufgestockt. Nun arbeiteten zwei in der Entwicklung, das WiP-Limit haben sie aber geflissentlich bei 1 belassen. So kam es, dass alle initialen 8 Stories abgearbeitet werden konnten, die Abnahme durch den Auftraggeber wurde zur Engstelle und dem Lieferanten gingen die Legeteile aus.

Gute Vorzeichen für den Scrum-Durchgang.

Nachdem die Teilnehmer schon wussten, wie sie sich “eigentlich” organisieren wollten, gab es nun lebhafte Diskussionen, wie man sich auf den Scrum-Durchgang vorbereiten wollte. Legetafeln wurde ausgebreitet, die vermeintlich besten Analysten wurden bestimmt. Der Auftraggeber sortierte das Backlog und machte Häufchen. Viel Wert/wenig Arbeit, ausgeglichen, wenig Wert/viel Arbeit … You know 😉

Man verabredete wie man mit den erledigten Aufgaben umgehen möchte. Es war absehbar, dass es bald zu einem Engpass an Legeteilen kommen würde. Steh-Positionen wurden verändert. Der Auftraggeber bildete mit dem Team jetzt einen Kreis anstatt wie bei Kanban “vorne” Aufgaben hineinzugeben und am Ende der Entwicklungs-Kette “hinten” die Ergebnisse in Empfang zu nehmen.

Dann ging es los. Es wurde angespannter. Zunächst konzentrierte sich die Analyse darauf, die Entwicklung “unter Feuer” zu setzen. Man entwickelte mit drei, später mehr Entwicklern parallel. Beim Auftraggeber türmten sich die Stories auf “done”. Der Lieferant verlangte bereits lautstark nach Legeteilen. Pullover wurden ausgezogen. Der Auftraggeber musste noch näher herankommen. In der zweiten von nun drei Iterationen (von jetzt nur noch zwei Minuten) kippte der Auftraggeber erledigte Aufgaben nur noch auf einen Haufen beim Lieferanten. Sortieren nach Farben und Formen war bei der Geschwindigkeit der Abarbeitung nicht mehr möglich. Es wurden nur noch die erforderlichen Teile aus Haufen herausgesucht und sie “Stories” weitergegeben. Es kam zu spontanen Rollenwechseln. Wenn das Team merkte, dass es beim “Lieferanten” eng wurde bekam er Unterstützung. Der Protokollant hatte seine Mühe, mit dem Arbeitsfortschritt mitzuhalten. Das Team wurde euphorisch. Gipfel schienen zum Greifen nah. Die Velocity nahm aber in der letzten Iteration jedoch ab, da nun nur noch der Bodensatz vom Backlog verfügbar war. Kleine Stories mit viel Aufwand, die eigentlich nur deshalb gemacht wurden, weil man noch Zeit hat und nichts Besseres da ist.

You know … 😉

Die Retro mit dem Team

Der Vorstellungstermin wurde abgeschlossen mit einer Retro des gesamten Teams. Ein Kollege wollte aber nicht recht aufhören. Er saß noch an einer Story mit Wert 1 und Aufwand 20. Ihn hatte der Ehrgeiz gepackt. Zur Gesamt-Performance trug es aber nicht bei. Das Endergebnis stand schon fest. You know … 😉

Das Ergebnis war klar. Die “Learnings” bekannt.

Der Wert dieser Stunde lag aber darin, es komprimiert und gemeinsam gefühlt zu haben, was sonst nur Ahnung, Annahme und verteilte Erfahrung über mehrere Tage, Wochen, Sprints ist.

Die Nachbesprechung

Nach etwas über einer Stunde war der “große Termin” vorbei. Das Führungsteam verabschiedete sich. Es folgte die Nachbesprechung mit der Unternehmensspitze.

Das Erlebte brachte den Geschäftsführer direkt auf eine Idee. “Vielleicht sollten wir das Spiel verwenden, um zu überprüfen, ob ein neuer Kunde zu unserer Arbeitsweise passt. Immerhin bedeutet Scrum für den Auftraggeber harte Arbeit. Er wird aktiv eigebunden und gefordert…”

Gelernt: “Über den Zaun werfen” ist nicht mehr. Die lauen Zeiten des Wasserfalls sind vorbei.

So geht Arbeit heute. “New Work” in Reinkultur. “Wir müssen mal schauen, ob uns ein neuer Auftraggeber gut tut …”

Das Ergebnis

Der Termin fühlte sich für mich richtig an. Mir wurde im Nachgang berichtet, das Feedback im Unternehmen war ebenfalls durchweg positiv. Sowohl zum Spiel als auch zu meiner Arbeit als Moderator meines Vorstellungsgesprächs. You know … 😉

Von der anderen Seite des Tisches wurde die Sache auch so gesehen.

Die Verträge sind jetzt “nur noch” Formsache.
Am 1. November (in Sachsen kein Feiertag) geht es dann los. Ich freue mich schon drauf.

8 responses to “Scrum ist anstrengend!”

  1. Freut mich, dass Du wieder im Südwesten zugange bist. Viel Erfolg dabei!

    1. Zum Verständnis: ich habe den Blogbeitrag im Zug verfasst. Ich war auf dem Weg zu einem “schwäbischen Maschinenbauer” im Großraum Stuttgart.
      Die Zugfahrten dorthin und zurück geben mir u.a. Gelegenheit länger am Stück an Dingen zu arbeiten, die nicht die allerhöchste Prio haben. So wie Blog-Beiträge eben.

  2. […] dass neben Lars Vollmer noch andere Vorreiter der neuen Arbeitswelt mit „meinem“ schwäbischen Maschinenbauer zu tun hatten. Die Welt ist so klein. Aber das ist eine andere Geschichte […]

  3. […] Alexander Gerber hat langjährige Erfahrung als Coach und Trainer und ist zertifizierter SCRUM Master. Wir haben ihn beim agiLE Barcamp kennengelernt. Ob er wirklich zu unserem Unternehmen passt, haben wir ganz unkonventionell in einem Ubongo Flow Game herausgefunden. Wie genau sich unser Team dabei angestellt hat, können Sie auf dem Blog von Alexander Gerber lesen: Scrum ist anstrengend! […]

  4. […] waterfall turn was pretty obvious („hand it over in complete“) and once again I had to steer in moderation that the players would not „intuitively“ switch to Kanban […]

  5. […] recht gut erkennen, wie es abgelaufen ist. Einigermaßen ausführlich habe ich einen Spieldurchgang hier […]

  6. […] gibt, in denen es bereits eine Überdrüssigkeit in Bezug auf Agilität gibt. Schon klar, Scrum ist anstrengend! Das wurde aber nicht zu meinem […]

  7. […] “Scrum ist anstrengend!” […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: