Verborgene Hindernisse aufdecken Bessere Prozesse mit dem Impediment Backlog

Unerwartete Nebeneffekte können einen Produktentwicklungsprozess deutlich verzögern. Dabei ist es nachrangig, ob ein projekt- oder produktorientierter Ansatz verfolgt wird. Peter Rubarth erklärt, wie Sie solche Nebeneffekte aufdecken, mit einem Impediment Backlog richtig priorisieren und mit Experimenten beheben.

Management Summary

Verborgene Hindernisse aufdecken Bessere Prozesse mit dem Impediment Backlog

Unerwartete Nebeneffekte können einen Produktentwicklungsprozess deutlich verzögern. Dabei ist es nachrangig, ob ein projekt- oder produktorientierter Ansatz verfolgt wird. Peter Rubarth erklärt, wie Sie solche Nebeneffekte aufdecken, mit einem Impediment Backlog richtig priorisieren und mit Experimenten beheben.

Management Summary

Dieser Tage wird viel darüber geschrieben, dass die Arbeit in Projekten überholt ist. Unter dem Hashtag #NoProjects werden die Argumente hierzu ausgetauscht. Im Juli 2018 ist ein Buch gleichen Namens erschienen. Die zentrale These des Buches ist, dass ein kontinuierlicher Ansatz zur Entwicklung von Produkten – und nicht zeitlich begrenzte Projekte – der richtige Weg zum Erfolg ist.

Bei dieser Diskussion entsteht leicht der Eindruck, dass es nur auf die richtige Struktur ankommt und sich damit alle Probleme lösen. Dieser Artikel beschreibt, warum es sein kann, dass weder Produkt- noch Projektorganisation bei der Produktentwicklung funktionieren.

Peter Rubarth live erleben auf der PM Welt am 21. April 2020!

Erleben Sie den Vortrag "Vom "Wir gegen Die" zum Treiber der Zusammenarbeit - So gelang die Verwandlung eines Teams", sowie 30 weitere Speaker in 7 Streams auf der PM Welt 2020.

Das Thema der Konferenz lautet dieses Jahr
Stark durch Kooperation! Zusammen.Arbeiten.Grenzenlos.
Die Teilnehmer erhalten in den unterschiedlichen Vorträgen, Diskussionen und Workshops konkrete Anleitungen und Tipps für ihren Projektalltag

Best Practice Produktorganisation?

Die Produktorganisation wird im Vergleich zur Arbeit in Projekten häufig als besserer Ansatz gesehen. Die Argumente dafür sind unter anderem:

  • Bessere Ausrichtung an gemeinsamen wirtschaftlichen Zielen statt mehr oder weniger losgelöste Projektziele
  • Flexible Reaktion auf sich ändernde Rahmenbedingungen gegenüber einem vor Beginn definierten und starren Projektscope, der zu erfüllen ist
  • Einbindung aller benötigten Funktionen in einer interdisziplinären Struktur statt "Silo-Denke" zwischen Fachabteilungen und entsprechend mühsamer Abstimmung
  • Vermeidung von Problemen, die daraus resultieren, dass Projektmitarbeiter sowohl dem Projektleiter als auch dem Linienvorgesetzten zuarbeiten
  • Teams bleiben langfristig zusammen und werden nicht für jedes Projekt neu geformt und dann wieder auseinander gerissen (was die Entwicklung zu einem performanten Team verhindert)

Zu Besuch bei IrgendeinShop.de

Wir befinden uns bei einem etablierten E-Commerce-Unternehmen mit ungefähr 500 Mitarbeitern, welches einen spezialisierten Online-Marktplatz betreibt. Bei IrgendeinShop.de handelt es sich um ein imaginäres Beispiel, in das Erfahrungen aus mehreren realen Unternehmen eingeflossen sind.

Ein zentrales Organisationselement von IrgendeinShop.de sind die vier agil organisierten Produktentwicklungsteams. Jedes dieser Teams fokussiert sich auf einen Aspekt des Geschäftsmodells. Die fachlichen Themen der Teams sind so festgelegt:

  • Anbieter: Dieses Team kümmert sich um alle Funktionen der Plattform im Zusammenhang mit Benutzern, die Produkte auf dem Marktplatz anbieten.
  • Nachfrager: Das Team verantwortet die Funktionalität für potentielle Käufer, die den Marktplatz nutzen.
  • Partnerschaften und Integrationen: Das Team bindet Partner, z.B. für Finanzierungen an das eCommerce System an. Es geht vor allem um öffentliche Programmierschnittstellen (APIs) und nicht um Benutzeroberflächen.
  • Suchmaschinenoptimierung: Dieses Team arbeitet eng mit dem Marketing zusammen und entwickelt Funktionen für die Findbarkeit in Suchmaschinen. Dazu gehört auch die Erstellung von Landing Pages für bezahlte Werbekampagnen in Suchmaschinen und Sozialen Medien.

Die Teams bestehen aus jeweils fünf bis neun Mitarbeitern. Dazu gehören Softwareentwickler mit unterschiedlicher Spezialisierung und Software-Tester. Grafikdesigner und andere Spezialfunktionen werden als gemeinsame Ressource eingesetzt. Jeweils ein Product Owner und ein Tech Lead leiten die Teams. Der Product Owner verantwortet das Product Backlog, erhebt und formuliert die Anforderungen und nimmt die Umsetzung ab. Der Tech Lead ist der fachliche und disziplinarische Vorgesetzte der Softwareentwickler und verantwortet die Softwarearchitektur.

Es gibt zwei Scrum Master, um die Teams zu unterstützen. Die Scrum Master sind dem Chief Technology Officer (CTO) unterstellt. Die Product Owner berichten an den Chief Product Officer (CPO). Die Teams arbeiten nach Scrum mit zweiwöchentlichen Sprints.

Ein Blick hinter die Kulissen bei IrgendeinShop.de

IrgendeinShop.de scheint ein Paradebeispiel für agil arbeitende Teams und agile Prozesse zu sein. Doch das Team stand dennoch vor einem Problem bzw. gleich mehreren im Zusammenhang mit einem etablierten Prozess: dem Project Pitch. In diesem Artikel nehme ich Sie mit zur Ausgangssituation dieses Prozesses, erkläre, warum Prozesse (egal ob in klassisch geleiteten oder agil abgewickelten Projekten) manchmal trotz besten Wissens und Gewissens nicht funktionieren und schildere als mögliche Lösung den Aufbau eines Impediments Backlogs sowie die Einführung zeitlich begrenzter Experimente wie im Beispielunternehmen.

Project Pitches mit abenteuerlichen Auswüchsen

Um die Arbeit der Teams bei IrgendeinShop.de zu priorisieren, wurde ein Prozess etabliert, bei dem interne Stakeholder ihre Anforderungen und den zu erwartenden Business Value präsentierten. Interne Stakeholder waren Führungskräfte aus anderen Unternehmensbereichen, wie dem Marketing, Business Development, Lager oder Einkauf. Die Präsentation erfolgte vor einem Gremium, zusammengesetzt aus Produktmanagement und Vertretern aller internen Stakeholder. Dieses Gremium musste sich auf die Priorität der vorgeschlagenen Initiativen einigen, wobei dem CPO das letzte Wort zukam. Anfragen mussten diesen Test bestehen und wurden dann in der Reihenfolge des kalkulierten Business Value in eine Roadmap aufgenommen.

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
1 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 6
Kommentare 1

Alle Kommentare (1)

Dr. Borris
Orlikowski
Dr.

Dieser Artikel liefert eine gute Anregung und Roadmap, um Hindernisse im Projekt mit einem Impediement-Backlog anzugehen. Heraufordernd dürfte sein, die Offenheit herzustellen, um ggf. auch "politische" Themen oder "Befindlichkeiten" im Backlog zu dokumentieren und anzugehen, insbesondere in Unternehmen, deren Kultur daran krankt, dass Störungen auf dieser Ebene nicht offen angesprochen werden können. Hier ist dann auch viel Feingefühl der Geschäftsleitung gefordert. Aber einen Versuch, ist das Vorgehen wert!