Scrum und die Bedeutung von Rhythmus

Dieser Artikel ist der zweite Artikel einer kleinen, vermutlich zwei bis dreiteiligen Serie, in der beleuchtet werden soll, wie Scrum abseits der allseits bekannten Rollen und Events denn eigentlich so funktioniert.

Rugby ist tatsächlich brutal.

So verlieren die Spieler schon mal hin- und wieder Zähne im Spiel, die dann in der Regel von Ärzten im Körper anderer Spieler wieder gefunden werden. Der Australier Jamie Ainscough verlor wegen eines solchen Gegnerzahns fast einen Arm, denn der Zahn hatte eine schwere Infektion verursacht.

Die Scrum-Urväter fanden trotzdem, man könne aus dem Teamplay der Rugby-Spieler lernen.

Aus ihrer Sicht sind wichtige Faktoren für erfolgreiche Teamarbeit:

• Gemeinsame Ziele

• Interdisziplinarität

• Selbstorganisation / Autonomie

• Informationsaustausch / Lernen

Aber machen wir uns nichts vor: man wirft Goldfische nicht zusammen mit ein paar Rochen ins Haifischbecken und erwartet, dass sie sich schon selbst organisieren und den Überlebenskampf mit den Haien gewinnen werden.

Auch wenn die Zusammensetzung des Teams sicher zu dessen Erfolg beiträgt, spielt der Kontext eine große Rolle.

Auch autonom agierende Teams brauchen Training, Unterstützung durch das Management und eine Schrittgeschwindigkeit, in der zwar schnell und flexibel Resultate erzielt, aber in der den Beteiligten eben nicht all zu schnell die Puste ausgeht.

Wenn es knirscht, liegt es nicht am Team sondern am Rhythmus

Dieser Aspekt kommt bei der Scrum-Terminologie und dem Wunsch nach Schnelligkeit gern zu kurz: insgesamt muss es nicht um schnell aufeinanderfolgende Sprints sondern eher um einen kontinuierlichen Ausdauerlauf gehen – in einem Tempo, das auf unbestimmte Zeit durchgehalten werden kann.

Wie erreicht man einen durchhaltbaren Takt?

Indem man die verschiedenen Fachbereiche von Anfang an zusammen arbeiten lässt, statt wie in einem Staffellauf den Stab streng sequentiell von einer zur nächsten Phase weiterzureichen, und sie dabei ihren eigenen gemeinsamen Rhythmus finden lässt.

Das zumindest meinen die Scrum-Urväter Hirotaka Takeuchi und Ikujiro Nonaka und sehen es anhand der Beispiele von schon damals mit entsprechenden Ansätzen erfolgreichen Unternehmen wie Fuji Xerox und Canon bestätigt.

Warum aber sollte das einen Unterschied machen?

Das hängt damit zusammen, dass eine strikte Trennung von Prozessschritten (wie Anforderungsanalyse, Design und Umsetzung) einfach oft nicht genügend der Realität gerecht wird:

• Weil sich neue oder geänderte Anforderungen aus dem Projektverlauf, Marktgegebenheiten und Kundenwünschen ergeben, muss die Anforderungsanalyse (also die Zusammenarbeit mit den Nutzern) praktisch zu jeder Zeit stattfinden.

• Die Zusammenarbeit mit den Nutzern ist aber erschwert, wenn man sich nur auf dem Papier über das spätere Endergebnis austauschen kann und auch keine Informationen hat, was denn überhaupt technisch machbar ist.

• Ein vorzeigbares Ergebnis entsteht aber in einem sequentiellen Vorgehen erst sehr spät – frühestens wenn die Anforderungsanalyse und Designphase abgeschlossen sind, aber realistisch betrachtet eher später (zum Beispiel am Ende der Testphase).

In einem strikt sequentiellen Vorgehen sind deshalb Rücksprünge auf frühere Phasen unvermeidlich.

In den anderen Phasen bedeutet das in der Regel Stillstand oder man arbeitet derweil eben an einem anderen Projekt – warum sollte man an etwas arbeiten, von dem man nicht weiß, wie es sich weiter entwickelt?

Schließlich dauert das Projekt länger oder die Qualität leidet. Weil die Phasen wegen des Stillstands nicht (zwangsläufig) kürzer werden und weil jedes Mal, wenn ein Fachbereich länger nicht am Projekt beteiligt ist, eben wieder eine gewisse Anlaufzeit benötigt wird.

Zusammen nach vorne spielen

Dahingegen kann in einer Vorgehensweise, bei der alle Experten von Anfang an zusammen nach vorne spielen, ein gewisser Rhythmus entstehen: es wird weniger (!) im Voraus geplant – dafür zielgerichteter also besser dosiert – und die Erkenntnisse aus den anderen, sonst später stattfindenden Phasen können besser miteinbezogen werden.

Ein Stillstand, bei dem die jeweiligen Fachbereiche ganz aus dem Thema gerissen werden, wird unwahrscheinlicher. Wenn etwa ein Programmierer gerade nicht an Anforderungen programmieren kann, kann er mit seinem Fachwissen beispielsweise das Anforderungsmanagement unterstützen oder vielleicht bei schon fertiggestellten Komponenten eine hohe Qualität, Testbar- und Integrationsfähigkeit sicherstellen.

„Real artists ship“ –Steve Jobs

In klassisch geplanten Projekten werden oft Meilensteine entlang der Phasenübergänge definiert, um das Risiko zu begrenzen, dass man nie etwas marktfähiges erreicht.

Solche Checkpoints sind auch aus Sicht der Scrum-Urväter sinnvoll – nur eben nicht, um die Einhaltung eines unrealistischen Plans zu überprüfen. Eher sollte an diesen Punkten voneinander und von der Realität (zum Beispiel Nutzerfeedback) gelernt und geprüft werden, ob die Richtung noch stimmt.

Das Ziel ist nicht die Einhaltung eines Plans zu sichern sondern ein Abdriften ins Chaos zu verhindern.

Ein interessanter Aspekt ist übrigens, dass die Autoren des „New new product development game“ nicht explizit von Zeitfenstern gleicher Länge sondern nur von „enough checkpoints“ sprechen. Da es hier vor allem um Risikobegrenzung geht und gleichzeitig der ganze Prozess auf Rhythmus abzielt, erscheinen zweierlei Dinge logisch:

1. Regelmäßigkeit ist Trumpf, weil es einen Rhythmus begünstigt und für alle wesentlich vorhersehbarer und damit einfacher ist.

2. Welcher Rhythmus angemessen ist, muss sich an der Risikotoleranz des Unternehmens orientieren.

Zu bedenken ist: Ein geänderter Ablauf allein ist nicht erfolgsversprechend.

Wenn ein Entwicklungsteam plötzlich in Sprints arbeiten soll, aber weiter mit vorgefassten Spezifikationen aus der Wasserfallprojektleitung begossen wird, wird das ebenso scheitern wie ein cross-funktional aufgestelltes Team, die in Puncto Selbstorganisation und Autonomie so kurz gehalten werden, dass ihnen die Luft zum Atmen fehlt.

Eine wichtige Aufgabe für das Management: Zurückhaltung

Für die Spieler im „New new development“-Game gibt es viel zu lernen und das funktioniert unter rigider Kontrolle nicht.

Zu den Anforderungen für die Teammitglieder gehört:

• der Informationsaustausch (auch zwischen verschiedenen Fachbereichen) muss organisiert und gewährleistet werden

• neue Themenfelder (Wissen) müssen erschlossen und zumindest in Grundzügen beherrscht werden

• neue Fähigkeiten müssen erlernt, ausgebaut und gemeistert werden, vor allem Soft Skills wie: Teamfähigkeit, Kritikfähigkeit, Lernbereitschaft, Verantwortungsbewusstsein und Empathie

Die Anforderungen ergeben sich direkt aus der Art der Zusammenarbeit und manchmal zeigen sich dabei auch bisher unbewusste Defizite (und das nicht unbedingt nur bei den Personen wo man es „schon irgendwie geahnt“ hat) – die zu Problemen führen.

Solche Probleme sind manchmal schwer auszuhalten und führen nicht immer zu den besten Lösungen: etwa Autonomie durch zu starke Kontrolle wieder einzuschränken und damit die Lernerfolge des Teams zu untergraben.

Die Urväter von Scrum sagen, dass auf dem Weg zu erfolgreichen Teams eine gewisse Instabilität dazu gehört.

Das bedeutet: die Aufgabe des Managements besteht darin, eine gewisse Unsicherheit auszuhalten, die durch das Gewähren von Autonomie entsteht. Vor allem musss das Management der Versuchung widerstehen, auf jede kleine Abweichung mit mehr Kontrolle zu reagieren.

Warum sollte man dieses Wagnis eingehen?

Da antworte ich mit einer Gegenfrage: Könnt ihr euch erinnern, wie ihr als Kind zu gehen oder Fahrrad fahren gelernt habt? Schwimmen?

Und wie würde es sich wohl auf den Erfolg der Rugby-Mannschaft auswirken, wenn der Vereinschef der Mannschaft bei jeder Abweichung von zuvor gefassten Plänen aufs Spielfeld springt und nach einer Erklärung verlangt?