

In agilen Projekten kommen in der Praxis oft mehr Rollen vor als nur Scrum Master, Product Owner und Entwickler. Auch klassische Rollen etablieren sich zunehmend, z.B. Software-Architekten oder Business Analysten. Wie Sie bei dieser Rollenvielfalt den Durchblick behalten, zeigt Ihnen Christian Czerwonka.
In agilen Projekten kommen in der Praxis oft mehr Rollen vor als nur Scrum Master, Product Owner und Entwickler. Auch klassische Rollen etablieren sich zunehmend, z.B. Software-Architekten oder Business Analysten. Wie Sie bei dieser Rollenvielfalt den Durchblick behalten, zeigt Ihnen Christian Czerwonka.
Projektleiter im agilen Umfeld: Ist nicht schon die Frage danach völlig verkehrt?
Projekte werden heutzutage (und immer noch zunehmend) "agil" durchgeführt. Trotz dieser "agilen" Maxime stellt man in der Praxis jedoch fest: In der Regel gibt es in agilen Projekten oft noch die Rolle eines (Gesamt-)Projektleiters. Dieser wird vom Kunden/ Projektsponsor – wie selbstverständlich – immer wieder für Projekte eingefordert. Als solcher ist der Projektleiter, wie im klassischen "Wasserfall", verantwortlich für das Projektbudget und für dessen Einhaltung. Auch "Meilensteine" (eigentlich eines der agilen Unwörter überhaupt) sind weiterhin verbreitet (auch wenn sie sich begrifflich als "Inkrement", "Epic" oder Ähnliches verstecken). Dies alles mag vor dem Hintergrund der populären und kaum infrage gestellten agilen Paradigmen überraschen.
Aber es sind auch die eigentlichen Scrum-Rollen vertreten: der Scrum Master, der Product Owner und die Entwickler oder "Developers", wie sie im Scrum Guide bezeichnet werden. Was konkret unter Developers zu verstehen ist, lohnt einer Betrachtung. Schließlich weisen die Autoren des Scrum Guides darauf hin, dass ihr Framework auch bei anderen Arten von Projekten (also nicht nur in Software-Entwicklungsprojekten) angewendet wird. Rein logisch muss insofern der Schluss gezogen werden, dass "Developers" auch andere fachliche Domänen, wie z. B. Business Analysts (auch als Requirements Engineers bezeichnet), Architekten oder fachliche und technische Tester umfasst. Die Notwendigkeit zur Besetzung der letztgenannten Bereiche in Projekten wird heutzutage kaum bestritten.
In der Betrachtung von Projektrollen hat es Sinn, zwischen formal steuernden und fachlich ausgerichteten Funktionen zu unterscheiden:
Formal steuernde Rollen:
Fachlich ausgerichtete Rollen:
Es fragt sich, wenn wir nun all diese Rollen in einem Projekt haben: Wie passen diese alle zusammen? Oder, anders gefragt: Besteht nicht das Risiko, dass sich bestimmte Funktionen im Projekt in die Quere kommen? Und schließlich: Wer kann bzw. soll verantwortlich gemacht werden, wenn der Projektfortschritt und die Erfüllung des fachlichen Scopes (oder erreichter Business Values) den Kosten und der Zeit hinterherlaufen? In einem solchen Projekt ist es sinnvoll, folgende Fragen zu stellen:
Projektleiter, Scrum Master, Product Owner und Entwickler: Darauf beschränkt es sich allerdings nicht in der heutigen Projektwelt. Die Vielseitigkeit der Aufgaben (und damit der Rollen) werden im Folgenden näher erläutert.
Blicken wir einmal auf heute im Projektalltag existierende Rollen mit Ihren Aufgaben.
Ob klassisch, agil oder hybrid: Wichtige in heutigen Projekten vorzufindende Rollen sind im Folgenden dargestellt. Diese zeichnen sich durch spezifische Verantwortlichkeiten und Aufgaben im Projektalltag aus.
Diese grundsätzlichen Rollenbeschreibungen gelten für jede Größe von Projekt. Aber wie sieht es nun in wirklich größeren Kontexten aus? Wie es bei einer Skalierung nach dem Framework "SAFe"?
Vor allem größere Organisationen stehen vor der Herausforderung, dass sich agile Frameworks wie Scrum auf einzelne Projekte und Teams mit bis zu neun Entwicklern beziehen. Für große Vorhaben mit vielen Teammitgliedern ist das keine Lösung. Durch die gesteigerte Anzahl an Mitgliedern in größeren Projekten steigt auch die Anzahl der Abhängigkeiten untereinander und folglich die Komplexität.
Eben für diese Problemstellung bieten skalierte Frameworks einen Lösungsansatz, um Scrum als Methode auch im großen Rahmen und für eine große Anzahl von Produktteams einzusetzen. Dabei können Unternehmen auf verschiedene Skalierungsframeworks zurückgreifen. Diese Frameworks sind in der Regel auf Basis von Scrum oder weiteren agilen Methoden entwickelt worden. Die wichtigsten und in der Praxis geläufigsten Frameworks sind Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) und Nexus. Innerhalb dieser Frameworks kommen weitere bedeutsame Projektrollen ins Spiel.
Kommen wir in diesem Zusammenhang auf die erste zusätzliche Rolle: der sogenannte Release Train Engineer (RTE) bzw. der Chief Product Owner in SAFe.
In einer Scaled-Agile-Umgebung mit ihren diversen Teams, die alle von Scrum Mastern unterstützt werden, kann man den Release Train Engineer als "Super Scrum Master" oder "Chief Scrum Master" bezeichnen: Er ist sozusagen der oberste Scrum Master, mit dem alle Scrum Master der einzelnen Teams zusammenarbeiten und der Hindernisse auf einer größeren, allgemeinen Projektebene (auf dieser Ebene auch als "Programm" bezeichnet) aus dem Weg räumen kann. Ähnlich dem "normalen" Scrum Master sind seine Aufgaben auf die Steigerung der Reife des Teams im Gebrauch von Scrum sowie der Produktivität gerichtet. Mittel der Umsetzung sind im Schwerpunkt Moderation und Coaching.
Darüber hinaus fungiert der RTE als Coach für das gesamte Programm und als Moderator für die meisten Abläufe und Veranstaltungen, die zu SAFe gehören. Im skalierten Scrum gibt es noch weitere Events als die herkömmlichen Scrum Events, was sicherlich auch den Overhead steigert.
Aber nicht nur die Scrum Master erhalten einen obersten Chef, sondern auch die Product Owner durch den Chief Product Owner: An einem gewissen Punkt in einem wachsenden Projekt kann es Sinn haben, eine Hierarchie von zusammenarbeitenden Product Ownern einzuführen. Die folgende Grafik (Bild 1) zeigt beispielhaft eine solche Hierarchie, bei der jeweils ein Product Owner pro Team zur Verfügung steht, zwei Product Line Owner jeweils für eine Gruppierung von Teams sowie ein Chief Product Owner. Der Chief Product Owner (kurz: CPO) verwaltet Anforderungen auf der obersten Ebene (strategisch) und bricht diese (häufig EPICS genannt) auf untergeordnete Ebenen herunter.
Eingangs erwähnte ich die m.E. in der Praxis unterschätzte inhaltliche Differenzierung der Rolle "Entwickler" in Scrum. Mit Blick auf heute angewendete Projektorganisationen finden wir (wie bereits angesprochen) Rollen wie Business Analysts, fachliche Tester und technische Tester. Aber über eine Funktion mit führendem Charakter haben wir noch nicht gesprochen. Denn typischerweise werden in Software-Entwicklungsprojekten sogenannte Software-Architekten eingesetzt.
Auch in diesem Fall sprechen wir zwar nicht von einer Scrum-Rolle, aber dennoch von einer höchstrelevanten Rolle, v.a. in größeren Projekten. Auch wenn der Architekt formal den Entwicklern gleichgestellt ist, trifft er doch grundlegende Designentscheidungen. Durch den Rückkopplungsprozess des Software-Architekturentwurfs wirken jedoch auch die Entwickler maßgeblich an der Architektur mit. Der Architekt trifft dabei globale Entscheidungen, lernt als Mitglied des Entwicklungsteams – zu dem er ja gehört – welches Design daraus auf tieferer Ebene entsteht und überprüft kontinuierlich, ob die Auswirkungen im Einklang mit den funktionalen und qualitativen Anforderungen des Kunden sind.
Der Architekt ist in der Rolle eines Kommunikators im Team. Er sollte mit einem technischen Fokus in der Lage sein, zwischen Entwicklern, Product Owner, Managern und anderen Interessengruppen zu vermitteln. Er kommuniziert die Architektur zwar schriftlich, aber auch im Projektalltag persönlich, ganz im Sinne des sechsten agilen Prinzips: "Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht." Sprint Planning und Sprint Review sind die Events in Scrum, um mit dem Entwicklungsteam über die Systemarchitektur zu diskutieren und sich auf ein gemeinsames Vorgehen zu verständigen.
Die Verbindung von fachlichen und technischen Aspekten mit Sozialkompetenz und Kommunikationsfähigkeiten stellt hohe Anforderungen an den Architekten. Bei unterschiedlichen Auffassungen im Entwicklungsteam, die etwa während des Sprint Plannings entstehen, ist es Aufgabe des Architekten, die Entscheidungsfindung in technischer Hinsicht zu unterstützen oder auch: letztlich zu entscheiden. Gerade bei verteilten Teams gibt es in der Regel mit dem Chefarchitekten eine Instanz, die notwendig für Richtungsgebung ist.
Der Product Owner vertritt die Produktvision, der Architekt vertritt technische Prinzipien.
Der Architekt im agilen Umfeld arbeitet deutlich technik- und entwicklungsnaher als der Product Owner – was aber nicht heißt, dass der Product Owner nicht zumindest über ausreichend technisches Wissen verfügen sollte, das er benötigt, um die Auswirkungen von Kundenanforderungen grob einschätzen zu können.
Trotz aller Zusammenarbeit und Gleichwertigkeit der Kompetenzen sollte zwischen Product Owner und Architekt ein konstruktives Spannungsverhältnis bestehen: Der Product Owner hat vor allem auf die Nutzenmaximierung zu achten, d.h. auf die Wertigkeit der Features, die im Sprint umgesetzt werden, der Architekt hingegen hat Qualitätsaspekte des auszuliefernden Produkts im Fokus. Erfahrungsgemäß ist dieser Gegensatz Ursache zahlreicher Diskussionen, sobald im Projektverlauf der Terminplan eng oder das Budget knapp wird.
Ohne diese Führungsrolle – die der Chef-Architekt in meinen Augen eindeutig hat – sind in heutigen Projekten Business Analysten für die Aufgaben der Architekten zuständig. Auch bei Business Analysten handelt es sich um keine Scrum-Rolle. Ein Business Analyst wird auch Requirements Engineer genannt und sorgt für die Richtigkeit und Vollständigkeit der Anforderungen.
Bei agilen Vorgehensmodellen steht die kontinuierliche Zusammenarbeit mit den (internen und externen) Kunden im Vordergrund. Herr über Anforderungen in einem agilen Projekt ist (wie gesehen) der Product Owner. Business Analysten hingegen können den Entwicklern auf einem genauer spezifizierten Grad diese Anforderungen in der geeigneten Detaillierung zur Verfügung stellen, damit diese das richtige Produkt entwickeln. Im Gegensatz zu langen Anforderungsdokumenten, z.B. bei Wasserfall-Vorgehensmodellen, werden tendenziell (aber nicht nur) eher "schlanke" Anforderungen z.B. in Form von User Storys geschrieben. Auch stellen Business Analysten die Anforderungen in jeder Iteration zur Verfügung und sammeln nicht zu Beginn des Projekts (möglichst) alle komplett spezifiziert Anforderungen ein. Business Analysten haben (ähnlich dem Architekten in der technischen Domäne) einen Überblick über die fachlichen Gesamtzusammenhänge (Zusammenspiel der Anforderungen) und sind ab einer gewissen Projektgröße und -komplexität in heutigen Projekten nicht mehr verzichtbar.
Kommunikation, Verhandlung und Moderation spielen dabei im agilen Umfeld eine große Rolle. Part des Business Analysten kann es sein, darauf hinzuwirken, dass die beteiligten Personen "eine Sprache sprechen". Dies kann z.B. durch ein formales (Projekt-)Glossar unterstützt werden, das der Business Analyst pflegt.
Support bei der fachlichen Ausarbeitung von Schnittstellen
Unterstützung des Product Owners
Beitrag zur Verbesserung der Produktqualität
Vor allem das Testen ist für die Produktqualität wichtig. Für dies ist eine weitere Rolle in Projekten verantwortlich: Tester in Scrum Teams. Die Rolle der Tester lässt sich strukturieren in:
Wie passen diese genannten Rollen nun eigentlich zusammen? Das sogenannte Kongruenzprinzip der Organisationslehre besagt, dass die Verantwortung für eine Aufgabe untrennbar mit den dafür erforderlichen Befugnissen verbunden sein sollte. Betrachten wir die oben skizzierten Rollen, stellt man fest:
Dies hat Konsequenzen. Ist das Projekt erst einmal in einer Schieflage, lässt sich schwer analysieren, was die Ursache ist. Folgende Ursachen sind möglich:
Sagen wir es direkt: wer trägt die Verantwortung? Wir haben ja gesehen: Viele Rollen haben Einfluss auf den Gesamterfolg eines Projekts, gerade auch Rollen mit Führungscharakter. Insofern ist es umso schwerer, in kritischen Situationen nun die endscheidende Stelle auszumachen.
In einem realen Projekt, in dem ich selbst als Business Analyst mitwirkte, existierten die nachfolgend aufgeführten Rollen. Es handelte sich hierbei um ein Software-Entwicklungsprojekt orientiert an SAFe. Projektgegenstand war der Bau eines Kundenportals im Bereich Wirtschaftsauskunftei Es handelte sich prinzipiell um ein internes Projekt, das mit beträchtlicher externer Unterstützung durchgeführt wurde. Gesamtprojektleiter und Scrum Master waren hierbei extern. Nun zu den Rollen:
Besagtes Projekt geriet "gefühlt" – und das drückt an sich schon ein Problem aus – in eine Schieflage. Diese empfundene Schieflage bestand in der aus Auftraggebersicht in der zu späten Fertigstellung des Produkts, obwohl der Zieltermin vorab willkürlich gesetzt war. Zudem beruhte die Setzung des Zieltermins nicht auf einer Aufwandsschätzung durch Experten. Vielmehr wurde die vorhandene Aufwandsschätzung ignoriert.
Aus heutiger Sicht sehe ich folgende Probleme:
Letzter Punkt spricht einen Aspekt an, der nicht zu vernachlässigen ist, wenn es um (vermeintlich) agile Projektumsetzung geht, es stellen sich aus meiner Sicht folgende Fragen für einen Auftraggeber:
Wenn Projekte initiiert werden, ist in der Regel wenig strittig, welche Rollen (und Qualifikationen) zur Erreichung der Projektziele notwendig sind. Mit der Erstellung eines Projekt-Organigramms (Übersicht über die Projektorganisation) ist der Umstand scheinbar schnell berücksichtigt. Scheinbar. Die genaue Definition und Abgrenzungen von Verantwortung im Detail jedoch ist umso empfehlenswerter, je mehr Rollen in einem Projekt unterscheiden werden (müssen). Ich empfehle folgendes:
Auch in der heutigen, "agilen" Welt ist u. a. der Projektleiter (immer noch) nicht verschwunden. Aber auch sonst wirken mehr Rollen auf den Projekterfolg ein als z.B. die reinen "Entwickler" in Scrum. Allerdings liegen Aufgaben wie Scope -Management und Steigerung der Team-Performance in der agilen Welt nicht mehr in der primären Verantwortung des Projektleiters. Für die Team-Performance gibt es mit dem Scrum Master einen Spezialisten. Die Fachlichkeit ist in der Domäne des Product Owners verankert und es gibt als technisches Pendant die Architektenrolle, jedoch in verschiedenen Ausprägungen: Chef-Architekt, Software-Architekt oder schlicht IT-Architekt.
Klare Kompetenz- und Verantwortlichkeitsabgrenzung ist wichtig, um zu vermeiden, dass sich die Rolleninhaber in der Entscheidungsfindung in die Quere kommen, und um eine unnötige "Verkopfung" eines Projekts zu vermeiden. Dies wäre der Fall, wenn z.B. viele entscheiden, aber keiner mehr praktisch Entscheidungen umsetzt. Gerade diese Umsetzer sind jedoch wichtig: Während der Scrum Guide nur "Developers" kennt, gibt es in der Praxis oft Business Analysts und (eher noch häufiger) Tester in Projektteams. Business Analysten müssen den Product Owner beim Anforderungsmanagement unterstützen und somit entlasten. Zusätzlich haben sie mit Entwicklern und Testern ihre Abnehmer bzw. Kunden und sind damit eine klare Stellschraube zur Effizienz im Projekt.