Theory & FoundationÄhnlichkeit nutzen

Ähnlichkeit nutzen

Dieses Element erläutert das Prinzip der Ähnlichkeit und wie es für unterschiedliche Aspekte genutzt werden kann.

„Ähnlichkeit nutzen“ kurz erklärt

Ähnlichkeiten, auch als Fraktale bezeichnet, sind ein uraltes Prinzip aus der Natur, um mit wenigen Regeln hochkomplexe Systeme zu erschaffen. Die Verwendung des fraktalen Prinzips ermöglicht die Wiederverwendung von gleichen Arbeitsweisen auf verschiedenen Ebenen im Projekt. Durch diese Ähnlichkeit werden Prozesse verständlich, einfach erlernbar und Informationen systematisch aggregierbar und schnell transportierbar.

Was bedeutet „Ähnlichkeit nutzen“ für den Kontext in FAST?

  • Es muss nicht alles gleich sein oder dogmatisch eingehalten werden.

  • Es darf aber auch nicht beliebig oder anarchisch sein.

  • „Ähnlich“ ist der richtige Weg.

  • Das ist effizient und lässt Raum für kontextabhängige Anpassungen.

Starre Einhaltung von Regeln ist nicht gewollt

  • Adaptieren erlaubt

  • Ähnlich reicht

  • Ähnlich erlaubt nicht, ganze Gesetze auszuhebeln.

Dabei gilt immer
  • Auf jeder Ebene wieder dieselben oder ähnliche Regeln anwenden.

  • Nicht in den God-Mode verfallen und alle Ebenen mit allen Details strukturieren.

Anwendung der Ähnlichkeit in Bezug auf Zeitstrukturen

Zeitstrukturen definieren verschiedene Größen von Timeboxen.

Fraktale Regel

Zeitstrukturen (Timeboxen)

  • Epoche: 3 Jahre

  • Year: 1 Jahr

  • Season: 3–4 Monate, d.h.

    • 4 Seasons (Quartale) oder

    • 3 Seasons (Tertiale)

    • Normal: 4 Seasons

    • bei komplexen Projekten mit hohem Overhead für Season Review, Release

  • Sprint: 1–4 Wochen

    • 2 Wochen: üblich für normale Teams in einem normalen Projekt

    • 3 Wochen:

      • bei mehreren Teams mit vielen Abhängigkeiten, d.h., eine Abstimmung zu jeder Season ist zu lange, aber alle 2 Wochen erzeugt zu viel Overhead

      • Wenn Team(s) verlässlich und routiniert arbeiten, wird weniger Transparenz benötigt und die Sprints können voller gepackt werden.

    • 4 Wochen:

      • bei Teilzeit-Teams, die nur ab und zu was beitragen müssen

  • Day: 1 Tag

Ergebnis-/Lösungsstrukturen

Ergebnisstrukturen definieren verschiedene Größen von Ergebniselementen.

Struktur

  • Vision

  • Moals – Mid Term Goals

  • Objective

  • Key Result

  • Feature

  • Use Case

  • Story

  • Subtask

Bedingungen

  • Jede Strukturebene enthält Elemente mit entsprechender Größe (Scope, Umfang).

  • Die Elemente dürfen nur so groß sein, dass sie in die Timebox, der sie zugeordnet sind, passen.

  • Beispiel:

    • Objective, Key Result und Use Case sollten in eine Season (ca. 3–4 Monate) passen.

    • Eine Story sollte in einen Sprint passen.

    • Ein Subtask sollte in einen Tag passen.

Projektstrukturen

Projektstrukturen definieren verschiedene Größen von Projekten.

Fraktale Regel

Jede Projektgröße hat grundsätzlich folgende Bestandteile:

  • Start, Ende

  • Scope = Ergebniselemente (s. o.)

  • Owner, Projektorganisation

  • Planung, Controlling, Reporting

  • Ressourcen- und Budget-Management

  • Requirement-Management, Risiko-Management, Stakeholder-_anagement

  • Change Management

  • Operative Management

Je nach Projektgröße sind auch diese Bestandteile unterschiedlich groß bzw. so klein, dass sie praktisch entfallen.

💡Es lohnt sich auch für kleinste Aufgaben, kurz diese Checkliste durchzugehen.

Struktur

  • Portfolio, Vision

  • Portfolio

  • Large Solution

  • Programm (ART)

  • Work Stream (z.B. PIM, siehe horizontale Capability)

  • Work Package (z.B. Datenmodell, siehe vertikaler Stack)

  • Task

  • Subtask

Fazit und Anwendung

  • Für komplexe Projekte sind einfache hierarchische Modelle nicht ausreichend.

  • Das „Gesamte“ lässt sich nur schwer fassen.

  • Iteratives Vorgehen

    • zeitlich

    • inhaltlich (Detailebene)

  • Sich zu jedem Zeitpunkt der fraktalen Ebene bewusst sein

    • zeitliche Ebene, z.B. Planung von heute, vom Sprint, vom Quartal, usw.

    • inhaltliche Ebene, z.B Gesamtscope, Feature, Story

  • Auf jeder Ebene dieselben Methoden, Tools und Templates anwenden

    • anpassen ist in Ordnung

    • „ähnlich“ muss es bleiben

  • Im Zweifel, bei unklaren Details

    • nicht ins Detail absteigen; sich nicht im Detail verlieren

    • auf der aktuellen Ebene bleiben und Ergebnis erzwingen

  • 80 % fertig, ist DONE

    • Ist die Aufgabe, das Feature oder Teilprojekt zu 80 % fertig → auf DONE setzen und für den Rest eine neue Beschreibung erstellen

    • Ist das Ticket am Sprintende erst zu 80 % fertig → abschließen und Folgeticket für den Rest erstellen

    • Für die letzten 20% braucht man noch mal genauso lang (siehe oben Pareto).

  • Nicht falsch ist erst mal richtig.

  • Richtung muss stimmen.

  • Wer weiß schon, ob die offenen Details dann auch wirklich nützlich sind?

  • Am Ende kommt es anders als man denkt, und es wird nicht so heiß gegessen wie es gekocht wird.

  • Spätere Iteration mit entsprechender Detailtiefe kann das klären. Wenn es wichtig ist, dann wird es auch priorisiert werden.

Weitere Anwendungsbeispiele

  • OKR lässt auf der Key Result-Ebene ganz ausdrücklich Key Results zu, die auf der Objective-Ebene nicht erkennbar waren oder auch nicht zu 100 % auf das Ziel einzahlen, aber im dem Kontext als Zusatz Sinn haben.

  • Beim Scrum Cycle wird nicht nur von oben nach unten das geplante Backlog durchgearbeitet, sondern ganz ausdrücklich gibt es einen Feedbackloop aus dem letzten Sprint, der weitere Tickets/Stories für das Backlog erzeugt, die so in der Planungsebene nicht sichtbar waren.

Das fraktale Prinzip ist eine Säule von FAST

Durch seinen fraktalen Grundcharakter lässt sich FAST beliebig skalieren:

  • Ziele und Scope

  • Personen, Abteilungen und Unternehmen

  • Stunden, Tage, Wochen, Monate, Jahre usw.

 

  • ins Detail: Projekt → Thema → Anforderung → Aufgabe

  • ins Große: Projekt → Multiprojekt → Programm → Portfolio → Enterprise