Das Buch von Axel Schröder und seinen Mitarbeitern stellt eine ganze Reihe kurzer Beiträge über praktisches Vorgehen in der Beratung von agilen Arbeitsformen vor. Man könnte das Praxishandbuch „Der Agile Coach“ fast als werblich bezeichnen, da am Anfang die insgesamt 29 Autoren mit Bild und kurzer Beschreibung ihrer Philosophie vorgestellt werden. Danach folgt allerdings ein interessanter Ansatz. Nach dem Einführungskapitel werden anhand der Schritte des agilen Arbeitens angelehnt an das Scrum Modell wesentliche Erfahrungen vorgestellt. Die Autoren bezeichnen das Agile als die Hardware und das Coachen als die Software in ihrem Vorgehen.
Zunächst gilt es, in einer Organisation das Thema „agil“ einzuführen und populär zu machen. Die Autoren beginnen dazu mit einem „Initial Workshop“ und vermeiden die Bezeichnung „Kick off“. Dann entwickeln sie die Rollenfiguren des Scrum interessant weiter, beginnend mit der Titelrolle. „Eine irreführende Bezeichnung für den AGILECOACH ist aus meiner Sicht der Name ‚Scrum Master‘.“ (S. 5) Der agile Coach sorgt für das Stattfinden des Daily Scrum im Team mit den drei Standardfragen: A. Was hatte ich mir vorgenommen? B. Was habe ich geschafft? C. Bei was brauche ich die Hilfe des Teams? Damit übernimmt der agile Coach die Aufgaben des Scrum Masters. Allerdings zeigen die Autoren im Fortgang, dass der agile Coach sowohl eine Art externer Coach sein als auch Scrum-Master-Funktionen wahrnehmen kann. Der Product Owner wird zum POT (Product Owner Team) weiterentwickelt. So ist das Rollenset des Scrum Product Owner (PO), Scrum Master und Team erweitert.
„Der AGILECOACH ist verantwortlich für die Veränderung: für den Change von der heutigen Arbeitsweise – dem IST-Workstyle – in den agilen Rhythmus." (S. 12) Die Autoren nennen die erste Zusammenkunft „das erste Konklave“. Das „Konklave“ ist die Zielklärungsphase des Product Owner Teams, das die Ziele der Entwicklung, z.B. bei einem Produkt, festlegt. Im ersten Konklave wird als Sprint 0 in einer Woche die Erarbeitung der Etappenplanung und des Backlogs, der zu erarbeitenden Elemente für den Sprint 1, vollzogen. Auf die Zielpräzisierung wird sehr viel Wert gelegt und Zeit investiert. Die Bestandteile des zu erstellenden Product Backlogs, der zu erreichenden Bestandteile eines Endproduktes und seiner Definitions of Done (DoD), gilt es sorgfältig zu bezeichnen.
Nach den eigenen Begriffsformungen folgt eine ganze Reihe von Aufsätzen, die praktische Erfahrungen einzelner agiler Coaches aufzeigen. Im Beitrag von Michael Heinzelmann wird eine interessante psychologische Dynamik beschrieben. In dem beschriebenen Fall bestand offensichtlich eine Sehnsucht nach einer Aberkennung durch eine höhere Führungskraft, die hier als Product Owner (PO) fungierte, aber zunächst nie anwesend sein konnte. Darin zeigt sich ein interessanter Punkt im Übergang von klassischer Hierarchieorganisation zu mehr New-Work-orientierten Formen. Das Beispiel, in dem der hochrangige Chef als PO (Product Owner) dient und seine unterstellten Direktoren das agile Team bilden, ergab eine Menge Probleme, da der Arbeitsaufwand weder seitens des PO noch seitens der Teammitglieder zu erbringen war. Hier stellt sich auch die Frage, wie hierarchische Führungsverhältnisse eins zu eins in die Scrum Organisation umsetzbar sind. Der PO ist normalerweise nicht die hierarchische Führungskraft, sondern jemand, der in einem Projekt die Anforderungen der Schnittstelle zum Kunden vertritt.
Laura Sawitzki und Frank-Michael Hoyer beschreiben Anwendungen der agilen Arbeit bei der Firma Festo. Manche Organisationen arbeiten „hybrid“, teilweise traditionell, teilweise mit agilen Elementen. Miriam Held überträgt das Teamentwicklungsmodell von Forming, Storming, Norming und Performing auf die Entwicklung von Product Owner Team und Entwicklerteam.
Den Beitrag von David Suo bestimmt die Einführung agiler Prinzipien in ein Unternehmen, die sogenannte agile Transformation. Dabei sind die agilen Coaches zunächst externe Coaches, die die Prinzipien der agilen Arbeit ins Unternehmen bringen. „Der externe Coach unterstützt den Product Owner darin, dem Team ein klares Verständnis von den Zielgruppen zu vermitteln … sowie einen ersten ‚Backlog‘ für das Team zu erstellen.“ (S. 51)
Im Fortgang äußern viele weitere Autoren ihre Erfahrungen zu Sprints, Dailies, Reviews und Retrospektiven. Das Sprint Review Meeting wird hier „Demonstration“ genannt. Der agile Coach gibt auch in der Retrospektive nach den zweiwöchigen Sprinteinheiten seine Wahrnehmung des Prozesses, insbesondere der „Demo“.
Die Beiträge sind sehr praxisorientiert und zeigen auch deutlich Klippen der agilen Prozeduren auf. Manchmal klappt etwas einfach nicht. Oder die täglichen „Dailies“ gehen den Leuten auf die Nerven. Was gilt es dann zu tun? Manchmal werden Übungen wie der Elevator-Pitch erwähnt, in dem eine Person seinem Vorstand während einer Aufzugfahrt sein momentanes Projekt vorstellen muss. Dies ist im Grunde eine ganz lustige Idee, unterstellt aber implizit eine sehr hierarchische Organisationsvorstellung. Auch manche Lebensweisheit hat den Weg ins Buch gefunden: „Das echte Leben ist nun mal meistens keine eindeutig planbare Vorgänger-Nachfolger-Beziehung, sondern ein Staffellauf mit einer ‚Übergabezone‘, in der man sehr viel miteinander reden muss.“ (S. 79) Die Autoren haben einen unterschiedlichen Stil, man muss sich als Leser immer wieder etwas neu einstellen. Am Ende des Buches folgt noch mehr Methodisches und das gesamte Buch ist mit Zeichnungen schön illustriert.
Fazit: Eine wahre Fundgrube für alle, die mit agilen Arbeitsstrukturen zu tun haben.