„Sie werden scheitern.“
So lautete mein abschließender Satz am Ende einer zweitägigen Schulung zum Thema Scrum / Agile Softwareentwicklung. Alle Teilnehmer waren verblüfft. Zwei Tage Schulung und am Ende erklärt der Coach allen Anwesenden, dass sie (trotzdem) scheitern werden?
Nicht unbedingt – und darum erklärte ich meine Aussage mit Hilfe eines einfachen Beispiels:
“Angenommen, Sie wären nicht für eine Scrum-Schulung hier, sondern wollten Trompete lernen. Wir hätten also die letzten zwei Tage damit verbracht, wie eine Trompete und das Trompete-Spielen funktioniert: Hier pusten Sie rein, das sind die drei Ventile und hier kommt die Musik raus. Würden sie als Teilnehmer am Ende der zwei Tage erwarten, nun in einem Philharmonie-Orchester mitspielen zu können?”
Die Teilnehmer waren sich einig: Eher nicht.
Im Rahmen von Softwareentwicklungsprojekten befinden wir uns häufig in komplexen Domänen. Ständig ändern sich die Anforderungen und Technologien, wie Programmiersprachen – Frameworks, usw., bieten immer mehr Möglichkeiten. Gleichzeitig bringt jede neue Version einer Technologie gewisse Unklarheiten mit sich.
Komplexe Domänen werden – neben vier weiteren Domänen – im Cynefin-Framework beschrieben – gemeinsam mit vier Ansätzen, wie auf sie reagiert werden kann. Für komplexe Domänen empfehlen sich emergente Praktiken (emergent practice): Probieren, Erkennen, Reagieren.
Befindet ihr euch in einer solch komplexen Domäne und erwartet ein schnelles Ergebnis – direkt nach eurem Trompeten-Seminar spielt ihr im Orchester – werdet ihr mit Sicherheit enttäuscht, denn es wird genau das passieren, was ich den Teilnehmern meines Kurses gesagt habe: Ihr werdet scheitern. Was ihr jetzt aber auf keinen Fall machen dürft, ist aufgeben. Ihr werdet Fehler machen, natürlich. Ihr habt viel gelernt, aber eben nur theoretisch und steht ganz am Anfang. Lernt aus euren Fehlern.
Genauso wie ihr einen Lehrer benötigt, wenn ihr ein Instrument spielen möchtet, braucht ihr auch in der Softwareentwicklung jemanden, der euch beim Üben (probieren) hilft und dabei, eure Fehler zu erkennen und zu korrigieren (reagieren). Genau diese Aufgabe hat ein agiler Coach in einem Team.
Kein Coach der Welt sichert euch den Erfolg zu, indem ihr euch einfach für ein bestimmtes Vorgehen entscheidet. Das Vorgehen – z.B. Scrum – ist ein Mittel zum Zweck. Ein Team setzt sich mit mehreren Herausforderungen auseinander. Das Vorgehen hilft dabei, diese Herausforderungen mit Hilfe von emergenten Praktiken effizient zu meistern. Die Hauptaufgabe eines Coaches liegt daher nicht darin, das Vorgehen zu optimieren, sondern das Team beim Umsetzen, Probieren und Lernen zu unterstützen.
Schauen wir uns ein weiteres Beispiel an. Ich kenne mich gut mit Cricket aus – nehmen wir also das. Alle Cricketspieler auf dem Feld kann man in drei Rollen – Bowler, Batsman, Fielder – einteilen.
Wenn der Coach feststellt, dass seine Batsmen Unterstützung benötigen, holt er einen entsprechenden Trainer. Ebenso gibt es für die andere Rollen auch Trainer, die den Spielern für ihre Rolle passende Tips geben und Techniken beibringen. Die internationalen Mannschaften haben üblicherweise insgesamt 3 Coaches – einen Coach für je eine Rolle.
Im agilen Software-Projekt ist es nicht anders: Ein einzelner Agile-Coach könnte ein ganzes Team nur alleine unterstützen, wenn er sich in allen Bereichen – Requirement Engineering, UX, PO Techniken, Prinzipien und Praktiken der Softwareentwicklung, Qualitätssicherung usw. – gut auskennt. Und auch nur, wenn das Team über technische Exzellenz verfügt.
Doch den perfekten Coach, der sich in allen Disziplinen auskennt, gibt es vermutlich nicht – das wissen wir bei itemis auch. Darum unterstützen wir unsere Kunden im Projekt als Team – genauso wie im Cricket. Der Coach hat so immer den passenden Ansprechpartner, der weiterführend in dem jeweiligen Bereich – TDD, agile Architekturen, Web Engineering, Software-Qualität, Product-Owner-Techniken, Usability Engineering, usw. – unterstützt. Das aus unterschiedlichen Rollen bestehende Team ist so optimal beraten und kann – sollte diese noch nicht erreicht sein – durch die breite Abdeckung der Themen auch zur notwendigen technischen Exzellenz hingeführt werden.
Um also auf die Ausgangsfrage zurückzukommen: Braucht ihr nach eurem Trompeten-Seminar noch regelmäßigen Unterricht? Brauchen Projektteams einen agilen Coach – auch wenn alle Teammitglieder im Zweifel schon eine Scrum-Schulung oder ähnliches besucht haben? Wenn es erfolgreich arbeiten soll, auf jeden Fall – und idealerweise sogar ein ganzes Coaching-Team.