PEP im Backlog
Scrum Teams sind selbstorganisiert und entscheiden eigenständig, wie sie ein wertvolles Produkt entwickeln. Andererseits haben die meisten Unternehmen, die mechatronische Produkte entwickeln, einen sauber strukturierten Produktentstehungsprozess (PEP), der eine wichtige Basis für die Produktentwicklung im Wasserfall war bzw. ist. Wie passt das nun zusammen, wenn solche Unternehmen erste Schritte im agilen Arbeiten wagen? Spielt der PEP dann überhaupt noch eine Rolle? Oder verhindert gar der PEP agiles Arbeiten grundsätzlich? Wir wollen hier aufzeigen, wie PEP und agiles Arbeiten zusammenpassen und sich sogar ideal ergänzen.
Das Product Backlog
Beim agilen Arbeiten ersetzt werden Lasten- und Pflichtenheft durch das Product Backlog ersetzt. Anders als bei reinen SW-Produkten ist es aber bei mechatronischen Produkten nicht möglich, das Gesamtprodukt durch die schrittweise („sprintweise“) Realisierung von Produktmerkmalen (Backlog Items) zu entwickeln. Bei physischen Produkten tragen einzelne Hardwarekomponenten zu vielen Produkteigenschaften bei, die bestimmten Kundennutzen erzeugen. Ein Gehäuse zum Beispiel kann dem Kunden Features wie Handhabbarkeit, Design, Stabilität, Gewicht, Geräuschemission und vieles mehr bieten. Natürlich meist in Kombination mit anderen HW-Komponenten. Und gerade diese Kombinatorik macht bei mechatronischen Produkten ein Vorgehen unmöglich, in dem Sprint für Sprint eine neues Produktfeature bzw. eine neue Produkteigenschaft realisiert wird.
Daher wird im Grunde immer ein komplettes Produkt in verschiedenen Reifegraden entwickelt. Beginnend mit virtuellen Mustern, über einzelnen Funktionsmuster bis zu Prototypen und Vorserien. Es versteht sich von selbst, dass beim agilen Arbeiten im Umfeld mechatronischer Produkte auch versucht wird, nach jedem Sprint ein MVP (Minimum Viable Product) zu erzeugen, für das im Rahmen des Reviews Feedback von Stakeholdern eingeholt werden kann. Kundenorientierung und -nähe sind entscheidende Erfolgsfaktoren.
Aber meist ist es in der Praxis nicht möglich, wie bei Software-Produkten, nach jedem Sprint ein Stück mehr vom Produkt zu zeigen, bei dem Feature für Feature – priorisiert nach Kundenwert – ein Gesamtprodukt entsteht. Ein mechatronisches Produkt muss zum Serienstart komplett sein. Ein späteres (HW-)Update ist in der Regel nicht möglich.
Das Backlog bei mechatronischen Produkten
Dieser Unterschied zwischen Software und Hardware führt dazu, dass bei mechatronischen Produkten eine andere Art von Backlog-Arbeit erforderlich ist, um letztlich ein erfolgreiches Produkt zu entwickeln. Jede Art von Produkt verbindet natürlich, dass im Backlog alle Produkteigenschaften aufgelistet werden. Sonst könnte das Backlog nicht das Lasten- bzw. Pflichtenheft ersetzen.
Aber einerseits ist es, wie oben erläutert, meist nicht möglich, diese Produkteigenschaften schrittweise zu entwickeln und andererseits arbeiten meist auch diverse Spezialisten aus verschiedenen Perspektiven an denselben Eigenschaften. Beispielsweise wird die Geräuschemission eines Produktes durch zahlreiche Elemente beeinflusst. Und um einen bestimmten Zielwert zu erreichen, müssen alle Elemente einen Beitrag leisten, entweder in der Form, dass sie weniger Geräusch emittieren oder dadurch, dass sie bessere Dämpfungseigenschaften haben.
Daher wird bei mechatronischen Produkten oft zwischen einem Produktanforderungsbacklog und einem Teambacklog unterschieden. Im erst genannten Backlog werden, wie der Name sagt, alle Produktanforderungen geführt. Im Teambacklog werden diese Anforderungen heruntergebrochen. Entweder in Teilanforderungen, die die jeweiligen Spezialisten erfüllen müssen. Oder, da auch dieses Herunterbrechen zumindest in der Anfangsphase auch nicht systematisch möglich ist, in Tasks – also in Tätigkeiten. Diese Tätigkeiten bzw. Aufgaben müssen die Spezialisten erledigen, um am Ende ein Gesamtprodukt zu entwickeln, das alle Anforderungen erfüllt.
Vor diesem Hintergrund dient der PEP als wertvoller Aufgabenspeicher für das Backlog. Phasenweise diskutiert das Team, welches Backlogelement für das laufende Projekt sinnvoll ist und welches nicht. Diese Selektion – das PEP Tailoring – ist allerdings auch für klassisches Projektmanagement sinnvoll. Denn Entwicklungsvorhaben sind nicht unbedingt vergleichbar. Beispielsweise sollte für kleine „Facelifts“ ein anderer Prozess zur Anwendung kommen als für eine große Neuentwicklung.
Diese Tailoring-Fähigkeit des PEPs nutzen agile Teams für die Überleitung in ihr Teambacklog. Sie entscheiden, welche Elemente für sie hilfreich sind und welche nicht. Mit dieser Vorgehensweise entsteht eine wertvolle Symbiose zwischen dem agilen Backlog und den Erfahrungswerten der Vergangenheit, die im PEP hinterlegt sind.
CO Improve hat zahlreiche Projekte unterstützt, bei denen diese Symbiose zum Nutzen der Unternehmen gewonnen werden konnte. Wir zeigen Ihnen, wie sich ein agiles Backlog und ein PEP hervorragend ergänzen können. Sprechen Sie uns an.
Ihr Nutzen
- Agiles Arbeiten bringt klare Wettbewerbsvorteile auch bei der Entwicklung mechatronischer Produkte
- Selbstorganisierte Teams führen ein Backlog mit hoher Qualität
- Die im PEP (Produktentstehungsprozess) hinterlegten Erfahrungswerte, wie gute Produkte entwickelt werden, gehen sinnvoll in die Backlog-Arbeit ein