Close
  • Start
  • AGIL
    • Agiles Projektmanagement
    • Scrum Zertifizierungen
  • SOFT
    • SOFT Skills nach iSAQB
    • Agil Führen
  • KI
    • Prompt Engineering
    • KI Strategie
  • About
  • Kontakt
  • Übersicht
  • Einstieg
    • Simulation
    • Wozu APM
    • Klassisch vs. Agil
    • Agile Werte
  • Prozess
    • Inkrement
    • Iterationen
    • Review
    • Retrospektive
    • Agiles Nachsteuern
  • Prinzipien
    • Einfachheit
    • Time Boxing
    • Selbstorganisierte Teams
  • Anforderungen
    • User Stories
    • User Stories vs. Tasks
    • Business Value
    • Persona
  • Kontrolle
    • Task Board
    • Story Points
    • Planning Poker
    • Burn Down Chart
    • Daily Stand-up
  • Scrum
    • Ursprung
    • Prozess
    • Rollen
    • Scrum-But
  • Abschluss
    • PM-Dreieck
    • Agil Skalieren
    • Klassisch&Agil
Übersicht
  • Übersicht
  • Einstieg
    • Simulation
    • Wozu APM
    • Klassisch vs. Agil
    • Agile Werte
  • Prozess
    • Inkrement
    • Iterationen
    • Review
    • Retrospektive
    • Agiles Nachsteuern
  • Prinzipien
    • Einfachheit
    • Time Boxing
    • Selbstorganisierte Teams
  • Anforderungen
    • User Stories
    • User Stories vs. Tasks
    • Business Value
    • Persona
  • Kontrolle
    • Task Board
    • Story Points
    • Planning Poker
    • Burn Down Chart
    • Daily Stand-up
  • Scrum
    • Ursprung
    • Prozess
    • Rollen
    • Scrum-But
  • Abschluss
    • PM-Dreieck
    • Agil Skalieren
    • Klassisch&Agil
Übersicht

E-Learning: Scrum Rollen

Scrum gibt drei Rollen für das Team vor, nämlich

  1. einen Scrum Master,
  2. einen Product Owner und
  3. die Developers.

Um Rollenkonflikte zu vermeiden, sollten der Scrum Master und der Product Owner nicht ein und dieselbe Person sein, auch wenn Scrum das so nicht explizit festlegt. Zwischen diesen Rollen kann es jedoch leicht zu einem Interessenskonflikt kommen, da der Scrum Master z. B. für ein striktes Einhalten von Prozessen steht und der Produkt Owner z. B. für die Umsetzung möglichst vieler Kundenwünsche. Ansonsten sind Doppelrollen bei Scrum möglich und auch gängige Praxis.

Der Scrum Master

Scrum legt fest, dass es in einem Scrum Team genau einen Scrum Master gibt. Er ist dafür verantwortlich, dass die Regeln des Scrum Prozesses eingehalten werden. Zudem unterstützt er alle wichtigen Stakeholder dabei, die Auswirkungen dieses Prozesses auf ihre Arbeit zu verstehen. Wenn jemand rund um ein Scrum Team unsicher ist, wie er nun, da mit dieser Methode gearbeitet wird, eine Aufgabe zu erledigen hat, so ist der Scrum Master der richtige Ansprechpartner, um ihm Sicherheit in dieser Frage zu geben.

In der offiziellen Beschreibung des Scrum Prozesses werden die Verantwortlichkeiten eines Scrum Masters genau aufgelistet. Wichtige Aufgaben eines Scrum Masters sind unter anderem:

  • Verständnis schaffen für die Notwendigkeit klarer, prägnanter Product-Backlog-Einträge im Scrum Team
  • Vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung
  • Coachen des Entwicklungsteams hin zu Selbstorganisation und funktionsübergreifender Teamarbeit
  • Beseitigen von Hindernissen, die das Entwicklungsteam aufhalten
  • Leiten und Coachen der Organisation bei der Einführung von Scrum
  • Möglichkeiten zur Produktivitätssteigerung des Teams identifizieren

Der Product Owner

In jedem Scrum Team gibt es genau einen Product Owner. Er muss nah an den Stakeholdern sein und deren Anforderungen kennen, denn er ist dafür verantwortlich, dass das Team alles an Wissen über das Produkt erhält, das es für die Entwicklung benötigt. Dazu muss er für die Entwickler auch kurzfristig erreichbar sein, wenn sie Klärungsbedarf zu den Produktanforderungen haben.

Damit der Product Owner seine Aufgabe erfolgreich erledigen kann, müssen die Entwickler und die gesamte Organisation seine Entscheidungen zu den Produktanforderungen respektieren.

Der Product Owner ist in einem Scrum Prozess insbesondere für das Product Backlog verantwortlich, in dem die Anforderungen an das Produkt stehen. In der offiziellen Beschreibung des Scrum Prozesses werden seine Verantwortlichkeiten für das Product Backlog genauer aufgelistet. Die wichtigsten Aufgaben lauten:

  • Sicherstellen, dass das Entwicklungsteam die Product-Backlog-Einträge im nötigen Maße versteht
  • Die Einträge im Product Backlog so sortieren, dass Ziele optimal erreicht werden können
  • Sicherstellen, dass das Product Backlog für alle sichtbar und verständlich ist und dass Klarheit darüber besteht, woran das Scrum Team als Nächstes arbeiten wird

In vielen Firmen gibt es die Rolle eines Produktmanagers, die in Bezug auf das Fachwissen mit der eines Product Owners vergleichbar ist.

Die Developers

Die Rolle der »Developers« entspricht der gängigen Rolle der Entwickler, die die Anforderungen umsetzen, bis ein fertiges Produkt vorliegt. Bei Scrum haben die Entwickler mehr Verantwortung für die eigenen Aufgaben und für den Gesamtprozess als in einem klassischen Prozess: Sie bestimmen mit, an welcher Aufgabe sie als Nächstes arbeiten und sind auch dafür verantwortlich, dass diese im Verhältnis zu den aktuellen Aufgaben der anderen Entwickler sinnvoll ist. Dies bedeutet z. B., dass sie selbstständig Abhängigkeiten zwischen den Aufgaben berücksichtigen. Im klassischen Projektmanagement wäre es der Projektleiter, der eine solche Reihenfolge in einem Sequenzdiagramm festlegt.

Ein wesentliches Merkmal des Developer Teams bei Scrum ist also die Selbstorganisation. Das Team übernimmt hier deutlich mehr Verantwortung für den Gesamtprozess als im klassischen Projektmanagement. Scrum gibt strenge Regeln vor, die die Autonomie des Teams schützen. Zwei wichtige Regeln sind:

  1. Die Entwickler arbeiten ausschließlich nach den fachlichen Angaben des Product Owners.
  2. Die Entwickler dürfen nicht von außerhalb des Scrum Prozesses zusätzliche Aufgaben bekommen.

In der offiziellen Beschreibung des Scrum Prozesses werden verschiedene Grundsätze für das Developer Team festgelegt. Im Folgenden sind einige wichtige daraus zusammengefasst.

  • Niemand (nicht einmal der Scrum Master) schreibt den Developern vor, wie es aus dem Product Backlog das Produkt entwickelt.
  • Scrum kennt keine weiteren Unterteilungen innerhalb des Entwicklungsteams, ungeachtet von bestimmten fachlichen Spezialisierungen, wie »Test« oder »Analyse«. Es gibt keine Ausnahmen von dieser Regel.
  • Einzelne Mitglieder des Entwicklungsteams können zwar spezialisierte Fähigkeiten oder Spezialgebiete haben, aber die Rechenschaftspflicht obliegt dem Team als Ganzem.

Diese Form der Arbeit ist natürlich nicht in beliebig großen Teams möglich. Scrum zieht die Grenze für eine sinnvolle Teamgröße bei neun Entwicklern.

Was auffällt ist, dass die Rolle des Projektleiters fehlt. Gerade im klassischen Projektumfeld kann dies zunächst für Verwirrung sorgen.

Dass Scrum ohne Projektleiter auskommt, liegt daran, dass es eine Methode zum Prozessmanagement und nicht zum Projektmanagement ist. Im Regelfall ist das Prozessmanagement in ein Projektmanagement eingebettet. Letzteres hat dann auch einen Projektleiter. Diese Vorgehensweise ist in vielen Unternehmen Praxis. In wieder anderen Firmen werden die Verantwortlichkeiten eines klassischen Projektmanagers auf die Scrum-Rollen verteilt. Dabei landen typischerweise die meisten dieser Verantwortlichkeiten bei dem Scrum Master oder Product Owner. Insgesamt sollte durch die Selbstorganisation des Teams natürlich weniger Management nötig sein.

Wenn es einen Projektmanager über einem Scrum Team gibt, so ist es wichtig, dass er die agilen Methoden verinnerlicht hat und auch berücksichtigt. Ein Projektmanager, der mit klassischen Methoden agile Teams auszusteuern versucht, entpuppt sich in der Praxis als typischer Stolperstein für das Projekt. Ebenso wichtig ist eine klare Aufteilung der Verantwortlichkeiten zwischen dem Projektleiter und den Scrum-Rollen.

(24/28)

Weiter
© Copyright Preußig Seminare