Der Erfolg eines Projektes hängt in großen Teilen vom idealen Zusammenspiel aller Beteiligten ab. Um so wichtiger, dass jeder Stakeholder seine Rolle im Projekt kennt.

Ziel von SCRUM ist es die Komplexität des Projektmanagements zu reduzieren und gleichzeitig die Flexibilität zu erhöhen. Neben minimalen Regeln gehören hierzu wenige Artefakte und im klassischem Sinne drei SCRUM-Rollen.

Doch warum braucht es in der Praxis weitere SCRUM-Rollen?

Für mich hat sich in der Praxis herausgestellt, dass mit Hilfe von drei weiteren SCRUM-Rollen der Nutzen dieser Methode, insbesondere für Unternehmen, die aus dem klassischen Projektmanagement kommen, erhöht werden kann. Nachfolgend möchte ich dir diese Projektrollen in SCRUM vorstellen. Los geht es mit den klassischen SCRUM-Rollen.

Scrum Master: Alias der Change Agent

Jedes Team hat einen Scrum Master. Er dient dem Team. Als Coach und Change Agent hilft der Scrum Master allen Beteiligten ihre SCRUM-Rollen zu verstehen und richtig auszuüben. Dies macht er, indem er daran arbeitet Schwierigkeiten, Blockaden und Probleme zu lösen. Dabei hat der Scrum Master keine Weisungsbefugnis.

Durch die Aufgabe die Zusammenarbeit zu fördern und gleichzeitig alte Prozesse zu hinterfragen sowie neue Verhaltensweisen zu etablieren, wird der Scrum Master oft als Unruhestifter und Querulant gesehen. Dabei ist es sein Ziel, selbst schnellstmöglich überflüssig zu werden. Boris Gloger bringt es auf den Punkt:

Product Owner: Alias der Visionär

Der Product Owner vertritt die Kundenbedürfnisse im Projekt. Somit stellt er die Brücke zwischen Endkunden und Entwicklungsteam dar.

Dafür plant und lenkt er die Produktentwicklung, indem er die gewünschten Funktionalitäten in der richtigen Reihenfolge priorisiert (Product Backlog). Hierfür detailliert er kontinuierlich die Anforderungen (Backlog Items). In enger Abstimmung mit dem Entwicklungsteam arbeitet der Product Owner zudem an der Releaseplanung.

Gleichzeitig ist er für die Kostenverfolgung und das Stakeholder-Management verantwortlich. Somit vereint er Produkt- und Projektmanagementaufgaben.

Entwicklungsteam: Alias die Lieferanten

Das Scrum-Team ist gemeinschaftlich für die regelmäßige Auslieferung von einsetzbaren Produktinkrementen verantwortlich. Dabei organisiert es sich eigenständig. Entscheidungen werden im Konsens getroffen.

Dies inkludiert die Freiheit, alles Zielführende im Rahmen der vorgegebenen Prozesse zu tun, um die Akzeptanzkriterien (Definition of Done) zu erfüllen. Dadurch, dass das Entwicklungsteam seine Arbeitsmenge selbst bestimmt, trägt es die Verantwortung für die pünktliche Auslieferung.

Kunde: Alias der Auftraggeber

Ob intern oder extern: Der Kunde erteilt den Auftrag zur Entwicklung und finanziert das Projekt. Im ursprünglichen Modell von SCRUM gibt es diese Rolle nicht. Sie wird im Product Owner vereint. Wieso dann diese Unterteilung?

Genau wie auch von Gloger beschrieben, konnte ich in der Praxis beobachten, dass ein Product Owner solange Anforderungen nach ihrem maximalen Nutzen priorisieren kann, solange er Marktkenntnis hat: Sprich, sich in die Rolle des Nutzers und seiner Bedürfnisse versetzen kann.

Dies funktioniert i. d. R. mit unternehmensinternen Anforderungen gut. Kommt der Projektauftrag jedoch von außerhalb, können diese Kenntnisse fehlen. Wie soll ein Product Owner in dieser Situation nun den Nutzen maximieren? An dieser Stelle kann ihm nur der Auftraggeber bzw. der Nutzer Informationen liefern.

Ähnlich lagert sich der Fall bei Organisationen, die z. B. mit einem Projektmanagement Office (PMO), welches die strategische Projektauswahl trifft, arbeitet. Sie beauftragen den Product Owner mit der Realisation, überlassen ihm aber nicht die Budgetverantwortung. Alternativ wäre auch ein Vorgesetzter mit Budgetverantwortung denkbar, welche nicht an den Product Owner übergeben wird. In beiden Fällen würde ich empfehlen die klassische Scrum Rolle des Product Owners zu trennen.

Stellt ein Unternehmen seine Projektmanagementmethode vom klassischen Projektmanagement auf SCRUM um, so besteht ein weiterer Vorteil in der Einführung dieser Rolle. Durch den Wegfall von Hierarchien fühlt sich das Management in seiner Verantwortung häufig beschnitten. Sie versuchen nun ihren Platz in einer der drei klassischen SCRUM-Rollen zu finden.

So konnte ich häufig beobachten, dass Abteilungsleiter/-innen die Rolle des Product Owners übernehmen wollten, Bereichs- oder Geschäftsleitungen die des Scrum Masters. Den eigentlichen Job der Rolle verrichteten jedoch ihre jeweiligen Teammitglieder. Dies widerspricht massiv dem Prinzip von SCRUM.

Als Kunde ist somit eine adäquate Rolle, zumindest für die direkten Vorgesetzten, gefunden. Keine Sorge, auch das restliche Management wird nach Einführung von SCRUM, in Bezug auf die Projektarbeit, nicht arbeitslos sein (siehe Rolle Management).

Management: Alias die Durchsetzer

SCRUM schafft das Management ab. Denn Product Owner, Team und Scrum Master realisieren autark ihre Projekte – dies ist die unbegründete Sorge vieler Manager. Sicherlich, der Aufgabenschwerpunkt verändert sich, aber die Rolle an sich ist unverzichtbar.

Statt Anweisungen zu geben, unterstützt der Manager in SCRUM als Führungskraft. Dies beinhaltet z. B. die aktive Gestaltung des Wandels der Unternehmenskultur, die Einführung von Prozessen und Richtlinien genauso wie die Sicherstellung der Qualifizierung der Mitarbeiter oder die strategische Ausrichtung des Unternehmens.

Passen die Rahmenbedingungen nicht, so wird die Unterstützung des Managements benötigt. Ob Räume, Arbeitsmittel, Prozesse – das Management ist der Ansprechpartner für den Scrum Master.

Im Gegensatz zum Scrum Master ist dieses mit der Macht ausgestattet Dinge anzupacken, zu verändern und damit zu lösen. Somit ermöglicht das Management dem Team, so effizient und professionell wie irgend möglich Projekte zu realisieren.

Auch wenn diese Rolle das klassische SCRUM nicht vorsieht: Aus der Praxis kommend stellt diese Rolle für mich einen weiteren unverzichtbaren Bestandteil eines praxisorientierten SCRUM-Projektmanagements dar.

Du willst mehr zur Projektmethode SCRUM erfahren? In meinem Blogbeitrag „SCRUM – die Macht des Agilen“ gehe ich auf die Grundlagen ein.

Impressum | Datenschutz