Core Elemente / Slice the elephant

Slice the elephant

„Slice the Elephant“ als Metapher gilt als feststehender Begriff in vielen Methoden für das Teilen von großen Vorhaben in kleinere „beherrschbare“ Teile. In FAST fassen wir unter diesem Begriff ein Methodenset zusammen, welches die wesentlichen „Slicing“-Methoden umfasst, die in den verschiedenen Fällen angewendet werden können.

Der Nutzen entsteht, wenn man Ziele, Scope und Projekte immer nach demselben Schema in kleinere Stücke teilt. 

  • Es ergibt sich eine effiziente Denkstruktur, um Probleme und Anforderungen in beherrschbare Teile zu gliedern.

  • Es ergeben sich Templates und Good Practices, wodurch man in einem neuen Projekt sehr schnell sehr hohe Qualität erzeugen kann.

  • Es ergeben sich klare, immer wiederkehrende Themen und Verantwortlichkeiten.

  • Projektmitglieder können sich auf bestimmte Themen spezialisieren.

  • Das Personalmanagement kann sich gemäß diesen Themen aufbauen.

FAST Slicing mit 360°-Sicht

 In FAST gibt es eine allgemeingültige Regel, wie ein Vorhaben grundsätzlich immer segmentiert wird. Diese Regel gilt ungeachtet der Größe des Vorhabens. Durch die allgemeingültige Segmentierung wird eine 360°-Sicht geschaffen, die nicht nur das Ergebnis fokussiert, sondern auch Change Management und Operation zu Kernbestandteilen erklärt.

Segmentierung

  •  Solution (Lösung): Ist das eigentliche, nachhaltige Ergebnis
  • Projektmanagement: den Prozess verwalten, um eine Lösung zu erhalten

    • Sicht nach innen auf die Lösung und die Programmorganisation

    • Gilt für alle Elemente der Projektstruktur

  • Change Management: den Veränderungsprozess in der Organisation managen

    • Sicht nach außen auf das Umfeld

  • Operation (Betrieb): Sicht auf den Einsatz im Alltag

Klassifizierung von Streams 

Diese 4 Teile können in 2 Klassen unterschieden werden

Value Streams  

Alle Resultate in einem Continuous Deployment-Prozess bilden die Solution (Lösung) und ergeben einen Value Stream.

 

Work Streams 

Bestandteile der folgenden Tätigkeiten sind die sogenannten Work Streams:

  • die Arbeit managen, um das Ergebnis zu erhalten → Projektmanagement

  • das Ergebnis mit dem Umfeld abstimmen → Change Management

  • das Ergebnis im Alltag nutzen → Operation

 

Value Streams weiter teilen 

 

Häufig sind Solutions (Lösungen) so groß, dass eine weitere Unterteilung notwendig wird.

Hier setzt sich immer mehr der Ansatz des „Value Stream Slicing“ durch. Dieser „Wertstrom-Ansatz“ verfolgt das Ziel einer End-to-End-Betrachtung einer Solution und schneidet daher diese nicht mehr nach Verantwortlichkeiten z.B. in der Organisation oder Kernkompetenzen von Teams (bspw. IT), sondern nach der Nutzenperspektive (Value).

Kombiniert mit einer hohen Kundenzentrierung (Customer Centric), entsteht so eine sehr zielgerichtete Arbeitsweise, und aus den verschiedenen benötigten Kompetenzen zusammengesetzte Teams, bieten effizientere Strukturen.

Betrachtet man nach diesem Grundsatz den inneren Bereich der Solution genauer und somit die Value Streams, ergeben sich verschiedene Ansätze, Value Streams zu schneiden. Die Solution kann je nach Einstieg eine Vision, ein Programm oder Capability sein und zerlegt sich in entsprechend viele fraktale Ebenen. So ergibt es mehr Sinn, wenn der Projekteinstieg und die Solution ein

 

  • einzelnes IT-System (bspw. ein PIM, CMS, E-Commerce-System) ist,
    als Value Streams auf die Komponenten des jeweiligen Systems zu setzen.

  • IT-Konglomerat oder Framework (bspw.  ein Hybrid PIM+MAM+PRINT-System) ist, als Value Streams auf die Capabilities zu setzen und die Komponenten als tieferes Ordnungskriterium anzuwenden.

  • vorhandenes Konglomerat von Systemen ist, die es gilt, in einem End-to-End-Prozess zusammenzuführen, als diesen End-to-End-Prozess als Value Stream zu definieren.

 

Mit Erfahrung kann man diese Vorgaben/Empfehlungen auch anpassen aufgrund von speziellen inhaltlichen Anforderungen oder auch Projektgrößen.

Am Ende darf der Organisationsaufwand nicht den Nutzen übersteigen. Es handelt sich bei FAST um ein Framework mit Empfehlungen. Anpassungen sind in Teilen durchaus gewünscht.

Sehr hilfreich ist, bei der Aufteilungsentscheidung die Zahl 7 im Blick zu haben und darauf basierend Entscheidungen über die notwendige Anzahl der fraktalen Ebenen zu fällen. Beispielhaft kann ein entsprechendes Slicing folgendermaßen aussehen:

Was ist beim Slicing zu beachten? 

 

Bei allen Slicing-Ansätzen wie oben beschrieben sind insbesondere die Hinweise im Artikel Orientierung an Value Streams zu beachten, da nicht nur Fähigkeiten, sondern vor allem auch Teams „geschnitten“ werden, die diese Capabilities bzw. Workstreams bearbeiten sollen. Gerade diese manchmal diametrale Verbindung stellt einige Herausforderungen auf, ein optimales Slicing zu finden, welches dem Anspruch an Sinnhaftigkeit, „Value“ zu generieren, einerseits gerecht wird und auf der anderen Seite aber auch die praktische Umsetzbarkeit in den notwendigen Teams ermöglicht.

Programme slicen


Eine Programm-Solution bildet in der Regel mehrere Capabilities und Systeme ab, welche bei der Umsetzung des Programms mehr oder weniger betroffen sind. Häufig verfolgen Programme einen ganzheitlichen End-to-End-Ansatz und sind somit schon sehr dicht im gedanklichen Mindset am Konstrukt des Value Stream-Gedankens. Jedoch sind diese Programme in der Regel zu groß, als dass sie mit einem einzelnen Value Stream bearbeitet werden können. Beispiele sind etwa Customer Journey, Single Point Of Truth oder Internationalization.

Somit ist es notwendig, diese Programme weiter zu untergliedern (zu slicen).

Capabilities slicen


Capabilities (Fähigkeiten) bestehen in der Regel aus verschiedenen Systemen, die in einem Programm zusammen interagieren sollen, um gemeinsam einen Value zu generieren.
Somit werden häufig in einem Programm mehrere Capabilties zu einem Value Stream zusammengefasst.

 

Components slicen


Dies sind die einzelnen Elemente bzw. zu erreichenden Fähigkeiten der Capabilies. Beispielsweise „Data & Data model“ als Elemente, welche in mehreren Capabilties eines Value Stream benötigt werden. Somit ergibt es auch hier Sinn, diese Komponenten entsprechend so zu schneiden, dass Learning Cycles entstehen können und Wissen weiter gegeben werden kann.

Weitere Slicing Ansätze 

 

Unter dem Begriff „Elephant Slicing“ findet sich eine Vielzahl von weiteren Ansätzen, die beschreiben, wie Dinge, Vorhaben etc. geschnitten werden können. Wir haben hier noch ein paar weitere Ansätze kurz aufgeführt, für die es sich aus unserer Erfahrung lohnt, sie sich im Rahmen von FAST einmal bei Bedarf an weiteren Slicing-Methoden anzuschauen.

 

 

Workflow Slicing 

 

Um zu große Vorhaben weiter zu schneiden, kann auch entlang des umzusetzenden Workflow geschnitten werden. Hierbei versucht man, die zugehörigen Workflowschritte immer weiter zu reduzieren, aber immer noch ein funktionierendes Inkrement (Lösung) zu generieren. Auf diese Weise reduziert man immer weiter den Funktionsumfang und kommt dem Ansatz eines MVP (Minimum Viable Product) immer näher.

Das folgende Beispiel macht den Ansatz deutlich:


Ein Nutzer möchte in einem Bestellprozess eine Aufgabe in einem bestimmten Workflow ausführen. Alle Varianten führen zu einer großen User Story. Daher wird die User Story anhand der Schritte des Workflow aufgeteilt, um inkrementell entwickelt werden zu können. Daraus folgt, dass jede Stufe ihre eigene kleinere User Story bekommt.

  • Groß: Als Online-Shop-Kunde möchte ich beim Bestellprozess verschiedene Möglichkeiten des Zahlens haben, um mir die passendste aussuchen zu können.

  • Klein: Als Online-Shop-Kunde möchte ich beim Bestellprozess mit Paypal zahlen können, da dies für mich der schnellste Weg ist.

  • Klein: Als Online-Shop-Kunde möchte ich beim Bestellprozess auf Rechnung zahlen können, da ich kein Online-Banking habe.

 

User Story Slicing nach INVEST-Prinzip 

 

Wenn eine User Story zu groß für einen Sprint ist und somit das S der INVEST Kriterien nicht erfüllt ist, muss diese User Story kleiner geschnitten werden. In diesem Fall wendet man das User Story Slicing an. Sie wird in mehrere kleine Storys aufgeteilt, die innerhalb von einem Sprint umgesetzt werden.

Bevor wir uns mit den verschiedenen Möglichkeiten des User Story Slicing beschäftigen, betrachten wir kurz die Regeln des INVEST-Prinzips:

 

Ist die User Story gut formuliert?  

Mithilfe der INVEST-Kriterien lässt sich gut erkennen, ob eine User Story gut formuliert ist.

 

Independent (unabhängig)


Jede Story soll unabhängig von anderen User Stories sein. Dies bedeutet, dass die Umsetzung einer Story nicht voraussetzt, dass vorher eine andere Story umgesetzt wurde.

 

Negotiable (verhandelbar)


In den meisten Fällen schreibt ein Product Owner die User Story. Diese ist aber nicht „fest“ geschrieben, sondern wird vom Product Owner und dem Entwicklerteam zusammen diskutieren und dann präzisiert. Dies dient dazu, ein gemeinsames Verständnis zu schaffen, um die User Story dann bestmöglich umsetzten zu können.

 

Valuable (nützlich)


Die Story sollte einen erkennbaren Mehrwert liefern. Das Ergebnis der Story muss für den User einen Nutzen aufweisen.

 

Estimable (schätzbar)


Die Story dient dem Entwicklerteam als Grundlage für die Aufwandsschätzung.

 

Small (klein)


Der Arbeitsaufwand einer Story soll in einem Sprint realisierbar sein.

 

Testable (testbar)


Jede Story muss testbar sein, auch wenn es noch keinen Test gibt. Die Tests sind der Maßstab dafür, ob eine Story erfolgreich fertiggestellt wurde oder nicht. Sie verfügt daher über Akzeptanzkriterien, die prüfbar sind.

Varianten zum Schneiden von User Stories 

 

Horizontales Schneiden bezieht sich auf den Schnitt durch die verschiedenen Arbeitsschichten. Es handelt sich um die Zerlegung von großen Features durch ein einzelnes Gewerk. So gibt es beispielsweise eine Story für UI, eine für Front-End, eine für Back-End und eine für Datenbanken. Das Problem bei dieser Herangehensweise ist, dass die INVEST-Kriterien nicht erfüllt sind. Wenn wir uns die Kriterien noch einmal ansehen, stellen wir fest, dass es sich vor allem um die Aspekte Independent und Valuable der INVEST-Kriterien handelt.

Vertikales Schneiden bezeichnet das Zerteilen von Features, die alle Gewerke beinhalten. Dabei umfasst jedes Feature die Arbeiten aller Schichten.
Häufig wird von der „Kuchen-Analogie“ gesprochen. Die Idee ist, dass ein funktionierendes Feature (Software) ein vielschichtiger Kuchen ist. Der Kuchen macht die gesamte Arbeit aus, und jede Schicht stellt die gesamte Arbeit für diesen Teil des Produktes dar. Wenn wir den Kuchen horizontal zerschneiden, hätten wir beispielsweise nur die obere Sahneschicht auf dem Teller. Um Kuchenstücke mit allen Schichten zu erhalten, schneiden wir also vertikal durch den Kuchen. Die Analogie zu beispielsweise Software oder einer Lösung ist, dass eine Story kleinere Elemente einer funktionsfähigen, demonstrierbaren Software oder Lösung enthält, die dem Nutzer Mehrwert liefern.

Es gibt eine Vielzahl von Techniken wie User Stories vertikal geschnitten werden können. Wir führen hier nur die aus unserer Erfahrung wesentlichen Ansätze auf, die es grundsätzlich zu beachten gilt, und verweisen auf die vielfältigen Standardbeschreibungen im Netz zu den unterschiedlichen Verfahren wie Schneiden nach Business Rules, Operations, Rollen/Persona etc.

Auf die folgenden beiden Ansätze möchten wir jedoch gesondert hinweisen, da diese aus unserer Erfahrung die schnellsten und effektivsten Hinweise liefern, User Stories weiter zu schneiden:

Akzeptanzkriterien:

Betrachte deine Akzeptanzkriterien und überlege, ob diese eher eine eigene Story sind.

Conjunctions:

Wenn in deiner User Story Verbindungswörter wie beispielsweise „und”, „oder” vorkommen, ist dies häufig ein Zeichen dafür, die Story aufzuteilen.

 

Attribute Listing 

 

Die Attributauflistung ist ein systematischer Versuch, alle möglichen Ansätze für Produkt- und Prozessverbesserungen oder Varianten zu identifizieren. Dies geschieht in der Regel in einer geführten Brainstorming-Sitzung mit den Teilnehmern beispielsweise eines Value Streams oder einer Capability.

Das vorherrschende Prinzip des Attribute Listing ist das der systematischen Variation.

Sinnvoll ist es, wenn die ersten Bearbeitungsschritte zentral vorbereitet werden – also den Ist-Zustand (Merkmalliste des weiterzuentwickelnden Produktes oder Prozesses) aufbereitet.

Im Nachfolgenden können dann die Teilnehmer gemeinsam mögliche Variationen für jedes Feature/jeden Prozessschritt finden. Dies lässt sich sehr effizient nach den Regeln des Brainstorming bewerkstelligen.

Beispielhafter Aufbau für Features:

  • Merkmal (Attribute) – vorbereitet

  • aktuelle Lösung – vorbereitet

  • mögliche andere Varianten – Brainstorming

  • Bewertung des Nutzens (Values) der Varianten – Teamarbeit

  • Reduzierung Varianten – Teamarbeit

 

Beispielhafter Aufbau für Prozesse

  • aktuelle (geplante) Prozessschritte – vorbereitet

  • mögliche andere Prozessschritte – Brainstorming

  • Reduzierung auf minimale Prozessschritte, wo der Prozess aber noch funktioniert (Durchstich) – Teamarbeit

 

Auf diese Weise kann das Attribute Listing einen wertvollen Beitrag, vor allem bei dem Aufbau von gemeinsamen Verständnis und Know-how für das Schneiden von Vorhaben liefern, da es als Brainstorming-Methode in der Gruppe funktioniert und damit den Lösungsraum zunächst breit eröffnet, ihn dann aber wieder fokussiert. Ebenso kann es gut mit den oben genannten anderen Methoden kombiniert werden.