Wissenslücken (Knowledge Gaps)

ist einBacklog-Item-Typ
beschreibtNutzbares Wissen

Produktentwicklungen beginnen heute sehr selten „auf der grünen Wiese“. Je nach Kompetenz der Organisation, sind gewisse Dinge bereits bekannt und können wiederverwendet werden. Alle unbekannten Dinge bezeichnet das P4-Framework als „Knowledge-Gaps“. Die Idee dahinter ist, dass eine Produktentwicklung als beendet betrachtet werden kann, wenn alle Knowledge-Gaps in nutzbares Wissen und Design-Entscheidungen verwandelt wurden.

Knowledge-Gaps verbinden die Idee der „Hypothesen“ aus Lean-Startup mit dem „Knowledge-based“ Development von LPPD, dem Risiko-Management klassischer Prozesse und dem risiko-basierten Vorgehen aus dem Unified Process.

In Googles Design-Sprint-Vorgehen heißen die Knowledge-Gaps WKWs (= Wie können wir …) bzw. HMW (= How might we …). Hier ist eine Vorlage, mit der im Team solche Fragestellungen mit Ideen angereichert werden.

Image for post

Dabei schreibt jeder eine Fragestellung auf. Dann werden die Arbeitsblätter im Team rotiert und jeder schreibt eine Idee zur Lösung auf. Das geht so lange, bis die Fragestellung einmal das ganze Team durchlaufen hat. Danach können die Ideen bewertet und entschieden werden.

Issues

Issues sind Abweichungen, die in Review-Prozessen oder beim Testen festgestellt werden. Dabei kann es sich um falsch verstandene Anforderungen, inkorrekte Spezifikationen oder Implementierungen, oder um Fehler in den Abnahmekriterien oder Testfällen handeln. Daher muss für jeden Einzelfall entschieden werden, ob es sich überhaupt um eine Abweichung handelt oder wie diese zu beheben ist.

Andere Vorgehensweisen nennen Issues z.B. Bug oder Deviation.

Die Gap-Map

Die Gap-Map zeigt auf dem Hintergrund einer geeigneten Darstellung des „System-under-Development“ und seines Kontexts, die dazugehörenden Knowledge-Gaps als rote Post-its. Grüne Post-its visualisieren Elemente und Schnittstellen, die nicht geändert werden oder im Laufe des Vorhabens bereits durch Gelerntes entschieden wurden.

Folgende Dinge können über die Gap-Map abgelesen werden:

  1. Bereiche, mit einer Häufung von Knowledge-Gaps bedürfen einer höheren Aufmerksamkeit
  2. Die Summe der Aufwandsschätungen aller gewichteten Knowledge-Gaps ergeben den (Rest-) Aufwand der Produktentwicklung! Die Gewichtung bzw. Aufwandsschätzung wird von dem durchführenden, interdisziplinären Team vorgenommen, z.B. mittels Planning Poker.
  3. Knowledge-Gaps sind Backlog-Elemente auf einer hohen Flughöhe und werden durch Herunterbrechen (Refinement) in kleinere, ausführbare Elemente zerlegt. Damit stellen Knowledge-Gaps den inhaltlichen Plan der Produktentwicklung dar.
  4. Knowledge-Gaps ermöglichen ein einfaches Risiko-Management, da sie die produktbezogenen Unsicherheiten darstellen. (Achtung: Organisatorisches Risikomanagement ist zusätzlich notwendig)
  5. Wenn alle roten Post-its in grüne Post-its verwandelt wurden ist die Produktentwicklung beendet

Durch die Einfachheit und Übersichtlichkeit stellt eine Gap-Map ein hervorragend geeignetes Kommunikationsmittel zwischen dem Team und dem Management dar.

Gap-Backlog und Gap-Burndown

Für das proaktive Risikomanagement und die Fortschrittskontrolle lassen sich die geschätzen Aufwandswerte der Knowledge-Gaps als Burndown-Chart darstellen:

Knowledge-Gap-Tree (Decision Tree)

In jeder Produktentwicklung gibt es Design-Entscheidungen, die das ganze Konzept zum Fliegen bringen oder es unmöglich machen. Diese haben naturgemäß den größten Einfluß und sollten damit auch zuerst getroffen werden.

Der Entscheidungsbaum oder „Decision Tree“ beantwortet die Frage nach der Wichtigkeit und des Einflusses von Knowledge-Gaps, und damit die der Reihenfolge der Bearbeitung und Lösung in Richtung einer Design-Entscheidung. Dafür ist es nötig „vorranginge“ und nachfolgende Knowledge-Gaps zu identifizieren und in eine Reihenfolge von abhängigen Entscheidungen zu bringen.

Durch die Priorisierung der Bearbeitung von Knowledge-Gaps nach ihrem Einfluss, läßt sich das Gesamtrisiko einer Produktentwicklung am schnellsten reduzieren. Damit lässt sich die Aussicht auf Erfolg erhöhen oder das Vorhaben frühest möglich abbrechen, um die genutzten Teams und Ressourcen wertschöpfender einzusetzen.

.


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Product-Owner

Cluster-System-Engineer

.

Portfolio-Owner

Portfolio-Architekt

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Managementkreis der Organisation

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD