Vor kurzem haben die beiden Autoren des Artikels sich einmal mehr mit der Frage beschäftigt, wie sich erfolgreiche und weniger erfolgreiche Teams unterscheiden und was die Erfolgsfaktoren für erfolgreiche Teams sind. Es geht dabei nicht nur um die rein betriebswirtschaftlichen Erfolgsfaktoren wie In-Time und In-Budget, sondern vor allem auch um Kunden- und Mitarbeiterzufriedenheit und um den Nutzen der im Rahmen eines Projektes geschaffen wurde. Warum gibt es nun aber Teams, die diesen Erfolg vergleichsweise einfach erzielen während andere Teams sich mächtig ins Zeug legen, der Erfolg aber eher bescheiden ausfällt. Natürlich lassen sich dafür immer Gründe finden – der Kunde, das technologische Umfeld, das Unvermögen der Teammitglieder oder zumindest einzelner Personen oder einfach nur Pech – je nach Perspektive, die man einnimmt. Aber während man damit Misserfolge für sich selbst rechtfertigen kann, taugen diese Argumente wenig um eine nachhaltige Verbesserung zu erreichen.
Trotz der intensiven Beschäftigung mit verschiedenen Projektansätzen – in den letzten Jahren vor allem mit agilen Konzepten – war es uns nicht gelungen, das Erfolgsmodell von einem Team auf andere zu übertragen. Es scheint jedenfalls nicht der Prozess zu sein. Nur weil ein Team mit Scrum erfolgreich ist, bedeutet das nicht automatisch, dass Scrum auch die Probleme anderer Teams löst. Auch die Rahmenbedingungen scheinen nur einen Teil des Erfolges auszumachen. Ein Copy & Paste funktioniert hier nicht. Spannend war auch zu beobachten, dass bei einem Team das sehr erfolgreich war ein paar Monate später Probleme auftraten. Also scheint es auch nicht unbedingt an der Teamzusammensetzung zu liegen.
Ausgangspunkt der neuerlichen Diskussion war die Aussage eines Scrum Masters, dass er das Gefühl hat, bei einem seiner Teams aktuell mehr als Projektleiter denn als Servant Leader zu agieren. Dabei hat ihn irritiert, dass dieser Ansatz anscheinend recht gut funktionierte. Wie konnten wir nun diese Beobachtungen mit unserem tiefen Glauben an agile Werte vereinbaren? War die Projektleiter-Rolle nicht „böse“? Nach einigem Diskutieren wurde für uns klarer, was den Erfolg einzelner Teams ausmacht.
Es sind ein oder mehrere Menschen die genau auf entstehende Probleme und Risiken achten und konsequent handeln. Sie erkennen früh, wenn es ein Qualitätsproblem im Projekt gibt und leiten konsequent Maßnahmen zur Verbesserung ein. Sie beobachten, dass es Kommunikationsprobleme innerhalb des Projekt-Teams oder mit den Stakeholdern gibt und sorgen dafür, dass die wichtigen Informationen bei den relevanten Personen ankommen. Sie machen darauf aufmerksam, wenn wichtige Kompetenzen fehlen und fordern Lösungen dafür ein. Kurzum, sie erkennen, was notwendig ist und werden dann direkt aktiv um das Erforderliche umzusetzen. Und das tun sie bereits in einem sehr frühen Stadium wo ein klassischer Projektstatusbericht noch lange auf grün stehen würde, bis das Problem endlich offensichtlich ist. Dieses frühe Erkennen, aber auch die direkte Nähe zu den Problemsituationen gibt diesen Personen breitere und wirksamere Handlungsmöglichkeiten um den Problemen zu begegnen. Während die Reaktion auf einen „roten“ Projektstatusbereich meist lautet „schneller arbeiten“, können diese Personen besser die Entstehung von Problemen beobachten und Ursachenbekämpfung betreiben.
In Scrum ist genau dafür die Rolle des Scrum Masters vorgesehen. Um das aber an dieser Stelle schon klar zu sagen, wir sind nicht der Meinung, dass Scrum die einzige Methode ist, um Projekte erfolgreich zu gestalten. Egal, nach welchem Vorgehensmodell das Projekt aufgestellt ist und wie diese Rolle betitelt wird, das entscheidende ist, dass diese Rolle im Projekt wahrgenommen wird. Wir brauchen Erfolgsgaranten im Team. Ob dies ein Projektleiter, ein Scrum Master oder eine Gruppe von Software Entwicklern ist, spielt dabei keine Rolle. Entscheidend ist, dass diese Rolle im Team besetzt ist und in einer kollaborativen Art ausgelebt wird. Und deshalb haben auch gute Projektleiter erfolgreiche Projekte, unabhängig von Scrum. Und selbstverständlich gilt das auch für eine weibliche Besetzung der Rolle, eine Erfolgsgarantin. Zur Vereinfachung haben wir stellvertretend in diesem Artikel die männliche Variante Scrum Master gewählt wobei in der Praxis Frauen diese Rolle mindestens genauso gut ausführen.
Dabei soll der Erfolgsgarant nicht als Lösungsexperte oder Heilsbringer agier en, sondern die Rahmenbedingungen schaff en, sodass Lösungsstrategien aus dem Team heraus entstehen. Stellvertretend wollen wir beispielhaft näher betrachten, wie dies bei einem Scrum Master aussehen könnte und wie dies mit dem Konzept der Selbstorganisation zusammengeht. Das hier Beschriebene gilt aber natürlich äquivalent für andere Rollenbezeichnungen oder Prozessmodelle, setzen sie dann in den folgenden Ausführungen statt Scrum Master einen anderen Titel ein.
Etwas flapsig formuliert kann man die Aufgabe eines Scrum Masters am besten damit beschreiben, dass er anderen Leuten beim Arbeiten zusieht. Das hört sich zunächst nach einem Traumjob oder Geldverschwendung an, ist aber gar nicht so einfach umzusetzen. Es ist aber für den Projekterfolg extrem wichtig. Um Projektrisiken und Handlungsbedarfe nämlich frühzeitig erkennen zu können, benötigt der Scrum Master feine Antennen um zu erspüren, wo sich im Projekt gerade etwas zusammenbraut. Und diese feinen Antennen funktionieren nicht, wenn man gerade selbst voll im Aktionsmodus und vollauf damit beschäftigt ist Aufgaben abzuarbeiten. Das bedeutet, ohne ausreichend Zeit wird diese entscheidende Funktion im Projekt zu kurz kommen.
Um diese Antennen optimal auszubilden, braucht der Scrum Master möglichst viel Projekterfahrung und ein Gespür für potenzielle Problemsituationen. Und er braucht geeignete Strategien um auf diese Situationen zu reagieren. Diese Erfahrung kann man nicht aus Büchern oder Trainings bekommen, diese können lediglich Impulse und Anregungen für die Entwicklung bieten. Es ist an dieser Stelle unabdingbar, dass der Scrum Master aus gemachten Erfahrungen lernt und daraus Schlüsse zieht, wie er zukünftig besser auf entsprechende Situationen reagieren bzw. wie er diese früher erkennen kann. In anderen Worten, der Scrum Master muss diese Situationen durchlebt haben.
Das hört sich jetzt zunächst nach Feuerwehr an, jemand der immer da ist um aufkeimende Probleme zu lösen, den man zur Hilfe ruft, wenn es irgendwo klemmt. Wie verträgt sich das aber mit der in Scrum so hochgepriesenen Selbstorganisation? In vielen Teams wird der Scrum Master genau so wahrgenommen – als Problemlöser. Er sollte aber keine Probleme lösen, sondern in erster Linie darauf hinweisen. Es macht Sinn, hier zwischen Erfolgsgarant und Erfolgsfaktoren zu unterscheiden. Um das klar zu sagen, der Scrum Master kann alleine nie ein Projekt erfolgreich machen. Die dafür notwendigen Kompetenzen hat das Team - der Product Owner und das Development Team. Der Scrum Master als Erfolgsgarant erkennt lediglich, wenn wichtige Kompetenzen fehlen, macht diese transparent und fordert entsprechende Maßnahmen ein . Wie diese Maßnahmen aussehen, sollte aber das Team entscheiden. Der Scrum Master beobachtet dann wieder und weist darauf hin, sollte er feststellen, dass die Maßnahmen nicht greifen. Das heißt die Problemlösungskompetenz und die Verantwortung zur Problemlösung liegt im Team. Der Scrum Master unterstützt das Team dabei, diese Kompetenz weiter auszubauen.
Das bedeutet, dass das Team ohne den Scrum Master weiterhin funktionsfähig ist, z.B. wenn dieser krank oder im Urlaub ist. Lediglich das Risiko, dass Probleme erst später erkannt werden, steigt dadurch. Und das beantwortet auch eine häufig gestellte Frage: ja , der Scrum Master ist immer hilfreich, egal wie gut das Team funktioniert und wie gut es eingespielt ist. Zumindest die Funktion, die hinter dieser Rolle steht. Ob dafür eine dedizierte Person erforderlich ist, steht nochmals auf einem anderen Blatt.
Der Scrum Master nimmt sich also die Zeit, in das Team und das Projekt hineinzuhorchen. Er beobachtet und spürt, wo es notwendig ist, aktiv zu werden. Diese Beobachtung teilt er mit dem Team und sorgt dann für die Wirksamkeit der ergriffenen Maßnahmen. Er befreit in dieser Rolle die Teammitglieder nicht von ihrer Verantwortung als Erfolgsfaktoren. Das heißt, auch diese übernehmen Verantwortung für den Projekterfolg. Scrum Master und Team ergänzen sich dabei. Während das Team dafür sorgt, dass die notwendigen Aufgaben im Team effizient und in hoher Qualität erledigt werden, sorgt der Scrum Master für gute Rahmenbedingungen und versucht einen guten Überblick über das Projekt zu behalten. Dazu nimmt er verschiedene Perspektiven auf das Projekt ein und fragt sich z.B. wie sehen die Anwender, die Stakeholder, der Support und andere unser Projekt. Und wo müssen wir gemeinsam reagieren, was kann im Moment erst mal weiterlaufen.
Unter diesem Blickwinkel wird nicht nur die Wichtigkeit des Scrum Masters nochmals klarer, sondern es verdeutlicht auch nochmals die notwendigen Fähigkeiten und die Aufgaben. Möchte man diese Rolle nicht nur irgendwie besetzen um dem Scrum Guide genüge zu tun, dann muss die Person, die diese Rolle ausfüllen soll, sorgfältig gewählt werden. Kann sie tatsächlich als Erfolgsgarant fungieren? Hat sie die notwendigen Fähigkeiten und Erfahrung aber auch das notwendige Standing um Situationen schonungslos darzustellen und Maßnahmen konsequent einzufordern, ggf. auch gegenüber dem Management? Wenn die Antwort auf diese Fragen Ja lautet, dann sollte der Scrum Master zusammen mit dem Team weitreichende Autonomie erhalten. Falls nicht, dann muss daran gearbeitet werden, den Scrum Master in diese Funktion zu entwickeln. Mit diesem Vorgehen wird der Projekterfolg sich auch einstellen, jedenfalls wahrscheinlicher als wenn der Vorgesetzte das Team einfach nur in die Selbstorganisation entlässt und sich dann einfach aus allem heraushält mit dem Kommentar „Ihr seid doch jetzt selbstorganisiert“.
Ob sie nun also Scrum in ihren Projekten nutzen oder anders aufgestellt sind, fragen sie sich: Wer ist in meinem Projekt der Erfolgsgarant? Handelt er so, dass er die Selbstorganisation und die Entwicklung der Teammitglieder fördert oder ist er der Flaschenhals an dem der Projekterfolg direkt hängt, weil er auch Lösungsexperte ist? Jedenfalls kann dieser Erfolgsgarant der entscheidende Faktor sein. Er wird flexibel auf Situationen reagieren und das Notwendige umsetzen. Und so sollten nicht nur ihre Projekte erfolgreicher sein, sondern sie haben ein Umfeld geschaffen in dem es Spaß macht und sich motiviert arbeiten lässt.