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.