Der Flow ist ein Charakteristikum agiler Vorgehensmodelle, das irgendwo zwischen Mythos und untrüglichem Zeichen gut funktionierender agiler Projekte beheimatet ist. Vom Flow spricht man im agilen Kontext dann, wenn das Team im Gleichklang mit einem gemeinsamen Takt arbeitet, in dem fast alles gelingt, und wo man nicht mehr darüber nachdenken muss, wie man eine Aufgabe angeht, sondern sich endlich voll und ganz auf die Inhalte konzentrieren kann. Ich habe diesen Flow tatsächlich in verschiedenen Scrum-Projekten erlebt – und am vergangenen Wochenende beim Osterfeuer.
Seit fünfzehn Jahren veranstaltet die Freiwillige Feuerwehr Wedel am Samstag vor Ostern ihr traditionelles Osterfeuer. Neben der Organisation dieser Veranstaltung sind wir Feuerwehrleute auch für den Ausschank an den Getränkeständen zuständig. Da wir keine Gastronomie-Profis sind, dauert es immer einige Zeit, bis sich das Team am Getränkestand aufeinander eingespielt und seine Handgriffe gelernt hat: Bestellungen entgegennehmen, Bier zapfen, Softdrinks einschenken, Getränke ausgeben, kassieren, Pfandbecher zurücknehmen, Pfand auszahlen (oder mit einer neuen Bestellung verrechnen) und Becher spülen. In diesem Jahr haben wir in Anbetracht der niedrigen Temperaturen auch Glühwein ausgeschenkt – wahlweise mit „Schuss“.
Es war interessant zu beobachten und zu erleben, wie wir den Flow gefunden haben.
Arbeitsteilung und Rotation
Schon von Beginn an hatten wir uns für eine arbeitsteilige Aufstellung entschieden: Während zwei Feuerwehrleute an den Zapfhähnen für den Biernachschub sorgten, füllte ein weiterer den Glühwein ab. Die beiden anderen Mitglieder des fünfköpfigen Teams übernahmen den Verkauf: Bestellungen wurden entgegengenommen und an die Bier- und Glühweinverantwortlichen weitergeleitet. Von denen bekamen die Verkäufer die Getränke zugereicht, Softdrinks füllten sie selber ab.
Wer wollte, der konnte durch die verschiedenen Stationen rotieren. Da es nicht jedermanns Sache ist, Bestellungen entgegenzunehmen und die Preise im Kopf zu berechnen (ich gebe zu, dass auch ich das Kopfrechnen erst wieder üben musste), kam es vor, dass einige Kameraden bei ihrer Station blieben.
Prozessoptimierung und Garbage Collection
Es dauerte nicht lange, da wurden erste Optimierungen des Prozesses in die Tat umgesetzt. Beispielsweise schufen wir einen Vorrat an Bechern, die wir mit Rum befüllten. Somit war die Lieferzeit für einen Glühwein mit und ohne Schuss genau gleich lang, weil in beiden Fällen nur noch der Glühwein aufgegossen werden musste. Der Vorrat an Rum-Bechern wurde in den kurzen Pausen aufgefüllt, die sich immer wieder ergaben. Die Kundschaft kam nämlich nicht gleichverteilt, sondern immer stoßweise, was unter anderem davon abhing, welche Musik der DJ gerade spielte.
Die zurückgenommenen Pfandbecher wurden zunächst im Spülbecken gesammelt, bis der Vorrat an frischen Bechern zur Neige ging oder das Spülbecken zu voll wurde. Erst dann baten wir einen weiteren Feuerwehrkameraden zur Hilfe, der das Team temporär verstärkte, um die Becher zu spülen. Unser Konzept gleicht dem der Garbage Collection in einer Java Virtual Machine, die ungenutzte Objekte nicht sofort wegräumt, sondern auf einen geeigneten Zeitpunkt wartet, an dem sich das Aufräumen lohnt und den Betrieb möglichst wenig beeinträchtigt. Die ungeliebte Aufgabe des Becherspülens wurde übrigens ebenfalls im Rotationsprinzip erledigt.
…und dann war er plötzlich da: der Flow!
Ich habe nicht auf die Uhr geschaut (dazu war einfach keine Zeit), aber wir haben ca. eine Stunde gebraucht, um die beschriebenen Verbesserungen im Prozess zum Laufen zu bringen und reibungslos miteinander zu arbeiten. Als ich spürte, dass wir gemeinsam alles im Griff haben, wich eine Anspannung von mir, die ich erst im Nachhinein wahrnahm. Jetzt fand ich endlich die Zeit, um mich besser um die Gäste zu kümmern. Ein Lächeln hier, ein kurzer Schnack dort – kleine verkaufsfördernde Maßnahmen, die zudem den Spaß an der Sache steigerten. Interessanter Weise wurden wir jetzt auch von den Gästen als eingespieltes Team wahrgenommen, wie ich einigen Äußerungen entnehmen durfte.
Auf dem Boden bleiben!
Die größte Gefahr im Flow ist, die Bodenhaftung zu verlieren und sich selbst zu überschätzen. So war es nur eine Frage der Zeit, bis ich mich zum ersten Mal an diesem Abend verrechnete – zu Ungunsten des Gastes, der meinen Irrtum bemerkte und mich freundlich darauf hinwies. Ich entschuldigte mich und war von diesem Moment an zwar immer noch im Flow, aber wieder mit der vollen Konzentration bei der Sache.
Fazit
Was kann man aus dieser kurzen Geschichte an Erkenntnissen für agile Projekte gewinnen?
- Es gibt ihn, den Flow. Ma braucht dafür ein echtes Team, das gerne gemeinsam arbeitet und willens ist, seine Arbeitsweisen zu reflektieren und gegebenenfalls anzupassen.
- Arbeitsteilung ist auch in agilen Projekten erlaubt und sinnvoll, solange man (z.B. durch Rotation oder Pair Programming) dafür sorgt, dass keine Wissensinseln entstehen.
- Es gibt Aufgaben, die man nicht sofort erledigen muss, sondern besser erst einmal ansammelt. Dieses „Garbage Collection“-Muster entspricht im weitesten Sinne dem Konzept der Backlogs (z.B. Product und Impediment Backlog, nicht aber Sprint Backlog), wobei dort natürlich kein Müll gesammelt wird. So findet ein Estimation Meeting üblicherweise nicht regelmäßig statt, sondern nur dann, wenn man sich aus bestimmten Gründen mit der Pflege des Backlogs beschäftigen muss.
- Die positive Stimmung, die der Flow auslöst, spüren auch die Kunden. Sie nehmen das (Entwicklungs-)Team als eingespielte Mannschaft wahr, der sie ihr Vertrauen schenken können.
- Bei aller Euphorie, die der Flow auslösen kann, muss das Team auf dem Boden bleiben und seine Aufgaben weiterhin mit voller Konzentration wahrnehmen.