Das nächste Planning steht an und der Backlog ist nicht gut genug strukturiert und beschrieben, sodass das Team nicht gut genug schätzen kann? Du bekommst kurzfristig eine Aufgabe zugeschoben, die Du nicht richtig verstehst? Shit-In/Shit-Out ist eine wesentliche Ursache für den mangelnden Erfolg agiler Methoden und dem Scheitern so vieler Projekte. The Standish Group report (2019) weist als Top-Faktor die mangelnde Güte aus: “83.9% of IT projects partially or completely fail.”
Häufig ist nicht klar, was zu tun ist
Häufig verstärken sich durch Remote Collaboration die Probleme. Die Ursache ist jedoch nicht die Zusammenarbeit selbst, sondern oft die Güte der Stories beziehungsweise der Anforderung. Mit Güte ist hier die Voraussetzung gemeint, damit Menschen eine Chance erhalten, es gut zu machen. Das Gegenteil von Güte wäre Strenge. Laut Manifesto for Agile Software Development wird funktionierende Software höher gewertet als umfassende Dokumentation (Beck et. al., 2001). Der Agile-way-of-working hat die Zusammenarbeit verbessert und die Auswüchse an Dokumentation begrenzt, jedoch das häufig auf Kosten der Güte.
Güte ist die Qualität und die gegenseitige unterstützende Zusammenarbeit, damit die Nachfolgeprozesse gut ablaufen und die Stakeholder erhalten, was sie brauchen.
Wer nicht kurzfristig Kollegen fragen kann, was mit der Story oder Aufgabe gemeint ist, hängt oft alleingelassen in der Luft. Man kann zwar sein Bestes geben und fantasieren, was gemeint sein könnte – umso ärgerlicher wird es dann, wenn man falsch lag und man im Review die bittere Quittung erhält. Es lässt sich also schon an der Aufgabenbeschreibung erkennen, ob Menschen eine Chance haben, es gut zu machen oder nicht.
Eine Umfrage bei den Code Days 2019 ergab eine durchschnittliche Güte der Stories im Backlog von (5), was auf der KiE Skala (1 bis 10) nicht ausreichend ist.
Die agilen Experten, die alle eine operative Rolle in agilen Vorhaben ausübten, bewerteten somit 91% der Stories aus ihrer jeweiligen Praxiserfahrung als nicht gut genug. Die Erfahrung aus 10 Jahren Agile Transformation Coaching zeigt ein ähnliches Bild: die Güte der Stories über unterschiedliche Branchen und diversen Vorhaben liegt nur bei (5). Das heißt nicht, dass Ihr zu denen gehört, es heißt nur, wenn Agile Transformation notwendig war, war die Güte auch immer ein Thema, was erhebliches Verbesserungspotenzial aufwies.
Der Güteprozess sorgt für Klarheit
Was können das Team und der Stakeholder also machen, damit Stories gut genug für den nächsten Prozess-Schritt beschrieben sind? Der Schlüssel ist der Güteprozess. Dieser wird beim Agile-Way-of-Working vor allem im Refinement angewendet und implementiert, wie in allen Prozessübergängen von der Epic in die Stories. Bei klassischen Projekten sollte Raum geschaffen werden, um die Anforderungen in ihrer Güte reifen zu lassen.
Story oder Anforderung
Auf der Anforderungsseite steht bei Agile-way-of-working als Verantwortlicher der Product Owner, bei tradierten Projekten letztendlich der Projektleiter, wenn der Projektauftrag geschlossen wird. Der Güteprozess nimmt die Person – den Vorgänger –, welcher eine Anforderung stellt, und den Nachfolger wie das agile Umsetzungsteam in den Fokus.
Der Product Owner verantwortet die Güte der Stories im Backlog, die den Arbeitsvorrat repräsentieren. Die Güte reflektiert, wie reif die Stories oder die Anforderungen sind, bevor sie zu Tasks im Sprint-Backlog werden. Die notwendige Güte der Stories hängt von vielen Parametern ab wie der Reife des Teams und der Reife des Agile-way-of-working. Typisch sind jedoch eine Priorität, Ergebnistyp und Umfang, eine Kurzbeschreibung, das Ziel, das verfolgt wird, sowie der Owner. Erst, wenn die Stories reif genug sind, also die vereinbarten Dimensionen in den Stories beschrieben sind, versieht der Product Owner diese mit einer Gütekennzahl als KiE-Zahl. Das ist die Einschätzung der Güte, wie gut die Story aus Sicht des Product Owner beschrieben ist. Gut genug würde auf der KiE-Skala eine (8) bedeuten.
So reift die Güte
Das agile Team spiegelt dem Product Owner wiederum mit einer KiE-Zahl zurück, welche Güte die Story tatsächlich für sie hat, um die Story gut umsetzen zu können. Ist die Zahl zwischen (8) und (10), so wird damit die Wertschätzung für die Arbeit des Product Owner ausgedrückt. Die agilen Werte werden einfach gelebt, statt darüber zu lamentieren. Das agile Team kann ohne weitere Kommunikation an der Story arbeiten.
Ist die Güte-Zahl eine (6) oder (7), so drückt das agile Team damit aus, dass noch Verbesserungen notwendig sind, um es gut machen zu können. Das agile Team kommt nun in die Pflicht, mit der Ressourcenfrage dem Product Owner anzugeben, was es noch braucht, um in der Story eine Güte von (8) zu erreichen. Die geringe Hebung der Güte wird direkt im Dialog mit dem Product Owner gelöst. Der Product Owner kann dann das Notwendige dem agilen Team geben, das, was sie brauchen, um gut arbeiten zu können.
Ist die Güte-Zahl von (1) bis (5), wird die Story zurückgewiesen, da die Qualität nicht ausreicht. Hier muss der Product Owner mit dem Owner der Story noch einmal selbst reflektieren und eine höhere Güte abliefern. Auch hier ist das agile Team in der Pflicht, die Ressourcen mitzugeben, damit der Product Owner nun seine Arbeit gut machen kann. Durch diesen Prozess wachsen alle miteinander und der Agile-way-of-working verfestigt sich bei allen.
Das klingt sehr einfach und ist es auch. Der Güteprozess hat jedoch eine große Wirkung. Insbesondere bei Projekten, die remote an unterschiedlichen Orten zusammenarbeiten, reden die Menschen mit einer klaren Orientierung miteinander und stellen meist fest, dass nur kleine Angaben gefehlt haben, woraus häufig größere Eskalationen entstanden sind. Durch die abgestufte Interaktion erleben alle, dass meist die Ressourcen vorhanden sind, um ein gutes Ergebnis zu erreichen. Tatsächlich ist die Integration des Güteprozesses und der DecisionMaking-Prozess ein Change, der als solcher committet, eingeführt und verstetigt werden muss. Die Integration der Gütekennzahlen in Collaboration Tools wie Jira oder Trello erfordern nur kleinen Aufwand.
Priorisierung und Commitments
Wenn nach dem Güteprozess die Stories klar beschrieben sind und sich die Menschen besser verstehen, ist die Voraussetzung gegeben, um die Priorisierung durchzuführen, um dann im Sprint-Planning festzulegen, was gemacht wird und was nicht.
Nach der Priorisierung und dem Sprint-Planning wird es mit dem Commitment-Prozess ein Kinderspiel, das Ziel und die zugehörigen Stories für den Sprint zu committen.
Damit sind alle Voraussetzungen für ein erfolgreiches Review geschaffen, indem die Stakeholder wiederum mit der Güte-Kennzahl die erreichten Ergebnisse wertschätzen oder sie in eine weitere Schleife zur Verbesserung schicken. Der Loop von der Anforderung über Epic, Story und umgesetztes Ergebnis wird geschlossen.
Alle Beteiligten im Agile-way-of-working erhalten nun die Chance, es gut zu machen und die Stakeholder erhalten, was sie brauchen. Der Güteprozess sorgt somit selbst-organisierend für eine funktionierende Zusammenarbeit und einen wertschätzenden Umgang.
Menschen beginnen sich gegenseitig zu verstehen, enger zusammenarbeiten und sich gegenseitig eine Chance zu geben, es gut zu machen.
Digitized Services für den Güteprozess
Bist Du gezwungen, remote zu arbeiten oder möchtet Ihr im Team alle gleichzeitig zu Wort kommen mit automatischer Dokumentation?
Mit dem Remote DecisionMaker lassen sich sowohl der Güteprozess als auch der Priorisierungs- und Commitment-Prozess abbilden. Reifere agile Teams implementieren die Gütekennzahlen im Backlogsystem und integrieren den digitized DecisionMaker in allen agilen Ceremonies.
Wie man scheitert
Die Güte der Stories ist neben dem fehlenden Commitment und der unangemessenen Prozesstreue in agilen Methoden einer der dominierenden Faktoren beim Scheitern agiler Vorhaben: „Research shows that 70% of complex, large-scale agile change programs don’t reach their stated goals.“ (IBM 2013, 2015, Forbes 2018, Standish Group 2019 mit 84%).
Success-Story – Velocity von 3 auf 30
Ein Referenzprojekt wurde mit klassischem Projektvorgehen begonnen und stand mit einer nachträglich gemessenen Velocity: 3 nach 12 Monaten vor dem Scheitern. Als Maßnahmen wurden DecisionMaking und Scrum eingeführt. Trotz oder gerade, weil das Team zur Remote Collaboration gezwungen war, entfaltete der Güteprozess sofort nach Einführung von Agile-way-of-working seine Wirkung.
Die agile Transformation dauerte 3 Monate und nach 6 Sprints war eine stabile Velocity erreicht. Das DevPos-Vorhaben wurde nach 16 Monaten erfolgreich abgeschlossen.
Jetzt bist Du dran
Mache nun auch Du einen weiteren Schritt Richtung Agile-Way-of-Working. Führe den KiE-Güteprozess in Deinem Team ein und erlebe, wie der sichere Prozess die Güte der Stories steigert und Ihr die Chance erhöht, es gut machen zu können.
Ihr werdet ein gemeinsames Verständnis entwickeln und als Team fachübergreifend zusammenwachsen.
Wir unterstützen Dich gerne dabei.
Mehr zur Artikelreihe Künstliche Intelligenz
Weitere Beiträge über Künstliche Intelligenz und wie diese mit KiE erweitert werden kann, findest Du nach den Quellen unten bei Schlagworte „Künstliche Intelligenz“.
_______________
Juni 2020, Elsa Graf und Richard Graf
„Fehlende Güte ist der Top-Faktor aller teilweise oder komplett gescheiterten Vorhaben.“ Richard Graf
Quellen
Graf, Richard: Die neue Entscheidungskultur: Mit gemeinsam getragenen Entscheidungen zum Erfolg. Carl Hanser Verlag GmbH Co KG, 2018
K. Beck et. al. (2001). Manifest für agile Softwareentwicklung. Abgerufen 02. Juni 2020, von https://agilemanifesto.org/iso/de/manifesto.html
McKinsey (2019): Why do most transformations fail?. Abgerufen 02. Juni 2020, von https://www.mckinsey.com/business-functions/transformation/our-insights/why-do-most-transformations-fail-a-conversation-with-harry-robinson
Standish Group report 2019. Abgerufen 02. Juni 2020. www.opendoorerp.com/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail/