Meine Lehren auf dem Weg zur nächsten Scrum-Meisterschaft

In den letzten Monaten durfte ich ein lokales Startup als Scrum Master begleiten. Der CEO wollte sein Unternehmen (nur er, seine Tochter, ein weiterer Mitarbeiter und ein paar studentische Aushilfskräfte) agiler ausrichten.

Aber was bedeutet schon „agil“? In einem ersten Video-Call führte ich ihn von der alten, starren Welt, in der stoisch Pläne abgearbeitet und Deadlines eingehalten werden, um dann am Ende zu spät, zu teuer und ein Produkt am Kunden vorbei ensteht, hin in eine agile Welt, in der etwas produziert wird, was die Stakeholder wirklich brauchen und was auch Wert hat. Das hat dann natürlich große Konsequenzen auf die Zusammenarbeit und auch auf die Priorisierung der Arbeit.

Aber darum geht es mir heute nicht. Lieber will ich meine Lehren aus dem Projekt festhalten. Denn es gab einige Erkenntnisse. Die wichtigste (und eigentlich nicht überraschendste) Lehre: Gewohnheiten und die Menschen insgesamt verändern sich nicht über Nacht. Und ich auch nicht.

1. Mehr Zeit für ein tieferes Briefing nehmen: Nach dem ersten Gespräch ging es sofort los. Ich steckte in einem Video-Meeting mit dem Team und der CEO übergab mir sofort das Kommando: Also, Reiner, erzähl uns mal was von agil und von Scrum. Bei mir hätten da schon alle Alarmglocken angehen müssen, denn offensichtlich wusste das Team noch nichts von mir und so musste ich meine Idee und mich erst einmal „verkaufen“. Ein besonders undankbarer Start. Denn als guter Scrum Master (das weiß ich nun) geht es ja vorrangig ums Zuhören und eben nicht ums Schaumschlagen.

   Ich hätte besser das Meeting absagen und mit dem CEO erst einmal abstimmen sollen, was er von mir erwartet, wo er mit seinem Team steht, was er erreichen will, ob er schon einen Purpose, eine Roadmap und überhaupt weiß, was er für wen anbieten will. Im Nachhinein stellte sich heraus: nichts davon war vorhanden. Noch einmal derart unvorbereitet in die Arena geschickt, würde ich besser mit einer allgemeine Fragerunde oder mit einer kurzen Liberating Structure starten. Bloß nicht so viel über sich selber reden.

2. Mit kleineren Schritten näher ans Ziel: Gerade bei Startups will man ja gerne so schnell wie möglich weiterkommen, sich „durchwursteln“ und im Harakiri-Stil improvisieren. Ist diese unbedingte Flexibilität, die sich nach der Stimmung des Chefs richtet, nicht auch ein Bestandteil einer agilen Denke? In meiner Interpration haben agil praktizierende Menschen ein Rückgrat und agieren eben nicht als wären sie Wimpel im Wind. Das geht nur, wenn transparent genug ist, was man warum macht und was man besser lässt, weil es nicht zielführend ist. Dazu muss dem ganzen Team klar sein, warum und wozu es überhaupt existiert, welchen Prinzipien es folgt und für wen es etwas produziert. Also: Purpose, ein paar Regeln für die Zusammenarbeit und Stakeholder, Stakeholder, Stakeholder.

   Ich habe zu oft gesehen, dass Teams etwas produzieren, das für die Stakeholder in dieser Form keinen Wert hat – oder mehr Wert gehabt hätte, wenn sich das Team von Anfang tief und empathisch mit der Situation der Stakeholder beschäftigt hätten. Und, das ist ja wohl unerhört, mit den Stakeholdern frühzeitig gesprochen oder sogar eingebunden hätten. Wie soll man Arbeiten priorisieren, wenn das nicht klar ist? Ich bin daher schon im zweiten Meeting mit der Stakeholder-Map angekommen. Wir sammelten also Stakeholder und ordneten sie dann in eine Matrix aus Einfluss/Stake. Das Team hatte Schwierigkeiten, die Stakeholder in den wichtigsten Quadranten einzuordnen. Ein klärendes Gespräch half nichts. Denn am Ende zählte die Stimme des CEOs gefühlt fünffach.

   Als Scrum Master kommt man da schnell in eine schwierige Situation, wenn man beobachtet, dass die Teammitglieder nicht viel zu sagen haben. Das ist ein unangenehmes „Antipattern“. Ich habe diese Beobachtung dem CEO dann in einem Vieraugengespräch mitgeteilt, bin aber auf taube Ohren gestoßen. Er war immer begeistert von der agilen Idee, aber so richtig leben wollte er sie nicht. Und mehrmals beendete er Gespräche mitten in der Unterhaltung, wenn ihm das Thema zu heikel wurde.

3. Keine Zaubertricks versprechen: Zu Beginn war uns klar, dass ich bis zum Ende des Jahres als Scrum-Master dabei bin. Was kann man in drei Monaten erreichen? Wir können Stakeholder bestimmen, ein Daily Scrum starten und vielleicht ein Backlog-Board in Jira einrichten. Wenn sich aber zwei der drei Mitarbeiter nicht mit JIRA anfreunden wollen, dann wird es schwierig mit dem agilen Bootcamp.

   Ich erinnere mich an ein Meeting, in dem der CEO aus dem Auto auf der Autobahn hinzuschaltet und mit uns das Backlog bestücken und sortieren will. Eine fruchtlose Übung, wenn nicht klar ist, für welchen Stakeholder die Aufgabe (wir sind erst spät zum Thema „User Story“ gekommen) gedacht ist. Meine Lehre daraus: Ich bin erheblich konservativer, wenn es um eine Fortschrittsprognose geht. Lieber tiefstapeln und erklären, dass das alles Zeit benötigt und dass man erst einmal am gegenseitigen Vertrauen arbeiten sollte und nicht gleich alles umwerfen muss. Also: Aufpassen bei ungeduldigen Auftraggebern. Das geht eher schief.

4. Ein Hut reicht: Ich sollte das Unternehmen agiler machen und dachte zuerst an Scrum. Im Scrum Framework gibt es ein Scrum-Team, das aus einem Product Owner, einem Scrum Master und aus Developern besteht. Wie geht das, wenn das Team (inklusive mir) nur aus vier Leuten besteht? Ich merkte schnell, dass nicht der CEO, sondern einer der beiden Mitarbeiter ein geborener Product Owner ist. Fit, schnell und agil im Kopf. Allerdings war die Rolle schon besetzt. Der CEO war natürlich der Product Owner. Doch übernahm er nicht die Aufgaben eines Scrum-Product Owners: Wertoptimierung für Stakeholder, Markt genau kennen und den Backlog priorisieren.

Zu Beginn versuchte ich es mit Neutralität. Ich war die personifizierte Schweiz, hielt mich als Facilitator zurück. Doch zunehmend wollte ich meine Meinung bekunden. Das signalisierte ich mit einem Cowboy-Hut auf meinem Kopf. Wenn ich den anhatte, äußerte ich eine Meinung, eine Einschätzung. Ich dachte die Gruppe nach vorne zu bringen, aber letztlich störte ich das Gefüge, indem ich mich vermutlich zu sehr einmischte. Beim nächsten Projekt will ich diplomatischer leiten und wirklich nur eine Meinung abgeben, wenn ich zweimal hintereinander danach gefragt werde. Zumindest verstehe ich nun, dass ich zukünftig nur noch Scrum Master und keine Kombination aus Product Owner und Developer sein mag.

5. Dranbleiben: Für mich die wichtigste Erkenntnis ist, dass mir die Arbeit als Scrum Master sehr viel Spaß macht und dass ich damit auch zum Erfolg des Teams beitragen kann. Ich muss immer an die Katze Momo denken, die da ist und der sich jeder anvertraut, die aber doch eigentlich nichts sagt.

Als Ergebnis habe ich mein eigenes Purpose- und Mission-Statement als Scrum Master verfeinert. Noch eine Erkenntnis: Ich hatte mich zu sehr hinter Tools versteckt, doch eigentlich geht es um Präsenz und um das Öffnen eines Raumes, in dem Menschen offen und achtsam miteinander denken und arbeiten können. Das ist mein Ziel, aber ich bin noch weit weg davon. Ich bin gespannt, wo ich dann neue Erkenntnisse sammeln darf.