Viele Menschen verknüpfen mit agilen Frameworks die Vorstellung, dass es keine Prozesse, Zuständigkeiten oder Verantwortungen und auch keine Pläne gebe. In ihrer Vorstellung bedeutet Agilität und agile Vorgehensweisen, dass jeder das macht, was er für richtig hält, und am Ende grossartige Produkte entstehen würden. Diese Vorstellung ist komplett falsch. Der Erfolg des agilen Vorgehens basiert zu einem guten Teil auf der Tatsache, dass Prozesse eingehalten werden und Rollen mit Aufgaben, Verantwortungen und Kompetenzen klar definiert sind.
Der Scrum-Guide benennt innerhalb des Scrum-Teams drei Rollen:
- Product Owner – verantwortlich für die Steigerung des Geschäftswertes des entstehenden Produktes
- Scrum Master – unterstützt das Team dabei, Scrum optimal zu nutzen.
- Entwickler (3-9 pro Team) – entwickelt das Produkt
- Und der Projektleiter?
- Andere Rollen
- Schweine und Hühner
Keine der genannten Rollen hat dabei die Gesamtleitung oder Weisungsbefugnis den anderen Rollen oder Personen innerhalb der eigenen Rolle gegenüber.
Obwohl es grundsätzlich möglich ist, dass eine Person mehrere verschiedene Scrum-Rollen im selben Entwicklungsprojekt innehat, wird davon abgeraten. Diese Rollen interagieren mit internen und externen Stakeholdern wie Management, Kunden, Benutzern, externen Fachleuten und ggf. weiteren Personen, deren Zusammensetzung und Ziele je nach Projekt sehr unterschiedlich sein können. Sie werden alle im Rahmen des Scrum-Guide nicht weiter definiert.
Das Scrum-Team hat zwei grundlegende Eigenschaften: es ist selbst-organisiert und funktionsübergreifend (cross-functional).
Selbst-organisiert meint dabei, dass das Team nicht von einem Manager geführt wird, sondern gemeinsam entscheidet und Entscheidungen gemeinsam verantwortet und trägt. Dies bietet gerade in sehr hierarchisch geprägten Unternehmen eine grosse Herausforderung. Das Scrum-Mindset unterscheidet nicht in Management und Spezialisten-Aufgaben innerhalb von Scrum. So ist es nur folgerichtig, dass es auch keine hierarchischen Unterschiede zwischen den verschiedenen Rollen gibt und auch innerhalb der Rolle «Entwickler» kein Team-Leader existiert.
Funktionsübergreifend wird im agilen Kontext oft fälschlicherweise so verstanden, dass innerhalb eines Teams alle alles tun würden und das auch noch alle gleich gut. Dies ist ein Missverständnis. Der Ausdruck «Cross-Funktional» bezieht sich auf das Team als Ganzes, nicht auf seine einzelnen Mitglieder. Oft finden sich innerhalb eines Teams Menschen mit sehr unterschiedlichen Kernkompetenzen wie «Tester», «UI-Entwickler» oder «Architekt», die schwergewichtig die entsprechenden Aufgaben übernehmen. Funktionsübergreifend meint lediglich, dass das Team als Ganzes in der Lage sein soll, die übernommenen Arbeiten selbstständig umzusetzen. Dabei ist es sinnvoll, dass auch Stellvertretungen und Unterstützungen durch andere Team-Mitglieder sichergestellt werden, selbst wenn das bedeutet, dass diese nicht ausschließlich innerhalb ihrer Kernkompetenzen eingesetzt werden. Das Team übernimmt als Ganzes die Umsetzungsverantwortung und stimmt sich gemeinsam ab, wie diese am besten stattfinden kann.
1) Die Rolle des Product Owners
Anders als man vermuten möchte ist der Product Owner und nicht der Scrum Master die zentrale Rolle in Scrum. Seine Aufgaben entsprechen am ehesten jenen eines klassischen Projektleiters, gehen aber in manchen Bereichen erheblich darüber hinaus. Sie umfassen zu einem guten Teil auch jene eines klassischen Product Managers. Was dabei aber vollständig fehlt ist eine Führungsfunktion oder eine Weisungsbefugnis den anderen Rollen gegenüber.
Maximierung des Geschäftswerts
Die Rolle des Product Owners hat als Kernaufgabe jene, den Geschäftswert (Business Value) der umgesetzten Software zu maximieren. Dies bedeutet in keiner Weise, dass er dafür verantwortlich wäre, dass möglichst viel Software erstellt würde, sondern im Gegenteil liegt der Anspruch an einen erfolgreichen Product Owner darin, dass mit möglichst wenig Software ein maximaler Geschäftswert erreicht werden kann. Man kann dabei an den Pareto-Ansatz denken, wo man davon ausgeht, dass 20 % des Aufwandes 80 % der Wertschöpfung ergibt, wohingegen für die Realisierung der letzten 20 % Wertschöpfung ein Aufwand von 80 % benötigt wird. Dies stellt erhebliche Anforderungen an den Product Owner:
Hauptansprechpartner des Kunden
Als Hauptansprechpartner des Kunden muss er in der Lage sein, dem Kunden die richtigen Fragen zu stellen, um mit ihm gemeinsam zu evaluieren, welche Anforderungen bestehen und welche davon den höchsten Geschäftswert repräsentieren. Neben den Anforderungen, welche der Kunde kommuniziert, ist es oft eine besondere Herausforderung für den Product Owner, herauszuarbeiten, welche wichtigen Anforderungen der Kunde nicht geäußert hat. Sei es, weil dieser sie vergessen hat, sei es, weil der Kunde diese Anforderungen für so trivial oder selbstverständlich hält, dass er sie nicht extra hervorhebt.
Für Kunde, Benutzer und Stakeholder
Die Zusammenarbeit mit dem Kunden und Benutzer sowie weiteren Stakeholdern bietet für den Product Owner eine grosse Herausforderung. Oft haben die verschiedenen an einem Projekt interessierten Parteien unterschiedliche Erwartungen und Präferenzen und versuchen primär und priorisiert ihre Wünsche und Anforderungen umgesetzt zu sehen. Hieraus ergeben sich nicht nur Anforderungen an die Kommunikations- und Verhandlungsfähigkeit, sondern auch die Notwendigkeit, dass der Product Owner stets einen Überblick bewahrt und entscheiden kann, wo tatsächlich die grösste Wertschöpfung für seinen Kunden liegt. Dazu ist ein Business-Fokus notwendig, wohingegen es nicht notwendig ist, dass der Product Owner Entwickler-Kenntnisse besitzt. Oft ist es sogar besser, wenn er diese nicht besitzt, damit er Anforderungen in Bezug auf den angestrebten Nutzen beschreibt und es dem Entwicklerteam überlässt, innerhalb der bestehenden Rahmenbedingungen die optimale Lösung zu finden.
Bei der Entwickler-Organisation angesiedelt
Der Product Owner stammt aus der Organisation, welche das Produkt entwickelt (nicht aus der Kundenorganisation). Der Kunde wird seinerseits aus der eigenen Organisation eine beschränkte Anzahl an primären Ansprechpersonen benennen. Diese haben im Scrum Guide keine besondere Rollenbezeichnung.
Hat das letzte Wort
Ein Produkt besitzt stets nur einen einzigen Product Owner, der finale Entscheidungen trifft. Es ist aber zulässig, dass eine Gruppe oder ein Komitee den Product Owner berät. Genauso besteht auch die Möglichkeit, dass der Product Owner einige seiner Verantwortungen delegiert. Er bleibt aber in jedem Fall finaler Entscheider und Verantwortlicher. Dies muss sowohl von Kunden- wie auch von Lieferantenseite (selbst von Geschäftsleitungsmitgliedern) akzeptiert und mitgetragen werden, um die Rolle und das ganze Gleichgewicht der Verantwortlichkeiten und Aufgaben nicht nachhaltig zu beschädigen.
Transparenz an oberster Stelle
Offenheit ist ein zentraler Wert von Scrum und so sollte es eigentlich selbstverständlich sein, dass der Product Owner diese Offenheit und Transparenz auch den Stakeholdern gegenüber pflegt und sie über Entwicklungsforschritt und Releaseplanung offen informiert. Da eine erfolgreiche Zusammenarbeit mit dem Kunden für den Erfolg von Scrum-Enwicklungsprojekten (und nicht nur diesen) grundlegend ist, versteht es sich von selbst, dass Transparenz nicht nur in Bezug auf positive Entwicklungen gepflegt wird, sondern dass der Kunde auch bei Rückschlägen oder sich abzeichnenden Verzögerungen so früh wie möglich informiert wird, damit auch er seine Planung anpassen und gemeinsam nach Lösungen gesucht werden kann.
Jetzt für die Infoveranstaltung IPMA-Kurse anmelden!
2) Die Rolle des Scrum Masters
Es ist eines der grossen Missverständnisse in Scrum, dass die Rollen-Bezeichnung «Scrum Master» in vielen Fällen in einem hierarchischen Kontext von «Herr und Meister» statt im Sinne von «Meisterschaft und Kompetenz» verstanden wird.
Der Manager
Die Rolle des «Scrum Masters» ist eine Management-Rolle. Seine Verantwortung ist die eines Prozessmanagers, welcher den Scrum-Prozess so unterstützt und optimiert, dass er bestmögliche Resultate bringt, sowie die eines Coaches, der sein Team unterstützt und Hindernisse beseitigt. Voraussetzung dafür sind profunde Kenntnisse von Scrum sowie die Fähigkeit, das Team in der Implementierung und Umsetzung optimal zu unterstützen. Da die Rolle des Scrum Masters kein Weisungsrecht besitzt, ist er darauf angewiesen, die anderen Team-Mitglieder von der Sinnhaftigkeit eines richtigen Vorgehens (Abhalten der Events, Timeboxing, Wahrnehmung von deren Aufgaben etc.) zu überzeugen.
Der Leader
Der Scrum Master ist ein Servant Leader. Wo Leadership üblicherweise auf Befehl und Kontrolle basiert, steht beim Scrum Master das Überzeugen und Begeistern des Teams im Vordergrund.
Der Scrum Master unterstützt den Product Owner, indem er ihm bei Bedarf hilft, geeignete Techniken und Vorgehensweisen zu finden, Informationen zu kommunizieren und Events zu ermöglichen.
Die Entwickler unterstützt der Scrum Master, indem er Hindernisse beseitigt, ihre Events unterstützt und sie als Trainer und Coach unterstützt.
Der Botschafter
Ein guter Scrum Master wirkt nicht nur innerhalb des Scrum-Teams, sondern ist auch als Botschafter von Scrum in der Organisation tätig. Er vermittelt das Verständnis für Scrum und die optimale Zusammenarbeit mit dem Scrum-Team. In mancher Organisation stellt es eine große Herausforderung dar, die Zusammenarbeit einer eher hierarchischen, basierend auf Aufträgen und Kontrollen geführten Firma mit einem (oder mehreren) Teams zu ermöglichen, welche selbst-organisiert und selbst-verantwortlich agieren.
Kann mehrere Teams leiten
Die Rolle eines Scrum Masters ist oft keine Vollzeittätigkeit. Theoretisch wäre es auch möglich, dass ein Team-Mitglied die Rolle ausfüllen würde. Davon wird aber explizit abgeraten. Sinnvoller wäre es, dass ein nicht voll ausgelasteter Scrum Master diese Rolle bei mehr als einem Team einnehmen kann.
Jetzt für die Infoveranstaltung IPMA-Kurse anmelden!
3) Das Entwickler-Team
Das Entwickler-Team setzt sich aus Fachleuten zusammen, welche gemeinsam in der Lage sind, die Anforderungen im Product Backlog umzusetzen. Um das sicherzustellen, muss das Team funktionsübergreifend (cross-functional) zusammengesetzt werden. Dabei können einzelne Team-Mitglieder Spezialisten für bestimmte Bereiche sein und auch schwergewichtig mit entsprechenden Tätigkeiten beschäftigt sein; es muss aber sichergestellt werden, dass das Team als Ganzes alle Anforderungen abzudecken vermag. Das Team verpflichtet sich zur Umsetzung der für einen Sprint gewählten Anforderungen (Backlog Items) und muss entsprechend sicherstellen, dass auch alle benötigten Fähigkeiten vorhanden sind. Als «Besitzer» des Sprint Backlogs sind sie aber frei, wie sie die Umsetzung gestalten. Während die Anforderungen stets in der Verantwortung des gesamten Teams liegen, können einzelne Teammitglieder die Verantwortung für die Umsetzung einzelner Aufgaben (Tasks) übernehmen.
Entwicklung von Inkrementen
Im Verlauf des Sprints entwickelt das Team gemeinsam das nächste Inkrement, in das alle umgesetzten Anforderungen, welche der «Definition of Done» entsprechen, aufgenommen werden.
Teams von 3-9 Entwicklern
Das Entwicklerteam besteht aus 3-9 Entwicklern, die selbstverantwortlich arbeiten. Einen Team-Chef gibt es nicht. Entscheidungen werden stets gemeinsam getroffen und verantwortet. Um diese Arbeitsweise erfolgversprechend zu gestalten, ist es wichtig, dass alle Teammitglieder vollzeitig in einem Team sind und das Team gemeinsam an einem einzigen Produkt arbeitet. Nur so kann sichergestellt werden, dass fokussiert und agil gearbeitet werden kann.
Sollte es zu Wechseln im Team kommen, so sollten diese, wenn immer möglich, zum Ende eines Sprints erfolgen. Dabei ist zu berücksichtigen, dass jeder Wechsel zu kurzfristigen Performance-Verlusten des Teams führt.
Jetzt für die Infoveranstaltung IPMA-Kurse anmelden!
4) Und der Projektleiter?
Klassische Projektorganisation vs. selbstorganisiertes Team
Eine Frage, die in fast jeder Scrum-Prüfung direkt oder indirekt auftaucht, ist jene nach dem Projektleiter. Welche Rolle leitet nun das ganze Projekt? Ist es der Scrum Master, der Product Owner oder gibt es da doch noch weitere Rollen?
Das Projektmanagement ohne Projektleiter
Zunächst ist die Antwort ganz einfach: In Scrum gibt es keinen Projektleiter und keine andere Rolle agiert wie ein Projektleiter. Schaut man aber genauer hin, so erkennt man, dass viele Aufgaben eines Projektleiters auch in einem Scrum-Projekt durchgeführt werden müssen. Hier gilt, dass die verschiedenen Aufgabenstellungen unter den Rollen basierend auf deren Verantwortungsbereichen aufgeteilt werden. Von zentraler Bedeutung dabei ist aber, dass damit keine der Rollen eine hierarchische Leitungsfunktion übernimmt. Vielmehr kann man sich das Zusammenspiel womöglich wie Rollen in einem klassischen Ballett vorstellen, bei dem unterschiedliche Rollen zu bestimmten Zeiten aktiver oder auch besser sichtbar sind, wo sich der tatsächliche Erfolg aber nur dann einstellt, wenn alle Rollen gemeinsam ein Ganzes bilden und miteinander agieren.
Jetzt für die Infoveranstaltung IPMA-Kurse anmelden!
5) Andere Rollen
Das Scrum-Team agiert mit internen und externen Stakeholdern. Dazu gehört das eigene Management genauso wie der Kunde, eventuell auch der Endbenutzer und weitere Rollen. Der Scrum-Guide beschreibt diese nicht detailliert. Zweifellos ist aber gerade die Zusammenarbeit mit ihnen und ihr Beitrag von essentieller Bedeutung für den Erfolg agiler Software-Entwicklung. Ist das eigene Management und die eigene Organisation nicht in der Lage, das (oder die) Scrum-Team(s) mit Ressourcen zu unterstützen und ihnen den Freiraum zu geben, welchen sie für ihre selbstverantwortliche und selbstorganisierte Arbeit brauchen, werden sie nicht effektiv arbeiten können. Besteht der Kunde darauf, dass alle seine Anforderungen «Muss-Kriterien» sind oder verschließt sich einer Zusammenarbeit für die Klärung von Anforderungen oder das Beitragen von Feedbacks, wird es unmöglich sein, das optimale Produkt zu erstellen.
6) Schweine und Hühner
Um die Zusammenarbeit in Scrum besser zu verstehen, wird oft eine kleine Geschichte über ein Schwein und ein Huhn verwendet:
Ein Schwein und ein Huhn unterhalten sich. Das Huhn schlägt vor, ein gemeinsames Restaurant zu eröffnen. «Was sollen wir dort anbieten?», fragt das Schwein begeistert. Das Huhn antwortet: «Schinken und Eier». Das Schwein ist nicht einverstanden und ruft wütend: «Ich wäre committed (betroffen), während du nur involved (beteiligt) wärst.»
Das Scrum-Team nimmt in dieser Analogie die Rolle des Schweins ein, während die restlichen Stakeholder nur jene des Huhns einnehmen würden.
