Auch wenn es viele nicht wahrhaben wollen, 83.9% der IT-Projekte sind 2019 teilweise oder komplett gescheitert (Standish Group Report 2019). Diese schier unglaubliche Zahl hat sich seit 1994 auch nicht wesentlich verbessert.
Die Ursachen für die gescheiterten Projekte sind bekannt: mangelnde Güte bei den Anforderungen. Bisher fehlen DecisionMaking-Prozesse, um diesen Mangel sicher und dauerhaft auszugleichen. Die Erfolgskriterien aus dem Standish Group Report: Beteiligung der Benutzer und das Commitment des Managements werden ebenfalls sicher in DecisionMaking-Prozesse integriert.
An kompetenten agilen Teams, Mitarbeitern, Führungskräften, Beratern, Coachs und Trainern mangelt es nicht.
Ausweichen vor der Realität
In meinen Projekten, Key-Notes und Seminaren wird der schmerzhaften Erkenntnis dieser dramatischen Zahlen ausgewichen: „Man müsste definieren was gescheitert und was erfolgreich ist“ oder „Mit agilen Methoden wäre das alles kein Problem mehr.“
Nein, wir müssen es nicht definieren, weil es hinreichend klar ist, was „in time, in budget und in specification“ bedeutet.
Auch nein, weil die Beteiligten es meist selbst wissen und erfahren haben.
Nein, weil mit der Ressourcen-Frage, die in dieser Artikel-Reihe bereits vorgestellt wurde, den Problem-Talk sofort in einen Solution-Talk überführen und alle Ressourcen sichtbar würden, die nötig wären, damit alle Menschen eine Chance bekommen, es gut zu machen: „Die Ressourcen-Frage eröffnet eine neue Dimension der Zusammenarbeit“.
Nein, weil die Veröffentlichung der Standish Group (2019), IBM und McKinsey (2019) sowie vieler anderer eine klare Sprache sprechen und ähnliche Zahlen und Ursachen liefern.
Nein, weil die Überdifferenzierung in Fachbüchern, Artikel, Posts und Weiterbildungen die Situation meist verschleiert und eine Komplexität einführt, die wenig hilft.
Richtig ist, dass die agilen Methoden eine höhere Erfolgsquote haben, aber dem wirkt entgegen, dass die Agilen Transformationen ebenfalls zu 70% scheitern (McKinsey 2019). Auch eingespielte Teams leiden an der mangelnden Güte der Stories. Mehr in dieser Artikelreihe: „Mit dem Güteprozess gelingen agile sowie klassische Vorhaben“.
Nein, der Agile-way-of-working hat die Zusammenarbeit verbessert und die Auswüchse an Dokumentation begrenzt, jedoch häufig auf Kosten der Güte. Die Forderung im „Manifesto for Agile Software Development“ (Beck et. al., 2001) funktionierende Software höher zu werten als umfassende Dokumentation wurde vielfach missinterpretiert. Die Kunst besteht darin, sich nicht in Polaritäten zwischen funktionierender Software und Güte der Stories zu verlieren, sondern den agilen Teams eine Chance zu geben, damit sie selbstorganisiert dafür sorgen können, es gut zu machen. Mehr in dieser Artikelreihe: Umfrage Code Days 2019 zeigt die fehlende Güte als Top-Faktor gescheiterter Projekte, wie den Erfolg, wenn der Güteprozess eingeführt ist.
Was Scheitern für Menschen bedeutet
Hinter der Zahl von 83.9% teilweise und komplett gescheiterten IT Projekte, stehen Menschen, die mit dieser Belastung umgehen müssen sowie die wirtschaftlichen Einschränkungen, die damit einhergehen.
Wie groß ist die Frustration, wenn im Review dem agilen Team gespiegelt wird, dass ihre Arbeit im Sprint nicht gut war? Wie groß ist die Demotivation bei den Projektmitgliedern und beim Projektleiter, wenn die Abnahme nicht erteilt wird, nachdem alle ihr Bestes gegeben haben? Alle Beteiligten kennen die Not, sowohl die, die hart gearbeitet haben und auch diejenigen, die ihre bestellte oder angeforderte Leistung nicht erhalten. Alle kennen auch die Not, ob interne oder externe Projektbeteiligten, wenn die vermeintlich Schuldigen Konsequenzen erleiden müssen.
Agile Teams, Projektleiter und Projektbeteiligte, aber auch Partner, Zulieferer, Bürgermeister, Architekten, Politiker und alle Beteiligten wissen es selbst sehr genau. Die Folgen sind Frustration, Motivationsschwund, innere und reale Kündigungen sowie der Niedergang von Entscheidungs-, Projekt- und Unternehmenskultur.
Remote Collaboration verstärkt das Problem
Die bereits vor der Krise offensichtlichen Mängel, gemeinsam eine ausreichende Güte herbeizuführen, verstärken sich im digitalen Miteinander. Unternehmen sind gezwungen ihre Arbeit remote zu organisieren. Der Weg über eine kurze persönliche Abstimmung bei Gütemängeln ist nicht mehr möglich.
Die Ursache ist selten die Zusammenarbeit selbst, sondern oft die Güte der Stories beziehungsweise der Anforderung.
Der Güteprozess sorgt für Klarheit
Mit Güte ist hier die Voraussetzung dafür gemeint, damit Menschen eine Chance erhalten, es gut zu machen. Güte hat als Begriff zwei Schattierungen
- Güte bedeutet erstens eine innere Bereitschaft, eine Haltung, anderen Gutes zu tun. Güte umfasst Großmut, Entgegenkommen, Hilfsbereitschaft und Milde. Güte ist die Eigenschaft des Wohlwollens. Das Gegenteil von Güte ist die Strenge.
- Zweitens den Grad der erwünschten und beabsichtigten Qualität, und damit den Wert eines Objektes. Wichtige Vertreter wären die DIN-Norm oder die international anerkannte Qualitätsnorm ISO 9000.
Der Güteprozess bringt die Qualität und die gegenseitig wertschätzende Unterstützung in einem klaren Prozess zusammen.
Das Gegenteil von Güte wäre Strenge, die sich in der Zusammenarbeit bedingt eignet. So wird der Anspruch – eine angemessene Qualität gemeinsam herzustellen – zum Standard und die Strenge zur Ausnahme, wenn die Kooperation verweigert wird. So normiert der Güteprozess die gegenseitig unterstützende Zusammenarbeit und lässt so die innere Haltung wachsen.
Die Qualität wird selbstverantwortlich und selbstorganisiert mit dem Güteprozess herbeigeführt. Dieser kann auf alle Beteiligten ausgedehnt werden kann, wie Kollegen, Bereiche, das gesamte Unternehmen und über die Unternehmensgrenzen hinweg auf Kunden, Zulieferer und Partner. Die hieraus resultierende Komplexität und Anzahl der Beteiligten sowie die hohe Geschwindigkeit sind meist nicht mehr direktiv zu steuern und Effizienzvorgaben folglich nur schwer einzuhalten. Der Güteprozess reduziert die Steuerung von außen und verlagert die Organisation in die Selbstverantwortung der Beteiligten.
Was können das Team und die Stakeholder also machen, damit Stories gut genug für den nächsten Prozess-Schritt beschrieben sind? Dieser wird beim Agile-Way-of-Working, wie in Abbildung 02 bei einem einfachen Scrum-Prozess vor allem im Refinement angewendet, wie in allen anderen Prozessübergängen von Ideas zu Stories und beim Sprint-Planning für die Umsetzung des Product-Increments. Der Kreislauf schließt sich wieder im Review und das Product-Increment offenbart, wie gut die Idea umgesetzt wurde. Bei klassischen Projekten sollte Raum geschaffen werden, um die Anforderungen in ihrer Güte reifen zu lassen.
Konsequente Umsetzung des Agile Manifesto
Auf der Anforderungsseite steht beim 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, welcher eine Anforderung stellt, den Prozess-Vorgänger, und den Prozess-Nachfolger wie das agile Umsetzungsteam in die Verantwortung, damit sie die Arbeit selbstorganisiert und selbstverantwortlich durchführen können.
Der Product Owner verantwortet die Güte der Stories im Backlog, die den Arbeitsvorrat repräsentieren. Die Güte reflektiert, wie reif die Stories sind, bevor sie zu Tasks im Sprint-Backlog werden. Die notwendige Güte der Stories hängt von vielen Parametern ab, wie von der Reife des Teams und der Reife des Agile-way-of-working. Für den Güteprozess wird die Story nur um zwei Gütekennzahlen in der Wie-Dimension erweitert.
Das Agile Manifesto wird konsequent umgesetzt und nur so viel dokumentiert, wie die Beteiligten brauchen, um ein Product -Increment zu erstellen, das im späteren Product-Review der Idee der Stakeholder entspricht. Der Umfang sowie die Detaillierung der Stories werden der Reife der Beteiligten im Agile-way-of-working angepasst und reduziert sich selbstorganisiert auf das angemessene Maß, um erfolgreich zusammenarbeiten zu können.
Güteprozess
Mit den Gütekennzahlen in der Beschreibung der Story erhalten alle Beteiligten: Stakeholder, Product-Owner, Scrum Master und das agile Team die Voraussetzung für ein sicheres und transparentes Vorgehen, in dem Stories reifen und das agile Team eine Chance erhält, eine erfolgreiche Arbeit zu machen.
Der Güteprozess ist eine Anwendung der KiE-Skala, um eine normierte und akzeptierte Bewertung der Gütekennzahlen zu erreichen und der Ressourcen-Frage, mit der die notwendigen Ressourcen herausgearbeitet werden.
Mehr in dieser Artikelreihe „Zusammenarbeit auf Augenhöhe mit einem universellen Bewertungssystem“.
Mehr in dieser Artikelreihe „Die Ressourcen-Frage eröffnet eine neue Dimension der Zusammenarbeit“.
Die zwei KiE-Zahlen (8,7) dienen dazu den Prozess sicher zu steuern und die jeweilige Verantwortung den Personen mit ihren Rollen zuzuordnen und sie in die Pflicht zu nehmen.
Innovation 01: Der Product Owner versieht die Story mit einer Gütekennzahl (8), siehe Abbildung 02, über seine Einschätzung der Güte der Story. Als Innovation führt der Güteprozess den Product Owner in die agilen Werte:
- Offenheit
- Beteiligung
- Fokus, Augenhöhe
- Mut
- Wertschätzung und
- Commitment,
Wie geschieht das? Indem er selbst reflektiert, welche Qualität er produziert. Diese erste Innovation ist ungewohnt in der bisherigen agilen wie tradierten Arbeitswelt und der erste Erfolgsfaktor.
Gut genug bedeutet auf der Standard-KiE-Skala eine (8) und wird meist als Standard-Qualität erwartet sowie vorausgesetzt. Manchmal ist es jedoch sinnvoll eine niedrigere Güte zu wählen und dem agilen Team zu signalisieren, dass die Story noch nicht ausgereift ist.
So reift die Güte
Innovation 02: Das agile Team spiegelt dem Product Owner wiederum mit einer KiE-Zahl (7) zurück, siehe Abbildung 02, welche Güte die Story tatsächlich für sie hat, um die Story gut umsetzen zu können. Diese zweite Innovation ist zentral, weil er die Selbstverantwortung im Güteprozess verankert. Es wird nicht mehr vorgeschrieben, was sein müsste, das nur die bekannten fruchtlosen Verflechtungen anfeuert, mit der Menschen wie Unternehmen seit so vielen Jahren kämpfen. Das agile Team agiert offen mit klarem Fokus auf den Reifungsprozess und fordert auf Augenhöhe selbstverantwortlich die notwendige Zuarbeit ein.
Die vom agilen Team gespiegelte KiE-Zahl drückt die Wertschätzung für die Arbeit des Product Owners auf, insbesondere wenn sie (8), (9) oder (10=exzellent) ist. Die agilen Werte werden einfach gelebt, anstatt darüber zu lamentieren.
Innovation 03: Der weitere Prozess der Zusammenarbeit ist offen im Güteprozess verankert und jeder weiß was zu tun ist und wer für welche Situation verantwortlich ist. Das Team kann bei einer Gütekennzahl von (8) bis (10) ohne weitere Kommunikation an der Story arbeiten. Die Offenheit erlaubt dem Team eigenverantwortlich dafür zu sorgen, das die agile Zusammenarbeit gelingt. Die klassische Führung wird ersetzt durch DecisionMaking.
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. Ist die Güte-Zahl von (1) bis (5), wird die Story zurückgewiesen, da die Qualität nicht ausreicht.
Innovation 04: 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) oder ggf. (9) sowie (10) zu erreichen. Diese Innovation ändert komplett die Zusammenarbeit, Problem-Talk wie lamentieren oder resignieren wird durch Solution-Talk ersetzt. Jeder einzelne sorgt dafür, dass es für alle gut ausgeht.
Die geringe Hebung der Güte von (6) oder (7) wird direkt im Dialog mit dem Product Owner gelöst. Der Product Owner kann dann ggf. mit Hilfe des Agile Master dem agilen Team das Notwendige geben, was sie brauchen, um gut arbeiten zu können. Bei einer größeren Kluft mit einer Güte (1) bis (5) muss der der Product Owner mit dem Owner der Story und ggf. den Stakeholdern noch einmal selbst reflektieren, um eine höhere Güte abzuliefern. Auch hier kann der Agile Master unterstützen. Das agile Team ist auch hier in der Pflicht, die Ressourcen so 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.
Innovation 05: Das gesamte Team lernt selbstverantwortlich und selbstorganisiert im Rahmen und Schutz des Güteprozesses. Das klingt sehr einfach und ist es auch. Der Güteprozess hat jedoch eine große Wirkung. Insbesondere bei Projekten, die mit remote Collaboration an unterschiedlichen Orten zusammenarbeiten. Die Kommunikation der Menschen erhält somit eine klare Orientierung. Häufig fehlen nur kleine Angaben, woraus häufig später größere Eskalationen entstehen. Durch die abgestufte Interaktion erleben alle, dass meist die Ressourcen vorhanden sind, um ein gutes Ergebnis zu erreichen.
Wenn wirklich große Themen unklar sind, wird das bereits in einer frühen Phase und nicht erst im Review sichtbar, wenn das Agile Team die Arbeit bereits gemacht hat. Nicht nur, dass dann die Ressourcen verschwendet sind, sondern erhält das agile Team im Review ein niedriges Rating für das Product-Increment, mit den entsprechenden Folgen für die Motivation und erneuten gegenseitigen Schuldzuweisungen.
Innovation 06: Klassische Führung wird durch DecisionMaking ersetzt, das ist integratives Leadership. Tatsächlich sind 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 sind leicht zu bewerkstelligen. In der Stadtverwaltung einer deutschen Großstadt wurden die Gütekennzahlen und die Ressourcen-Frage auf einem Beiblatt auf die Eingabepläne gelegt.
Als Lohn entwickelt sich der agile Mindset, weil die agilen Werte Offenheit, Beteiligung, Fokus, Augenhöhe, Mut, Wertschätzung und Commitment als Verhalten im Prozess eingebettet sind und sich dadurch bei allen Beteiligten entwickeln.
Die Entscheidungskultur und Unternehmenskultur entwickelt sich selbstverantwortlich und selbstorganisiert, weil die Arbeit erfolgreich getan wird. DecisionMaking als integrative Leadership anstelle von autoritärer sowie partizipativer Führung.
Priorisierung und Commitments
Wenn nach dem Güteprozess die Stories klar beschrieben sind und sich die Menschen besser verstehen, ist die Voraussetzung gegeben, die Priorisierung durchzuführen, um im Sprint-Planning festzulegen, was gemacht wird und was nicht.
Nach der Priorisierung wird der Commitment-Prozess ein Kinderspiel, das Sprint-Ziel und die zugehörigen Stories werden mühelos im Sprint-Planning committet.
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.
Auch die Erfolgskriterien, die der Standish Group Report (2019) klar ausweist: Beteiligung der Benutzer, Commitment der Stakeholder und realistische Erwartungen werden als Prozessbestandteile sicher im Güteprozess und mit den DecisionMaking-Prozessen verankert und erhöhen die Chance für eine gelungene Arbeit.
Alle Beteiligten im Agile-way-of-working erhalten nun die Chance, es gut zu machen und die Chance für die Stakeholder steigt, zu erhalten, was sie brauchen. Der Güteprozess sorgt somit selbstorganisierend 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.
Die DecisionMaking-Prozesse sind mit dem digitalisierten DecisionMaker sowohl für Präsenz- als auch für Remote Collaboration zu verwenden. Mit dem 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 digitalisierten DecisionMaker in allen agilen Ceremonies.
Mehr in dieser Artikelreihe „Führe mit dem digitalen KiE-DecisionMaker gemeinsam getragene Entscheidungen herbei“.
Güteprozess für komplexere Prozesse
Der Güteprozess ist für einfache Delegation, für einfaches Agile-Way-of-Working sowie für komplexe traditionelle Projekte und Scaled Agile geeignet.
Success-Story DevOps – Velocity von 3 auf 30
Der größte Software-Integrator weltweit begann beim drittgrößten 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 DecisionMaking 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) im Product-Review. Die Annahme des Vorstandes war, das agile Team 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 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 DecisionMaking trainiert, um anschließend den agilen Prozess „Business-Requiremenn-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 Ressourceneinsatz in angemessener 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.
Mehr zur remote collaboration
Die aktuelle Krise zwingt uns alle zur digitalisierten Zusammenarbeit. Die bereits vor der Krise offensichtlichen Mängel, gemeinsam Entscheidungen herbeizuführen, verstärkt sich im digitalen Miteinander. Unternehmen müssen jetzt ihre Arbeit remote organisieren und viele Menschen versuchen, damit ihre sozialen Kontakte zu leben.
Der frei zugängliche digitized KiE-DecisionMaker löst die Probleme.
Weitere Beiträge über remote Collaboration findest Du nach den Quellen unten bei Schlagworte „Künstliche Intelligenz“.
_______________
Juni 2020, Elsa Graf und 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
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
Standish Group report 2019. Abgerufen 02. Juni 2020. www.opendoorerp.com/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail/
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
Jeff Sutherland et. al.: Unternehmensführung Schnell und Flexibel, Abgerufen am 12. Juni 2020 von https://www.harvardbusinessmanager.de/heft/d-146757099.html
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/