Was Schweine und Hühner mit Softwareentwicklung zu tun haben? …

… Gut, dass Sie sich das fragen!

Diese Fabel taucht häufig im Zusammenhang mit Scrum auf, weil sie wichtige Parallelen dazu aufweist: So lassen sich Beteiligte in einem Softwareprojekt in zwei Gruppen teilen.
Erstere sind die Personen, welche mit der Umsetzung des Projekts betraut sind und dementsprechend ‚ihren Kopf dafür hinhalten‘.
Zur zweiten Gruppe gehören diejenigen, die in das Projekt involviert sind, aber keine größere Verpflichtung darin haben.

Die drei Rollen
Über eine genaue Differenzierung, wer denn jetzt welcher Gruppe zuzuordnen ist, lässt sich sicherlich von Projekt zu Projekt streiten.
Scrum kennt dafür drei klar definierte Rollen, welche eine enge Zusammenarbeit für ein erfolgreiches Softwareprojekt gewährleisten sollen.

Team und Scrum Master sind die mit der tatsächlichen Umsetzung des Projekts beauftragten Personen.

Der Product Owner ist die Schnittstelle zwischen diesen und allen anderen Stakeholdern, die ein gewisses Interesse an dem Projekt haben. Demnach ist er meiner Meinung nach sowohl der einen als auch der anderen Personengruppe zuzuordnen.

Hauptaufgabe des Product Owner ist es,  das Projekt zu steuern und dafür zu sorgen, dass genau das Produkt entwickelt wird, welches der Auftraggeber wünscht und ihm den größtmöglichen Nutzen bringt.
Somit trägt er eine große Verantwortung und gehört aus diesem Blickwinkel zur Gruppe derer, die ihren Kopf für das Projekt hinhalten.
Scrum schreibt vor, dass er dazu eine Liste an Anforderungen pflegt, die vom Team umgesetzt werden sollen. Die ständige Aktualisierung der Anforderungen und deren Sortierung nach Priorität durch den Product Owner gemäß den aktuellen Gegebenheiten ist dabei essenziell.
In regelmäßigem Abstand (monatlich) verhandelt der Product Owner mit dem Team, welche der Anforderungen, die oben in der Liste stehen, voraussichtlich im nächsten Monat umgesetzt werden können. Danach darf der Product Owner bis zum nächsten Meeting keine weiteren Aufgaben mehr an das Team übertragen oder Änderungen an diesen ausgewählten Anforderungen vornehmen.
Das heißt, aus Sicht des Teams gehört er dann zur zweiten Gruppe, die ein Interesse an dem Projekt vertreten, aber in diesem Zeitraum keinen Einfluss auf die umsetzende Gruppe ausüben dürfen.

Das Team hat stets genau einen Monat – man nennt diese Zeiträume in agiler Softwareentwicklung »Sprints« – zur Verfügung, die ausgewählten Anforderungen in Eigenregie zu erfüllen. Es arbeitet also gemäß den 12 Prinzipien agiler Softwareentwicklung selbstorganisiert. Alle benötigten Kompetenzen und Ressourcen sind innerhalb des Teams vorhanden.

Schließlich ist noch die Rolle des Scrum Masters als besonderes Teammitglied zu klären. Er nimmt eine Schiedsrichterrolle ein, in der er dafür sorgt, dass alle beteiligten Personen ihre Rollen sowie alle weiteren notwendigen Regeln von Scrum einhalten und leben.
So schützt er beispielsweise während eines Sprints das Team vor äußeren Einflüssen, die von der zielgerichteten, effizienten Umsetzung der aktuellen Anforderungen ablenken.

Hinweis zu Quellen
In der Literatur gibt es verschiedene Aussagen über Details der einzelnen Rollen in Scrum.

Kontroverse Meinungen bestehen beispielsweise darüber, ob der Scrum Master Mitglied des Teams sein sollte / darf oder nicht.

Die Beiträge hier spiegeln stets meine Sichtweise auf Scrum wider. Dabei halte ich mich größtenteils an Ken Schwaber und Mike Beedle – die Urväter von Scrum.

• Schwaber, Ken & Beedle, Mike (2002): Agile software development with Scrum. Upper Saddle River: Prentice Hall

Eine ausführliche Link- und Literaturliste mit diesen und vielen anderen Autoren biete ich in einem der Folgebeiträge an …

Im nächsten Beitrag möchte ich Licht ins Dunkel der Zyklen – dazu gehören beispielsweise die Sprints – und des daraus resultierenden Scrum-Alltags bringen.

Scrum bei forcont R&D (Teil 3)…coming soon