Agile Projekt Priorisierung mit der WSJF Methode

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.

Erst den Markt besetzen, dann den Kunden zufriedenstellen. 

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.  

Scrum Velocity berechnen
Scrum Velocity berechnen
In diesem Artikel geht es darum, eine Methode zur Berechnung und Darstellung der Velocity zu beschreiben, die geeignet ist, einen wirklichen Trend zu zeigen und eine Prognose zu erlauben.

Time-to-Market-Anforderungen und Agilität

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.  

Agiles Projektmanagement als Lösung für die kurzen Time-To-Market Zyklen

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? 

Blog.RunScrum.Agile.Organisation
Agile Organisation – Bildung einer agilen vertikalen Organisation
Wenn Organisationen sich in eine agile Transformation begeben, werden sie an irgendeinem Punkt über das Bilden von agilen Teams nachdenken müssen. Dabei kann die Ausgangslage in einzelnen Unternehmen oder IT-Abteilungen recht unterschiedlich sein und die Frage, wie sich die agilen Teams zusammensetzen und wie sie zueinander stehen kann dann schon…

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.  

Scrum Prozess: Risikomanagement
Scrum Prozess: Wertschöpfung und Risikomanagement
Wie in Scrum – verstanden als Risikomanagement Methode – schnell eine konkrete Zeit- und Kostenschätzung gegeben werden kann.

Ein Produkt, dass 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.

Die WSJF-Methode – wie priorisierеn Organisationen richtig? 

In unserem Produkt runScrum – 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. 

runnScrum: Scaled Agile Projektmanagement für SharePoint

Sit back. Relax.
Let SharePoint runScrum!

Die erste all-in-one scaled Agile Projektmanagement Suite für SharePoint

Projektmanagement vs Scrum
Projektmanagement vs. Scrum
Scrum gilt als Vertreter der agilen Projektmanagement Methode. Warum Scrum keine Projektmanagment Methode ist, sondern IM Projekt und nicht ALS Projekt aufgesetzt wird, erfahren Sie hier.

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.

Scrum Training

Agile in a Day

Wir trainieren Ihr Team, coachen Ihre Stakeholder und führen Ihr Projekt zum Erfolg!

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.  

WSJF-Template

Mit diesem Excel Template können Sie ganz leicht Ihre Projekte nach der WSJF-Methode priorisieren. Probieren Sie es doch einmal aus:

Die agile Vorgehensweise 

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.  

Leave a Comment

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.