Machmal frage ich mich, ob wir vor lauter Tools und Techniken - von der Timer-Uhr für Meetings bis zu Tipps für die richtigen Umgebungsbedingungen - die Quintessenz unseres Jobs als ScrumMaster übersehen. Natürlich, das höchste Ziel des ScrumMasters ist es letztendlich, die Produktivität zu erhöhen. Es geht dabei aber nicht darum, die Teams mit Tools zu überschütten, sondern sie auf dem Weg zur Selbstorganisation zu begleiten. Es geht darum, die Kraft des Teams freizusetzen.Scrum als Methode hat vor allem ein Ziel: Die Entscheidungen dorthin zu bringen, wo das Wissen vorhanden ist - also beim Team. Darüber hinaus ist eines der Prinzipien: learn fast and fail fast. Zu Deutsch: Mach das, was du für richtig hältst, finde eine Möglichkeit, schnell eine Ergebnis zu erhalten und dann lerne aus deinen Fehlern. So sehr wir diese Werte als ScrumMaster vertreten mögen, manchmal vergisst man dabei, was es konkret heißt.
In einer meiner letzten Retrospektiven als ScrumMaster habe ich um Feedback gebeten. Es ging mir darum, mich selbst und meine Arbeit als ScrumMaster zu verbessern. Am prägnantesten sind mir zwei Kommentare in Erinnerung geblieben: „Entspann dich, wir müssen mehrere Stories parallel fertigstellen, die Abhängigkeiten sind einfach zu groß“ und „Lächle mal wieder“. Der Hintergrund dieser Geschichte war, dass ich mein Team immer wieder motivierte, einzelne Stories abzuschließen, statt viele Stories auf einmal zu eröffnen und parallel zu bearbeiten. Ich wusste ja, dass die Leistung bei parallelen Tätigkeiten abnimmt (siehe Synchronitis).Und plötzlich hat es Klick gemacht. Seien wir doch mal ehrlich: Ich arbeite in einem multidisziplinären Team, ich bin nur oberflächlich in das tägliche Doing involviert und last but not least bin ich nicht die Stelle, an der die meisten Informationen zentriert sind. Sprich, ich weiß einfach nicht am besten, was das Team braucht. Das Team selbst weiß es und wenn es auch einmal falsch liegen sollte, dann muss ich darauf vertrauen, dass es lernt und es beim nächsten Mal besser macht. Das Elementare ist dabei aber nicht, jeden Fehler zu vermeiden, sondern die Möglichkeit zum Lernen zu etablieren. Schafft er das nicht, wird ein ScrumMaster immer wieder das Gefühl haben, am Ende die Kohlen aus dem Feuer holen zu müssen. Das mag dem Ego schmeicheln, funktioniert aber sicher nicht als Basis für die Selbstorganisation eines Teams.
Was ich von da an machte, war von außen betrachtet genau so simpel, wie es innerlich schwierig war. Ich hielt mich raus. Ich ging zum Management und sagte: „Ich kann nicht sagen, wie wir den nächsten Sprint abschließen werden. Kann sein, dass unsere Leute eine schlechtere Performance ablegen und daraus lernen. Langfristig betrachtet sollen sie sich selbst organisieren und dazu müssen sie aus ihren Fehlern lernen. Kann aber auch sein, dass sie eine wahnsinnig gute Performance hinlegen und ich mich geirrt habe. Dann habe ich sie in den letzten Monaten zu sehr darauf getrimmt, fokussiert an einer Sache zu arbeiten. Fakt ist, wir wollen selbstorganisierte Teams, also müssen wir ihnen auch den Platz fürs Lernen einräumen.“Ja, aus dem Feedback hatte ich definitiv gelernt, dem Team Raum zu lassen, um sich zu entfalten. Ich muss ihnen den Freiraum verschaffen, möglicherweise Fehler zu machen und eventuell muss ich in meiner Rolle als ScrumMaster auch den Kopf dafür hinhalten. Denn am Ende des Tages ist und bleibt es meine Aufgabe, die Produktivität zu erhöhen und ich werde danach vom Management beurteilt. Aber ich habe vor allem auch das Management informiert und über meine Beweggründe auf dem Laufenden gehalten, denn das Management muss wissen, woran es ist. Darüber hinaus habe ich dem Team zeitweise meine Hilfe angeboten und mit einzelnen Teammitgliedern über den Stand der Dinge geredet. Was gebraucht wurde, habe ich organisiert. In anderen Punkten hat mir das Team gesagt, dass es sein Bestes tun werde, um das Commitment zu halten. Mehr kann ich mir nicht wünschen.
In den letzten Tagen vor Sprintende bemerkte ich, dass eine große Anzahl an Stories noch offen war, dass aber auch kaum mehr Tasks bei diesen Stories vorhanden waren. Die Ruhe, die mich und das Team umgab, war Neu. Die Teammitglieder hetzten nicht, sondern arbeiteten konzentriert und Sie committeten eine Vielzahl von Stories (aus meiner Sicht zu viele). Der Druck war hoch, aber alle blieben ruhig. Zum ersten Mal hatte ich das Gefühl, dass es ihr Sprint war, weil sie für ihre Fehler und Erfolge gerade stehen durften und es nicht für jemand anderen taten.In diesem Sinne: Lassen Sie als ScrumMaster Ihrem Team die Luft zum Atmen. Es fällt schwer, die Dinge aus der Hand zu geben, aber echte Selbstorganisation braucht Raum für Fehler, um sich entfalten zu können. Und was Sie nicht vergessen sollten: Halten Sie das Management am Laufenden - schließlich ist Transparenz einer der Grundwerte von Scrum.