Klassische und agile Projektrollen im agilen Umfeld Sorgen Sie für Durchblick im agilen Rollendschungel!

Sorgen Sie für Durchblick im agilen Rollendschungel!

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.

Management Summary

Download PDFDownload PDF

Klassische und agile Projektrollen im agilen Umfeld Sorgen Sie für Durchblick im agilen Rollendschungel!

Sorgen Sie für Durchblick im agilen Rollendschungel!

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.

Management Summary

Wir empfehlen zum Thema Scrum
1 Tag
26.06.2024
795,00,-
So gelingen Veränderungen unter hoher Auslastung

In diesem Workshop betrachten wir verschiedene Wege, wie Unternehmen Veränderungen unter Vollauslastung des Systems erfolgreich einleiten und umsetzen können. Mehr Infos

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. 

Wie sind Rollen grundsätzlich zu unterscheiden? 

In der Betrachtung von Projektrollen hat es Sinn, zwischen formal steuernden und fachlich ausgerichteten Funktionen zu unterscheiden:

Formal steuernde Rollen: 

  • Der (klassische) Projektleiter, der Zeit, Kosten und Qualität im Blick hat
  • Der Scrum Master, der die Steigerung der Teamperformance und das Coaching in Bezug auf Scrum-Prinzipien als Aufgabe hat

Fachlich ausgerichtete Rollen:

  • Der Product Owner
  • Fachliche Tester
  • Alle Arten von Entwicklern (Developers) im oben beschriebenen Sinne

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: 

  • Frage an den Scrum Master: Erwerben die agilen Teams zu wenig Maturity, d.h. Grundverständnis über die Scrum-Methoden, und entwickelt sich die Velocity (d.h. Geschwindigkeit, mit der ein Team seine Ziele erreicht) in die falsche Richtung?
  • Frage an den Product Owner: Werden die Backlog Items nicht adäquat priorisiert oder die Storys nicht hinreichend präzise formuliert oder sinnvoll heruntergebrochen?
  • Frage an den Projektleiter: Hat er seine Metriken zur Steuerung des Gesamtprojekts im Griff? Hat er die Steuerungsmittel (auch in Abgrenzung zum Product Owner und Scrum Master), um das Projektziel zum Erfolg führen zu können? Hat er einen geeigneten Modus gefunden (auch in Abgrenzung zum Product Owner und Scrum Master), in dem er im Sinne der Steuerung wertstiftenden Einfluss auf die Erreichung der Projektziele ausüben kann?

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.

Welche (traditionellen) Rollen gibt es in agilen Projekten?

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.

Das könnte Sie auch interessieren

Vorschaubild

Gute Teamarbeit klappt nur bei klar formulierten Rollen und festgelegten Aufgaben. Ein initialer Workshop zur Rollenklärung gibt dem Projektteam eine gute Grundlage. Zudem gibt es sechs weitere Anlässe, an denen Rollenklärung sich lohnt.

Vorschaubild

Teammitglieder, die andere in Diskussionen ausbremsen oder Führungskräfte, die ohne Absprache im Team getroffene Entscheidungen kippen, üben Macht aus. Aber auch weniger offensichtliche Machtfaktoren, wie z.B.

Vorschaubild
Definieren Sie eindeutige Verantwortlichkeiten im Projekt einprägsam und klar verständlich! Geben Sie allen Stakeholdern einen schnellen Überblick, wer für was zuständig ist!

Agilität = Chaos = der Albtraum jedes Qualitätsexperten – so lautet ein weit verbreitetes Vorurteil.

t_kollaboration.jpg

Ad hoc, bereichsübergreifend und quer zur Hierarchie: Als flexible und schnelle Form der Zusammenarbeit erlaubt Kollaboration, komplexe Fragestellungen mit hoher Geschwindigkeit zu lösen.

Alle Kommentare (2)

Dieter
Bertsch

Liegen die Probleme, die der Artikel anspricht, nicht eher im „Verständnis-Dschungel“ als bei den Rollen?

Developer Verantwortlichkeit
Obwohl das Problem „was bedeutet Developer“ thematisiert wurde, wird im Artikel von den „klassischen Rollen“ wie z.B. Business Analysten gesprochen. Hier wird die Idee von Scrum, die „Reduktion der sozialen Komplexität“, nicht wirklich berücksichtigt: Scrum kennt nur drei Rollen; eine davon ist der Entwickler („Developer“), von der es zwischen 6 +/- 2 im Team gibt. Die Skills jedoch, die diese Developer als multifunktionales Team benötigen, sind sehr vielseitig. Da benötige es UX-Know How, Leute mit Skill in Busines Analyse, Software-Entwickler, techn. wie fachl. Tester und heute üblicherweise auch Leute, die als DevOp tätig sind. (Warum wird der „fachl. Tester“ extra genannt und sollte er kein Developer sein?)
Ein Entwickler (und hier bitte nicht „SW-Entwickler“ assoziieren!) kann viele Skills abdecken.
Wenn aber weiterhin jeder Skill der benötigt wird, als Rolle angesehen wird; und dann – so wie ich das in vielen Firmen sehe – eine Rolle eine 1:1-Beziehung zu einer Person darstellt, wundert es mich nicht, dass viele Teams
- zu groß sind („Wir brauchen doch jede Rolle und die muss doch wegen Ausfallsicherheit mehrfach besetzt sein…“)
- durch „klare Verantwortlichkeiten“ der Rollen sich schwertun, voneinander zu lernen und ein Team zu werden
- weiter als Gruppe von Experten mit vielen Schnittstellen & Übergaben nebeneinander her arbeiten
1. Fazit:
Klassisch – viele dedizierte Rollen für die Umsetzung der Projektinhalte
Scrum – eine Rolle für die Umsetzung der Projektinhalte (und nicht mehr!). Aufgabenfokus & Ergebnisverantwortung liegen bei den Developern.

PO-/SM-Verantwortlichkeit
„Reduktion der sozialen Komplexität“ findet bei Scrum auch bei den Rollen Product Owner & ScrumMaster statt. Der PO ist der „Unternehmer“ der durch seine Arbeit (Stakeholder Management, Priorisierung nach Busines-Wert, Backlog-Refinement) dafür sorgt, aus den zur Verfügung stehenden Budget den größten Nutzen zu generieren. Was soll da ein klassischer PL an „formaler Steuerung“ noch für Tätigkeiten haben. Projektfokus bzw. besser Produkt-Fokus, klarer Projektauftrag bzw. besser die Produkt Vision & die Schnittstelle zwischen Auftraggeber, den Fachbereichen und dem Projektteam sind Verantwortungen des PO. Das würde ja zu Doppelarbeiten führen und ggf. Widersprüche hervorrufen, hierfür einen PL einzusetzen. Auch würden Komplexität und unnötige Kosten erzeugen.
Und der ScrumMaster sorgt für den reibungslosen Ablauf der Prozesse; insb. für die Beseitigung von Hindernissen (Entfernung aller Motivationshemmer). So können die Developer im Flow („Schaffensrausch“) arbeiten. Auch hier: Was soll der PL noch beitragen?
2. Fazit:
Der Interessenskonflikt aus dem „Drama-Dreieck“, Time – Function – Budget einhalten zu müssen, und dazu noch „die Entwickler bei der Stange zu halten“, mit dem der klassische PL zu kämpfen hat, wird durch das Duo PO & SM aufgelöst.

Projekt- vs. Produktmanagement
Der 3. Fehler, der m.E. in der leichtfertigen Verwendung von Begrifflichkeiten liegt, ist der Begriff Projektmanagement im Agilen Kontext. Agiles Vorgehen und insb. Scrum fokussieren auf die Produktentwicklung
– iterativ, inkrementell in kurzen Zyklen mit langlebigen stabilen Teams. Kein „Big Bang“! Kein neues Team für jedes Projekt!
Umsetzungserfolg bei Agile (Nutzen für den Kunden) vs. Abwicklungserfolg bei klassischem PM (Einhaltung von Time & Budget).
3. Fazit:
Wenn man Agiles Vorgehen in den Rahmenbedingungen des klassischen PM und deren Instrumenten betreibt, verwundert es mich nicht, dass Agiles Vorgehen nicht wirklich seine Potenziale entfaltet.
Metapher: Wenn ich Autos (agile Vorgehen) auf Schienen (klassisches Vorgehen) fahren lasse, brauche ich mich nicht wundern, dass die Flexibilität des Individualverkehrs verloren geht… (Und dann hat jedes Auto noch einen Lockführer zusätzlich mit an Bord.)

Betrachtung der aufgeführten Gefahren, die durch falsche Implementierung Agiler Methoden entstehen
• „Der für die Team-Performance zuständige Scrum Master hat keine Ergebnisverantwortung und auch keinen Stakeholder-Kontakt.“
=> Gut und genau richtig so!
Um bei meiner Metapher zu bleiben: Das wäre ja sonst so, als ob das Öl im Motor für das Ziel und die Wegstrecke verantwortlich wäre…
• „Der für die Wertmaximierung zuständige Product Owner hat keinen Einfluss auf die Team-Performance (d.h. auf die Aufgabe des Scrum Masters).“
=> Auch hier: Gut und genau richtig so!
Als Fahrer meines Autos, der das Ziel bestimmt, habe ich doch keinen Einfluss auf die Leistung des Motors. Dafür habe ich Mechaniker in der Werkstätte meines Vertrauens.
• „Der Projektleiter hat weder Einfluss auf das Produkt noch auf die Team-Performance, muss aber die Budgets (und irgendwie auch das Ergebnis) verantworten.“
=> Ja & nein!
Er hat keinen Einfluss auf das Produkt: Ja! Das macht auch der PO.
Er hat keinen Einfluss auf die Team-Performance: Ja! Das macht der SM.
Er muss das Budget verantworten: Nein! Das macht der Unternehmer, der PO.

4. Fazit:
In Scrum ist die Rolle des PL obsolet!
Kaum macht man Scrum „by the Book“, hat man kein Rollendschungel …

Leider haben Sie schon die Einleitung (und darauf fußt die Argumentation des Artikels) nicht richtig gelesen. Es geht darum, heutige Projektwirklichkeiten kritisch zu bewerten. Natürlich stellen sich diese Themen so nicht bei "Kaum macht man Scrum „by the Book“, hat man kein Rollendschungel …". Die Realität läuft eben selten "by the Book". Nicht mehr und nicht weniger wollte ich ausdrücken und das haben erfahrene Berater, mit denen ich diesen Inhalt geteilt und diskutiert habe, ansonsten alle verstanden. Lesen Sie noch mal nach.