Im ersten Teil dieser Artikelserie erfuhren wir von einem melanesischen Stamm, der begann, einen Cargo-Kult zu praktizieren. In diesem zweiten Teil der Artikelserie möchte ich einige Ratschläge geben, wie du und dein Team vermeiden kannst, zum Cargo-Kult zu werden.
Nachdem sie beobachtet hatten, wie das Militär während des Zweiten Weltkriegs Vorräte mit Flugzeugen einflog, übernahmen die Inselbewohner ein Glaubenssystem, in dem sie magische Rituale durchführten, von denen sie glaubten, dass sie eine technologisch fortschrittlichere Gesellschaft zur Lieferung von Gütern veranlassen würden (Frachtkult).
Auch viele Softwareteams auf der ganzen Welt praktizieren einen Cargo-Kult, wenn es um die Einführung agiler Praktiken geht. Diese Teams haben die zugrunde liegenden Prinzipien nie verstanden und verschwenden nun wertvolle Zeit und Projektbudget, indem sie agile Teams schlecht imitieren, ohne einen sinnvollen Beitrag zu liefern.
Das Cargo-Kult Agile-Syndrom ist der Grund, warum die meisten agilen Transformationen scheitern.
Sehen wir uns einige Fragen an, anhand derer du beurteilen kannst, ob sich deine Investition in agile Praktiken gelohnt hat oder lohnen wird. Dann erkläre ich dir die vier Schritte, mit denen du vermeiden kannst, zum Cargo-Kult zu werden.
Fragen, die du stellen kannst, um nicht zum Cargo-Kult zu werden
Diese Fragen können dir helfen zu beurteilen, ob dein Training oder Coaching eine gute oder schlechte Investition ist oder war:
Klingt das zu einfach?
Reicht es aus, deine drei Projektmanager zu einem zweitägigen Scrum-Training für 999 US-Dollar pro Sitzplatz zu schicken? Kannst du wirklich damit rechnen, das Schiff mit nur 2.997 $ zu retten?
Es heißt Scrum Master und Produktmanager. Weder „Projekt“ noch „Manager“ ist ein beliebter Begriff in agilen Praktiken, und dafür gibt es einen guten Grund.
Wenn es günstig ist und nur ein paar Tage dauert, ist es wahrscheinlich zu schön, um wahr zu sein.
Sei auch vorsichtig mit Scrum Mastern und Produktmanagern auf dem Markt. Frage dich, ob ihr Zertifikat wirklich etwas bedeutet.
Klingt das zu komplex?
Einige größere Unternehmen ziehen das „Scaled Agile Framework“ (SAFe) in Betracht.
Hier ist ein „einfaches“ Diagramm, das erklärt, wie es funktioniert:
In diesem Diagramm ist der Versuch, den Endbenutzer oder Kunden zu finden, so, als würde man „Wo ist Waldo?“ spielen
Wenn du SAFe in Betracht ziehst, empfehle ich dir, zuerst diesen Artikel diesen Artikel zu lesen..
Siehst du Ergebnisse (oder zumindest Verbesserungen)?
Wenn du bereits mit der agilen Transformation begonnen hast, woher weist du dann, dass sie funktioniert? Woher weist du, dass sich deine Fähigkeit, bessere Software schneller auszuliefern, verbessert hat?
Ein häufiger Fehler besteht darin, überhaupt nichts zu messen. Und die Gefahr bei der Fortschrittsverfolgung besteht darin, dass man das Falsche misst.
Ein schlechter Maßstab für deine Fähigkeit, Software zu liefern, sind „User Story Points“. Diese von agilen Methoden wie Scrum vorgeschlagene Metrik hat einen ganz anderen Zweck. Und in den meisten Organisationen, die ich gesehen habe, ist diese Metrik ohnehin verstümmelt (eine weitere Manifestation von Cargo-Kult Agilität).
Was sollte man also stattdessen messen?
In erster Linie wirst du höchstwahrscheinlich am organisatorischen Erfolg interessiert sein, und die Frage sollte daher lauten:
Steigert sich deine Organisationsleistung?
Was das in deinem konkreten Fall bedeutet, hängt natürlich von deinen individuellen kommerziellen und nichtkommerziellen Zielen ab.
Das Maß für die Organisationsleistung korreliert häufig mit der Kapitalrendite und ist robust gegenüber Konjunkturzyklen.
Erfüllen deine KPIs diese Kriterien? Und hat sich deine organisatorische Leistung verbessert?
Hier ist eine alternative Frage die du dir stellen kannst:
Steigert sich deine Software Delivery Performance?
Das DORA-Forschungsprogramm konnte wissenschaftlich nachweisen, dass Organisationsleistung und -erfolg mit der Software Delivery Performance (SDP) korrelieren.
Und die Software Delivery Performance wiederum kann mit 4 vier einfachen Proxy-Metriken gemessen werden:
- Deployment-Frequenz
- Zeit für Änderungen
- Zeit, den Dienst wiederherzustellen
- Ausfallquote
Je nachdem, wie du bei diesen vier Kennzahlen abschneidest (du kannst hier einen kurzen Selbsttest durchführen), bist du entweder ein Low-, Medium-, High- oder Elite-Performer.
Ich empfehle die Messung dieser 4 Software Delivery Performance (SDP)-Kennzahlen, um die Frage zu beantworten, ob deine Fähigkeit, bessere Software schneller auszuliefern, mit der Zeit zunimmt.
4 Schritte um zu verhindern zum Cargo-Kult zu werden
Ich empfehle nicht nur, die richtigen Fragen zu stellen (und sie ehrlich zu beantworten), sondern auch datengesteuert zu arbeiten, um die Prinzipien hinter agiler und schlanker Softwareentwicklung zu verstehen und Praktiken auszuwählen, die tatsächlich funktionieren.
Hier sind die 4 Grundschritte die ich für eine erfolgreiche agile Transformation benutze:
- Fange an zu messen
- Erstelle eine Anzeigetafel
- Setze dir ein Ziel
- Bewege die Messnadel
1. Beginne mit der Messung deiner Software Delivery Performance (SDP)
An diese vier Zahlen zu kommen ist relativ einfach. Es gibt Tools, die dutzende von Integrationen zur Verfolgung von Fehler-Tickets wie JIRA oder Continuous-Deployment-Systeme wie Jenkins anbieten. Aber für den Anfang brauchst du das alles nicht.
Angenommen, deine Software Delivery Performance ist niedrig und du lieferst die Software nur einmal im Monat aus. In diesem Fall reicht es aus, die Ergebnisse manuell zu aktualisieren, indem du die Teams oder Abteilungen fragst, wie oft sie beispielsweise diese Woche Software ausgeliefert haben.
Wenn deine SDP steigt, kann die manuelle Aktualisierung der Ergebnisse lästig werden. Das ist ein gutes Problem. Jetzt hast du und deine Mitarbeiter einen guten Grund, die Erfassung einiger Kennzahlen zu automatisieren.
2. Erstelle dir eine Anzeigetafel und mache deine SDP sichtbar
Ohne eine Anzeigetafel kannst du nicht sagen, ob du das Spiel gewinnst.
Es ist tatsächlich schlimmer. Ohne Anzeigetafel wird das Spiel langweilig. Denn die Spieler im Team werden nicht gezwungen sein, ihr Bestes zu geben und an ihre Grenzen zu gehen.
Ich empfehle dir, alle 4 SDP-Metriken als KPIs zu verfolgen und diese KPIs für alle in deinem Unternehmen sichtbar zu machen.
3. Setze dir ein Ziel, um deine SDP zu beeinflussen
Als nächstes erstelle jährliche und vierteljährliche OKRs, die darauf abzielen, die 4 SDP-Metriken zu verbessern.
Objective and Key Results (OKRs) bieten einen hervorragenden Rahmen für die Verbesserung dieser Metriken. Frühere OKRs zielen darauf ab, die 4 SDP-Metriken zu verbessern.
In diesem Zusammenhang könnte das Ziel darin bestehen, die nächste Stufe auf der Rangliste „Low-Medium-High-Elite Performer“ zu erklimmen. Und das Schlüsselergebnis könnte folgenden Charakter haben:
„Erhöhe <SDP METRIC> von <CURRENT LEVEL> bis <NEW LEVEL> mit <DATE>„
4. Bewege die Nadel, indem Sie SDP-Fähigkeiten erwerben
Das DORA-Forschungsprogramm hat etwa 30 Fähigkeiten identifiziert, die die Leistung und den Erfolg einer Organisation vorhersagen.
Das bedeutet, dass die meisten leistungsstarken Unternehmen über Praktiken verfügen, die diese 30 Fähigkeiten unterstützen. Und die Mehrheit der leistungsschwachen Unternehmen hat diese Fähigkeiten (noch) nicht erworben.
Wähle in diesem letzten Schritt eine (oder mehrere) Fähigkeiten aus und beginne mit der Arbeit am Erwerb oder der Verbesserung dieser Fähigkeiten als OKR-Initiativen.
Fähigkeiten sind keine Praktiken
Fähigkeiten sind nicht unbedingt konkrete Praktiken.
Nimm zum Beispiel die Fähigkeit zum kontinuierlichen Testen. Um diese Fähigkeit zu erwerben, müssen Sie Ihre Abteilungen in funktionsübergreifende Teams umstrukturieren und alle Teammitglieder müssen sich mit Unit-, Integrations- und Abnahmetests vertraut machen. High- und Elite-Performer beherrschen darüber hinaus die Kunst der Test-First-Programmierung.
Es ist nicht immer sofort klar, wie man eine bestimmte Fähigkeit erlangt.
Deshalb kombiniere ich das Konzept der Software Delivery Performance mit eXtreme Programming (XP).
eXtreme Programming (XP) ist etwas komplexer als Scrum (das lediglich ein Framework ist), aber XP ist deutlich weniger kompliziert als SAFe.
Was mir an eXtreme Programming (XP) gefällt, ist, dass es viel spezifischer ist, wenn es um tatsächlich funktionierende agile Praktiken geht. Zum Beispiel Pair Programming, Test-First Programming oder Emergent Design.
XP bringt alles, was in der Softwareentwicklung funktioniert, auf die Spitze.
Scrum hat keine Meinung darüber, welche Praktiken verwendet werden sollen, und genau das führt zu vielen Problemen. XP-Praktiken hingegen wurden sorgfältig ausgewählt, da sie sich bewährt haben und dazu beitragen, häufige Probleme bei der Einführung von agiler Softwareentwicklung zu vermeiden.
Anstatt also Zeit mit Versuch und Irrtum zu verschwenden, empfehle ich dir, dieser agilen Methodik zu vertrauen, welche die meisten Dinge bereits für dich herausgefunden hat.
Zusammenfassung
Hier sind noch einmal die 4 grundlegenden Schritte, die dir helfen können, nicht zum Cargo-Kult zu werden:
- Beginne mit der Messung deiner SDP
- Erstelle dir eine Anzeigetafel und mache deine SDP sichtbar
- Setze ein Ziel um deine SDP zu beeinflussen
- Bewege die Nadel durch das Erwerben von SDP Fähigkeiten
Wenn du mehr über Leistungsmetriken und -funktionen für eXtreme Programming oder Software Delivery erfahren möchtest, wende dich hier an uns. Und falls du daran interessiert bist, die Kunst des Test-First-Programmierens zu erlernen, empfehle ich dir meinen Online-Videokurs anzuschauen oder sich für einen der kommenden Live-Kurse anzumelden.
Bis demnächst
-David