First, let's fire all agile coaches
Eine spannende Debatte ist ausgebrochen: Was bringen agile Coaches? Auf Think Different argumentiert Bob Marshall gegen den Einsatz agiler Berater: Zum einen, schreibt er, versprechen sie das Blaue vom Himmel und machen damit Unternehmen falsche Hoffnungen. Zum anderen führen sie zu lokalen Optimierungen innerhalb des Unternehmens, indem bestimmte Gruppen (meist Scrum-Teams) erhöhte Ressourcen und Aufmerksamkeit bekommen.Bob Marshall wirft damit die Frage nach dem Selbstvertändnis von agilen Coaches und ScrumMastern auf. Sind wir dazu da, agile Luftschlösser zu bauen und die Rosinen für unsere Scrum-Teams herauszupicken? Dass diese Wahrnehmung entstehen kann - und auch häufig ensteht - sei geschenkt. Das ist ja auch einer der Gründe, warum Scrum-Implementationen scheitern: Die Differenz zwischen Anspruch und Wirklichkeit wird zu groß: Unternehmen fangen an zu glauben, Scrum sei für andere genau das Richtige, nicht aber für sie selbst.Ich durfte als ScrumMaster und Coach einige Projekte über längere Zeit begleiten. Die Erwartungen, die dabei an meine Rolle herangetragen wurden, waren nie gleich. In manchen Projekten wurde vom ersten Tag an erwartet, dass ich Verantwortung für den Projekterfolg übernehme. In anderen sollte ich bereits bestehende Rollen und Verantwortungen in ihrer Arbeit unterstützen oder bestehende Prozesse optimieren.Mein Selbstverständnis als Berater kann ich bei der ersten Art von Projekten (volle Verantwortung vom ersten Tag an) leichter ausüben. Denn ich kann mit Scrum von innen heraus arbeiten. Es geht dann in erster Linie um das Meistern von alltäglichen Herausforderungen und nur in zweiter Linie um Scrum. Anders gesagt: Ich kann dann einen bestehenden Prozess mitgestalten und im Zuge dessen an seiner Agilisierung arbeiten.Und da ist er auch schon, der springende Punkt: Wenn der Beraterjob sich darauf begrenzen soll, Ratschläge, Empfehlungen und Anstöße zu erteilen, dann sind agile Coaches meist schlecht investiertes Geld. Lernen geschieht nur durch Vormachen. Ein guter Berater ist dazu da, vorzutanzen - und das heißt, die Arbeit so lange selber zu machen, wie es eben nötig ist. Ein einfaches Beispiel: Das Scrum-Team soll User Stories schreiben, weil das in Scrum eben so ist. Nun kann man dem Product Owner von Mike Cohn und den drei Fragen der User Story erzählen. Ein fleißiger Product Owner wird dann etwas daraus basteln und im nächsten Sprint Planning mit einem Stapel lustiger Sätze aufwarten.Wir können aber auch ganz anders vorgehen: Warum nicht im Sprint Planning die klassischen Anforderungen durchgehen und dort, im Gespräch mit dem Team, eben diese drei Fragen stellen? Dann werden User Stories aus der Arbeit heraus, im Kontext ihrer Verwendung, entstehen. Die Puristen unter uns werden einwenden, dass Stories im Planning ja gar nicht geschrieben werden dürfen (Story Readiness!). Aber wie soll ein Scrum-Team darauf kommen, wenn es noch nie ein Backlog Grooming hatte? Auch hier ist es wichtig, die Besserwisserei im Schrank zu lassen und stattdessen dem Team ganz konkret aufzuzeigen, welches seiner Probleme ein solches Meeting lösen kann.Dieser Umgang mit Scrum ist deflationär, denn er hält sich nicht mit großen Einführungen und Glaubenssätzen auf, sondern orientiert sich strikt am Bedarf der Personen und Gruppen im Unternehmen (und das nicht nur für die Scrum-Teams).Wir Berater erzählen gerne von Scrum, weil wir uns damit am besten auskennen. Stattdessen sollten wir uns viel mehr mit dem auseinandersetzen, was nicht im Lehrbuch steht. Wir müssen besser verstehen, wie Unternehmen ticken, was ihre Produkte ausmacht, wo ihre Probleme sind, und was sie jetzt gerade brauchen. Nur dann haben wir eine Chance, Scrum als Rahmenwerk aufzuspannen, das im Unternehmen verankert ist. Ansonsten wird unsere Arbeit als Berater und/oder SMs sich auf das Verteilen von agilen Sahnehäubchen beschränken.
