In diesem Erfahrungsbericht aus der Praxis möchte ich zeigen, wie wichtig in einem agilen Projekt die Rolle des Product Owners ist, um dem Entwicklungsteam einen optimalen Rahmen mit klarem Fokus auf die Projektziele zu geben.

Aufgaben eines Product Owners

Bei der AIT GmbH erstellen wir individuelle Softwarelösungen für unsere Kunden in agilen Projekten. Oft sind Teams in Teilen durch uns und den Kunden besetzt, sodass wir mit den Kunden zusammen im Projekt arbeiten. Dieser Modus der "Co-Creation" ist im Scrum Guide so nicht beschrieben. Wir möchten jedoch die agilen Werte leben und streben daher ein partnerschaftliches Verhältnis auf Augenhöhe an.

In unseren agilen Projekten ist typischerweise die Rolle des Product Owners (PO) durch den Kunden besetzt. Dies sichert ihm den notwendigen Einfluss zu, denn der PO entscheidet über den Leistungsumfang und den zeitlichen Rahmen des Projekts.

Der PO ist die zentrale Stelle, um die Interessen aller Stakeholder auszuhandeln, abzuwägen und zu repräsentieren. Dies erzeugt Druck von vielen verschiedenen Seiten. Aufgabe des POs ist es, diesen Druck abzufedern und das Team davor zu schützen. Kommt er dieser Aufgabe nicht nach, kann dies gravierende Folgen haben: schlechte Stimmung im Team, Ineffizienz, Nichterfüllung von Deadlines bis hin zum Scheitern des gesamten Projekts.

Der PO hat noch einige andere Aufgaben. Ich möchte mich jedoch in diesem Beitrag auf die Aufgabe als Puffer zwischen Stakeholdern und Entwickler:innen konzentrieren, da diese essenziell ist, um dem Team einen optimalen Arbeitsrahmen mit klarem Fokus auf die Projektziele zu geben.

Störungen von außen: Stakeholdermanagement verbessern

Problem

Häufig haben Stakeholder eigene Interessen und Ziele, die manchmal nicht vollständig mit den Projektzielen in Einklang zu bringen sind. Manche Stakeholder sind außerdem mit der agilen Arbeitsweise nicht ausreichend vertraut, um ihre Anforderungen über die vorgesehenen Wege einfließen zu lassen. Die Folgen ihres Tuns sind ihnen daher nicht immer bewusst.

In der Praxis beobachte ich, dass manche Stakeholder versuchen, ihre Themen – auch am Prozess vorbei – zu platzieren. Die Symptome sind vielfältig und reichen von

• Störungen in Scrum Events (z.B. "ganz dringende" Themen mal eben im Daily einbringen, Aufgaben mit "hoher Prio" ungeschätzt im Planning in den nächsten Sprint drücken)
• über unabgestimmte Änderungen an den Work Items im Backlog (z.B. neue erstellen, bestehende editieren)
• bis hin zur direkten Ansprache und Auftragserteilung an einzelne Entwickler:innen.

Folge

Dies führt oft zum Verlust des Fokus. Wenn ständig und ad hoc Aufgaben mit hoher Priorität auf das Entwicklungsteam einprasseln und damit in jedem Sprint die Planung ad absurdum geführt wird, wissen die Entwickler:innen nicht mehr, was eigentlich wichtig und das Ziel ist.

Die vielen Kontextwechsel führen zu Ineffizienz. Um überhaupt noch Aufgaben abschließen zu können, machen die Entwickler:innen viele Abstriche bei der Softwarequalität und bauen dadurch (oft unbewusst) technische Schuld auf. Selbst wenn Tools zur statischen Code-Analyse mit Quality Gates genutzt werden, finden die Entwickler:innen aus der Not heraus immer Möglichkeiten, Abkürzungen zu nehmen, welche eben nicht unmittelbar aufgedeckt, sondern erst später sichtbar werden.