Das nächste Planning steht an und die Reife der Stories ist nicht gut genug. Oft versteht das Team die Story nicht vollständig und kann den Aufwand nur bedingt schätzen. So stehen das Sprintziel und das Commitment dafür auf wackeligen Beinen. Als Konsequenz ist die Enttäuschung und Frustration bei allem hoch, wenn im Review weder die Qualität des Product-Increments noch die Velocity passen.
Shit-In/Shit-Out ist die zentrale Ursache für den mangelnden Erfolg agiler Methoden und dem Scheitern so vieler Projekte. Die ungenügende Güte der Stories, die das agile Team braucht sowie halbherzige Commitments und die unangemessen Prozesstreue führen zum 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) und „84% partially or completely failed“ (Standish Group 2019).
Mit digitalisiertem Decision Making Management (dDMM) wird die Nutzer-Beteiligung garantiert sowie die Commitments des Managements und aller Stakeholder sicher und zeitnah herbeigeführt.
Teile Dein Wissen und erfahre, wie es anderen geht
Du kannst gerne Deine Erfahrung teilen und an den Erfahrungen anderer teilhaben. Nimm einfach am Survey teil: Start Survey.
Wie gut sind Deine Stories beschrieben, damit Du sie bearbeiten kannst?
Häufig ist nicht genau klar, was zu tun ist
Die aktuelle Krise zwingt uns alle zur digitalisierten Zusammenarbeit. Die bereits vor der Krise offensichtlichen Mängel, gemeinsam Entscheidungen herbeizuführen, verstärken sich im digitalen Miteinander. Die Lust zur Mitarbeit und der Nutzen von Video-Conferencing sowie remote Collaboration-Tools wird dadurch erheblich eingeschränkt.
Die Ursache ist aber weniger die Zusammenarbeit, sondern mehr die Güte der Stories oder der Anforderungen. 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. Das „Manifesto for Agile Software Development“ gab „Working software“ eine höhere Priorität über „comprehensive documentation“. Tatsächlich verbesserte sich die Situation mit nutzloser Dokumentation, jedoch wird in vielen agilen Vorhaben die notwendige Güte der Information nicht an die Bedürfnisse und Reife des agilen Umsetzungsteams angepasst. Die zu umfangreiche Dokumentation, die das Agile Manifesto begrenzen wollte, schlägt nun häufig in das andere Extrem um: „nicht gut genug“.
Güte ist die Qualität und die gegenseitige unterstützende Zusammenarbeit, damit die Nachfolgeprozesse selbstorganisiert bearbeitet werden können und die Stakeholder erhalten, was sie brauchen.
Wer nicht kurzfristig Kollegen fragen kann, was mit der Aufgabe oder der Story gemeint ist, hängt anleingelassen 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 Güte der Aufgabenbeschreibung erkennen, ob Menschen eine Chance haben, es gut zu machen oder nicht.
Umfrage Code Days 2019
Die Umfrage bei den Code Days 2019 ergab bei 70 Agilen Experten eine durchschnittliche Güte der Stories im Backlog von (5), auf der KiE Skala (1 bis 10) nicht ausreichend. Die erfahrenen Teilnehmer bewerteten somit 91% der Stories aus ihrer jeweiligen Praxiserfahrung als nicht gut genug. Die Erfahrung aus gut 10 Jahren Agile Transformation Coaching zeigt ein ähnliches Bild: Die Güte der Stories liegt meist zwischen (4) und (6). Das heißt nicht, dass Ihr zu denen gehört. Es bedeutet nur, wenn Agile Transformation Coaching notwendig war, wies die Güte auch erhebliches Verbesserungspotenzial auf.
Mangelnde Prozesstreue
Agile Methoden wie Scrum verlangen ein diszipliniertes Vorgehen, in dessen Rahmen Teammitglieder selbstorganisiert und selbstverantwortlich gute Ergebnisse produzieren. So erreichen agile Teams mit Disziplin die angestrebte Resilienz bei gleichzeitiger Stabilität in Entscheidungsprozessen.
Was alle erfahrenen Scrum-Experten wissen, zeigte auch die Umfrage auf den Code Days 2019, eine nicht ausreichende Prozesstreue von (6). Eine Prozesstreue von nur 31% ist nicht gut genug, damit die Einführung agiler Methoden gelingt.
Die Prozesstreue ist nicht zu verwechseln mit Pedanterie und zwanghaftem Festhalten an Regeln und Vorgaben vermeintlicher agiler Gurus. Die Prozesstreue zielt auf die Einhaltung der Ceremonies, die Güte in den Artfakten und die Verantwortung in den Rollen, damit eine Zusammenarbeit auf Augenhöhe entsteht und die Menschen eine Chance erhalten, es gut zu machen.
Der Güteprozess sorgt für Klarheit
Was können das Team, der Product-Owner und die Stakeholder also machen, damit Stories gut genug für den nächsten Prozess-Schritt beschrieben sind? Der Schlüssel ist der Güteprozess. Dieser findet bei Agile-Way-of-Working vor allem im Refinement statt, sowie in allen Prozessübergängen wie 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 wurde. Der Güteprozess nimmt die Person – den Vorgänger – welcher eine Anforderung stellt und den Nachfolger, wie das agile Umsetzungsteam in den Fokus.
Der Anforderer 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, einer KiE-Zahl. Das ist die Einschätzung der Güte, wie gut die Story aus Sicht des Vorgängers beschrieben ist. Gut genug würde auf der KiE-Skala [Link KiE-Skala] eine (8) bedeuten.
Die Reifung der Güte
Das agile Team spiegelt dem Produkt-Owner wiederum mit einer KiE-Zahl zurück, welche Güte die Story tatsächlich für es hat. Ist die Zahl zwischen (8) und (10), so wird damit die Wertschätzung für die Arbeit des Produkt-Owner ausgedrückt. Die agilen Werte werden einfach gelebt, statt darüber zu lamentieren. Das agile Team kann ohne weitere Kommunikation selbstorganisiert 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 steht nun in der Pflicht mit der Ressourcenfrage [Link Ressourcenfrage] dem Product-Owner anzugeben, was sie noch brauchen, um in der Story eine Güte von (8) zu erreichen. Die geringe Verbesserung der Güte wird direkt im Dialog mit dem Produkt-Owner erreicht. Er kann das Notwendige dem agilen Team geben, was sie brauchen, um gut arbeiten zu können.
Ist die Güte-Zahl von (1) bis (5), wird die Anforderung zurückgewiesen, da die Qualität nicht ausreicht. Hier muss derjenige, der die Anforderung verfasst hat, 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 aneinander und der Agile-Way-of-Working und die agile Werte verfestigen sich bei allen.
Das klingt sehr einfach und ist es auch. Der Güte-Prozess erhält dadurch seine große Wirkung. Insbesondere bei Projekten, in denen remote an unterschiedlichen Orten zusammenarbeitet wird, reden die Leute plötzlich miteinander und stellen meist fest, dass eigentlich 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.
Priorisierung und Commiments
Wenn nach dem Güteprozess die Anforderungen klar beschrieben sind und sich die Stackeholder, Product-Owner sowie agiles Team besser verstehen, ist die Voraussetzung gegeben, um die Priorisierung durchzuführen. Das Sprint-Planning wird zum Kinderspiel und alle wissen, was gemacht wird und was nicht. Mit dem Commitment-Prozess ist es ein Leichtes, das Sprint-Ziel und die zugehörigen Stories zu committen.
Damit sind alle Voraussetzung 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 fokussierte Schleife zur Verbesserung schicken.
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 wertschätzenden Umgang.
Menschen beginnen sich gegenseitig zu verstehen, enger zusammenarbeiten und sich gegenseitig eine Chance zu geben, es gut zu machen.
Digitized Decision Making Management (dDMM)
Bist Du gezwungen remote zu arbeiten oder möchtest Du im Team, dass alle gleichzeitig zu Wort kommen? Ist es für Dich hilfreich, wenn die Entscheidungsprozesse automatisch dokumentiert werden?
Mit dem remote DecisionMaker lassen sich sowohl der Güteprozess als auch Priorisierungs- und Commitment-Prozess abbilden. Reifere agile Teams implementieren die Gütekennzahlen im Backlogsystem und integrieren den digitized DecisionMaker [Link] in allen agile Ceremonies.
Summary
Das aufgeregte Streben nach dem agilen Mindset ist künstlich verursacht. Der agile Mindset entsteht aus gelungenen Entscheidungsprozessen und einer hohen Güte der Stories im Backlog. Die Beteiligten in den Unternehmen und vor allem die Agile Transformation Coachs sind verantwortlich für diese Schwierigkeiten und fatalen Auswirkungen genauso wie die agilen Teams, die diesen Mangel anzeigen müssen. Darrell K. Rigby, Jeff Sutherland und Hirotaka Takeuchi bestätigten dies im Harvard Business Manager 2019, “aber in Wahrheit haben sie das Konzept nie richtig gelernt und verstehen es deshalb auch nicht richtig.“
Sind Entscheidungsmanagement und agile Methoden integriert, wird Agilität erreicht. Neben der notwendigen Flexibilität warten agile Methoden mit digitalisierten Decision Making Management mit einer höheren Performance (Velocity) auf. Als Begleiteffekt steigt die Velocity von agilen Teams um einen Faktor zwei bis vier.
Success-Story: DevOps – Velocity von 3 auf 30
Der größte Software-Integrator weltweit begann beim drittgrößten deutschen Automobilbauer mit klassischem Vorgehen ein DevOps-Projekt und stand mit einer nachträglich gemessenen Velocity von 3 nach 12 Monaten vor dem Scheitern. Als Maßnahme wurde digitalisiertes Decision Making Management mit Scrum als agile Methode 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 überwältigende Wirkung.
Die agile Transformation dauerte 3 Monate und nach 6 Sprints war eine stabile Velocity erreicht. Das DevOps-Vorhaben wurde nach 16 Monaten erfolgreich abgeschlossen.
Success-Story: Business Engineering – Güte von 3 auf 8
Bei einem Agile Transformation Coaching bei einem großen deutschen Online-Händler war die ursprüngliche Problemstellung die niedrige Güte (6) des Product-Increments im Review. Die Annahme des Vorstandes war, das agile Team wäre das Problem und würde nicht die nötige Qualität für eine Abnahme produzieren. Das Shadowing, in dem ein erfahrener Agile Coach den agile Ceremonies beiwohnte, offenbarte sowohl Problem als auch Lösung.
Tatsächlich wurden nur 60% der Stories im Review abgenommen. Jedoch zeigte das Shadowing im Planning zum einen ein hoch entwickeltes Scrum-Vorgehen (Prozesstreue) mit einer Güte von (9) als auch eine ausreichende Güte (8) im Sprint-Backlog.
Die Annahme, das agile Team würde nicht ordentlich arbeiten, konnte nach wenigen Stunden Shadowing nicht bestätigt werden. Die Ressourcen-Frage bei dem erfahrenen agilen Team zeigte, dass die Stories im Mittel nur mit einer Güte (3) spezifiziert waren und dass Senior-Member des agilen Teams, die Güte in aufwändigen Analysen die Güte der Sub-Tasks auf (8) brachten. Shadowing und Analyse der Artefacts: Product-Backlog und Business-Requests bestätigten die Vermutung, dass die Güte (3) und (2) einfach nicht ausreicht, um die Arbeit gut machen zu können.
Das Agile-Coaching wurde umgewidmet zu einem Agile Transformation Coaching für die Erstellung eines agilen Prozesses zur „Business-Requirement-Creation“. Die Beteiligten wurden in Decision Making trainiert, um anschließend den agilen Prozess „Business-Requirement-Creation“ mit agilen Ceremonies und Artefacts zu entwerfen, einzuführen und zu verstetigen.
Nach 6 Monaten wurde der Business-Requirement-Process mit dem Commitment des Vorstandes eingeführt. Alle Artefacts werden mit angemessenem Ressourcen-Einsatz in passender Qualität erstellt. Dabei wird die Qualität bereits in frühen Phasen hergestellt, wodurch spätere Probleme und Aufwände begrenzt werden. Ein geschlossener Kreislauf führt zu einer hohen Reife der Product-Increments und lässt die Kompetenzen und das Vertrauen untereinander wachsen.
_______________
März 2021, Richard Graf
„Mit dem Güteprozess entwickelt sich die Eigenverantwortung der Beteiligten als Voraussetzung, um den gemeinsamen Erfolg herzustellen. Darüber hinaus wird die gemeinsame Unterstützung für das gesamte Lieferergebnis entwickelt und im Prozess verankert.“ Richard Graf
Quellen
K. Beck et. al. (2001). Manifest für agile Softwareentwicklung. Abgerufen am 02. Juni 2020, von https://agilemanifesto.org/iso/de/manifesto.html
Standish Group report 2019. Abgerufen am 02. Juni 2020, von www.opendoorerp.com/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail/
McKinsey (2019): Why do most transformations fail?. Abgerufen am 02. Juni 2020, von https://www.mckinsey.com/business-functions/transformation/our-insights/why-do-most-transformations-fail-a-conversation-with-harry-robinson
Jeff Sutherland et. al.: Unternehmensführung Schnell und Flexibel, Abgerufen am 12. Juni 2020 von https://www.harvardbusinessmanager.de/heft/