Jira

Konzepte sind einfach, handlungsfähig zu sein ist herausfordernd

Der Handlungsschritt nutzt Kanban, um die Roadmap zur Aktion zu führen. Damit sollte der grundlegende Ansatz gut bekannt sein. Der herausfordernde Teil im Handlungsschritt verbirgt sich in den Details des täglichen Lebens. Der wichtigste Teil ist es, ein gemeinsames und geteiltes Verständnis dafür zu finden, wie man Portfolio-Initiativen durch das Portfolio-Kanban reifen und ziehen kann. Es ist sicherlich von Vorteil, wenn alle Teilnehmer das Handlungsspiel mehr oder weniger identisch spielen. Das erfordert Coaching, Feedback, Kommunikation und einen Kaizen-Ansatz, um das Handlungsspiel kontinuierlich zu verbessern.

Unternehmen, die bereits Agilität praktizieren, verstehen, wie man gute Praktiken im Laufe der Zeit entwickelt und weiterentwickelt. Wenn Ihr Unternehmen gerade am Anfang steht, bietet dieser Schritt eine Gelegenheit zum Lernen – einschließlich der Mitglieder des Managements.

Werfen wir einen Blick auf das Portfolio-Kanban. Ich persönlich arbeite gerne mit einem Kanban mit folgenden Statusspalten:

List

Die Farben der Initiativen im Kanban-Board visualisieren die verschiedenen Themen. Gelbe Initiativen repräsentieren Thema A, blaue Thema B und die roten Thema C.

Es gibt einige lustige Bahnen im Kanban: fuzzy und SMART.

Kurzer Kommentar:

In SAFe werden die Portfolio-Kanban-Bahnen wie folgt benannt: Trichter, Überprüfung, Analyse, Portfolio-Backlog, Implementierung, erledigt. Um ehrlich zu sein: Für mich klingt das wie ein versteckter Wasserfall. Tatsächlich ist dies eine meiner persönlichen Bedenken bei SAFe. In einigen SAFe-Implementierungen, die ich beobachten konnte, führte dieses Konstrukt stillschweigend Serien von dreimonatigen Wasserfällen ein. Die Geschäftsanalyse schreibt drei Monate lang Spezifikationen bis zum nächsten PI. Vor dem PI drückt die Organisation die analysierten SAFe-Epen in die agilen Release-Züge. Im PI-Meeting dürfen die Implementierungsteams schätzen und ein kleines Feedback geben, und dann ertönt das Horn des Release-Train-Ingenieurs: „Beginnt damit zu arbeiten und beeilt euch“.

Nun, um fair zu sein: Das ist kein Problem von SAFe, man kann SAFe auf agile Weise leben. Dennoch beeinflusst das Konstrukt von SAFe mit PIs in diese Richtung. Traditionellere Unternehmen neigen dazu, in über Jahre hinweg trainiertes Verhalten zurückzufallen und leben dreimonatige Wasserfälle, indem sie Portfolio-Epen in die „agile Lieferorganisation“ drücken. Schon der Begriff „agile Lieferorganisation“ impliziert eine Kunden-Auftragnehmer-Beziehung und nicht eine „wir sind ein Organismus, der in die gleiche Richtung zieht“-Mentalität.

Das Kanban visualisiert den Reifeprozess

Der Grund, warum ich die Bahnen im Kanban wie im obigen Bild benenne, ist, dass dahinter ein Reifemodell von Ideen steht. Initiativen reifen mit unterschiedlicher Geschwindigkeit. Wir wissen aus dem Lean Startup, dass es essenziell ist, in kleinen Schritten im realen Leben zu experimentieren, wie ein Service oder Produkt die Bedürfnisse der Kunden befriedigen wird. Dieses Experimentieren braucht seine Zeit. Es ist unmöglich zu sagen, wann der Moment erreicht ist, dass ein Service oder Produkt diesen Punkt erreicht und es Zeit ist, zu skalieren (oder zu schwenken). Wir folgen dieser Idee des Lean Startup auch mit diesem Portfolio-Kanban.

Was wir zu vermeiden versuchen, ist, eine Initiative zu früh reifen zu lassen – das führt zu verschwendeter Vorarbeit – und zu vermeiden, zu spät zu reifen – in diesem Fall könnten wir den perfekten Zeitpunkt verpassen, um auf Kundenseite Wert zu generieren. Der agile Aspekt besteht darin, den perfekten Zeitpunkt zu treffen, um Aufwand in reife Initiativen zu investieren, den Wert für die Kunden – und für uns – zu maximieren. Dies ist ein interessantes Priorisierungs- und Reifespiel. In komplexen und schnellen Ökosystemen ist der Wandel schnell und proaktives Handeln kann zwischen Gewinn oder Verlust entscheiden. Das Portfolio-Kanban ist das Instrument, um dieses Spiel zu spielen.

Dieser Hintergrund des Reifens von Initiativen zur richtigen Zeit für die Kunden ist der Grund für die Bahnen fuzzy und SMART. Eine fuzzy Initiative ist – nun ja – fuzzy. Wir kennen nicht viele Details, aber wir sind uns einig, dass dieses Feature oder dieser Service cool klingt. Wir benötigen mehr Informationen für fuzzy Initiativen, um über die Priorität in der fuzzy Bahn zu entscheiden. Eine fuzzy Initiative erreicht ihre Definition of Ready (DoR), wenn wir genügend Informationen haben, um sie gegen die anderen fuzzy Initiativen zu bewerten. Die fuzzy Initiative mit der höchsten Priorität (im Hinblick auf die Wertschöpfung) wird oben in der fuzzy Bahn platziert und wird als nächstes in die SMART Bahn gezogen, sobald das Work in Progress (WIP) Limit dies zulässt.

Bitte erlauben Sie einen weiteren Kommentar zu SAFe als einem der beliebtesten agilen Skalierungsframeworks. Aus der Ferne betrachtet mag das Denkplan Portfolio-Kanban dem SAFe Business & Enabler Epic Kanban ziemlich ähnlich sehen. Wenn man das Kanban als WIP-Limit-Instrument betrachtet – könnte das zutreffen.

Dennoch haben die Hintergründe und Prinzipien, die zur Identifizierung, Reifung und Realisierung von Elementen in diesen Kanban-Boards verwendet werden, grundlegende Unterschiede. Die Prinzipien der Warteschlangentheorie im SAFe Business Epic Kanban sind schwach. Durchlauf- und Zykluszeiten haben oft enorme Varianz und – noch schlimmer – Business Epics werden in das Kanban-Board gedrückt, anstatt gezogen zu werden. Dies ist kein Problem von SAFe, es ist ein Defekt in einer SAFe-Implementierung. Tatsache ist, dass SAFe, so wie es ist und von Unternehmen auf einem noch zu entwickelnden Agilitätsreifegrad verwendet wird, dazu verführt, diese fehlerhaften Verhaltensweisen zu entwickeln. Die Business-IT-Lücke wird durch das Business Epic Kanban wiederhergestellt.

Die nächste Frage ist: Wer sammelt und analysiert die zusätzlichen Informationen, damit wir die Initiativen in der fuzzy Bahn priorisieren können?

Wer reift Initiativen wann?

Meine agile Antwort lautet: (ein) autonomes und multidisziplinäres Team(s), das dauerhaft im Bereich der spezifischen Initiative agiert.

Domain: Eine Domain oder Subdomain deckt einen Teil oder Abschnitt des Wertstroms eines Unternehmens mit hoher Kohäsion innerhalb eines Wissensbereichs, mit gemeinsamen Regeln und Verfahren ab. Beispiele für Domains sind das Produktplatzierungswissen eines Online-Shops oder pharmazeutische Prüfungen von ärztlichen Verschreibungen.

Die Portfolio-Roadmap bietet dem/den Team(s) Kandidateninitiativen zur Reifung an; oder die Teams entdecken selbst Kandidateninitiativen und setzen sie auf die Roadmap. Damit wissen die Teams in einer Domain, welche fuzzy Kandidaten zur Priorisierung bearbeitet werden müssen. Sobald eine Initiative die DoR erreicht, um bereit für die Priorisierung zu sein, kann die Priorisierung gegen alle anderen DoR fuzzy Initiativen aus anderen Domains erfolgen. Dies ist ein Agendapunkt eines wiederkehrenden Ereignisses, das mit dem Portfolio-Kanban als Instrument arbeitet. Mehr über die Ereignisse und die Kadenz folgt in einem zusätzlichen Blog. Mehr darüber, wie man mit der Reifung einer Initiative umgeht, wenn eine Organisation noch nicht in autonomen Teams organisiert ist, die in einer Domain arbeiten, wird ebenfalls in einem zusätzlichen Blog behandelt.

Nun wissen wir, wie eine Initiative von fuzzy in SMART gezogen wird. Das Spiel in der SMART Bahn ist analog. Dies ist der nächste Schritt in der Reifung, wobei wir von einem besseren Ausgangspunkt starten – einer ersten Idee über Priorität und Geschäftswert. Die SMART Bahn reift nun eine Initiative zu einem Reifegrad von SMART-Zielen. Daher stammt der Name SMART. Mit SMART-Zielen haben wir genügend Informationen erarbeitet, um die Ziele dieser Initiative zu erreichen. Die Initiative ist bereit, in die „in Arbeit“ Bahn gezogen zu werden. Wenn sie in die „in Arbeit“ Bahn gezogen wird, konzentrieren wir uns darauf, die SMART-Ziele der Initiative innerhalb der kürzest möglichen Durchlaufzeit und mit minimalem Aufwand zu erreichen. Das ist das Ziel der „in Arbeit“ Bahn.

Alles in allem soll das Kanban-Spiel die folgenden wichtigen Aspekte unterstützen:

  • Reife Initiativen zur richtigen Zeit unter Berücksichtigung des Einflusses von Markt, Technologie, Wettbewerb und Organisation
  • Priorisierung basierend auf der Wertschöpfung für Kunden und Unternehmen
  • Klare Definitionen von Ready haben, um den Reifegrad einer Initiative zu überprüfen
  • Den geringsten Aufwand in den Reifungsprozess vor der Realisierung des Wertes investieren
  • Fokus schaffen und danach streben, die SMART-Ziele einer Initiative mit minimalem Aufwand in der kürzest möglichen Durchlaufzeit zu erreichen.

Warum existiert eine Bahn zum Review?

Die „in Überprüfung“ Bahn mag etwas seltsam klingen. Warum ist eine Überprüfung notwendig? Das Ergebnis ist verfügbar, wenn die DoR der „in Arbeit“ Bahn erreicht ist; Kunden und Benutzer können mit dem Ergebnis arbeiten und Wert generieren. Warum also warten wir, während wir in der „in Überprüfung“ Bahn sitzen? Der Grund ist, den gewünschten Einfluss zu bestimmen. Das Ergebnis mag da sein und der Service oder das Produkt wird von den Kunden genutzt, aber der gewünschte Einfluss erfordert möglicherweise etwas Betriebszeit, um Zahlen zu sammeln. Hoffentlich sind die zu beobachtenden Zahlen Teil der SMART-Zieldefinition in den Initiativen. Diese Zahlen zur Bewertung des Einflusses einer Initiative zu definieren, sind wichtige Akzeptanzkriterien einer Initiative. Idealerweise implementieren die Teams die Messungen mit oder sogar vor der Implementierung der Ergebnisse. Dies ist analog zur agilen Softwareentwicklung. Die Akzeptanzkriterien sind die Vorlagen für automatisierte Tests, die geschrieben werden sollen. In einem TDD (testgetriebenes Design)-Ansatz werden automatisierte Tests geschrieben, bevor der Quellcode der Software geschrieben wird. IT-Leute verstehen diese Analogie – ich hoffe, Geschäftsleute verzeihen diesen technischen Exkurs.

Die DoR der „in Überprüfung“ Bahn ist erreicht, wenn wir den Einfluss bewertet haben. Dies führt wahrscheinlich zu neuen Ideen für Initiativen – und das Spiel beginnt von neuem.

Ist Implementierung erlaubt, während eine Initiative noch fuzzy ist?

Es gibt viele offene Fragen rund um dieses Kanban-Spiel. Ich würde mich freuen, Ihre Fragen zu erhalten, um sie zu diskutieren.

Eine der meistgestellten Fragen ist: „Ist es erlaubt, ein Stück Software zu implementieren, wenn eine Initiative noch in der fuzzy oder SMART Bahn ist?“ Die Antwort ist offensichtlich: Ja. Und was ist der Grund dafür?

Denken Sie daran, es ist ein Reifungsprozess. Eine Initiative ist reif, wenn alle folgenden Bedingungen erfüllt sind:

  • Geschäftsleute sagen, dass der Markt und die Kunden bereit sind, zu konsumieren.
  • IT-Leute sagen, dass es möglich ist, die erforderliche Software einschließlich architektonischer Aspekte zu implementieren, während die Gesundheit der gesamten IT-Systeme auf dem gewünschten Niveau bleibt.
  • Die Organisation ist rechtzeitig bereit, den Service bereitzustellen, d.h. interne Benutzer sind geschult, die Infrastruktur ist bereit (Infrastruktur ist mehr als IT-Infrastruktur, stellen Sie sich vor, die Initiative ist die Eröffnung eines neuen Flaggschiff-Stores in einer großen Stadt) und was auch immer erforderlich ist, um das Ergebnis zu betreiben.

Mit diesem Hintergrundwissen, ja, es ist definitiv erlaubt, zu „implementieren“, wenn eine Initiative noch in der fuzzy Bahn ist. Der Flaggschiff-Store ist ein gutes Beispiel. Während in der fuzzy Bahn prüfen Sie beispielsweise die Situation des Immobilienmarktes im Zielgebiet, um ein Gefühl dafür zu bekommen, wie machbar es überhaupt ist, einen attraktiven Standort zu finden. Vielleicht müssen Sie prüfen, ob die IT-Systeme eine Flaggschiff-Store-Logistik unterstützen können, und Sie implementieren einen Spike mit zwei oder drei User Stories in einem aktuellen Sprint – und so weiter. Sie sehen das Spiel.

Noch einmal: Autonome Teams, die kontinuierlich in einem bestimmten Bereich arbeiten, lernen, das Spiel zu spielen, wann in welche Initiative investiert werden soll, um den Fluss zu etablieren.

Ein nicht diskutiertes Hindernis ist: Wie handelt man, wenn der Fokus sich von einer Domain zu einer anderen Domain verschiebt, mit dem Effekt, dass in Zukunft mehr Kapazität in Domain A und weniger in Domain B benötigt wird? Dies ist ebenfalls eine Frage für einen zukünftigen Blog.

Schreibe einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit * markiert.


Beitragskommentare