TopMenue

Scrum-Master

Scrum ist der Rahmen, Scrumcess der Prozess

Ein Teil dieser Seiten wurde ursprünglich für doktor-scrum.de geschrieben und ziehen nun hierher nach scrumcess.de um; leider sind sie aber inhaltlich noch nicht vollständig auf scrumcess.de umgearbeitet. Zudem ist es durchaus möglich, dass die enthaltenen Links noch ins Leere zeigen, bzw. noch auf doktor-scrum.de verweisen.
Ich bitte Sie, das zu entschuldigen.

Verantwortungsbereiche des Scrum-Masters  ^

Die Rolle des Scrum-Masters ist eine der zentralen Rollen in Scrum, er ist der Hüter des Prozesses. Seine Aufgabe ist zum einen, darauf zu achten, dass alle am Projekt Beteiligten die Regeln von Scrum kennen und einhalten und zum anderen, den am Projekt beteiligten Personen eine höchstmögliche Produktivität zu ermöglichen. Er ist dabei dem Prinzip des „dienenden Führens“ verpflichtet, da er — im Gegensatz z.B. zu Team- oder Projektleitern, die „beherrschend führen“ — gegenüber den Teammitgliedern über keine disziplinarischen oder anderweitigen Machtmittel verfügt, weshalb Team- oder Projektleiter nicht die Scrum-Master „ihres“ Teams sein oder werden sollten.

Man kann beim Scrum-Master zwischen zwei „Modi“ seiner Tätigkeit unterscheiden:

  1. Einführung von Scrum in einer Test- oder Pilotphase, vielleicht aber auch in einem (produktiven) Projekt, und
  2. Produktiver Einsatz von Scrum einem (produktiven) Projekt

Der Unterschied liegt darin, dass der Scrum-Master das Team während der Einführung von Scrum auch an den Stellen, wo die Projektbeteiligten sich über ihre innere Organisation (später) selbst führen sollen, in hohem Maß führen wird, um sie an den Weg, den Scrum vorgibt und der ein anderer ist als in den klassischen Softwareentwicklungsprozessen, heranzuführen. Er wird anfangs die Meetings moderieren und die Backlogs pflegen, aber alle diese Aufgaben so früh wie möglich an die entsprechenden Adressaten abgeben. In dieser Phase kann man davon ausgehen, dass die Rolle des Scrum-Masters ein Vollzeit-Job ist.

Ist die Einführung bereits sehr weit fortgeschritten oder sogar abgeschlossen und treten nur noch selten Situationen auf, in denen der Scrum-Master eingreifen muss, wird er sich bereits sehr weit aus der Selbstorganisation und Pflichten der Projektbeteiligten herausgezogen haben und kann — sofern er ein externer Scrum-Coach war — seine Aufgabe vollständig an einen Projektteam-internen Scrum-Master übergeben.

Sofern sich das Team / Projekt noch in der Einführung von Scrum befindet, wird der Scrum-Master allen Beteiligten den Prozess, seine Abläufe und Regeln, nahe bringen, bzw. sie darin schulen. Im Laufe des Projektes wird er daher solange die Moderationen der verschiedenen Meetings übernehmen, bis sich die jeweils beteiligten Personen (-Gruppen) in der Lage fühlen, die Meetings in eigener Regie durchzuführen. Er wird die Meetings jedoch weiterhin begleiten, um bei Problemen, Konflikten oder Unsicherheiten beratend und unterstützend eingreifen zu können.

Darüber hinaus steht die Produktivität des Teams in seinem Fokus. Sollten Situationen auftreten, in denen Teammitglieder durch äußere Umstände in ihrer Produktivität eingeschränkt werden und erkennt der Scrum-Master dies oder wird es ihm zur Kenntnis gebracht, ist es seine Aufgabe, diese Probleme umgehend zu beseitigen.

Die Stellung des Scrum-Masters im Projekt  ^

Die Rolle „Scrum-Master“ wird mancherorts recht kritisch betrachtet. Man hört dann, dass diese Rolle komplett unproduktiv sei. Ein Scrum-Master erzeugt keinen Code, keine Dokumentation und auch keine Diagramme, er nimmt keine Spezifikation auf und er ist auch nicht die Urlaubsvertretung von Entwicklern oder des Product-Owners. Viel sinnvoller wäre es daher, je nach Entlohnung des Scrum-Masters einen oder mehrere weitere Entwickler in das Projekt zu holen, statt den Platz mit einer einzelnen „lame duck“ zu blockieren. Diese (extreme) Sicht ist sicher nachvollziehbar, aber gewiss nicht zielführend. Sie ist vergleichbar mit der Idee, in einem Fußballverein den Trainer zugunsten eines weiteren Feldspielers oder Torhüters einzusparen, was aber — so wurde mir versichert — sowohl ganz unmöglich und auch etwas ganz anderes sei. Aha.

Andere beurteilen die Rolle des Scrum-Masters weitaus positiver. Sie sagen z.B., die Aufgabe des Scrum-Masters wird umso wichtiger und umfangreicher, je versierter und effektiver Entwicklungsteam und Product-Owner in der Ausübung des Prozesses sind, da es für den Scrum-Master immer schwieriger und zeitaufwändiger wird, Optimierungspotenziale aufzudecken und durchzusetzen. Diese (ebenfalls extreme) Sicht ist auch durchaus nachvollziehbar, aber man kann darüber streiten oder zumindest diskutieren, ob auch sie vielleicht nur in Grenzen zielführend ist, da irgendwann der Punkt erreicht ist, wo eine weitere intensive Suche nach potenziellen Optimierungsmöglichkeiten einen weitaus größeren Aufwand mit sich bringt, als es wirtschaftlichen Nutzen einfährt. Das bedeutet nicht, dass das Engagement des Scrum-Masters für dieses Team oder Projekt nicht mehr gebraucht würde, aber spätestens wenn man erkennt, eventuell so einem Punkt angekommen zu sein, sollte es möglich sein, dem Scrum-Master zu ermöglichen, seine Aktivitäten auf weitere Ziele — welche auch immer das sein könnten, z.B. Betreuung weiterer Teams oder Mitarbeit im Projekt als Entwickler, Tester, usw. — ausdehnen zu können.

Die Wahrheit liegt wahrscheinlich — wie so oft — irgendwo dazwischen, mit Sicherheit jedoch mit einer deutlichen Tendenz zu der Seite der Fraktion der Immerweiteroptimierer.

Die Rolle des Scrum-Masters ist weniger eine Position, wie sie z.B. „Projektleiter“ oder „Teamleiter“ ist, sondern vielmehr eine wesentliche Aufgabe und Herausforderung im Scrum-Prozess, deren Bedeutung nicht unterschätzt werden darf. Der Scrum-Master ist nicht nur der Hüter des Prozesses, sondern auch der gute Geist des Projektteams. Er ist der Koordinator des Prozesses, der die innere Reibung im Team vermindert, der Kanten glättet, der Hindernisse beseitigt oder Pfade zu Umgehung von Hindernissen aufzeigt und Wege frei macht; er ist derjenige, der das Team von außen betrachtet und dabei die Optimierung des Realisationsprozesses und der Maximierung der Produktivität im Auge hat, er ist derjenige, der Rotkäppchen auf dem optimalen Weg durch den Wald zu halten versucht; nicht nur, damit es nicht vom Wolf gefressen wird, sondern auch, damit es möglichst schnell und vollständig samt Korb und Inhalt bei der Großmutter ankommt.

Das Team, das der Scrum-Master zu unterstützen hat, ist zwar hauptsächlich das Entwicklungsteam, besteht aus der o.g. Sicht heraus jedoch bei Bedarf aus allen am Projekt beteiligten Personen, also nicht nur die Entwickler, sondern auch der Product-Owner und ggf. sogar die Stakeholder.

Aufgaben des Scrum-Masters  ^

Sicherstellen, dass alle Beteiligten den Regeln des Prozesses folgen  ^

Eine der wichtigsten Aufgaben des Scrum-Masters ist, allen Beteiligten die Regeln und Prozesse von Scrum nahezubringen; er ist der Hüter des Prozesses. Er wird Sie in der Handhabung von Scrum unterweisen, anleiten und coachen. Er wird in allen wichtigen Meetings dabei sein und darauf achten, dass sich alle Beteiligten an die Regeln von Scrum halten. Gibt es Bestrebungen, sich vom Prozess zu entfernen, wird er die Beteiligten über die Konsequenzen ihres Handelns aufklären und sie wieder auf dem Scrum-Pfad zurückbringen.

Permanenter Ansprechpartner für Product-Owner und Entwicklungsteam  ^

Der Scrum-Master ist für alle projektbeteiligten Personen für jede Frage bezüglich Scrum jederzeit ansprechbar. Er wird jeden gerne, egal ob Entwickler, Product-Owner oder Stakeholder, in Sachen Scrum und der Optimierung der jeweiligen Prozesse beraten.

Permanente und intensive Zusammenarbeit mit dem Scrum-Team  ^

Der Scrum-Master unterweist und coacht das gesamte Scrum-Team im Hinblick auf den Scrum-Prozess. So, wie der Product-Owner verantwortlich ist für den wirtschaftlichen Erfolg des Projektes, ist der Scrum-Master verantwortlich für die erfolgreiche Einführung und Umsetzung des Scrum-Prozesses. Er wird mit allen Beteiligten intensiv zusammenarbeiten und sicherstellen, dass die Prinzipien und Werte, auf denen Scrum basiert, verstanden und verinnerlicht wurden.

Dabei ist er auf die Unterstützung des Managements des Unternehmens, in/für das das Projekt durchgeführt werden soll, angewiesen; ein Sachverhalt, den man als selbstverständlich ansehen sollte, der aber nicht immer vollumfänglich gegeben ist, da die Sichtweisen, auf denen Scrum basiert, oftmals von den bis dahin praktizierten Sichtweisen abweicht und daher oft kontrovers aufgenommen wird.

Anwalt des Entwicklungsteam  ^

Der Scrum-Master ist nicht nur für die Einhaltung der Regeln von Scrum zuständig, sondern er vertritt auch die Belange des Entwicklungsteams gegenüber dem Product-Owner und den Stakeholdern.

Verantwortlich für die Produktivität  ^

Die Produktivität des Entwicklungsteams ist für den Scrum-Master das Maß aller Dinge. Hierfür ist er verantwortlich. Dabei arbeitet er insbesondere dem Entwicklungsteam zu.

Motivator des Scrum-Teams  ^

Der Scrum-Master ist verantwortlich für die Produktivität des Teams. Dazu gehört, das Team immer wieder im Hinblick auf das Befolgen der Regeln von Scrum und das erfolgreiche Erreichen des Projektzieles hin zu motivieren.

Unterstützer des Product-Owners  ^

Der Scrum-Master wird den Product-Owner in der Durchführung der Projektplanung und in der Anforderungsanalyse und -management, d.h. in der Erarbeitung und Formulierung von User-Stories (ggf. auf Wunsch des Product-Owner auch vor Ort mit den Stakeholdern) unterstützen.

Insbesondere, wenn der Product-Owner zuvor der Projektleiter war, ändert sich für ihn in einem Scrum-Projekt so einiges. Er ist nicht mehr der „Bestimmer“, sondern muss der Teamplayer sei, der mit den anderen Projektbeteiligen verhandeln muss, was nicht jedem sofort und ansatzlos gelingt. Der Scrum-Master unterstützt ihn darin.

Unterstützer des Entwicklungsteams  ^

Auch wenn der Scrum-Master der Scrum-Master für das ganze Team ist, ist doch sein eigentliches Team das Entwicklungsteam. Das Entwicklungsteam ist der Motor des Projektes und die Aufgabe des Scrum-Masters in Zusammenarbeit mit dem Product-Owner ist, diesen Motor schön am Brummen zu halten.

Die „Drehzahl“ des Entwicklungsteams ist die Summe aus der Menge, der Relevanz und der Qualität des Codes, den sie produzieren. Je mehr sich das Entwicklungsteam auf diese drei Werte konzentrieren kann, also die Produktion einer großen Menge relevanten und qualitativ hochwertigen und durch Unit-Tests abgesicherten Codes, desto höher ist in dieser Darstellung ihre Drehzahl. Das Entwicklungsteam soll im Leerlauf laufen, aber auch nicht ständig auf Höchstdrehzahl und schon gar nicht im roten Bereich, sondern möglichst auf einer Drehzahl zwischen höchstem Drehmoment und höchster Leistung; auf einer Drehzahl, die das Entwicklungsteam gut, dauerhaft und ohne Überlastung und damit ohne den sich aus einer Überbelastung zwangsläufig ergebenden Verschleiß, durchhalten können und wollen.

Um das zu erreichen, müssen er und der Product-Owner sich mit dem Entwicklungsteam beschäftigen, die Mitglieder des Entwicklungsteam kennenlernen, ihre Stärken und Schwächen, sie müssen wissen, wie die Entwickler denken, wie sie „ticken“. Sie beide sehen den maximalen Nutzen für das Projekt in einem optimal funktionierenden Team, in dem sich jeder auf jeden verlassen kann („einer für alle, alle für einen“), nicht aus einer Zusammenstellung vielleicht hochbegabter, aber dennoch zueinander inkompatibler Diven.

Beseitigen von Hindernissen, die der Produktivität des Teams im Weg stehen  ^

Damit das Entwicklungsteam auf hoher Drehzahl ohne Aussetzer touren kann, ist es die Aufgabe des Scrum-Master (und auch des Product-Owners, aber eben hauptsächlich die des Scrum-Master), dem Entwicklungsteam alle Hindernisse, die das Halten der optimalen Drehzahl, also in diesem Zusammenhang das Erreichen der höchstmöglichen Produktivität, gefährden könnten, so schnell wie möglich aus dem Weg zu räumen.

Treten im Projekt Probleme auf, wie z.B., dass Meeting-Räume belegt sind, der Beamer besetzt ist, Zugangsberechtigungen fehlen oder andere notwendige Ressourcen nicht oder nicht im notwendigen Rahmen zur Verfügung stehen, sind das Hindernisse, die sich negativ auf die Produktivität des Teams niederschlagen, da sich jemand darum kümmern werden muss, diese Hindernisse möglichst zeitnah zu beseitigen. In Scrum sollen sich die Mitglieder des Entwicklungsteams ausschließlich auf ihre eigentliche Aufgabe, die von ihnen für den jeweiligen Sprint akzeptierten Anforderungen vollständig zu realisieren, konzentrieren können, daher ist es die Aufgabe des Scrum-Masters, sich darum zu kümmern, dass diese, die Produktivität des Teams gefährdenden Hindernisse (sog. Impediments) zeitnah beseitigt werden.

Sobald dem Scrum-Master solche Hindernisse bekannt werden, trägt er sie in das Impediment-Backlog ein, dass er — analog zum Product-Backlog, das der Product-Owner pflegt — nach Priorität absteigend sortiert, sodass das Impediment mit der höchsten Priorität ganz oben zu finden ist. Seine Aufgabe besteht nun darin, die Impediments des Backlogs in der Reihenfolge der Sortierung abzuarbeiten, um diese Hindernisse zu beseitigen und damit die höchstmögliche Produktivität des Entwicklungsteams zu gewährleisten. Im Daily-Scrum wird der Scrum-Master dann von den von ihm bearbeiteten und den sich noch im Impediment-Backlog befindlichen Einträgen berichten.

Optimieren des Teams, insbesondere des Entwicklungsteams  ^

Die Aktivitäten des Scrum-Masters, dem Team eine möglichst hohe Produktivität zu ermöglichen, erschöpfen sich allerdings nicht nur in der Optimierung der Rahmenbedingungen für die Arbeit des Teams, sondern er achtet auch auf das Team an sich. Er beobachtet die einzelnen Teammitglieder und das Team insgesamt und sucht nach Optimierungspotenzialen in ihrer Arbeitsweise, in ihrer Kommunikation und Kollaboration und in den von ihnen angewandten Techniken, Prozessen und Strukturen. Je nachdem, wie er die Dringlichkeit einer Veränderung einschätzt, wird er diese Optimierung entweder kurzfristig, mittelfristig (z.B. während oder im Anschluss an das nächste Daily-Scrum), oder am Ende des Sprints in der Sprint-Retrospektive thematisieren.

Liegt das Optimierungspotenzial auf Seiten des Product-Owners oder in der Kollaboration von Entwicklungsteam und Product-Owner, wird der Scrum-Master das Thema bereits bei der nächsten sich bietenden Gelegenheit zur Sprache bringen, da der Product-Owner z.B. an der Sprint-Retrospektive nicht teilnimmt.

Reporting gegenüber Product-Owner und Entwicklungsteam  ^

Eine der Aufgaben des Scrum-Masters ist, das Impediment-Backlog zu führen. Im täglichen Daily-Scrum wird der Scrum-Master dem Entwicklungsteam über die von ihm bearbeiteten und den Stand der sich noch im Impediment-Backlog befindlichen Einträgen berichten. Im Sprint-Review wird der Scrum-Master dem Product-Owner einen Überblick über die von ihm bearbeiteten und sich noch im Impediment-Backlog befindlichen Einträgen geben.

Teilnehmer aller Meetings, ggf. als Coach und Moderator  ^

Der Scrum-Master nimmt an allen von Mitgliedern des Scrum-Teams durchgeführten Scrum-Terminen teil. An externen Termin, z.B. bei den Stakeholdern, die vorrangig durch den Product-Owner durchgeführt werden, nimmt der Scrum-Master nur dann teil, wenn der Product-Owner oder die Stakeholder ihn ausdrücklich dazu einladen.

Befindet sich Scrum noch in der Einführungsphase wird der Scrum-Master / Scrum-Coach zunächst einen großen Teil der Meetings — wenn nicht sogar alle — moderieren; er wird er so lange in die Abläufe und Prozessschritte eingreifen, bis sie von den Beteiligten vollständig verstanden und verinnerlicht wurden. Später wird er die Moderation der Meetings größtenteils an die dafür vorgesehen Personen abgeben (außer Daily-Scrum) und dann nur noch als normaler Teilnehmer teilnehmen. Gibt es neben dem Scrum-Master einen separaten Scrum-Coach, wird der Coach den Scrum-Master an alle diese Aufgaben heranführen und unterstützen.

Sollte es sich auch später noch als notwendig erweisen, in den Ablauf eines Meetings einzugreifen, werden Scrum-Master oder Scrum-Coach (und nur sie) diesen Eingriff in Abstimmung mit dem aktuellen Gesprächsführer durchführen, bzw. den aktuellen Gesprächsführer in der Gesprächsführung aktiv unterstützen.

Es ist nicht im Sinn oder Aufgabe des Scrum-Master, die Leitung eines Teams oder eines / aller Meetings dauerhaft zu übernehmen; es ist seine Aufgabe, andere aus dem Team dazu zu befähigen und zu ermutigen, diese Aufgabe verantwortlich zu übernehmen.

Keine Aufgaben des Scrum-Masters  ^

Entwicklungsteam zusammenstellen  ^

Dies ist eine Aufgabe des ausführenden Unternehmens. Ggf. kann der Scrum-Master, wie auch der Product-Owner, dabei beratender Teilnehmer zu sein.

Der Scrum-Master ist der Hüter des Prozesses und kein Projekt- oder Personalleiter. Es ist daher nicht seine Aufgabe, sich ein Team zusammenzustellen, sondern seine Aufgabe ist, einem vorhandenen Team die Thematik „Scrum“ nahezubringen. Betrachtet man den gesamten Prozess, wäre es weitaus sinnvoller, wenn sich das Entwicklungsteam einen Scrum-Master suchen würde, als dass ein Scrum-Master ein Team „bekommt“. Allerdings ist das in den seltensten Fällen möglich. Im Allgemeinen ist das Team bereits vorhanden, oder der Product-Owner kennt ein Team und hat gute Erfahrungen mit ihnen und wird sich darauf verwenden, das Projekt mit diesem Team durchzuführen, denn umso besser das Team aufeinander eingespielt ist, umso besser wird auch das Projekt laufen.

Festlegen, was im Sprint bearbeitet wird  ^

Dabei handelt es sich um eine Aufgabe, die (fast) ausschließlich dem Entwicklungsteam obliegt; der Product-Owner präsentiert eine nach dem Geschäftswert der Aufgaben sortierte Liste mit Vorschlägen, aus denen (darum „fast“) das Entwicklungsteam eine den Sprint füllende Anzahl der höchstpriorisierten Einträge für die Realisation im Sprint auswählt.

Der Scrum Master ist zwar Teilnehmer des Sprint Planning, hat aber in seiner Rolle kein Mitspracherecht bezüglich der im Sprint zu realisierenden Funktionalitäten. Das Festlegen des im Sprint zu realisierenden Funktionsumfangs, wird im Sprint-Planning, Phase 1, durchgeführt. Der Product-Owner schlägt eine Anzahl der am höchsten priorisierten Product-Backlog-Items für die Realisierung im Sprint vor. Die Entwickler und der Product-Owner diskutieren über die Funktionalitäten. Ist eine Anforderung ausgiebig genug vertieft, geben die Entwickler eine Schätzung über den potentiellen Realisationsaufwand ab. Sind alle, oder zumindest eine ausreichend erscheinende Menge der vom Product-Owner vorgeschlagenen Funktionalitäten besprochen und geschätzt, legt das Entwicklungsteam gemeinsam mit dem Product-Owner anhand von Priorität, Größe und Abhängigkeiten zwischen den Anforderungen fest, welche Anforderungen im zu planenden Sprint realisiert werden.

Das ist ein sehr interaktiver Prozess, in dem Entwicklungsteam und Product-Owner permanent verhandeln, abwägen und nach Kompromissen suchen.

Aufgabe des Scrum-Masters ist, darauf zu achten, dass sich alle Beteiligten an die Regeln halten und dass es zu keinen kommunikativen Dead-Locks kommt. Insbesondere in der Anfangsphase eines Projektes mit einem in Scrum noch unerfahrenen Team ist der Zyklus des Vorstellens einer Anforderung, des Diskutierens und des Schätzens viel einfacher, wenn es von einem erfahrenen Coach / Scrum-Master begleitet wird.

Im Sprint Aufgaben verteilen und organisieren  ^

Eine Kernaussage von Scrum ist, dass sich das Entwicklungsteam ausschließlich selbst organisiert; weder die Stakeholder, noch der Product-Owner oder der Scrum-Master nehmen Einfluss auf das Entwicklungsteam oder schreiben dem Entwicklungsteam vor, wie sie nach welchem Muster in welcher Reihenfolge die anstehenden Arbeiten durchzuführen haben. Entscheidend ist, dass am Ende des Sprints die Anforderungen, zu deren vollständiger Umsetzung sich das Entwicklungsteam verpflichtet hat, fertiggestellt wurden. Selbstverständlich steht der Scrum-Master dem Entwicklungsteam jederzeit helfend mit Rat und Tat zur Seite, aber wer wann welche Aufgabe in welcher Form löst, bestimmt das Entwicklungsteam allein; hier sollte der Scrum-Master dem Entwicklungsteam allerdings bei Bedarf mit Rat und Tat unterstützend zur Seite stehen.

Anforderungen in Arbeitspakete zerlegen  ^

Die Anforderungen in Arbeitspakete zu zerlegen ist eine ausschließliche Aufgabe des Entwicklungsteams. Ein in der Softwareentwicklung erfahrener Scrum-Master kann hier zwar ganz sicher sehr wertvolle Hilfestellung leisten, aber die Entscheidung über die Art und Weise der Zerlegung der Anforderungen in an ihren Stil und ihre Arbeitsweise angepasste Arbeitspakete, liegt ganz bei den Mitgliedern des Entwicklungsteams.

Vorgesetzter / Leiter des Scrum-Teams / Entwicklungsteams sein  ^

Scrum schließt disziplinäre Hierarchien, Weisungsbefugnisse, etc., zwischen den Rollen und innerhalb der Teams explizit aus, um insbesondere dem Entwicklungsteam die Möglichkeit zu öffnen, frei von äußerem Druck ihre inneren Potentiale für die Schaffung kreative und innovative Lösungen freisetzen und bündeln zu können.

Aus diesem Grund schließt Scrum disziplinäre Hierarchien, Weisungsbefugnisse, etc., zwischen den Rollen und innerhalb der Teams explizit aus. Scrum stellt statt dessen Werte und Eigenschaften, wie Eigenständigkeit, Gleichwertigkeit und Kompromiss- und Konsensfähigkeit aller am Projekt beteiligten Rollen und Individuen, insbesondere des Entwicklungsteams, konsequent und ausdrücklich in den Vordergrund, um damit die Motivation und den Willen eines jeden Beteiligten ausdrücklich darin zu unterstützen, das Projekt schnell, sicher und erfolgreich für das eigene Unternehmen und die Stakeholder abzuschließen.

Gleichzeitig Product-Owner / Stakeholder / Entwickler sein

Der Scrum-Master muss eine unabhängige Rolle sein, um seine Aufgaben durchführen zu können, da ansonsten, wenn diese Unabhängigkeit nicht gegeben ist, Interessenkonflikte drohen. Selbstverständlich gelten diese Bedenken auch unter der Maßgabe, dass die Person, die die zwei Rollen einnimmt, zu einer Zeit immer nur eine der (zwei oder mehr) Rollen vertritt und dann jeweils zu der anderen Rolle vollständig umschaltet.

Gleichzeitig Product-Owner?
In Scrum sind die Rollen Scrum-Master und Product-Owner nicht nur gute Teamworker, sondern gleichzeitig auch Gegenspieler, da der Scrum-Master der Anwalt des Entwicklungsteams und der Product-Owner der Anwalt der Stakeholder ist. Besetzt eine Person beide Rollen, ist es sehr unwahrscheinlich, dass sie gleichzeitig beide Seiten angemessen vertreten kann.

Gleichzeitig Stakeholder?
Auch wenn in diesem Fall der innere Konflikt nicht ganz so groß sein mag, wie in der Konstellation „Scrum-Master und Product-Owner“ ist auch hier ein Konfliktpotential enthalten; soll der Scrum-Master doch der Anwalt des Entwicklungsteam sein und das Entwicklungsteam z.B. gegen Forderungen und Einflussnahme der Stakeholder schützen. Auch wenn es gar nicht so sehr um das Problemfeld „Scrum-Master und Stakeholder“ geht, sondern auch nur um das Feld „Scrum-Master kommt vom Stakeholder„, ist zu hinterfragen, inwieweit der Scrum-Master in dieser Konstellation unabhängig von den Stakeholder agieren kann.

Gleichzeitig Entwickler?
Diese Konstellation ist die noch am ehesten denkbare, vielleicht zumindest zeitweilig noch gangbare Konstellation. Ist Scrum gut im Team eingeführt und von allen Beteiligten vollständig verstanden und verinnerlicht worden, könnte es durchaus möglich sein, dass jeweils einer der Entwickler aus dem Entwicklungsteam für eine gewisse Zeitspanne, z.B. jeweils für einen Sprint, gleichzeitig zu seiner Aufgabe als Entwickler auch die Rolle des Scrum-Master übernimmt. Da der Scrum-Master insbesondere das Entwicklungsteam unterstützen und schützen soll, muss sich die Person, die gleichzeitig Entwickler und Scrum-Master sein soll, nicht vollständig von den Belangen seiner Ursprungsrolle frei machen, sondern insbesondere diese Belange berücksichtigen und vertreten. Selbst die Entwicklungsteam-interne Disziplinierung, die auch Teil Selbstorganisation und Teamdisziplin ist, muss nicht automatisch zum Problem werden, da der Scrum-Master keine Macht hat, sondern seine Arbeit innerhalb des Entwicklungsteam durch Gespräch und Modereration durchführt.

Die Person muss ein besonderes Auge auf die Performanz des Teams (Produktivität, Geschwindigkeit, Qualität) haben und sie ggf. thematisieren, zudem muss sie auch sich selbst sehr selbstkritisch betrachten, denn sie läuft leicht Gefahr, „betriebsblind“ zu werden; soll sie doch als Entwickler in der Robe eines Scrum-Masters das Verhalten der Entwickler — und damit ihr eigenes — kritisch betrachten, hinterfragen und eventuelle, sich einschleichende Ungenauigkeiten und Insuffizienzen aufdecken.

Das ist ein Prozess, der nicht nur der die Rolle des Scrum-Masters einnehmenden Person einiges abverlangt, sondern auch nur dann funktioniert, wenn sich das restliche Team zu 100% hinter jeweils diese Person und ihre Doppelaufgabe stellt. Trotz allem handelt es sich dabei immer um eine Gratwanderung und es ist fraglich, ob diese Konstellation den Anforderungen, die an sie gestellt wird, in ausreichendem Maß gerecht werden kann, denn die Anforderungen und Erwartungen an einen Scrum-Master sind zu recht hoch.

Sowohl das Entwicklungsteam, als auch der Product-Owner müssen darüber hinaus in der Planung des Sprints berücksichtigen, dass einer der Entwickler potenziell einen wesentlichen Teil seiner Zeit (wieviel Zeit das ist, müssen die an der Planung beteiligten Personen anhand ihrer Erfahrung in den bereits abgeschlossenen Sprints, schätzen) in der Rolle des Scrum-Master verbringt und in dieser Zeit nicht als Entwickler produktiv sein kann und wird.

Und der Scrum-Coach?
Wird die Rolle des Scrum-Master im Zuge der Einführung von Scrum jedoch von einen Scrum-Coach ausgefüllt, sollte diesem Scrum-Coach im Gegensatz zu den Mitarbeitern des Unternehmens, dass das Projekt durchführt und den Mitarbeiter des Auftraggebers durchaus unterstellbar sein, dass er durchaus in der Lage ist, für die begrenzte Zeit seines Coaching-Auftrages jede mögliche Rolle „gleichzeitig“ einnehmen zu können (wobei mit „gleichzeitig“ wieder das oben Genannte gemeint ist, dass er zu einer Zeit immer nur eine der Rollen vertritt und dann jeweils auf die andere Rolle vollständig umschaltet). Einem produktiven Projektmitarbeiter (mit der oben bereits diskutierten Einschränkung auf Entwickler) sollte man diesen Spagat jedoch nicht zumuten.

Seine Aufgaben an das Team delegieren  ^

Seine Aufgaben sind seine Aufgaben. Sie sind für das Projekt sehr wichtig, dienen jedoch — wie von manchen Unternehmen gerne bemängelt wird — nicht direkt der Produktion, sondern konzentrieren sich darauf, dem Team eine möglichst hohe Produktivität zu ermöglichen. Befindet sich das Projekt allerdings noch in der Phase der Einführung von Scrum oder wird die Rolle des Scrum-Masters durch einen Coach ausgefüllt, kann es durchaus Sinn machen, dass er Teile seiner Aufgaben an jeweils einzelne Mitglieder des Entwicklungsteam zu Schulungszwecken delegiert.

Das Daily-Scrum beaufsichtigen/moderieren oder sich ungefragt einmischen  ^

Die Durchführung des Daily-Scrum ist die ausschließliche Aufgabe des Entwicklungsteams. Der Scrum-Master ist nur einer der Teilnehmer. Gibt es jedoch im Laufe des Daily-Scrum Probleme oder bittet das Entwicklungsteam den Scrum-Master um Hilfe, muss / wird er eingreifen und unterstützen.

Der Scrum-Master, der an jedem Daily-Scrum „seines“ Teams teilnimmt (schon allein, um über den Stand der Impediments und des Impediment-Backlogs zu berichten), wird sehr genau darauf achten, dass sich die Teilnehmer (und die dem Daily-Scrum beiwohnenden stillen Gäste) regelkonform verhalten und eingreifen, sobald sich Teilnehmer oder Gäste außerhalb der Toleranzen bewegen. Das kann man sicher auch als „beaufsichtigen / moderieren / sich ungefragt einmischen“ einstufen, aber man muss unterscheiden, ob der Scrum-Master dem Daily-Scrum als Coach oder als Teammitglied beiwohnt. Wäre es als Scrum-Master seine Aufgabe, das Daily-Scrum zu beaufsichtigen oder zu moderieren, würde er den Ablauf bestimmen und vorgegeben und alles würde sich auf ihn konzentrieren, wobei gerade das eben nicht der Fall sein soll: das Daily-Scrum gehört ausschließlich dem Entwicklungsteam und das Ziel des Scrum-Masters als Coach ist es, dass das Entwicklungsteam als autonomer Körper in der Lage ist, das Meeting ohne separate Leitfigur im vorgegebenen Rahmen durchzuführen. Jedes Mitglied des Entwicklungsteams sollte am Ende selbst Scrum-Master genug sein, um den Fall eines aus dem Ruder laufenden Meetings zu erkennen und entsprechend in der Runde adressieren zu können, d.h. selbst als Kontrollinstanz zu fungieren.

Sprint-Review vorbereiten, einladen oder durchführen  ^

Für das Sprint-Review gilt das gleiche wie für das Daily-Scrum.
Die Durchführung des Sprint-Review ist die ausschließliche Aufgabe des Entwicklungsteams. Der Scrum-Master ist in diesem Meeting auch nur Teilnehmer. Gibt es jedoch im Laufe des Sprint-Review Probleme oder bittet das Entwicklungsteam den Scrum-Master um Hilfe, muss / wird er eingreifen und unterstützen.

Sprint-Retrospektive vorbereiten, einladen oder durchführen  ^

Für das Sprint-Retrospektive gilt ähnliches wie für Sprint-Review und Daily-Scrum.
Die Durchführung der Sprint-Retrospektive ist die ausschließliche Aufgabe des Product-Owner. Der Scrum-Master ist in diesem Meeting auch nur Teilnehmer. Gibt es jedoch im Laufe der Sprint-Retrospektive Probleme oder bittet der Product-Owner den Scrum-Master um Hilfe, muss / wird er eingreifen und unterstützen.

Sprint-Burndown aktualisieren  ^

Die Durchführung der Aktualisierung des Sprint-Burndown-Charts ist eine Aufgabe des Entwicklungsteams.
Der Scrum-Master wird darauf achten, dass im Laufe des Daily-Scrum Task-Board und analog dazu auch Sprint-Burndown-Chart aktualisiert werden und dass das Sprint-Burndown-Chart dann später an die jeweiligen Adressaten verteilt wird.

Eigenschaften und Fähigkeiten des Scrum-Masters  ^

Scrum-Werte und -Techniken vermitteln und einführen  ^

Eine der wesentlichsten Aufgaben des Scrum-Masters ist es, den beteiligten Personen die Scrum-Werte und -Techniken zu vermitteln. Darüber hinaus ist es selbstverständlich auch die Aufgabe des Scrum-Masters, darauf zu achten, dass sich alle Beteiligten an die Erfordernisse und Regeln von Scrum halten. Er ist derjenige, der am meisten über die Abläufe und Prozesse innerhalb Scrums und innerhalb des Teams und die Auswirkungen auf Team, Prozess und Projekt weiß und sollte von daher zumindest immer dann, wenn es um Fragen bzgl. Scrum und Prozess geht, die erste Anlaufstelle sein.
Immer wenn Fragen rund um den Prozess auftauchen oder wenn es Behinderungen (Impediments) gibt, die die Team-Mitglieder in ihrer Produktivität einschränken, wird der Scrum-Master hilfreich und unterstützend zur Seite stehen.

Berechenbarkeit  ^

Ein besonderes Merkmal von Scrum ist, dass in dem Prozess viel darauf Wert gelegt wird, dass sich alle Vorgänge und Rollen berechen- und vorhersehbar, sowie so verlässlich wie möglich verhalten. Nur wenn dies der Fall ist, braucht man sich nicht mehr um die Details der jeweiligen Vorgänge und Handlungen kümmern, da sie verlässlich so eintreffen, wie es zu erwarten ist. So ist es nur bei wesentlichen Änderungen nötig, sich abzustimmen.

Das gilt auch für den Scrum-Master. Die Team-Mitglieder sollen sich darauf verlassen können, dass sich (gerade) der Scrum-Master ebenso, wie es von ihnen selbst verlangt wird, an die Regeln von Scrum, bzw. an die Regeln der jeweiligen Rolle halten wird. Darüber hinaus sollte die Person des Scrum-Masters sich so authentisch wie möglich verhalten, damit die Projektmitglieder ein klares Bild von Rolle und Person und dem zu erwartenden Verhalten haben.

Teamplayer unter Teamplayern  ^

Eine wesentliche Anforderung an den Scrum Master ist, ein ausgezeichneter Teamplayer zu sein. Zwar ist er auf der einen Seite der Coach der den am Projekt beteiligten Personen die Prinzipien und die Mechanik von Scrum nahe bringt, auf der anderen Seite hat er aber auch seinen festen Platz im Team als derjenige, der das Team darin unterstützt, eine höchstmögliche Produktivität zu erreichen. Das erreicht er unter anderem dadurch, dass er ein sehr genaues Auge auf die Kommunikation zwischen den Personen hat. Er wird sein Augenmerk darauf ausrichten, dass die Kommunikation in einer möglichst effizienten Art und Weise abläuft. Das sicherzustellen, ist alleine durch Coachen nicht möglich; er muss es vorleben, mit den Personen sehr eng zusammenarbeiten und auf sie zu- und eingehen.

Er wird Streit schlichten, Wogen glätten, Konflikten bereinigen, Probleme beseitigen, Kampfhähne trennen und alles tun, damit es eine verlässliche, gute und produktive Atmosphäre im Projekt gibt.

Kompetenz in Zusammenarbeit  ^

Scrum ist ein People-Prozess, das bedeutet, dass dem reibungslosen Zusammenspiel der Akteure ein wesentlich größerer Einfluss auf das Projektergebnis zugemessen wird, als dem reinen Befolgen der Mechanik des Prozesses.

Die Erfahrung lehrt, dass die größten Probleme in Projekten daher rühren, dass die im Projekt agierenden Personen nicht optimal zusammenarbeiten. Da der Scrum-Master dafür verantwortlich ist, dem Team eine möglichst hohe Produktivität zu ermöglichen, muss er darauf achten und in der Lage sein, Defizite in Kommunikation und Zusammenarbeit zu identifizieren, in geeigneter Form zu thematisieren, um die ansonsten zwangsläufig auftretenden Reibungsverluste zu vermeiden.

Es ist immer wieder erstaunlich, wie produktiv ein Team sein kann, in dem eine optimierte Kommunikation- und Zusammenarbeitskultur herrscht.

Gleichberechtigung auf Augenhöhe  ^

Eines der Prinzipien von Scrum basiert darauf, dass die beteiligten Personen ihr gesamtes Leistungspotenzial in das Projekt einbringen. Dies werden Sie nicht tun, wenn sie sich unter Druck gesetzt und bevormundet fühlen. Es ist daher von hoher Bedeutung, den beteiligten Personen nicht nur das sichere Gefühl zu vermitteln, akzeptiert und angenommen zu werden, sondern ihnen auch Raum für Kreativität und Intuition zur Verfügung zu stellen. Aus diesem Grund ist Gleichberechtigung auf Augenhöhe sehr wichtig, denn erst dieses Prinzip schafft eine Atmosphäre, in der kreatives und höchstmöglich produktives Arbeiten möglich ist.

Moderation  ^

Effektive Kommunikation ist sehr schwer zu erreichen. Jeder der etwas zu sagen hat, möchte es auch sagen können und zwar nicht irgendwann, sondern, wenn möglich, sofort. Das führt zu Chaos und es benötigt eine Instanz, die die Kommunikation — insbesondere in Meetings — kanalisiert und moderiert. Zumindest, solange die Teams noch keine große Erfahrung mit Scrum haben, wird der Scrum-Master diese Aufgabe übernehmen.

Der Scrum-Master wird darauf achten, dass alle die, die etwas zu sagen haben, auch zu Wort kommen werden. Er wird aber auch darauf achten, dass über einzelne Sachverhalte nicht in Endlosschleifen palavert wird, sondern, dass die Kommunikation zielgerichtet zu einem Ergebnis führt. Er ist daher derjenige, der die Fäden in der Hand hält, um die Kommunikation immer wieder auf den richtigen Weg in Richtung des Zieles zu bringen, ohne die zeitlichen Grenzen aus den Augen zu verlieren.

Verständnis und Einfühlungsvermögen  ^

Ein Scrum-Master ist der Scrum-Coach, der Kommunikator und Moderator und er derjenige, der Hindernisse aus dem Weg räumt. Darüber hinaus ist er aber auch derjenige, der sich der Probleme und Ängste der am Projekt beteiligten Personen annimmt. Er ist ein Seelentröster und in-den-Arm-Nehmer und um diese Aufgabe ausfüllen zu können, muss er viel Verständnis für diese Personen aufbringen. Er muss sie verstehen können, er muss ihre Motivation, etwas in einer bestimmten Weise zu sagen oder zu tun, annehmen, akzeptieren und reflektieren können, um sich ein Bild von seinem Gegenüber in der aktuellen (ggf. problembehafteten) Situation machen zu können. Er muss sich in andere Menschen hineinversetzen und ihre Motivation nachvollziehen können.

Konfliktlösungskompetenz  ^

Es werden in einem Projekt immer wieder zwischenmenschliche Konflikte auftreten. Da wird es Projektmitglieder geben, die mit der Art wie andere Projektmitglieder kommunizieren und arbeiten nicht einverstanden sind, usw. und sofort. Der Scrum-Master muss sich dieser Konflikte annehmen und sie auflösen, um sein Ziel, dem Team eine möglichst hohe Produktivität zu ermöglichen, zu erreichen. Er wird sich aller auftretenden Konflikte annehmen, er wird moderieren und schlichten statt zu richten.

Problemlösungskompetenz  ^

In einem Projekt können alle möglichen Arten von produktivitätshemmenden Problemen auftreten. Da können Unterlagen, Lizenzen, Zugänge, Rechte und andere Dinge fehlen, die für eine produktive Arbeit notwendig sind, aber in manchen Fällen eben nicht oder in nicht ausreichender Menge zur Verfügung stehen. Statt dass sich nun jede Person selbst daran macht, die in ihrem Bereich bestehenden Produktivitätshemmnisse zu beseitigen — was die vorhandene Produktivität noch weiter verringern würde — übernimmt der Scrum-Master diese Aufgabe und kümmert sich darum, dass der Betrieb weiter geht.

Gut erklären können  ^

Ein Scrum-Master ist, zumindest zu Beginn eines Projektes, auch immer ein Coach. Seine Aufgabe ist, den beteiligten Personen die Prinzipien und die Mechanik von Scrum nahezubringen. Dies kann aber nicht funktionieren, wenn der Scrum-Master nicht in der Lage ist, die Werte die er vermitteln will, gut erklären zu können.

So einfach Scrum in seiner Mechanik auch ist, so komplex sind die hinter Scrum stehenden Prinzipien, denn es geht Scrum weniger um die Einhaltung von Regeln und um das Verständnis der Mechanik, sondern vielmehr darum, dass jeder am Projekt Beteiligte verstanden hat, dass es die Menschen sind, die das Projekt voranbringen und dass daher zwischen den Beteiligten eine möglichst optimale Zusammenarbeit erreicht werden muss.

Die Regeln und die Mechanik von Scrum dienen daher dazu, diese optimale Zusammenarbeit zu ermöglichen und herbeizuführen. Das ist eine neue und damit ungewöhnliche Sicht auf diesen Sachverhalt, der daher erklärungsbedürftig ist. Wenn der Scrum-Master jedoch keine gute Erklärungskompetenz hat, wird es ihm schwer fallen, Scrum und die dahinter stehenden Ideen verständlich zu machen, dass sie von den beteiligten Personen verstanden, akzeptiert, verinnerlicht und gelebt werden können.

Überzeugungs- und Führungskraft und -stärke  ^

Ein Scrum-Master hat keine disziplinarische Macht, was bedeutet, dass er keinerlei Weisungsbefugnis hat. Trotzdem muss er die beteiligten Personen in eine Richtung lenken, die ein optimales Ergebnis für das Projekt ermöglicht. Seine Macht ist also nur die Macht seiner Worte. Er muss daher überzeugen und führen können.

Integrationsvermögen  ^

Ein Scrum Projekt sollte aus 5 – 9 Entwicklern, dem Product-Owner, einer Anzahl von Stakeholdern und ihm selbst bestehen. In solch einem Team gibt es unterschiedliche Charaktere, die darüber hinaus auch noch unterschiedliche, wenn nicht sogar gegenteilige Interessen haben. Diese Personen müssen gemeinsam an dem Erfolg dieses einen Projekts arbeiten und auf einen Nenner gebracht werden, was zunächst einmal auch eine Aufgabe des Scrum-Masters ist. Er muss alle beteiligten Personen in das Team integrieren, er muss ihnen ihren Platz im Team erläutern und er muss ihnen eine möglichst hohe Produktivität ermöglichen. Das gelingt nur, wenn es gelingt, alle Beteiligten in das eine Team des Projektes zu integrieren.

Zusammenarbeit mit den Product-Owner  ^

Der Scrum-Master ist der Partner aller Projektbeteiligter, so auch der Partner des Product-Owner. Er wird ihn in allen Belangen von Scrum unterstützen. Das betrifft sowohl den Prozess als solches, aber auch die Kommunikation und den Umgang mit den Stakeholdern und dem Entwicklungsteam, sowie die Praxis der Aufgaben des Product-Owner und ihre konkrete Durchführung.

Dem Product-Owner gegenüber gibt sich der Scrum-Master zwar als der Anwalt des Entwicklungsteams, wird aber stets darum bemüht sein, zwischen den beiden auszugleichend und vermittelnd zu wirken, da sein Hauptinteresse darin liegt, dass die Produktivität des Team möglichst hoch ist, dass zwischen den Beteiligten keine Reibungsverluste auftreten und dass sie möglichst effizient miteinander Kommunizieren und Handeln.

Der Product-Owner ha ein breites und aufwendiges Aufgabenfeld, dass es zu beherrschen gilt und der Scrum-Master sollte den Product-Owner zumindest in der Einführungsphase tatkräftig darin unterstützen, sich sein Handwerk zu erarbeiten, um möglichst schnell alle Belange seiner Aufgabe selbstständig zu beherrschen.

Die Produktvision erarbeiten und formulieren  ^

Eine erste und wichtige Aufgabe des Product-Owner, in der der Scrum-Master gleich zu Beginn eines Projektes den Product-Owner unterstützen kann, ist, gemeinsam mit den Stakeholdern die Product-Vision zu erarbeiten und zu formulieren.

Die Product-Vision stellt ein klares, plakatives Bild des zu erstellenden Produktes dar, die jedem Projektbeteiligten und jedem Interessierten eine klare Vorstellung darüber vermittelt, um was für ein Produkt es sich bei dem zu erstellenden Produkt handeln wird, in welchem Umfeld es eingesetzt werden wird und welche Möglichkeiten und Einschränkungen sowohl das Produkt und sein Umfeld, aber auch das Projekt sein Umfeld kennzeichnen.

Mit den Stakeholder arbeiten  ^

Für die Stakeholder ist Scrum häufig ein neues und überraschendes Konzept. Plötzlich stehen sie in der Pflicht, nicht „einmalig“ in einer konzertierten Aktion ihre Gedanken und Wünsche über den Inhalt und Umfang des zu entwickelnden Produktes zu formulieren und weiterzugeben, sondern in Form eines dauerhaften Dialogs (z.B. Anforderungsanalyse und -reflexion, also das Feedback) aktiv an dem Projekt beteiligt zu sein. Diesen permanenten Dialog zu initiieren, zu führen und auf einem hohe Niveau effizient aufrecht zu erhalten, ist eine der wesentlichen Aufgaben des Product-Owner, in der er, aber oftmals auch die Stakeholder, insbesondere in der Einführungsphase von Scrum mit hoher Sicherheit Unterstützung seitens des Scrum-Master braucht.

Intensive Unterstützung und Zusammenarbeit  ^

Der Scrum-Master und der Product-Owner müssen keine Freunde sein, jedoch müssen sie auf eine effiziente und professionelle Art und Weise zusammenarbeiten können. Der Scrum-Master kann den Product-Owner im Umgang mit den Stakeholder, in der permanenten Anforderungsanalyse, in der Formulierung und Präsentation der Produktvision, der Erarbeitung und Formulierung User-Stories, sowie der Verwaltung des Product-Backlogs und in der Vorbereitung und später in der Moderation der vom Product-Owner zu leitenden Meetings helfen und unterstützen.

Zusammenarbeit mit dem Entwicklungsteam  ^

So, wie der Product-Owner der Anwalt der Stakeholder ist, ist der Scrum-Master der Anwalt des DTs. Der Scrum-Master ist verantwortlich für die Produktivität des DTs (wenn nicht sogar für die Produktivität des gesamten Teams) und aus diesem Grund wird er stets darum bemüht sein, insbesondere dem Entwicklungsteam den Weg zu einer möglichst hohen Produktivität so eben zu gestalten, wie nur irgend möglich.

Der Scrum-Master wird dem Entwicklungsteam den Scrum-Prozess, also die grundsätzlichen Spezifika, Regeln, Abläufe und die notwendigen Verhaltensmaßnahmen nahebringen, es in der Ausübung von Scrum coachen und er wird auch übergeordnete Themen, wie Moderation von Meetings, Selbstorganisation und Selbstreflexion eines jeden für sich selbst und in der entsprechenden Gruppe nicht auslassen.

Er wird das alles nicht nur vortragen, sondern er wird das alles als Teil des Teams, als Teil des Prozesses, als Teil der Betroffenen und Beteiligten auch täglich an eigenem Beispiel vorleben.

Wächter der Produktivität  ^

Das Maß der Dinge für den Scrum-Master ist — mal abgesehen davon, dass das gesamte Projektteam Scrum „können“ soll — die Produktivität des Entwicklungsteam.

Gibt es Dinge, die die Produktivität des Entwicklungsteams einschränken, wird er sie beseitigen.

Gibt es Dinge, die die Produktivität des Entwicklungsteams erhöhen, wird er sie — in Absprache mit Entwicklungsteam und Product-Owner — implementieren.

Jederzeit ansprechbar  ^

Wichtig ist, dass der Scrum-Master jederzeit, nicht nur im Daily-Scrum, für das Team ansprechbar ist und sich der an ihn herangetragenen Dinge zeitnah annimmt. Dies trifft umso mehr zu, umso größer die Relevanz des Geschilderten für das Projekt und die Produktivität des Teams ist.

Wenn ihm ein die Produktivität des Teams oder eines Mitgliedes des Teams einschränkendes Problem geschildert wird, wird er es in sein Impediment-Backlog eintragen und die Lösung des Problems sobald als möglich — idealer Weise sofort — angehen und im Daily-Scrum davon berichten

Motivator  ^

Der Scrum-Master ist per Definition der beste Freund des Entwicklungsteams und genau so sollte er auch handeln, wie ein ehrlicher Freund.
Wenn die Projektbeteiligten spüren, dass der Scrum-Master seine Aufgabe motiviert und engagiert, aber auch mutig und entschlossen angeht und sich darüber hinaus allen aufkommenden Fragen und Problemen ernsthaft stellt, Antworten gibt, oder sich zumindest intensiv darum kümmert, Antworten und Problemlösungen von dritter Seite zu erhalten, werden sie schon allein aus diesem Vorbild einen Teil ihrer eigenen Motivation schöpfen können.

Konfliktlöser und Moderator  ^

Man hört zwar immer mal wieder, dass der eine oder andere Scrum-Master schon mal im magischen Dreieck zwischen Entwicklungsteam-Mitarbeiter, Kaffeemaschine und Pizzadienst verloren gegangen sein soll, aber soweit sollte die Hingabe an das Team dann doch eigentlich nicht gehen; der Scrum-Master ist der Anwalt und der Freund des Entwicklungsteam, aber nicht der Diener.

Er wird aber, wann immer es zu Konflikten kommt, sei es innerhalb des Entwicklungsteam oder z.B. zwischen Entwicklungsteam und Product-Owner, sich als Konfliktlöser und Moderator einschalten und versuchen, das Problem aufzulösen oder Kompromisse zu finden oder die Konfliktparteien dahin zu bringen, dass sie sich selbst auf eine Lösung einigen können.

Nicht der Chef  ^

Scrum schließt disziplinäre Hierarchien, Weisungsbefugnisse, etc., zwischen den Rollen und innerhalb der Teams explizit aus, um insbesondere dem Entwicklungsteam die Möglichkeit zu öffnen, frei von äußerem Druck ihre inneren Potentiale für die Schaffung kreative und innovative Lösungen freisetzen und bündeln zu können.

Aus diesem Grund schließt Scrum disziplinäre Hierarchien, Weisungsbefugnisse, etc., zwischen den Rollen und innerhalb der Teams explizit aus. Scrum stellt statt dessen Werte und Eigenschaften, wie Eigenständigkeit, Gleichwertigkeit und Kompromiss- und Konsensfähigkeit aller am Projekt beteiligten Rollen und Individuen, insbesondere des Entwicklungsteams, konsequent und ausdrücklich in den Vordergrund, um damit die Motivation und den Willen eines jeden Beteiligten ausdrücklich darin zu unterstützen, das Projekt schnell, sicher und erfolgreich für das eigene Unternehmen und die Stakeholder abzuschließen.

Wie viele Teams sollte ein Scrum-Master gleichzeitig betreuen?  ^

Konservativ: „Keines. Der Scrum-Master ist so überflüssig wie ein Kropf. Er gehört geteert und gefedert und aus der Stadt gejagt, denn er stiehlt das Budget eines oder mehrerer Entwickler, die die Produktivität wirklich steigern würden. Bevor jetzt wieder das Argument mit dem Fussballtrainer kommt; das ist etwas ganz anderes und hat mit dieser Sache überhaupt nichts zu tun. Wenn der Trainer den Spielern Fussball erst erklären müsste, dann sollte sie besser gleich zu Hause bleiben. Oder sich zu Softwareentwicklern umschulen lassen. Oder zu Scrum-Mastern.“

Hyper-Agil: „Eines. Der Scrum-Master ist mit der Optimierung und Unterstützung des einen Teams vollständig ausgelastet. Sollte er Langeweile bekommen oder meinen, das Team sei mit 99,999% bereits ausreichend optimiert, dann hat er seinen Job nicht verstanden und gehört geteert und gefedert und aus der Stadt gejagt, denn er stiehlt das Budget eines wirklich guten Scrum-Masters, der das Team zu immer neuen Produktivitätshöhen antreiben anleiten kann.“

Realistisch betrachtet, kann er eines, max. zwei Teams betreuen. Im Grunde ist der Scrum-Master mit der Optimierung und Unterstützung eines Teams bereits ausgelastet. Durch seine Unterstützung und seine Optimierung haben die Mitglieder des Teams eine reelle Chance, effizient zu kommunizieren und zu kollaborieren und ihre individuellen Fähigkeiten weiterzuentwickeln und dem Team in vollem Umfang zur Verfügungen stellen zu können, um höchstmögliche, dauerhaft durch sie aufrechterhaltbare Werte für Produktivität und Geschwindigkeit zu erreichen. Das ist ein Fulltimejob, der den ganzen Mann / die ganze Frau fordert — und er rechnet sich für das Projekt. Trotzdem kann solch ein Team an einen Punkt kommen, wo die Aufwände für weitere Produktivitätssteigerungen die erreichbaren Produktivitätssteigerungen selbst übersteigen können. Dann (und erst dann), sollte darüber nachgedacht werden, ob sich der Scrum-Master eines weiteren Teams annehmen kann, ohne das erste Team hierfür vernachlässigen zu müssen.

Die Vorgehensweise, Scrum-Mastern generell und frühzeitig mehrere Teams zuzuordnen, führt dazu, dass sich die Identifikation mit und zwischen Scrum-Master und Team verringert (was in manchen Unternehmen durchaus erwünscht ist, jedoch den Team-Ansatz, den Scrum verfolgt, konterkariert) und damit die erreichbare Performanz des Teams (Produktivität, Entwicklungsgeschwindigkeit und Prozess-, sowie Produktqualität) limitiert.

Muss der Scrum-Master einen softwareentwicklerischen Background haben?  ^

Es ist keine Voraussetzung für die Rolle, jedoch kann und wird es seine Arbeit sehr unterstützen, wenn er eine ausgeprägte Vorstellung davon hat, was die Entwickler gerade tun, woran sie wie arbeiten und welchen Herausforderungen sie sich generell und gerade im Moment stellen müssen.

Zusammenarbeit mit den Stakeholdern  ^

Um die Kommunikationswege klar und verlässlich zu halten, ist in Scrum der erste und per Definition einzige Ansprechpartner der Stakeholder im Projekt der Product-Owner. Benötigt der Product-Owner jedoch in der Kommunikation mit den Stakeholdern Unterstützung oder möchte er, dass Scrum den Stakeholdern nahegebracht wird oder wünschen die Stakeholder das von sich aus, spricht prinzipiell nichts dagegen, dass der Product-Owner den Scrum-Master bei den Stakeholdern vorstellt und er ihnen den Scrum-Prozess und speziell ihre Rolle erläutert.

Er wird ihnen erklären, welche Vorteile gerade die Stakeholder durch Scrum haben; aber auch, welche Pflichten Scrum ihnen auferlegt und wird sie dazu motivieren, gemeinsam mit dem Scrum-Team intensiv am Erfolg des Projektes zu arbeiten.

Der Scrum-Master und die Scrum-Meetings  ^

Hier muss wieder unterschieden werden, ob sich Scrum noch in der Einführung oder bereits in einem gut implementierten Zustand befindet. In Ersterem wird sich der Scrum-Master intensiv in das jeweilige Meeting einbringen, da sich das Team irgendwo in einem Bereich zwischen Anleitung und Selbstständigkeit befindet; aus diesem Grund wird sich der Scrum-Master in diesem Fall aktiv und prozessbezogen in den Ablauf der Meetings integrieren.
Ist der Prozess allerdings bereits implementiert und das Team in der Lage, sicher mit Scrum zu arbeiten, wird der Scrum-Master das jeweilige Meeting entspannt verfolgen und nur dann eingreifen, wenn es aus seiner Sicht notwendig ist; je besser das Team den Prozess adaptiert hat, desto geringer ist die Wahrscheinlichkeit, dass das notwendig sein wird.

Sollte das Entwicklungsteam bereits soweit sein, dass der Prozess nicht nur implementiert ist, sondern dass darüber hinaus die Rolle des Scrum-Master aus dem Entwicklungsteam heraus besetzt werden könnte, wird die Person, die neben der Tätigkeit als Entwickler auch die Rolle des Scrum-Masters abbildet, je nach Lage in eine von beiden Rollen schlüpfen; also sich als auf der einen Seite als Entwickler aktiv am Geschehen beteiligen, den Verlauf des Meetings aber auch mit den Augen eines Scrum-Masters verfolgen.

Sprint-Planning und Estimation-Meeting  ^

Organisator und Moderator der Meetings ist der Product-Owner. Der Scrum-Master agiert, siehe oben, entweder als Coach oder ist aufmerksamer Teilnehmer, kann aber bei Bedarf auch unterstützend in das Geschehen eingreifen.

Daily-Scrum, Sprint-Review und Sprint-Retrospektive  ^

Organisator und Moderator der Meetings ist das Entwicklungsteam. Handelt es sich bei dem Meeting um das Sprint-Review oder die Sprint-Retrospektive, agiert der Scrum-Master, siehe oben, entweder als Coach oder ist aufmerksamer Teilnehmer, kann aber bei Bedarf auch unterstützend in das Geschehen eingreifen.

Handelt es sich um das Daily-Scrum, wird sich der Scrum-Master genauso, wie die anderen Teilnehmer, aktiv am Meeting beteiligen und die drei implizit gestellten Fragen beantworten. Darüber hinaus wird der Scrum-Master auch noch über die Inhalte des Impediment-Backlogs berichten und darauf achten, dass am Ende des Daily-Scrum das Sprint-Burndown-Chart durch die Mitglieder des Entwicklungsteam aktualisiert ist und das aktualisierte Sprint-Burndown-Chart nach dem Meeting an die interessierten Personen verteil wird.

Risiken für den Scrum-Master  ^

Mehrere Scrum-Master im Projekt  ^

Es kann durchaus vorkommen, dass es in einem Unternehmen mehrere Mitarbeiter gibt, die als Scrum-Master tätig sein können oder sollen. In diesem Fall wird „Scrum-Master“ oft nicht als Rolle, sondern als Titel oder Stelle verstanden und ein Projekt manchmal von mehr als einem Scrum-Master betreut, damit die Scrum-Master Erfahrungen sammeln.

Das ist für das Scrum-Team eine problematische Konstellation, weil es nun mehrere Ansprechpartner für die Rolle des Scrum-Masters gibt. Das wird insbesondere dann zum Problem, wenn die Scrum-Master (zumindest potentiell) bzgl. der Linie von Scrum unterschiedliche Sichten vertreten, bzw., weil sie dann — zumindest in Konfliktsituationen — gegeneinander ausspielbar sind.

Es sollte daher immer nur ein erfahrener Scrum-Master oder Scrum-Coach als Hauptansprechpartner in allen Fragen und Aufgaben rund um Scrum und den Prozess im Projekt zuständig sein. Er sollte dann nicht nur für die Kern-Projektmitglieder Ansprechpartner in Sachen Scrum sein, sondern auch die weiteren Scrum-Master schulen, betreuen und ggf. Aufgaben an sie ihnen delegieren.

Zu wenig Erfahrung  ^

Hat der Scrum-Master zu wenig Erfahrung mit Scrum, zum Beispiel weil er im Hinblick auf das Projekt zu einer Scrum-Master Schulung geschickt wurde und seine dort erlernten Fähigkeiten nunmehr im Projekt einsetzen soll, ist es für diesen Junior-Scrum-Master oft sehr schwierig, den richtigen Weg im Projekt einzuschlagen. In diesem Fall ist es sinnvoll, für eine überschaubare Zeit einen erfahrenen Scrum-Coach hinzuzuziehen, der gemeinsam mit dem Junior-Scrum-Master eine Linie entwickelt, entlang sich der Scrum-Master und sein Team durch das Projekt bewilligt.

Oft ist es auch ratsam, einen erfahrenen Scrum-Coach in das Projekt einzubeziehen, der zunächst die Rolle des Scrum-Master verantwortlich übernimmt, um im Laufe des Projektes einen oder mehrere unternehmensinterne Scrum-Master zu coachen.

Es sei noch einmal gesagt, dass es insbesondere bei jungen, Scrum-unerfahrenen Teams sehr wichtig ist, dass die Position des Scrum-Master zumindest zeitweilig von einem erfahrenen Scrum-Master oder Scrum-Coach übernommen wird, um die beteiligten Mitarbeiter erfolgreich in Scrum, im Team und im Projekt einzuführen.

Mangelnde Mitarbeit / Akzeptanz der anderen Teammitglieder gegenüber Scrum  ^

Das Scrum Team besteht aus dem Scrum-Master selbst, dem Entwicklungsteam und dem Product-Owner. Dazu kommen im erweiterten Sinne auch noch die Stakeholder, die in diesem Zusammenhang allerdings zunächst einmal außen vor gelassen werden sollen. Insofern sind zunächst das Entwicklungsteam und der Product-Owner von der Einführung von Scrum betroffen.

Damit der Prozess sein Potential vollständig entfalten kann, ist es äußerst wichtig, dass die Teammitglieder aufgeschlossen gegenüber der Einführung von Scrum sind, seine Philosophie, Regeln und Prozeduren annehmen und verinnerlichen.

Schafft es der Scrum-Master allein nicht, die Projektmitglieder zu einer erfolgreichen Zusammenarbeit für die Einführung von Scrum ermuntern, bleibt ihm nur die Möglichkeit, das Management einzubinden, um auch von dieser Seite aus Einfluss auf das Team zu nehmen, sich mit dem Prozess zu beschäftigen und ihn anzunehmen. Ist eine erfolgreiche Einführung des Teams in den Prozess gefährdet, werden die Vorteile, die man sich von Scrum erhofft, nicht eintreten und die erfolgreiche Durchführung des Projektes mit Scrum wird nicht gesichert sein.

Mangelnde Mitarbeit / Akzeptanz der Stakeholder gegenüber Scrum  ^

Für die Stakeholder ist Scrum häufig ein neues und überraschendes Konzept.
Bereits wenige Tagen nach Projektstart erhalten sie erstmalig und danach verlässlich und unaufgefordert in kurzen, regelmäßigen Abständen aus dem Projektes heraus aktuelle Fortschrittsberichte, sowie einen aktuellen, lauffähigen Stand des Produktes, in dem die für sie aktuell wertvollsten Anforderungen vollständig umgesetzt wurden. Darüber hinaus sehen sie sich plötzlich in der Pflicht, dieses Produktinkrement zu begutachten, zu testen und zu bewerten, um das Projekt mit wertvollem Feedback, Hinweisen und Änderungswünschen zu bereichern und damit eine wesentliche, wichtige und tragende Rolle im Projekt einzunehmen.

Mal davon abgesehen, dass die Stakeholder schon immer eine wichtige und tragende Säule des Projektes waren, da sie die Vorgaben formulierten und am Ende des Projektes die Abnahme machten, ist es bei Scrum von essenzieller Bedeutung, dass die Stakeholder einen aktiven Part im Projekt übernehmen.

Lehnen die die Stakeholder eine aktive Mitarbeit am Projekt kategorisch ab, bedeutet das natürlich nicht das Ende für das Projekt, aber doch eine nicht unerhebliche Einschränkung, da in diesem Fall das Feedback der Stakeholder ausbleibt und sie somit das Ergebnis eventueller Erfahrungs- und Erkenntnisgewinnung nicht in das Projekt zurückfließen lassen. Das Projektteam muss dies berücksichtigen und den Part der Stakeholder intern emulieren, was den zeitlichen Verlauf negativ beeinflusst und potentiell Geschäftswert des Produktes für die Stakeholder mindert.

Zunächst einmal ist es hauptsächlich der Product-Owner, der von dieser Verweigerung betroffen ist. Er ist derjenige, der mit den Stakeholdern kommuniziert und arbeitet. Sollte er bei der Einbindung der Stakeholdern ins Projekt auf Schwierigkeiten treffen, die er allein nicht lösen kann, wird er sich an den Scrum-Master wenden und ihn um Hilfe bitten, gemeinsam auf die Stakeholder einzuwirken, ihren Anteil am Projekt wahrzunehmen, was für den Scrum-Master erhebliche Aufwände abseits der Betreuung des DTs bedeuten kann.

Zeigen sich die Stakeholder trotz intensiven Bemühens von Product-Owner und Scrum-Master und auch nach der Verdeutlichung der Vorteile, die sich durch die tiefe und intensive Einbindung der Stakeholder ins Projekt ergeben, nicht bereit dazu, müssen Product-Owner und Scrum-Master gemeinsam mit dem Entwicklungsteam den projektinternen Ausfall der Stakeholder kompensieren. Eine Möglichkeit hierzu wäre z.B., sich gemeinsam noch intensiver mit den fachlichen Ansprüchen der Stakeholder auseinanderzusetzen, diese in entsprechenden Anforderungen zu formulieren, die der Product-Owner dann mit den Stakeholdern im Zuge der permanenten Anforderungsanalyse erörtert.

Mangelnde / ambivalente Unterstützung durch das Management  ^

Auch das Management hat eine wesentliche Verantwortung in Scrum-Projekten, da sie diejenigen sind, die die Entscheidung treffen, bzw. getroffen haben, im Scrum als Softwareentwicklungsprozess einzuführen. Das bedeutet nicht, dass die Initiative, Scrum einzuführen, grundsätzlich vom Management ausgegangen sein muss. Die Initiative dazu, kann von jeder am Projekt beteiligten Personen ausgegangen sein und vielleicht ist es sogar eine Vorgabe der Stakeholder gewesen, das Projekt mit Scrum durchzuführen. Gerade Stakeholder können ein großes Interesse daran haben, dass ihre Projekte mit Scrum durchgeführt werden, da gerade Sie von der Einbindung ins Projekt profitieren.

Insbesondere, wenn Scrum in einem Unternehmen neu als Softwareentwicklungsprozess eingeführt werden soll, ist es — unabhängig davon, ob die Entscheidung für Scrum bereits getroffen wurde, oder es sich um ein Pilotprojekt zur Evaluation und Entscheidungsfindung handelt — auf jeden Fall notwendig, dass das Management eine ganz deutliche Position zu der Durchführung dieses Projektes bezieht.

Soll zunächst ein Pilotprojekt zeigen, ob Scrum im Unternehmen einsetzbar ist und zeigt sich das Management während der Durchführung dieses Pilotprojektes unentschlossen, halbherzig oder gar widersprüchlich gegenüber dem Pilotprojekt, ist die Wahrscheinlichkeit, ein wirklich aussagekräftiges Ergebnis aus dem Pilotprojekt zu erhalten, sehr gering und man täte wahrscheinlich gut daran, den beteiligten Personen diesen Aufwand und die sich daraus ergebende Frustration zu ersparen.

Hat das Management bereits entschieden, Scrum als Softwareentwicklungsprozess im Unternehmen einzuführen und sendet es in der Praxis dann während der Einführung jedoch halbherzige, widersprüchliche oder unentschlossene Signale aus, ist die Wahrscheinlichkeit, Scrum erfolgreich zu implementieren und von den Vorteilen, die durch den Einsatz von Scrum zu erreichen sind, umfänglich zu profitieren, ebenfalls sehr gering.

Ähnliches gilt, wenn das Management beginnt, den Prozess bereits von vornherein, ohne Erfahrung mit dem Prozess zu haben oder das notwendige Knowhow zu besitzen, zu modifizieren oder zu manipulieren, bzw. des Prozess „an das Unternehmen / an die Unternehmenskultur anzupassen“. In so einem Fall ist — je nach Ausprägung der Modifikationen — zweifelhaft, ob das Unternehmen die Vorteile und Stärken von Scrum für sich nutzen können wird.

In all diesen Fällen ist der Scrum-Master derjenige, der dafür Sorge tragen zu hat, dass das Management erkennt, dass sich ambivalentes Verhalten gegenüber einer bereits getroffenen — und damit gesetzten — Entscheidung (und auch die Entscheidung, die eigentliche Entscheidung zu vertagen und erst nach Abschluss einer Evaluationsphase zu treffen, ist eine solche Entscheidung) dazu führt, dass die sich aufgrund der Entscheidung zu erwartenden Vorteile nicht oder nur in geringem Maße einstellen werden. Auch wenn diese Erkenntnis selbstverständlich erscheint, wird ihr häufig genug (aus den unterschiedlichsten Gründen heraus) nicht ausreichend Aufmerksamkeit geschenkt.

Dies birgt ein Risiko für den Scrum-Master oder den Scrum-Coach als für den Prozess und die Produktivität verantwortlicher Projektmitarbeiter. Für ihn stellt es sich, wenn dieser Fall eintritt, wie der Kampf gegen Windmühlen, dar, was außerordentlich belastend ist.

Fehlende fachliche/technische Kompetenzen der Teammitglieder  ^

Für das Projekt ist es sehr wichtig, dass die am Projekt beteiligten Personen eine hohe technische und fachliche Kompetenz / Exzellenz aufweisen. Darüber hinaus sollte Entwicklungsteam in Scrum interdisziplinär aufgebaut sein, was bedeutet, dass alle für die erfolgreiche Durchführung des Projektes notwendigen Kenntnisse im Projekt vorhanden sind.
Ist dies nicht der Fall, könnten Wartezeiten auf projektexterne Fachkräfte eintreten, die potentiell zu Verzögerungen und Störungen des Ablaufs eines Sprints führen könnten, womit das Erreichen des Zieles des Sprints, die vereinbarten Anforderungen im Laufe des Sprints vollständig zu realisieren, gefährdet wäre.

Ist das Entwicklungsteam fachlich/technisch nicht ausreichend kompetent, sinkt die Produktivität des DTs, was für ihn insofern ein Risiko darstellt, als dass er der Verantwortliche für eine möglichst hohe Produktivität des DTs ist.

Tritt der Fall auf, das immer wieder externe Kräfte in das Projekt einzubinden sind, führt das zu einer verstärkten Auslastung des Scrum-Masters, da er in ebenfalls verstärktem Maße immer wieder neue Mitglieder in das Team integrieren muss, sich viele Hindernisse die er aufzulösen hat, ergeben, was letztlich auch wieder in einer hohen Produktivität und Entwicklungsgeschwindigkeit entgegensteht.

Fehlende Erklärungs-, Vermittlungs-, Problemlösungskompetenz  ^

Hat der Scrum-Master zwar ausreichende Kenntnisse über Scrum, fehlen ihm aber kommunikative Kompetenzen (er kann nicht oder nicht gut erklären / er kann nicht oder nicht gut vermitteln, er kann Probleme nicht oder nicht gut lösen) wird es ihm sehr schwer fallen, seine Rolle im notwendigen Rahmen auszuführen.

Der Scrum-Master muss in der Lage sein, die Hintergründe, warum in Scrum dieses oder jenes genau so und nicht anders zu tun oder zu lassen ist, plausibel vermitteln können, er muss Stellen, an denen eine Modifikation des Prozesses in einem bestimmten Rahmen zulässig oder gar erforderlich ist, erkennen und für die Beteiligen plausibel begründen können.

Er muss ein sehr guter Teamplayer sein, da er alle am Projekt beteiligten Personen anleiten können muss, zu einer Einheit zu werden, bzw. ist er derjenige, der das Team erfolgreich durch den Prozess der Team-formierung leiten muss.

Und er ist derjenige der Scrum erklären können und sicherstellen muss, dass die Teammitglieder den Scrum-Prozess verstehen, annehmen und verinnerlichen, er ist derjenige, zwischen dem Teammitgliedern im Konfliktfall vermitteln muss.

Fehlen ihm diese Kompetenzen, wird es sehr schwierig für ihn, Scrum erfolgreich einzuführen.

Mangel an Geduld  ^

Erklärungs-, Vermittlungs-, Problemlösungskompetenz zu haben, ist das eine, ausreichend Geduld zu haben, diese Kompetenzen immer und immer und immer wieder einsetzen zu müssen, ist das andere. Häufig wird er auch einfach erscheinende Dinge immer wieder neu erklären und begründen müssen, um einzelne Mitglieder oder das ganze Team auf einen Kurs zu bringen, der das / die Projekte zu einem erfolgreichen Ende führen.

Geringe Durchsetzungskraft  ^

Manchmal sprechen Taten mehr als Worte, manchmal ist es notwendig, das Ergebnis eines Vorgangs vor sich zu sehen, um akzeptieren zu können, dass der Vorgang genau so und nicht anders durchgeführt werden kann, um zu einem Erfolg zu werden.

Scrum funktioniert an vielen Stellen anders als andere Softwareentwicklungsprozesse — schon allein dadurch, dass Scrum People-Prozess ist, der das reale soziale Verhalten und die Bedürfnisse der beteiligten Personen in den Prozess einbezieht. Von daher ist es oft notwendig, zunächst einmal Widerstände und Ängste gegenüber der Veränderung zu überwinden, um die Vorteile, die Scrum mit sich bringt, auch wirklich nutzen zu können. Insbesondere der Scrum-Master benötigt dafür ein gewisses Maß an Durchsetzungskraft, insbesondere dann, wenn es schwierig ist, allen oder einzelnen Teammitgliedern bezüglich einzelner Vorgänge glaubhaft zu machen, dass sie notwendig sind, bzw. dass sie auf die von ihm vorgegebene Weise durchgeführt werden müssen, um den entsprechenden Effekt herbeizuführen.

Wichtig ist in diesem Fall, dass das Management auch in diesem Fall hinter dem Scrum-Master und dem Projekt steht, um ihm die entsprechende Rückendeckung zu geben, darauf zu drängen, Scrum so, wie Scrum ist, durchzuführen und am Ende zu sehen, dass der Erfolg sich eingestellt hat.

Risiken durch den Scrum-Master  ^

Scrum-Master war/ist gleichzeitig Projektleiter/Vorgesetzter/Leiter des Teams  ^

Scrum schließt disziplinäre Hierarchien, Weisungsbefugnisse, etc., zwischen den Rollen und innerhalb der Teams explizit aus, um insbesondere dem Entwicklungsteam die Möglichkeit zu öffnen, frei von äußerem Druck ihre inneren Potentiale für die Schaffung kreative und innovative Lösungen freisetzen und bündeln zu können.

Aus diesem Grund schließt Scrum disziplinäre Hierarchien, Weisungsbefugnisse, etc., zwischen den Rollen und innerhalb der Teams explizit aus. Scrum stellt statt dessen Werte und Eigenschaften, wie Eigenständigkeit, Gleichwertigkeit und Kompromiss- und Konsensfähigkeit aller am Projekt beteiligten Rollen und Individuen, insbesondere des Entwicklungsteams, konsequent und ausdrücklich in den Vordergrund, um damit die Motivation und den Willen eines jeden Beteiligten ausdrücklich darin zu unterstützen, das Projekt schnell, sicher und erfolgreich für das eigene Unternehmen und die Stakeholder abzuschließen.

Die Person des Scrum-Masters hat mehr als nur die eine Rolle/Aufgabe, ist nicht unabhängig  ^

Der Scrum-Master muss eine unabhängige Rolle sein, um seine Aufgaben durchführen zu können, da ansonsten, wenn diese Unabhängigkeit nicht gegeben ist, Interessenkonflikte drohen. Selbstverständlich gelten diese Bedenken auch unter der Maßgabe, dass die Person, die die zwei Rollen einnimmt, zu einer Zeit immer nur eine der (zwei oder mehr) Rollen vertritt und dann jeweils zu der anderen Rolle vollständig umschaltet.

Die beiden Rollen Scrum-Master und Product-Owner oder Stakeholder sind gleichzeitig Teamworker und Gegenspieler, sodass die gleichzeitige Besetzung durch eine einzelne Person auf jeden Fall vermieden werden sollte. Ist Scrum bereits gut implementiert und vom Team gut angenommen, ist jedoch denkbar, dass sich der Scrum-Master aus den Reihen des DTs rekrutiert.

Dauerhafte Moderation der Scrum-Meetings  ^

Eine der wesentlichen Aufgaben des Scrum-Masters ist, die Mitgliedern des Scrum-Teams in der Handhabung, Durchführung und Nutzung von Scrum zu unterweisen und zu unterstützen. In diesem Kontext wird der Scrum-Master zunächst solange die Meetings moderieren, bis das Team sicher genug darin ist, die Moderation selbst durchzuführen.

Schafft es der Scrum-Master nicht, das Team zu motivieren, die Durchführung und Moderation der jeweiligen Meetings, zu denen auch das Daily-Scrum gehört, selbst zu übernehmen und sich als Scrum-Master auf die Funktion eines aufmerksamen Teilnehmer zu reduzieren, kann das Team die richtige Handhabung von Scrum nicht erlernen und wird weiterhin auf die Hilfe und Unterstützung des Scrum-Master angewiesen sein. Zudem besteht auf Dauer die Gefahr, dass der Scrum-Master als (permanenter) Moderator und Coach das jeweilige Ergebnis eines Meetings beeinflusst und mitbestimmt.

Mehrere Scrum-Master im Projekt  ^

Es kann vorkommen, dass es in einem Unternehmen mehrere Mitarbeiter gibt, die als Scrum-Master tätig sein können oder sollen. In so einem Fall wird ein Projekt manchmal von mehr als einem Scrum-Master betreut, damit die Scrum-Master Erfahrungen sammeln. Diese Konstellation ist für das Projekt problematisch, da es nun mehrere Ansprechpartner für das Team gibt, die sich untereinander wiederum abstimmen müssen, bzw. zumindest potentiell unterschiedliche Sichten vertreten könnten und — zumindest in Konfliktsituationen — gegeneinander ausspielbar sind.

Es sollte daher immer nur ein erfahrener Scrum-Master oder Scrum-Coach als Hauptansprechpartner in allen Fragen und Aufgaben rund um Scrum und den Prozess im Projekt zuständig sein. Er sollte dann nicht nur für die Kern-Projektmitglieder Ansprechpartner in Sachen Scrum sein, sondern auch die weiteren Scrum-Master schulen, betreuen und mit Ansage an das Team ggf. einzelne Aufgaben an sie delegieren.

Die Besetzung des Scrum-Masters wird immer wieder ausgewechselt  ^

Der Scrum-Master muss eine Konstante im Projekt sein, keine Variable. Wird der Scrum-Master immer wieder gegen jemand anderes, vielleicht sogar bis dahin jemand projektfremdes ausgetauscht, kann sich keine Beziehung aufbauen.

Eine Ausnahme ist, wenn der Prozess bereits gut eingeführt und von allen beteiligten Personen angenommen und verinnerlicht worden ist, der Scrum-master rotierend durch die Mitglieder des Entwicklungsteam gestellt wird und das von allen beteiligten Personen akzeptiert wird.

Fachliche Inkompetenz  ^

Ein Scrum-Master, der in Scrum nur wenig Erfahrung hat, wird große Probleme damit haben, Scrum korrekt einzuführen und das Entwicklungsteam in seinen Aufgaben zu unterstützen, was zu ernsthaften Problemen bei der Implementation des Prozesses und für das Projekt bedeuten kann. Identifizieren die Projektbeteiligten ein solches Problem, sollten sie das Gespräch mit dem Scrum-Master suche und versuchen, eine gemeinsame Lösung für das Problem zu suchen, z.B., dass der Scrum-Master durch einem Scrum-Coach gecoacht und unterstützt wird. Bleiben die Versuche ohne Erfolg, sollte das Problem an eine entsprechende Stelle eskaliert werden.

Steht für Fragen nicht zur Verfügung, ist schwer/nicht erreichbar, abwesend, überlastet
Der Scrum-Master ist essentieller Bestandteil des Scrum-Teams und muss dem Team regelmäßig zur Verfügung stehen. Steht der Scrum-Master dem Team insbesondere in der Einführungsphase regelmäßig nicht zur für Fragen, bzw. generell als Ansprechpartner zur Verfügung, ist keine ausreichende Unterstützung des Scrum-Teams für die Beseitigung von Hindernissen, Fragen rund um Scrum, Unterstützung und Moderation in Meetings und im täglichen Projektgeschäft — insbes. für das Entwicklungsteam — gewährleistet. Darüber hinaus ist fraglich, ob der Scrum-Master unter diesen Umständen das Impediment-Backlog pflegen und abarbeiten können wird.

Ist unkommunikativ, kann sich nicht ausdrücken, tut sich schwer mit Erklärungen  ^

Da der Scrum-Master über keine disziplinarische Hausmacht verfügt, sondern darauf angewiesen ist, die Beteiligten zu überzeugen, kann es für den ihn zu einem Problem werden, wenn seine Fähigkeiten, zu kommunizieren und einfache und/oder komplexe Sachverhalte schlüssig zu erläutern, nur gering ausgeprägt sind.

Der Scrum-Prozess ist, da er an vielen Stellen andere Konzepte als andere Softwareentwicklungsprozesse verfolgt, erklärungsbedürftig. Er stellt potentiell andere Werte und Konzepte als evtl. zuvor eingesetzte Prozesse in den Vordergrund und muss daher vor einer Beherrschung, erklärt und erlernt werden. Tut der Scrum-Master sich schwer damit, wird es ihm auch schwer fallen, dem Team den richtigen Umgang und Einsatz des Prozesses zu vermitteln und den Prozess erfolgreich zu implementieren.

Kann nicht NEIN sagen, lässt alles durchgehen  ^

Der Scrum-Master hat keine disziplinarischen oder anderweitigen Möglichkeiten, den Teammitgliedern Anweisungen zu erteilen oder durchzusetzen. Seine einzige Möglichkeit ist, zu überzeugen. Das erfordert Überzeugungsgraft, innere Ruhe und Geduld, um die Teammitglieder in die richtige Richtung zu lenken. Doch seine Geduld darf nicht unbegrenzt sein.

Seine Aufgabe ist, die Werte von Scrum darzustellen, sie zu erklären und auch, sie am Ende durchsetzen. Dazu gehört, das Team dahingehend zu motivieren, sich mit dem Prozess, seinen Rahmenbedingen, Regeln und Werten auseinanderzusetzen und sich auf ihn einzulassen. Insbesondere dann, wenn die Einführung von Scrum dazu dient, einen anderen Prozess abzulösen, ist es oft notwendig, einen klaren Schnitt gegenüber dem abzulösenden Prozess zu vollziehen und ihn gegenüber Scrum klar abzugrenzen, alte Verhaltensweisen aufzugeben und neue zu erlernen.

Verständlicherweise gibt es häufig Widerstände dagegen, alte, vielleicht im abzulösenden Prozess trotz allem als produktiv erlebte Verhaltensweisen, aufzugeben. Oft wird in dieser Situation verlangt, von vorn herein wesentliche Teile Scrums durch die bislang verfolgten Verhaltensweisen zu ersetzen und auch dann ist es notwendig und für die erfolgreiche Implementation des Prozesses essentiell, dass der Scrum-Master an dieser Stelle die ganz klare Linie verfolgt, Scrum zunächst einmal in seiner Grundform stabil zu etablieren und den Bestrebungen zu widerstehen, Scrum bereits im Vorweg der Implementation an die eigenen, potentiell kontraproduktiven Verhaltensweisen anzupassen.

Ist er nicht in der Lage, in diesen und anderen kritischen, den Einführungsprozess gefährdenden Situationen, diesen Bestrebungen eine ganz klare Absage zu erteilen und Nein zu sagen, oder lässt er häufig sich einschleichende Abweichungen und alte oder Gewohnheiten durchgehen, die dem Prozess und seiner Leistungsfähigkeit abträglich sind, wird ihm die angestrebte erfolgreiche Einführung, die den Prozess zünden lässt und dem Projektteam einen wirklichen und dauerhaften Vorteil verschafft, nicht gelingen.

Der Scrum-Master ist dafür verantwortlich, den Prozess gemeinsam mit dem Team zu implementieren und dem Team eine hohe und stabile Produktivität zu ermöglichen. Dazu kann auch gehören, dass er — je nach Fähigkeiten und Kenntnissen — die Beteiligten in ihrem produktiven Tagesgeschäft aktiv unterstützt. Diese Unterstützung darf aber nicht dazu führen, dass beteiligte Personen Teile ihrer Aufgaben dauerhaft an die Rolle des Scrum-Masters dauerhaft abgeben oder delegieren.

Handelt nicht als Anwalt des Entwicklungsteams  ^

Der Scrum-Master ist in Scrum der Anwalt des Entwicklungsteams. Seine Aufgabe ist u.a., das Entwicklungsteam vor Störungen und Einflussnahme von außen zu schützen und dem Team eine möglichst hohe Produktivität zu ermöglichen.

Das bedeutet z.B., dass er alle Hindernisse, die das Entwicklungsteam in ihrer Produktivität behindern könnten, verhindern und beseitigen wird, z.B., ausufernde Diskussionen oder Geschwafel im Daily-Scrum, dass Mitglieder des Entwicklungsteam wiederholt zu spät oder erst gar nach persönlicher Aufforderung zum Daily-Scrum kommen, dass der Product-Owner sich als Chef des DTs aufspielt, dass der Product-Owner Änderungen an den bereits beschlossenen und vom Team akzeptierten Aufgaben ohne vorherige Absprache mit dem Team vornimmt, dass der Product-Owner Zeiten und Termine nicht einhält, oder andere, für das Entwicklungsteam überraschende und/oder andere sie negativ beeinflussende Dinge, durchführt.

Das bedeutet auch, dass der Scrum-Master Konflikte innerhalb des Teams oder mit dem Team schlichtet und alle Beteiligten im Fall eines Konfliktes als Vermittler und Schlichter wieder an einen Tisch holt, um weder die Produktivität des Teams, noch den erfolgreichen Abschluss eines Sprints oder des gesamten Projektes aufs Spiel zu setzen.

Kümmert sich der Scrum-Master, wenn überhaupt, nur um die Einhaltung der Regeln von Scrum und überlässt das Team ansonsten sich selbst, unterstützt es nicht, dann kommt er wesentlichen Teilen seines Auftrags nicht nach setzt den Erfolg des Teams, des Projektes und der erfolgreichen Implementation von Scrum aufs Spiel.

Gibt den Druck an das Entwicklungsteam weiter  ^

Der Scrum-Master ist für die erfolgreiche Implementation von Scrum und die Produktivität des Teams verantwortlich. Dazu kann auch gehören, dass er — je nach Fähigkeiten und Kenntnissen — den Beteiligten zeitweise Teile seiner Aufgaben zu übertragen, in ihrem produktiven Tagesgeschäft aktiv unterstützt

Der Scrum-Master soll das Entwicklungsteam entlasten und nicht belasten. Er kann aber Aufgaben an das Entwicklungsteam delegieren, wenn es das Projekt voranbringt. Von außen sollte — sofern er seine Aufgaben nicht vernachlässigt — kein Druck auf den Scrum-Master ausgeübt werden.

Ändert Termine oder Aufgaben ohne Absprache, lässt Meetings ausfallen  ^

Einige der wichtigsten Aspekte von Scrum sind die Konzepte Verlässlichkeit, Konstanz und Vorhersehbarkeit.

Die Sprints in Scrum haben immer die gleiche Länge und immer die gleichen Termine, die immer verlässlich zum gleichen geplanten Zeitpunkt am geplanten Ort stattfinden und die pünktlich mit allen notwendigen Unterlagen und Vorbereitungen aufzusuchen sind. Jedem Beteiligten ist seine spezifische Verantwortlichkeit und Aufgabe vor, im und nach dem Meeting genauso klar, wie, dass das Meeting pünktlich am festgelegten Ort beginnen wird.

Dass diese Dinge fest gesetzt werden, dient nicht der Gängelung der Beteiligten und stellt auch keinen — wie immer mal wieder gemutmaßt wird — preußisch motivierten Eingriff in die persönliche Lebensplanung und Selbstbestimmung der beteiligten Individuen dar, sondern dient lediglich dazu, den Ablauf einer jeden Iteration und die Verläufe der Meetings klar und verlässlich und vollständig transparent zu gestalten und zu strukturieren. Auf diese Weise werden Unsicherheiten und unnötige Kommunikation vermieden, eventuelle Aufwand werden reduziert, bzw. ganz vermieden und Unklarheiten bzgl. der Termine, sowie der Inhalte und Aufgaben des Meetings von vorn herein gar nicht zugelassen.

Keines der vereinbarten Meetings ist optional, jedes hat seine spezifische Aufgabe und Bedeutung. Werden ohne Absprache, ohne allgemeinen Konsens Termine, Aufgaben oder Meetings verändert oder fallen gelassen, ist dieser wichtige Aspekt von Scrum gefährdet und es ist die Aufgabe des Scrum-Masters, diese Störung des Prozesses zu thematisieren und abzustellen. Ist es der Scrum-Master selbst, der den Prozess an dieser Stelle beschädigt, sollten die anderen am Prozess beteiligten Personen, vielleicht sogar das Management den Scrum-Master auf diesen Missstand hinweisen und ggf. sogar in geeigneter Form ahnden.

Delegiert seine Aufgaben an das Team  ^

Insbesondere während der Implementationsphase von Scrum kann es durchaus sinnvoll sein, dass der Scrum-Master zeitweise einen Teil seiner Aufgaben zu Schulungszwecken an das Entwicklungsteam delegiert. Ist dies der Fall, muss dies im Sprintplan berücksichtigt und sollte mit dem Entwicklungsteam und dem Product-Owner abgesprochen werden. Dieses Delegieren sollte nur im Rahmen von Schulungszwecken erfolgen und daher zeitlich begrenzt sein; eine dauerhafte Delegation seiner Aufgaben z.B. an das Entwicklungsteam unterstützt das Entwicklungsteam nicht, sondern belastet es und ist daher nicht akzeptabel.

Pflegt das Impediment-Backlog nicht / nur ungenügend  ^

Eine der wesentlichen Aufgaben des Scrum-Masters ist, das Entwicklungsteam gegenüber äußeren Einflüssen abzuschirmen, es in seinen Belangen und in seiner Produktivität zu unterstützen und zu fördern. Eventuelle Hindernisse, die die Produktivität des Entwicklungsteam einschränken, berichten sie dem Scrum-Master und er wird diese Hindernisse (Impediments) in Absprache mit dem Entwicklungsteam priorisieren, in das Impediment-Backlog eintragen und — analog zur Handhabung des Product-Backlogs durch den Product-Owner — das Impediment-Backlog nach Priorität absteigend sortieren, sodass das Impediment mit der höchsten Priorität ganz oben im Impediment-Backlog steht.

Das Impediment-Backlog ist sein Backlog (so wie das Product-Backlog das Backlog des Product-Owner und das Sprint-Backlog das Backlog des DTs ist) und er wird das höchst priorisierte Impediment aus dem Impediment-Backlog nehmen und als erstes bearbeiten, d.h., das dem Impediment zugrunde liegende Problem beseitigen.

Pflegt der Scrum-Master das Impediment-Backlog nicht und/oder bearbeitet er die Impediment nicht, vernachlässigt er damit seine Aufgaben und „sein“ Entwicklungsteam, das auf auch in dieser Hinsicht auf seine Unterstützung angewiesen ist. Behebt er allerdings die Hindernisse und aktualisiert lediglich das Impediment-Backlog nicht, sollte er vom Entwicklungsteam ermahnt werden, das Impediment-Backlog so zu pflegen, wie es sein sollte, denn gerade er müsse als Vorbild dienen, zumal das Impediment-Backlog eine der wesentlichen Informationsquellen für die Beurteilung des Sprint- und Projektverlaufs ist.

Nimmt seine Aufgaben nicht permanent wahr, ist in Meetings schlecht vorbereitet, unterstützt das Entwicklungsteam nicht oder nur ungenügend, scheint sich nicht für das Projekt zu interessieren  ^

Die wesentlichen Aufgaben des Scrum-Master sind, allen beteiligten Personen die Spezifika von Scrum nahezubringen, sie in der Ausübung des Scrum-Prozesses zu einzuweisen, das Entwicklungsteam gegenüber äußeren Einflüssen abzuschirmen, es in seinen Belangen und in seiner Produktivität zu unterstützen und zu fördern, sowie eventuelle Hindernisse zu protokollieren und zu beheben.

Haben die Projektbeteiligten den Eindruck, dass der Scrum-Master seine Aufgaben vernachlässigt (was nicht nur für den Scrum-Master, sondern genauso auch für das Entwicklungsteam und den Product-Owner gilt!), sollten sie sich untereinander darüber austauschen und dann das Gespräch mit dem Scrum-Master suchen und ihm ihre Sicht und Erwartungen klar darlegen. Vielleicht kann sich der Scrum-Master dann auch erklären. Alle Beteiligten sollten dann — wenn irgend möglich — einen gemeinsam Weg finden, die Situation entweder zu bereinigen oder aber, wenn gar nichts anderes mehr geht, an eine geeignete Stelle (z.B. Scrum-Coach oder ggf. Management) zu eskalieren.

Fazit  ^

Die Rolle des Scrum-Masters hat eine immense Bedeutung in Scrum. Der Scrum-Master ist die Seele, der gute Geist von Scrum, er ist der Wächter, Hüter und Optimierer des Prozesses. Sein ist der Prozess.

Soll Scrum im Unternehmen/Projekt implementiert werden, führt er die Implementierung durch, er schult und coacht das gesamte Team in allen Belangen von Scrum, bis alle Beteiligten Scrum „können“ und verinnerlicht haben, bzw., bis der Scrum-Master nicht mehr die Abläufe eingreifen muss. Er führt zerstrittene Parteien zusammen, er ist Vermittler, Schlichter, Unterstützer und Motivator, er ist Problemlöser, er ist der „key enabler“, das Schlüsselelement für Implementation und Betrieb von Scrum.

Sein besonderes Augenmerk hat das Entwicklungsteam, das er gegenüber dem Product-Owner und ggf. auch gegenüber den Stakeholdern oder, wenn notwendig, sogar gegenüber dem Management vertritt. Er unterstützt das Entwicklungsteam, indem er sich der Hindernisse, durch die die Mitglieder des DTs in ihrer Produktivität eingeschränkt werden, annimmt und die ihnen zugrunde liegenden Probleme auflöst; sein Ziel ist, dem Entwicklungsteam eine dauerhaft hohe Produktivität zu ermöglichen.

Bei alledem hat der Scrum-Master keine Hausmacht, sondern er regiert durch die Überzeugungskraft von Wort, Tat und Beispiel, er führt das Team und dient ihm gleichzeitig. Dabei ist der Scrum-Master darauf angewiesen, dass das Management vollständig hinter ihm und der Entscheidung, Scrum als Softwareentwicklungsprozess einzuführen steht, selbst dann, wenn die Eignung von Scrum für das Unternehmen im Rahmen eines Evaluationsprojektes zunächst ermittelt werden soll, denn steht das Management bereits einem Evaluationsprojekt kritisch gegenüber, signalisiert es den Beteiligten damit, den gesamten Prozess nur widerwillig zu unterstützen.

[zurück zum Seitenanfang]


, , ,

No comments yet.

Schreibe einen Kommentar

V1503130747DE