Sachen fertig machen ist wichtig und kann erfordern, sie in sinnvolle Zwischenergebnisse zu zerteilen.
Das Arbeiten in Zwischenergebnissen verringert nicht nur kognitive Last und sorgt für Erfolgserlebnisse, es hat auch andere weitreichende Vorteile:
Konsistente Zwischenergebnisse erzeugen einen Wert schon zum Zeitpunkt ihrer Fertigstellung und nicht erst mit Abschluss der Gesamt-Aufgabe
Zwischenergebnisse dienen als Integrations- und Feedback-Punkte
Fortschritt durch inkrementelles Arbeiten viel direkter erlebbar und messbar
Die Arbeit kann leichter übergeben und von Kolleg:innen fortgeführt werden, was bei kurzfristigen Planänderungen oder krankheitsbedingten Ausfällen hilft
Die Zerlegung macht Priorisierung möglich: Welcher Teil ist von entscheidender Bedeutung und sollte unbedingt früh erledigt werden? Welcher Teil ist Kür?
Arbeiten in Kadenzen, also mit selbstauferlegten regelmäßigen Deadlines, ist in der Softwareentwicklung gang und gäbe. Zusammen mit dem (öffentlichen) Zeigen der Zwischenergebnisse (im „Review“) forciert die Gestaltung von brauchbaren Zwischenergebnissen.
Die Erfahrung aus der agilen Softwareentwicklung zeigt: Das Zerlegen von scheinbar unzerlegbaren Aufgaben in sinnvolle Teile ist im Grunde immer möglich (vgl. dazu die Übung „Elephant Carpaccio“). Software-Teams gehen dabei in der täglichen Arbeit in der Regel sogar noch weiter: Das Einchecken von Code in ein gemeinsames Code-Repository wird technisch ausgeschlossen, wenn nicht ein kompilierbarer und fehlerfreier Zustand erreicht ist!
Die als „Slicing“ bekannte Praktik des Zerschneidens von Anforderungen kann auch als Inspiration beim Kleinschneiden von Tätigkeiten dienen, die nichts mit Software zu tun haben. Der Trick besteht darin, Stücke wie beim Kuchen „vertikal“ zu schneiden (ein „wertstiftendes“ Kuchenstück braucht schließlich alle Schichten) und nicht „horizontal“ (niemand will nur den Kuchenboden).
Schreibe ich etwa ein Konzept, kann ich mit dem Abstract beginnen und schonmal ein Quellenverzeichnis anlegen, weil diese Abschnitte für sich genommen am nützlichsten sind. Sie erfüllen auch schon das Kernbedürfnis des Managements, die sowieso die Details nicht lesen werden. Eine weitere Lesergruppe sind die Enterprise-Architekten. Sie interessieren sich vor allem für Rahmenbedingungen und die wichtigsten Qualitätsanforderungen, daher nehme ich mir diese kurzen Abschnitte als nächstes vor (gemäß Best Practice sind hier ohnehin nur wenige kurze Sätze gefragt). Anschließend erstelle ich die Struktur für das restliche Konzept; so können Leser:innen schon sehen, was sie erwartet. Die Abschnitte fülle ich zunächst mit Stichpunkten, die ich sukzessive ausformulieren und ergänzen kann. Inhalte, die aufgrund von neuen Erkenntnissen oder geänderten Anforderungen nicht mehr korrekt sind, markiere ich schonmal als nicht mehr aktuell und kommentiere kurz, was sich geändert hat. Diese Markierungen können in späteren Schritten abgearbeitet werden. So hat das Dokument jederzeit einen brauchbaren, konsistenten Zustand.
Der Umgang mit Zwischenergebnissen und die notwendige Kritikfähigkeit müssen ggf. geübt werden, wenn dies in einer Organisation noch neu ist. Hierbei kann Training, aber auch einfach ein formaler Rahmen helfen.
Lust auf mehr zum Thema?
Elephant Carpaccio Excercise [alistair.cockburn]
Vertical vs Horizontal Slicing Data Science Deliverables [Data Science - PM] – ein Beispiel für vertikales Slicing in Data-Science-Projekten
