Die Rollenverteilung in agilen Projekten - Teil 2
Im zweiten Teil unserer Reihe ĂĽber agile Projekte gehen wir genauer auf die Rollen ein
Als das Scrum-Framework vor ca. 20 Jahren erstmals vorgestellt wurde, lag der Fokus auf der internen Software-Entwicklung. Auch heute sind der Scrum-Guide oder auch andere agile Frameworks darauf ausgerichtet, dass sämtliche Tätigkeiten in der gleichen Unternehmung abgewickelt werden. Für Projekte zwischen Auftraggebern und Dienstleistern bieten agile Frameworks häufig keine fertigen Lösungen, Best Practices und Antworten, wie agile Projekte durchzuführen sind. Und somit ergeben sich in agilen Projekten in diesem Setup einige zusätzliche Herausforderungen, welche zu berücksichtigen sind. In dieser Blogpost-Serie möchte ich drei Bereiche vorstellen, welche eben solche Herausforderungen und Spannungen verursachen können. Welche Herausforderungen sind in Namics Projekten aufgetreten? Wie konnte diesen begegnet werden? Basis für die drei Blogposts ist meine Präsentation am Agile Breakfast von swissICT am 29. November 2016.
Potenzielle Herausforderungen
Die grösste Herausforderung zum Thema Rollen sehe ich in der Rollenverteilung zwischen Dienstleister und Auftraggeber. Wer nimmt im Projekt-Setup welche Scrum-Rolle wahr? Vor allem bei der Product Owner Rolle ist die Besetzung entscheidend. Ein häufiges Problem ist, dass die Rolle von einer Person besetzt ist, die nicht über die notwendige Entscheidungskompetenz verfügt, welche ein Product Owner eigentlich benötigt. Ich habe auch schon Projekte erlebt, bei denen der Product Owner vom Dienstleister gestellt wurde. Dies halte ich für eine sehr risikovolle und falsche Vorgehensweise. Der Product Owner muss aus meiner Sicht immer beim Kunden platziert sein, denn die Entscheidungen über das Produkt können und wollen wir als Dienstleister dem Kunden nicht abnehmen.
Eine weitere Herausforderung ist die Vermischung von mehreren Rollen. Aus meiner Erfahrung kommt es relativ häufig vor, dass die gleiche Person Aufgaben der Scrum Master Rolle und der Entwickler Rolle (z.B. Testing) gleichzeitig ĂĽbernimmt. Wenn man dann zusätzlich noch den Product Owner in seinen Aufgaben unterstĂĽtzt, kann durchaus ein gewisser Rollenkonflikt auftreten.Â
Mögliche Lösungsvorschläge
Eine klare Definition der Product Owner Rolle ist unerlässlich. Es muss eine Person sein, welche alle Kompetenzen und die Entscheidungsmacht hat, um die Rolle wahrnehmen zu können. Das bedeutet für mich erstens, dass die Rolle zwingend beim Auftraggeber sein muss. Als Dienstleister sind wir nicht dazu berechtigt, ein Backlog zu priorisieren und Entscheidungen zu treffen, die grossen Einfluss auf die entwickelte Lösung haben. Zweitens ist es wichtig, dass die Product Owner Rolle nicht auf zwei oder mehr Personen verteilt ist. Der PO darf natürlich Personen in seinem Umfeld haben, die ihn unterstützen und beraten. Entscheidungen müssen allerdings vom Product Owner selbst getroffen werden – er trägt die Vision und setzt das Scrum Team gezielt ein um den Business Value seines Produkts zu optimieren.
Wie bereits oben erwähnt dürfen wir als Dienstleister den Product Owner durchaus in seinen Aufgaben unterstützen. Tätigkeiten bei denen ein Product Owner Consultant üblicherweise mitwirkt sind das Aufnehmen und Ausformulieren von Anforderungen und das Vornehmen von fachlichen und technischen Abklärungen. Auch bei Entscheidungen dürfen wir als Dienstleister beratend zur Seite stehen. Entscheidungen sollten aber von Kundenseite bzw. vom Product Owner selbst kommen.
