Scrum
Scrum Prozess: Wertschöpfung und Risikomanagement
Scrum als Risikomanagement: Wie können agile Organisationen einen Scrum Prozess organisieren, ohne dabei die meiste Zeit im Dunkeln zu tappen?
Time-to-Market ist das aktuelle Credo aller Marketingabteilungen und Investoren. Früher, im letzen Jahrhundert, waren es ausgefeilte Funktionalitäten, je komplexer, je besser. Dann in den Milleniumjahren wandte sich das Credo in Richtung Usability, Design und Device-Kompatibilität. Und jetzt ist es Time-to-Market, was allerdings nicht bedeutet, dass die vorhergehenden Herausforderungen keine Rolle mehr spielen.
Aber wenn Organisationen sich entscheiden müssen, wovon sie sich bei der Entwicklung eines Produktes leiten lassen, dann ist es immer häufiger weniger das Wohlgefallen der Kunden, sondern mehr die ihr im Nacken sitzende Konkurrenz.
Hier erhältst du das WSJF Excel Template inklusive dem einfachen Step-by-Step Guide.
Dass dies nicht impact-los an den Produktentwicklungsorganisationen vorübergeht, ist natürlich keine Überraschung. Man beachte nur den irren Wettlauf der Unternehmen bei der Entwicklung eines Impfstoffes für Covid-19 um gleich mal ein Beispiel aus dem Nicht-IT Bereich zu nehmen.
Einige Länder verkürzen dafür schon gerne mal die Prüf- und Zertifizierungsverfahren, als ob es hier gar nicht um Menschenleben gehen würde.
Time-to-Market ist also nicht nur ein nice-to-have, sondern entscheidet oft über das Überleben von Unternehmen.
Und wenn man die überirdischen Investitionskosten für die Entwicklung von Impfstoffen oder für die Entwicklung von Elektromobilität sieht, dann ist das auch durchaus verständlich. Innovationen werden immer teurer, brauchen immer mehr Technologie und Ressourcen.
Auch das sind Gründe, warum Time-to-Market immer bedeutsamer wird. Disruptive Technologien lauern an jeder Ecke und bedrohen unsere liebgewonnen Market-Player, d.h, der Wettbewerb wird unübersichtlicher. Noch so ein Treiber für Time-to-Market Herausforderungen.
Da überrascht es nicht, dass in vielen Organisationen in der Projekt- und Produktentwicklung agile Methoden ins Spiel kommen. Überraschend ist da schon eher, dass viele den Zusammenhang zwischen Time-to-Market Anforderungen und dem Einsatz von agilen Methoden nicht erkennen, obwohl er bei näherem Hinsehen doch sehr offensichtlich ist.
Time-to-Market Anforderungen waren nicht der einzige Auslöser für diese „agile Revolution“.
Aber neben rasant gestiegener Komplexität von Produkten sowie der Vernetzheit von Produkten. Oder Produktionsweisen doch sicher einer von drei wesentlichen Faktoren, ohne Anspruch auf Vollständigkeit.
Agiles Projektmanagement muss sich dieser Herausforderung stellen. Die Erwartungshaltung, den Markt schnell zu besetzen, äußert sich gegenüber den Entwicklungsabteilungen in der Forderung nach einem sogenannten MVP – minimum viable product und wird oft so formuliert:
Alles, was wir nicht innerhalb von 6 Monaten auf den Markt bringen können, brauchen wir gar nicht erst beginnen. Ein Wettbewerber wird das dann für uns erledigen.
Sehen wir noch einmal auf die Entwicklung des Covid19-Impfstoffes, dann zeigt sich das sehr deutlich. Ca. im April 2020 – als absehbar war, dass es sich bei Covid19 um eine Pandemie handeln wird, viele Opfer fordern wird und damit ein Multimilliarden Markt da ist, begannen diverse Labore und Unternehmen mit der Entwicklung. Just nahezu genau 6 Monate später, hat der erste seinen Hut in den Ring geworfen.
Russland verkündete die Zulassung eines Impfstoffes unter Umgehung der üblichen 3. Testphase. Auch Donald Trump hatte für November 2020 einen Impfstoff angekündigt, rein zufällig waren dann US-Wahlen. Brauchen wir einen besseren Beleg für das oben gesagte, dass nämlich Time-to-Market alles andere overrouled? Das sehen wir heute überall.
Aber kehren wir zurück zum agilen Projektmanagement, denn dieser Artikel soll nicht nur das Problem beschreiben und beklagen, sondern eine konkrete und praktische Lösung anbieten
Wie hilft agiles Projektmanagement Organisationen die Time-to-Market Zyklen zu verkürzen?
Wie wir mit dem Ins-Spiel-Bringen eines MVP schon andeuten, wird agiles Projektmanagement – und das ist ein verbreiteter Irrtum – nicht das Entwickeln von Software beschleunigen in dem Sinne, dass die Entwicklungsteams jetzt schneller programmieren können.
Das mag im Vergleich zu früher wohl sein, liegt aber eher am Einsatz von Frameworks und CI-Pipelines und allerlei anderen technischen Errungenschaften. Der Ansatz agilem Projektmanagements – und dazu dient uns das MVP Beispiel – ist ein anderer, denn nur z.B. 20% schneller Entwickeln würde uns nicht zum Ziel bringen.
Agiles Projektmanagement und die agile Entwicklungsmethode zielt – und das ist der wesentliche Unterschied zum klassischen Projektmanagement und der klassischen Entwicklungsmethode (Wasserfall) – auf eine vertikale, sprich featureorientierte Entwicklung.
Diese erst ermöglicht die Definition eines MVP und die sich daran anschließende schrittweise Weiterentwicklung zur Vollversion. Aber so ein MVP zu entwickeln ist gar nicht mal so einfach.
Stellen wir uns vor, wir machen ein Brainstorming mit allen Fach-, Legal-, Strategy-, Marketing-, „you name it“- Abteilungen und sammeln dort alle Use-Cases und Feature-Ideas ein. Und nun sollen wir aus diesen vielen großartigen Ideen eine Handvoll auswählen, die sich sicher in drei bis sechs Monaten in ein marktreifes Produkt gießen lassen.
Jede Abteilung sieht ihre Features als lebenswichtig an: „ohne das können wir nicht life gehen…“. Und das ist auch gut so, denn die Abteilungen sollen als Stakeholder ja für ihre Produktfeatures „brennen“.
Trotzdem braucht es einen Kompromiss.
Und agiles Projektmanagement wäre nicht agiles Projektmanagement wenn es dafür nicht eine Lösung in Form eines einfachen aber effektiven Prozesses hat.
Ein Produkt, das vom Anwender vielleicht noch nicht geliebt werden muss, aber doch mindestens neugierig macht und uns nicht komplett um die Ohren gehauen wird.
Wie entscheiden wir, welches der Features auserwählt wird und wie es konkret in das Produkt implementiert wird?
In unserem Produkt Scagile – ein all-in-one Tool für skaliertes agiles Projektmanagement haben wir dieses Verfahren eingebaut und in der Praxis in unterschiedlichsten Projekten getestet.
Das Verfahren ist nicht neu, es ist sogar deutlich älter als agiles Projektmanagement.
Empfohlen wird auch von den SAFe Autoren und spielt in der SAFe Methode eine nicht ganz unwesentliche Rolle.
Das Verfahren nennt sich WSJF – weighted shortest job first und soll hier gar nicht im Detail beschrieben werden.
Wir konzentrieren uns darauf, wie es im agilen Projektmanagement helfen kann, time-to-market Zeiten zu verkürzen indem es hilft Features zu priorisieren und damit ein MVP- aber auch alle folgenden Phasen zu planen.
Kurz gesagt basiert die Methode darauf, dass es günstig wäre, die Features zuerst zu entwickeln, die sehr wertvoll sind und gleichzeitig wenig Aufwand machen. Natürlich fallen beide Attribute selten in einem Feature zusammen, sonst wäre es ja leicht.
WSJF errechnet einen Index aus den sogenannten „Cost of Delay“ – Was kostet es mich, dieses Feature nicht oder erst verspätet zu bekommen und der sogenannten „Jobsize“, also dem Aufwand. Die „Cost of Delay“ wiederum setzen sich aus drei Faktoren zusammen, dem Business Value, der Time-Criticality und der Risk-Reduction bzw. Opportunity-Enablement.
Der Vorteil dieser Methode liegt einerseits in seiner einfachen Anwendung, vor allem aber in dem Umstand, dass ein Feature aus mindestens vier Perspektiven bewertet wird. Zur endgültigen Priorisierung wird noch eine fünfte Dimension, nämlich Abhängigkeiten zwischen den Features hinzugezogen werden müssen, aber das müssen wir aus naheliegenden Gründen nicht extra beschreiben.
Der Business Value wird meist von den Fachabteilungen vertreten, Time Criticality oft von Legal- oder Compliance Abteilungen (z.B. Umsetzung DSGVO), Risk-Reduction/Opportunity Enablement oft von Marketing oder strategischem Management (z.B. Stichwort disruptive Technologien) und schließlich die Job-Size von den IT-Abteilungen.
Letztere kommen jetzt tatsächlich in den Genuss, durch ihren Input an der Priorisierung der Features früh beteiligt zu werden, statt – wie sehr oft gesehen – nur das ausführende Organ, oder wie mir gerade jemand sagte, die Programmierknechte zu sein.
Das alleine fördert schon eine im agilen Projektmanagement so wichtige wie intensive Kommunikation und wechselseitige Wertschätzung, kurz eine Dev-Ops Kultur, bzw. das vielbeschworene agile Mindset.
Die Priorisierung kann nun entlang des kalkulierten WSJF-Indexes erfolgen. In das MVP können beispielsweise alle Features mit einem Index grösser x genommen werden, oder alle Features in der Reihenfolge, bis 6 Monate um sind, mindestens aber die ersten 7. Natürlich müssen noch etwaige Abhängigkeiten berücksichtigt werden.
Für den Prozess verwenden wir ein Kanban-Board mit den Status Funnel, Analyzing, Backlog, in Progress und Done. Mehr braucht es eigentlich nicht um den gesamten Demandprozess bis hin in die Implementierung abzudecken.
Die WSJF Methode repräsentiert den Schritt Analyzing. Nachdem die Entscheidung für die MVP-Epics erfolgt ist, gehen sie ins Product Backlog und werden für die Umsetzung vorbereitet. Das heißt, sie gehen nun in die Hoheit der Product Owner bzw. der Scrum Teams.
Agiles Projektmanagement beginnt also weit bevor Product Owner und Scrum Teams ins Spiel kommen, bzw. in der Bewertung der Jobsize sind sie auch in der frühen Phase des Demand Management schon involviert. In vielen Organisationen beginnt „agil“ leider erst in der Implementierungsphase.
Aber agil ist nicht ein Projekt, sondern eine Organisation.
Der Vorteil echtem agilen Projektmanagements liegt gerade in dem Umstand, dass erstens die IT auch als ein Stakeholder gesehen wird und dadurch der Wertschöpfungsprozess buchstäblich end-to-end gedacht wird.
Und zweitens bringt es alle involvierten Stakeholder so zusammen, dass sie den gesamten Wertschöpfungsprozess durch alle Phasen hindurch begleiten. Es kann sehr schnell Feedback generiert werden und ebenso schnell kann auf das Feedback reagiert werden. Dadurch erst entsteht die Beschleunigung in Bezug auf Time-to-Market.
Hier erhältst du das WSJF Excel Template inklusive dem einfachen Step-by-Step Guide.
Scrum als Risikomanagement: Wie können agile Organisationen einen Scrum Prozess organisieren, ohne dabei die meiste Zeit im Dunkeln zu tappen?
Scrum vs. Wasserfall – Für alle Scrum Fans die schlechte Nachricht zuerst: Scrum ist nur ein Kompromiss. Die gute Nachricht, dies ist die einzige schlechte Nachricht..
Wie schreibt man eine gute Scrum User Story? Hier erklären wir dir, worauf es ankommt …und worauf nicht.
Für Scaled Agile Organisationen kann es frustriererend sein, wenn Projektmanagement Tools ihre Prozesse nicht unterstützen.
Daher haben wir scagile als eine App entwickelt, die aktiv agile Best-Practices fördert und mit der ein Value Flow über die gesamte Organisation hinweg etabliert wird.
