Jeff Sutherland hat mich persönlich vor etwas mehr als einem Jahr mit Scrum infiziert. Wir hatten schon seit Jahren eXtreme Programming Praktiken bei uns eingesetzt, aber Scrum war aus meiner Sicht die perfekte Ergänzung als agiles Projektmanagement Framework.
Seit diesem Zeitpunkt setzen wir in fast allen unseren Projekten Scrum in Kombination mit eXtreme Programming ein und zertifizieren schrittweise alle Mitarbeiter zum Certified ScrumMaster. Aus meiner Sicht hat Jeff nicht zu viel versprochen: Unsere Kunden freuen sich über gestiegene Produktivität und Qualität. Gerade die kurzen Release Zyklen (Sprints) von meistens 2 Wochen haben schon die ein oder andere Begeisterung ausgelöst.
Trotzdem waren wir nicht immer in der Lage Scrum wirklich richtig mit unseren Kunden zu implementieren. In der Schulung von Jeff, aber auch in den Scrum Büchern von Ken Schwaber wird eigentlich immer davon ausgegangen, dass Product Owner, Scrum Master und Team aus einem Unternehmen kommen. Wie passt das aber in das Konzept eines Dienstleisters wir wir einer sind und welche Rollen von Scrum stellt der Kunde und welche werden von uns übernommen? Eine Antwort bleibt die Scrum Theorie schuldig.
Unsere Lösung dafür war bisher, dass wir den Product Owner immer bei unseren Kunden installiert haben. Für uns war dies die logische Konsequenz auf die Aufgaben des Product Owners: Entwicklung einer Produktvision sowie Erstellung und Priorisierung des Backlogs. (Eine andere witzige Definition hat Henning Wolf in seinem Vortrag bei uns gegeben: „Product Owner sind Business Analysten mit Eiern in der Hose“) Wir haben uns dann in den Projekten auf die Rolle der Experten für die agile Entwicklung der Software konzentriert und dabei das Team und den ScrumMaster gestellt.
Die Herausforderung dabei ist aber den geeigneten Product Owner beim Kunden zu finden und zu etablieren – das haben wir nur selten geschafft. Aus diesem Grund haben wir den „Product Owner Proxy“ definiert, der die Funktion des Product Owners bei uns einnimmt und i.d.R. zusammen mit dem Kunden das Backlog erstellt und priorisiert. Dieses Vorgehen hat funktioniert, war aber aus meiner Sicht nicht „rund“ und teilweise auch problematisch, weil es zu einem „Konflikt“ beim Product Owner Proxy kommt, denn er muss einerseits den Kunden gegenüber dem Team vertreten, zum anderen ist er aber auch Teil von codecentric und muss darauf achten, dass das Projekt wirtschaftlich für uns ist.
Auf unserem meet the experts – agilität habe ich dieses Problem deshalb in einem Open Space zusammen mit einigen Kunden und Scrum Experten diskutiert. Die Diskussion endete damit, dass Boris Gloger sich an ein Flipchart gestellt und seine Idee zu diesem Thema skizziert hat. Zunächst habe ich seine Thesen angezweifelt, doch schon während der Diskussion wurde mir klar, dass er gerade die Lösung für unser Problem skizziert hatte:
Schon in seinem Buch schreibt Boris, dass es sich Scrum mit den drei definierten Rollen Scrum Master, Product Owner und Team etwas zu einfach gemacht hat und eigentlich drei Rollen vergessen wurden: Der Manager, der Kunde und der Anwender. Somit gibt es in Scrum 3 +3 Rollen. Diese neuen Rollen alleine lösen aber den Konflikt als Dienstleister noch nicht auf oder doch?
Die klassischen Rollen von Scrum liegen aus Sicht von Boris alle beim Dienstleister, da dieser das Produkt erstellt. Gerade der Product Owner bezieht dabei eine Rolle, die im Open Space stark diskutiert wurde aber irgendwie auch konsequent ist. Er versucht Business Value zu generieren – für den Dienstleister!? …aber wie kommt jetzt der Kunde zu seiner Vision und zu seinem Business Value? Und wie bekommt der Dienstleister die fachlichen Informationen vom Kunden, der seine Domaine ja am besten kennt?
Entscheidend ist, dass der Kunde das Geld für die Entwicklung beisteuert – d.h. durch die Bezahlung legt der Kunde den Wert für eine User Story fest. Den fachlichen Input gibt der Anwender, der beispielsweise aus dem Fachbereich des Kunden kommt. Dieser wird im besten Fall in das Team integriert und erstellt zusammen mit diesem den Inhalt des Product Backlogs. Alternativ kann auch ein Business Analyst mit in das Team integriert werden und erfasst die Anforderungen direkt beim Anwender. Zudem wird der Kunde gemeinsam mit dem Product Owner die Vision entwickeln.
Dieser Ansatz von Boris hat aus meiner Sicht entscheidende Vorteile:
- Die Rollen Kunde, Anwender und Manager sind einfach vorhanden und jetzt ist auch klar welche Aufgabe sie innerhalb von Scrum haben.
- Wir können Scrum beim Kunden einfacher einsetzen, weil wir die klassischen Scrum Rollen selber stellen können und der Kunde so einfacher die Vorteile von Scrum nutzen kann. Natürlich kann er mittelfristig auch selber Scrum anwenden und die entsprechenden Rollen durch Coaching aufbauen.
- Der Kunde bezahlt Business Value und kann so über das eingesetzte Budget auch die Priorität eines Features festlegen.
- Der Product Owner steht nicht mehr zwichen den Stühlen.
Wir werden das sicherlich intern bei uns noch weiter diskutieren, aber ich denke, dass es eine sehr gute Erweiterung des „klassischen“ Scrums ist und man dadurch gerade als Dienstleister einfacher und besser mit dem Kunden zusammenarbeiten kann – vor allem weil es den Kunden jetzt auch in Scrum gibt 🙂
War dieser Beitrag hilfreich?
Weitere Beiträge
von Mirko Novakovic
21.2.2014 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Mirko Novakovic
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.