15
.
December
2022
|
All
Im zweiten Teil unseres Interviews mit Lisa geht es nun um die Zusammenarbeit mit Partnern im Hinblick auf eine agile Heransgehensweise. Denn die Zusammenarbeit und ein gemeinsames Verständnis für Agilität sind einer der wichtigen Erfolgsfaktoren für die Umsetzung von E-Commerce Projekten. Denn als Full-Service-Provider fungieren wir als strategischer Partner, weshalb wir auch die Beziehung mit unseren Kunden, als Partnerschaft betrachten.
Olivia: Nicht jedes Unternehmen arbeitet mit dem Framework Scrum, geschweige denn agil. Auch viele unserer Partner anfänglich nicht. Wie arbeiten wir mit solchen Partnern zusammen? Kommt es hierdurch manchmal zu Unstimmigkeiten?
Lisa: Agilität ist nicht der einzige Weg. Aber es ist ein Weg, der besser funktioniert besser als viele Andere. Genau das verdeutlichen wir unseren Partnern. Und nach dem ersten Meeting verstehen sie das auch und sind sogar begeistert, das auszuprobieren.
Wir leben schon lange in einer VUCA-Welt. Diese ist dabei von Volatility (Unbeständigkeit), Uncertaincy (Unsicherheit), Complexity (Komplexität) und Ambigousity (Mehrdeutigkeit) geprägt. Da sich nicht nur die E-Commerce-Branche stetig verändert, sondern auch unsere Umwelt einem andauernden Wandel unterliegt und wir heutzutage nun mal in einem Zeitalter voller Chaos leben, liefert uns das VUCA-Konzept immer weniger brauchbare Erkenntnisse. Das Framework VUCA hat sich daher zu BANI weiterentwickelt, ein Konzept dass sich 2020 etabliert hat und die Unsicherheiten und die Fragiliät unserer Zeit noch präziser benennt. BANI steht für: Brittle (brüchig), Anxious (ängslich), Non-linear (nicht-linear) und Incomprehensible (unbegreiflich).
Wenn wir genau das unseren Partnern erklären, kann sich dort jeder wiederfinden. Die Geschäftsumgebung ist komplex und Anforderungen sind nicht immer eindeutig. Daher wissen wir bereits, dass es nicht zielführend ist, ein Backlog von Anfang an fest zu definieren und abzuarbeiten. Das würde Ineffizienzen hervorrufen. Denn Anforderungen werden sich im Zuge der Umsetzung verändern! Deshalb ist Agilität der beste Weg der Zusammenarbeit…in kleinen Iterationen zu hinterfragen „Machen wir gerade noch das Richtige?“.
Dabei soll jeder im Team das "Why" verstehen. Was ist das Ziel? Was bauen wir eigentlich? Somit kann sich auch jeder daran beteiligen, wie das Produkt gebaut wird. Bisher hat kein Partner gesagt, dass diese Art der Zusammenarbeit keinen Sinn für ihn macht. (grinst) Sie sagen sogar meist „Super, macht das so“.
Natürlich sind wir uns bewusst, dass es für Partner ein mulmiges Gefühl erzeugen kann, wenn wir den Aufwand jeder einzelnen Story nicht genau schätzen können. Aber genau deshalb arbeiten wir mit Budgetobergrenzen. Innerhalb dieser Indikationen können wir flexibel umplanen um in Total dann dennoch ein Produkt zu erstellen, dass der Vision entspricht und marktfähig ist.
Olivia: Ich hätte nicht gedacht, dass wir hier so schnell überzeugen können.
Lisa: Stell dir vor, du als Partner bekommst durch die Scrum-Rhythmik innerhalb jedes Sprints einen Zwischenstand vom Projekt. Das Team trifft sich täglich,um gemeinsam zu besprechen, wie das Sprintziel erreicht werden kann. Darüber hinaus wird nach jeder Iteration der Produkt-Fortschritt präsentiert und die Effizienz optimiert. Das ist alles wünschenswert, nicht wahr?
Kritisch wird es, wenn wir feststellen, dass ein Teil der Umsetzung nicht funktioniert, weil Edgecases nicht berücksichtigt wurde. Und schon dieser Effekt bestätigt mal wieder die agile Vorgehensweise. In einem Wasserfall-Projekt würde uns niemals vorher auffallen, dass beispielsweise auf Partnerseite eine Anforderung vergessen wurde. Dabei hilft uns natürlich auch unsere Expertise, weil wir in der Lage sind, gezielte Fragen zu stellen, um so etwas aufzudecken.
Olivia: Cool. Da schließt sich gerade ein Kreis für mich. Danke für die Erklärung! Du hattest mich vorhin bereits über die verschiedenen Rollen innerhalb des Scrum Frameworks aufgeklärt und dabei erwähnt, dass sich der Product Owner auf Partnerseite befindet. Zu wie viel Prozent sollte er/sie auf dem Projekt arbeiten? 100%?
Lisa: Da möchte ich keine absoluten Zahlen nennen. Es sollte grundsätzlich schon ein starker Product Owner sein, der die Produktvision unter Beachtung von Kosten und Nutzen voranträgt und auch mutig genug ist, Entscheidungen zu treffen oder auch um zu priorisieren, umso die Ziele zu erreichen.
Vollzeit auf dem Projekt? Würde ich eher verneinen. Vordergründig ist eher die Reaktionsfähigkeit. Manchmal braucht es schnelle Zuarbeit. Und auch hier wieder der Vorteil von Scrum: neben all den Meetings, die ca. 10h pro 14 Tagen ausmachen, fokussiert sich jeder auf seine Arbeit. Für den Product Owner steht neben den Meetings das Testing und die Abnahme an. Es ist dann abhängig vom Typ und der Komplexität, wie lange er dafür benötigt.
Neben der Priorisierung des Backlogs oder auch der Abnahme der Anforderungen, ist die Hauptaufgabe des Product Owners, den Wert des Backlogs zu maximieren. Gerade um den Product Owner auf Partnerseite zu unterstützen, stellen wir auf unserer Seite einen Product Owner Proxy zur Verfügung, sodass beide eine Einheit bilden. So wird der Wert des Produktes maximiert. Der Proxy gibt auch Handlungsempfehlungen und kümmert sich um das Monitoring & Controlling. Hauptaufgabe vom PO Proxy ist, das Produkt in Time, Scope und Budgetauszuliefern.
Olivia: Woher nimmt denn der Product Owner Proxy diese Expertise?
Lisa: Unsere PO Proxys sind erfahren und können zwischen verschiedenen Business Modellen aus verschiedenen Projekten, Synergien herstellen. Manchmal haben sie auch ein höheres technisches Verständnis, als der PO auf Partnerseite, gerade auch was Default-Funktionalitäten des Shopsystems angeht. Und ansonsten legt mediawave einfach sehr viel Wert auf Trainings und Schulungen. Zusätzlich tauschen wir uns in gewissen Gremien untereinander aus, sodass auch hier ein großer Wissensaustausch stattfindet.
Olivia: Ok. Und wer arbeitet sonst noch bei einer Projektauslieferung mit? Ich kann mir vorstellen, dass hier sicherlich noch weitere Personen involviert sind.
Lisa: Uns ist wichtig, dass die Leute unserer Teams t-shaped sind. Das bedeutet, dass die Personen im Team nicht nur ein tiefes Wissen in ihrem Gebiet haben, sondern auch breitgefächertes Wissen in anderen relevanten Bereichen, umso alle Anforderungen selbst lösen zu können. Zusätzlich haben wir Experten, die jederzeit zur Beratung und zum Austausch zur Verfügung stehen und somit auch deren Know-how in das Projekt gezogen wird. Dazu zählen zum Beispiel unsere Solution Consultants, die besondere Expertise mit unseren Shop Systemen und den Lösungsarchitekturen haben. Dann haben wir noch Business Analysten, die gewisse Cases zu Business Modellen challengen und dazu beraten. Auch unser UX Designer unterstützt innerhalb einer gewissen Projektlaufzeit on Demand. Dann gibt es Rollen wie meine als Delivery Manager und das technische Äquivalent, die in diversen Projekten kontribuieren, unterstützen und beraten.
Der Fokus liegt jedoch auf dem vorher genannten Kernteam: PO, PO Proxy, Scrum Master und das Dev Team. Sie sind das Herzstück der Auslieferung.
Olivia: Alles klar. Nun ist die Stunde fast vorbei und du musst sicherlich direkt in dein nächstes Meeting. Was mich aber noch brennend interessieren würde, ist, was denn für dich die größten Herausforderungen in den letzten Projekten waren?
Lisa: Komplexität – nicht nur technisch, sondern auch durch die großen Dev Teams. Bei vielen Teammitgliedern wird natürlich auch die Zusammenarbeit komplexer. Hierbei müssen die Menschen gut auf einander eingespielt werden.
Als weitere Herausforderung gilt, die richtigen Fragen zu stellen und widersprüchliche Anforderungen zu erkennen. In jedem Refinement müssen Edge Cases hinterfragt werden.
Und eine andere große Herausforderung ist es, den Kunden hinsichtlich der Prioritäten zu beraten. Denn es ist oftmals eine Abwägung zwischen Produkt, zeitlicher und budgetärer Erwartungshaltung erforderlich.
Olivia: Und was machst du, um diese Herausforderungen zu meistern?
Lisa: Komplexität händeln wir mit unserer agilen Arbeitsweise. Wir fangen dabei stets klein an und gehen step by step voran. Wir setzen dabei auf verschiedene Methoden wie Proof of Concept oder auch auf ein MVP (Minimum Viable Product). Dies ist vor allem bei komplexen Features von Vorteil. Auch unsere Teams werden nicht außer Acht gelassen, weshalb wir die eben genannten Herausforderungen auch aufgrund unseres agilen Frameworks Scrum meistern können.
Zu den anderen beiden Themen: am Ende kommt es auf die Erfahrungen an. Wir haben Erfahrung mit Replatforming, wir haben Erfahrung mit Greenfield-Projekten, wir haben Erfahrung, wie man eCommerce-Projekte gestaltet und welche Risiken sich verbergen. Das versetzt uns in die Lage im Refinement auch die richtigen Fragen zu stellen. So auch auf Seite der Entwickler. Wenn die Devs das "Why" verstehen, sind sie in der Lage die richtigen Fragen für das "How" zu stellen.
Und für die Beratung sind wir darauf angewiesen, dass unser Partner sein Wissen mit uns teilt. Wir müssen den Markt, die Wettbewerber und das Geschäftsmodell verstehen. Dann können wir beraten, zum Beispiel, dass eine Funktion geschäftskritischer ist, als eine andere und wir deshalb empfehlen erst einmal auf den Markt zu gehen und erste Testergebnisse einzuholen.
Olivia: Für das Ende unseres Interviews würde ich gern wissen, was denn die schönsten Rückmeldungen von Partnern bisher waren?
Lisa: Da habe ich sofort etwas im Kopf. Ein Partner hatte mir erzählt, dass deren Shop "überperformed" und den Business Case übertroffen hat. Das hat mich sehr gefreut. Und ein weiterer Partner meinte am Ende, dass ihm die Zusammenarbeit zu tatsächlich jedem Zeitpunkt Spaß gemacht hat.
Olivia: Wow, das ist doch ein schöner Abschluss und ein großes Kompliment! Danke für das tolle Gespräch und dass du dir die Zeit genommen hast.
Lisa: Immer wieder gerne. Ich hoffe du hast nun einen noch besseren Einblick in unseren agilen Way of Work.
