GitHubs Playbook für erfolgreiche Engineering-Systeme

• Für den Engineering-Erfolg ist es wichtig, dass die drei Bereiche Qualität (Quality), Geschwindigkeit (Velocity) und Entwicklerzufriedenheit (Happiness) im Gleichgewicht sind
• Das ESSP (Engineering System Success Playbook) bietet dafür ein dreistufiges Framework, um diese Bereiche integriert zu verbessern und so den Geschäftserfolg zu maximieren
• Anhand von 12 Kernmetriken, die auf verschiedenen Frameworks wie SPACE, DevEx, DX Core 4, DORA basieren, lässt sich der aktuelle Stand der Organisation erfassen, Prioritäten entsprechend den Verbesserungszielen setzen und schrittweise Veränderung umsetzen und anpassen
  • Diese 12 Metriken sind so aufgebaut, dass sich jeder Bereich quantitativ nachverfolgen lässt, und können je nach Situation der Organisation angepasst werden
• Alle Verbesserungen basieren auf Nachhaltigkeit auf Teamebene und systemischem Denken und betonen einen ausgewogenen Ansatz, der Frühindikatoren und Spätindikatoren gemeinsam berücksichtigt
• Angestrebt wird keine schnelle Verbesserung, sondern nachhaltige langfristige Veränderung
• Mit ESSP kann man auch ohne eigene Messtools starten; eine erste Diagnose über qualitative Methoden wie Umfragen ist ebenfalls sinnvoll
• GitHub betont anhand eigener Beispiele, dass qualitätsorientierte Verbesserungen sich letztlich auch positiv auf Geschwindigkeit und Entwicklerzufriedenheit auswirken

GitHubs Metriken für Engineering-Erfolg

• Quality
  • Change failure rate: Änderungsfehlerquote
    → Anteil der Änderungen, die zu Ausfällen oder Problemen geführt haben
    • Berechnung: (Anzahl fehlgeschlagener Deployments / Gesamtzahl der Deployments) × 100
    • Tipp: Im Team klar festlegen, nach welchen Kriterien etwas als Fehler gilt (z. B. Rollback, Monitoring-Warnung usw.)
  • Failed deployment recovery time: Wiederherstellungszeit nach fehlgeschlagenen Deployments
    → Zeit, die benötigt wird, um ein fehlgeschlagenes Deployment zurückzusetzen oder den Normalzustand wiederherzustellen
    • Berechnung: Median aus „Zeitpunkt der abgeschlossenen Wiederherstellung − Zeitpunkt des Fehlers“ für jedes fehlgeschlagene Deployment
    • Tipp: Empfehlenswert ist die automatische Erfassung über Alerting-Systeme oder Logs. Statt des Durchschnitts sollte der Median verwendet werden, um Ausreißer zu vermeiden
  • Code security and maintainability: Code-Sicherheit und Wartbarkeit
    • Berechnung: Gesamtbewertung von Anzahl der Schwachstellen, Komplexität, Coverage usw. mithilfe statischer Analysetools, GitHub Advanced Security, CodeQL usw.
    • Tipp: Regelmäßige automatische Scans einrichten. Nützlich, um die Wirkung von Refactoring oder Änderungen an Sicherheitsrichtlinien zu messen
• Velocity
  • Lead time: Lead Time
    → Zeit, bis eine Codeänderung in der Produktion ankommt
    • Berechnung: Zeit vom Erstellen des PR bis zum Deployment nach dem Merge
    • Tipp: Die Verwendung des Medians statt des Durchschnitts reduziert Verzerrungen. Bei langer Lead Time sollten Wartezeiten bei PRs oder Review-Verzögerungen separat gemessen werden
  • Deployment frequency: Deployment-Frequenz
    → Wie häufig Deployments in die Produktion erfolgen
    • Berechnung: Anzahl der Deployments in einem bestimmten Zeitraum (pro Tag/Woche)
    • Tipp: Es sollte klar definiert werden, ob automatisierte Deployments mitgezählt werden; für kleine Teams kann eine wöchentliche Betrachtung sinnvoller sein
  • PRs merged per developer: Gemergte PRs pro Entwickler
    • Berechnung: Gesamtzahl gemergter PRs / Anzahl der beitragenden Entwickler
    • Tipp: Nicht als Vergleichsmaßstab, sondern zur Messung der Effizienz des Team-Workflows verwenden. Sollte zusammen mit PR-Größe oder -Komplexität interpretiert werden
• Developer Happiness
  • Flow state experience: Flow-Erlebnis
    • Berechnung: Bewertung von „Häufigkeit/Dauer jüngster Flow-Erlebnisse“ per Entwicklerumfrage
    • Tipp: Eine regelmäßige Erhebung mindestens einmal pro Monat wird empfohlen. Freitextantworten können zusätzliche qualitative Erkenntnisse liefern
  • Engineering tooling satisfaction: Zufriedenheit mit Engineering-Tools
    • Berechnung: Erhebung von Zufriedenheit bei der Tool-Nutzung und gewünschten Verbesserungen per Entwicklerumfrage
    • Tipp: Wenn man nach einzelnen Tools aufschlüsselt (IDE, CI, Issue-Tracking usw.), lassen sich konkrete Verbesserungsansätze ableiten
  • Copilot satisfaction: Zufriedenheit mit Copilot
    • Berechnung: Zufriedenheitsumfrage unter Copilot-Lizenzinhabern (NPS oder Punktbewertung)
    • Tipp: Ein Vergleich zwischen Zeitpunkten wie direkt nach der Einführung und nach drei Monaten ist empfehlenswert. Feedback kann helfen, Schulungen und Nutzungsszenarien zu verbessern
• Business Outcomes
  • AI leverage: AI-Nutzungsgrad
    • Berechnung: Anteil von Copilot-Commits, Übernahmerate von AI-Codevorschlägen, Nutzungszeit usw.
    • Tipp: Die Nutzung der Copilot Telemetry API von GitHub oder interner Instrumentierung ist möglich. Noch aussagekräftiger wird die Analyse zusammen mit qualitativem Feedback
  • Engineering expenses to revenue: Verhältnis von Engineering-Kosten zu Umsatz
    • Berechnung: Engineering-bezogene Ausgaben / Gesamtumsatz
    • Tipp: Erfordert klar definierte interne Buchungsstandards. Für Vergleiche wird eine monatliche oder quartalsweise Trendanalyse empfohlen
  • Feature engineering expenses to total engineering expenses: Anteil der Kosten für Feature-Entwicklung an den gesamten Engineering-Kosten
    • Berechnung: (Ausgaben für Feature-Entwicklung / gesamte Engineering-Ausgaben)
    • Tipp: Für eine genaue Messung müssen die Kriterien zur Abgrenzung nicht featurebezogener Kosten wie Wartung, Infrastruktur oder Tests vorab klar definiert werden

[Drei Schritte für Engineering-Erfolg]

Step 1: Identify the current barriers to success

• Entscheidend ist, die Probleme im aktuellen Entwicklungsprozess und die Hindernisse, die den Engineering-Erfolg blockieren, zu identifizieren
• Dies dient als Baseline zur Festlegung der künftigen Verbesserungsrichtung und Prioritäten
• Ansatz
  • Analyse des gesamten SDLC(Sofware Development Life Cycle), um Engpässe zu erkennen
  • Bei GitHub erfolgt die Analyse anhand von 12 Standardmetriken, je nach Organisationscharakteristik können aber auch nur einige davon genutzt werden
• Beteiligung des Teams
  • Nicht eine einzelne Führungskraft, sondern das gesamte Team sollte den Verbesserungsprozess gemeinsam definieren
  • Es reicht auch aus, mit nur wenigen Metriken ein sinnvolles Gespräch zu beginnen
• Methodik

  • 1. Grundlegenden Ablauf verstehen

    • Der gesamte Engineering-Ablauf wird in folgende Schritte unterteilt betrachtet:
      • Planung (Plan) → Entwicklung (Develop) → Review (Review) → Build (Build) → Test (Test) → Release (Release) → Betrieb (Operate)

  • 2. Quantitative Signale erfassen

    • Dabei werden quantitative Daten wie die folgenden analysiert:
      • Deployment-Frequenz: Wie oft wird deployt
      • Lead Time: Wie viel Zeit vergeht vom Schreiben des Codes bis zum Deployment
      • Change Failure Rate: Wie hoch ist der Anteil der Deployments, nach denen Fehler auftreten
      • MTTR (mittlere Wiederherstellungszeit): Wie viel Zeit vergeht vom Auftreten eines Problems bis zur Wiederherstellung

  • 3. Qualitative Signale erfassen

    • Sammlung von erfahrungsbasiertem Feedback von Entwicklern und Teams:
      • Wann empfinden Teammitglieder Ineffizienz
      • Welche Tools oder Verfahren verursachen wiederholt Probleme
      • Welche Aktivitäten erzeugen die größte psychologische Belastung
    • Methoden:
      • Umfragen, Retrospektiven, 1:1-Interviews usw. nutzen
      • Es kann auch ein vordefinierter ESSP-Fragenkatalog verwendet werden

  • 4. Kernprobleme definieren

    • Auf Basis der gesammelten Daten werden Barrieren (Barrier) definiert
    • Beispiele:
      • "Die lange Lead Time verzögert die Entwicklung neuer Funktionen"
      • "Häufige Build-Fehlschläge verringern die Zuverlässigkeit von Deployments"
      • "Entwickler erleben häufig Context Switching"
    • Probleme sollten konkret und beobachtbar formuliert werden

  • 5. Priorisierung der Metriken

    • Statt alle Metriken gleichzeitig zu verbessern, sollte der Fokus auf ein oder zwei Metriken mit dem größten Einfluss liegen
    • Diese Priorisierung dient in Step 2 und Step 3 später als Maßstab für Verbesserungsversuche und Erfolgsmessung
• Tipps für die erfolgreiche Durchführung von Step 1
  • 1. Auf Grundursachen statt auf Symptome fokussieren
    • Nicht nur oberflächliche Symptome betrachten, sondern tief zur Wurzel des Problems vordringen
      • Beispiel: Es kann so aussehen, als sei der Grund für langsames Tempo das "manuelle Testen", tatsächlich kann die eigentliche Ursache aber ein mangelndes Vertrauen in automatisierte Tests sein
    • Dafür ist es hilfreich, sich an in der Softwareentwicklung häufig auftretenden Antipatterns zu orientieren
  • 2. Antipatterns heranziehen
    • Antipatterns sind häufig verwendete Lösungsansätze, die das eigentliche Problem nicht lösen und stattdessen Nebenwirkungen verursachen können
    • GitHub stellt Beispiele für mögliche Antipatterns im Team als separate Ressource bereit, die als Instrument zur Selbstüberprüfung genutzt werden kann
  • 3. Die richtigen Personen einbeziehen
    • In Task 1 von Step 1 ist es wichtig, Input von Mitgliedern mit unterschiedlichen Rollen einzuholen
      • Beispiel: Entwickler, Tester, Betrieb, Security, Product Manager usw.
    • So lässt sich der gesamte Workflow aus mehreren Perspektiven verstehen, ohne bestimmte Blickwinkel zu übersehen
  • 4. Quantitative und qualitative Daten ausgewogen nutzen
    • Metriken allein reichen nicht aus, um den gesamten Kontext zu verstehen
    • Zusätzlich zur quantitativen Analyse sollte auch qualitatives Feedback zu psychologischen, kulturellen und kollaborativen Problemen im Team gesammelt werden
    • Beispiel: sinkende Team-Moral, fehlende Kommunikation oder Unzufriedenheit in Retrospektiven werden in Zahlen nicht sichtbar
  • 5. Nicht zu viele Barrieren auswählen
    • Nicht versuchen, alle Probleme auf einmal zu lösen, sondern sich auf die einflussreichsten und dringendsten Barrieren konzentrieren
    • Werden anfangs zu viele Verbesserungsaufgaben aufgenommen, besteht die Gefahr, Umsetzungskraft und Momentum zu verlieren
  • 6. Psychologische Sicherheit gewährleisten
    • Es sollte ein Umfeld geschaffen werden, in dem Teammitglieder ohne Angst vor Nachteilen oder Vergeltung offen ihre Meinung äußern können
    • Das ist eine zentrale Voraussetzung dafür, die echten Probleme sichtbar zu machen, und erhöht die Glaubwürdigkeit und Wirksamkeit der Verbesserungsaktivitäten
  • 7. Vergleiche dienen dem Lernen, nicht der Bewertung
    • Vergleiche von Metriken zwischen Teams oder Unterschiede in Workflows sollten zur Gewinnung von Erkenntnissen und nicht zur quantitativen Leistungsbewertung genutzt werden
    • Da sich Situation, Ziele, Tech-Stack und Rahmenbedingungen von Team zu Team unterscheiden, können einfache Vergleiche zu Missverständnissen führen
    • Stattdessen sollte eine Lernkultur gefördert werden, in der geteilt wird, was gut funktioniert, und Lehren daraus gezogen werden

Schritt 2: Bewerten, was getan werden muss, um Ihr Ziel zu erreichen

• Ziel
  • In diesem Schritt wird analysiert, welche Veränderungen umgesetzt werden müssen, um das in Schritt 1 definierte Kernproblem (Barrier) zu lösen.
  • Es geht über die bloße Einführung von Funktionen oder den Wechsel von Tools hinaus und zielt darauf ab, die grundlegenden Ursachen und Lösungen auf organisatorischer, technischer und kultureller Ebene zu identifizieren.

• 1. Ursachenanalyse des aktuellen Zustands

  • Es reicht nicht, nur Ergebnisse wie „zu langsam“ oder „geringe Zufriedenheit“ festzustellen; stattdessen muss geklärt werden,
    • warum es langsam ist,
    • welche strukturellen oder organisatorischen Gründe dahinterstehen,
    • und was veränderbar ist und was nicht.
  • Verfügbare Werkzeuge:
    • 5-Why-Methode
    • Fishbone-Diagramm (Ursache-Wirkung)
    • Analyse qualitativen Feedbacks aus Team-Retrospektiven

• 2. Mögliche Lösungen ableiten

  • Brainstorming zu technischen, kulturellen und prozessbezogenen Lösungsansätzen für das Problem
  • Beispiele:
    • Technisch: Testgeschwindigkeit erhöhen, CI/CD-Pipeline verbessern
    • Kulturell: Code-Review-Praktiken überarbeiten, Onboarding verbessern
    • Prozesse: PR-Größe begrenzen, Merge-Kriterien ändern
  • Von GitHub empfohlene Methode:
    • beobachtungsbasierte Lösungen mit menschenzentrierten Verbesserungen kombinieren

• 3. Wirkung und Risiken bewerten

  • Für jede Lösung werden die folgenden Faktoren bewertet:
    • Erwartete Wirkung: Welche Verbesserungsmetriken könnten beeinflusst werden?
    • Umsetzbarkeit: Team-Ressourcen und realistische Umsetzungskraft
    • Organisatorische Akzeptanz: Grad des Widerstands gegen die Veränderung
    • Unterscheidung zwischen kurz- und langfristiger Wirkung: Liefert sie schnell Ergebnisse oder schafft sie nachhaltige Veränderung?
  • Dafür wird ein Pilotbetrieb empfohlen.
    • Zunächst im kleinen Teamrahmen testen, Feedback sammeln und dann über eine Ausweitung entscheiden

• 4. Priorisieren und kommunizieren

  • Unter mehreren Lösungsansätzen nach den folgenden Kriterien priorisieren:
    • Was den größten Impact liefern kann
    • Was am besten umsetzbar ist
    • Was den dringendsten Schmerzpunkt löst
  • Diese Entscheidung sollte mit dem Team geteilt werden, um Zustimmung zu gewinnen,
    • und idealerweise klar als OKR oder Verbesserungsziel formuliert werden.
• Tipps für die erfolgreiche Umsetzung von Schritt 2
  • 1. Langfristige Nachhaltigkeit unbedingt berücksichtigen
    • Wer sich nur auf kurzfristige Ergebnisse konzentriert, kann dadurch langfristige Probleme verursachen.
      • Beispiel: Ein neues Tool kann die Geschwindigkeit sofort verbessern, aber wenn Schulung, Support und Change Management nicht mitgedacht werden, kann es im Gegenteil Fehler und Verwirrung erzeugen.
    • Deshalb sollte jeder Verbesserungsversuch eine Strategie sein, die auch Wartbarkeit und Skalierbarkeit berücksichtigt.
  • 2. Trade-offs zwischen den einzelnen Bereichen (Zones) berücksichtigen
    • Darauf achten, dass eine Veränderung zur Verbesserung eines Bereichs (z. B. Geschwindigkeit) nicht auf Kosten eines anderen Bereichs (z. B. Entwicklerzufriedenheit oder Qualität) geht.
      • Beispiel: Lockerere Review-Kriterien erhöhen zwar die Geschwindigkeit, können aber Code-Qualität oder Entwicklerermüdung verschlechtern.
    • Immer berücksichtigen, dass sich Auswirkungen über mehrere Bereiche erstrecken, und einen ausgewogenen Ansatz wählen.
  • 3. Das Team von Anfang an einbeziehen
    • Veränderungen, an denen das Team direkt beteiligt ist und die gemeinsam gestaltet werden, haben eine höhere Erfolgswahrscheinlichkeit.
    • Meinungen der Beteiligten einholen, damit Veränderung bottom-up entstehen kann
    • Einseitig angeordnete top-down-Veränderungen können Widerstand und Gleichgültigkeit auslösen.
  • 4. Erfolgsmetriken klar definieren
    • Vor der Umsetzung der Veränderung muss Einigkeit darüber bestehen, was als Erfolg gilt.
    • Beispiel: Wenn „kürzere Deployment-Zeit“ das Ziel ist,
      • nachgelagerter Indikator: tatsächliche Verringerung der Deployment-Zeit
      • vorlaufender Indikator: kürzere PR-Wartezeit, mehr Antworten in Entwicklerumfragen mit dem Inhalt „PR-Geschwindigkeit als verbessert wahrgenommen“
    • Ideal ist es, Leading Indicators und Lagging Indicators gemeinsam zu definieren.
  • 5. Schnelle Experimente statt perfekter Planung anstreben
    • Ein iterativer Ansatz, bei dem selbst kleine Veränderungen schnell ausprobiert, Feedback eingeholt und anschließend verbessert werden, ist wirksam.
      • Auch wenn der erste Versuch noch unvollständig ist, sollte er im kleinen Rahmen getestet und bei nachgewiesener Wirkung ausgeweitet werden.
    • Das senkt das Fehlerrisiko und stärkt die Agilität und Anpassungsfähigkeit des Teams gegenüber Veränderungen.
  • 6. Mit Veränderungen beginnen, die mit wenig Aufwand große Wirkung erzielen
    • Wenn viele und komplexe Veränderungspunkte bestehen, zuerst Verbesserungen im Bereich „hohe Wirkung, geringe Kosten“ auswählen.
    • Beispiel: Die Einführung einfacher Review-Guidelines oder das Entfernen unnötiger Benachrichtigungen lässt sich schnell umsetzen und kann dennoch großen Einfluss auf die Zufriedenheit haben.
    • Frühe Erfolgserlebnisse geben dem Team Selbstvertrauen und liefern den Antrieb, sich schwierigeren Problemen zu widmen.

Schritt 3: Ihre Veränderungen umsetzen, die Ergebnisse überwachen und Anpassungen vornehmen

• In Step 2 identifizierte Verbesserungsmaßnahmen (Interventions) werden tatsächlich in der Organisation umgesetzt; durch Messung der Ergebnisse sowie bei Bedarf Anpassung oder iterative Verbesserung wird ein kontinuierlicher Engineering-Erfolg angestrebt.

• 1. Umsetzung (Implement the change)

  • Vor der Umsetzung sollte Folgendes klar definiert sein:
    • Welche Veränderung wird vorgenommen?
    • Wer trägt die Verantwortung?
    • Anhand welcher Kennzahlen wird bewertet?
    • Von wann bis wann wird gemessen?
  • Aspekte, die bei der Umsetzung zu berücksichtigen sind:
    • Verantwortliche benennen: klare Ownership
    • Team-Onboarding und Schulung: Alle Teammitglieder müssen verstehen, warum die Veränderung nötig ist und was sich ändert.
    • Veränderung dokumentieren: Aufzeichnungen hinterlassen, damit sie bei späteren Retrospektiven und Iterationen als Referenz dienen können.
  • Beispiele für die Einführung:
    • Änderung der Build-Cache-Strategie zur Verbesserung der CI/CD-Geschwindigkeit
    • Änderung der Code-Review-Richtlinie (z. B. Einführung einer Regel für Antworten innerhalb eines Tages)

• 2. Monitoring (Monitor the change)

  • Nach der Umsetzung der Verbesserungsmaßnahme wird die Wirkung anhand der vorab festgelegten Kennzahlen beobachtet und nachverfolgt.
    • Ob sich die Lead Time verkürzt hat
    • Ob die Fehlerrate gesunken ist
    • Ob sich die Zufriedenheit der Entwickler verbessert hat usw.
  • Tools:
    • GitHub Insights, Copilot Telemetry, interne BI-Systeme
    • Dashboard für wöchentliche/monatliche Reports
    • Entwicklerumfragen oder Feedback aus Retrospektiven
  • Wichtige Punkte:
    • Ein Vergleich mit der Baseline muss möglich sein.
    • Es ist wichtig, nicht nur einen einzelnen Wert, sondern Trends (Verläufe) zu betrachten.

• 3. Feedback sammeln (Collect feedback)

  • Zusätzlich zu quantitativen Kennzahlen muss Feedback dazu eingeholt werden, ob die Veränderung aus Sicht der Entwickler tatsächlich hilfreich war.
    • Retrospektiven, anonyme Umfragen, 1:1-Meetings usw. nutzen
    • Prüfen, ob die Verbesserung subjektiv deutlich spürbar ist oder ob die Veränderung im Gegenteil eher Ermüdung verursacht
  • Ohne organisatorischen Konsens vorschnell umgesetzte Veränderungen können Widerstand und Gegenreaktionen auslösen.

• 4. Anpassen oder iterieren (Adjust as needed)

  • Wenn die Ergebnisse der Verbesserungsmaßnahme hinter den Erwartungen zurückbleiben oder Nebenwirkungen auftreten, kann wie folgt reagiert werden:
    • Die Änderung zurücknehmen oder ergänzen
    • Nur bestimmte Elemente beibehalten und den Umfang reduzieren
    • Die Anwendung auf einen größeren Bereich ausweiten
  • Unabhängig davon, ob die Veränderung erfolgreich oder erfolglos war, sollte immer Folgendes gelernt werden:
    • Welche Elemente waren wirksam?
    • Was waren hinderliche Faktoren?
    • Was sollte beim nächsten Mal geändert werden?
• Tipps für eine erfolgreiche Umsetzung von Step 3
  • 1.Keine sofortige Perfektion erwarten
    • Nicht jede Veränderung führt sofort zu einer deutlich sichtbaren Verbesserung.
      • Es kann Zeit brauchen, bis sich die Wirkung zeigt.
      • Auch das Team braucht einen Anpassungsprozess an die Veränderung, daher sind Geduld und kontinuierliche Beobachtung wichtig.
    • Gerade anfangs ist es sinnvoll, mit qualitativen Feedback-Tools wie Umfragen zu erfassen, wie die Veränderung wahrgenommen wird.
  • 2.Veränderungen fortlaufend wiederholen und verbessern
    • Auch wenn etwas einmal erfolgreich war, sollte es nicht einfach unverändert beibehalten, sondern ebenfalls kontinuierlich weiterentwickelt und angepasst werden.
    • Je nach neuen Problemen oder Veränderungen im Umfeld kann es nötig sein, bestehende Verbesserungsmaßnahmen erneut zu überprüfen.
    • Das Team sollte dazu ermutigt werden, dies als regelmäßige Aktivität zu verstehen und den Verbesserungszyklus fortzusetzen.
  • 3.Auf unbeabsichtigte Nebenwirkungen achten
    • Manche Veränderungen können in anderen Bereichen unerwartete Reibungen verursachen.
      • Beispiel: Eine höhere Deployment-Geschwindigkeit ist positiv, aber wenn die Qualitätssicherung schwach ist, kann dies zu mehr Bugs führen.
    • Neben den Kennzahlen sollte auch die Veränderung des gesamten Workflow-Verlaufs betrachtet werden; bei Auffälligkeiten sind sofortige Maßnahmen nötig.
  • 4.Den Zustand der psychologischen Sicherheit kontinuierlich prüfen
    • Auch nach der Veränderung muss ein Umfeld erhalten bleiben, in dem das Team Probleme frei ansprechen kann.
    • Damit sich keine „unausgesprochenen Probleme“ ansammeln, muss eine Atmosphäre geschaffen werden, in der Teammitglieder ehrliches Feedback geben können.
    • Unzufriedenheit mit dem veränderten Prozess, übermäßige Arbeitszunahme, unerwarteter Stress usw.
  • 5.Langfristige Effekte kontinuierlich bewerten
    • Entscheidend sind nicht kurzfristige Ergebnisse, sondern nachhaltige Resultate und eine verbesserte Teammoral.
    • Im Lauf der Zeit sollte fortlaufend geprüft werden:
      • Ob sich die Veränderung etabliert hat
      • Ob neue Nebenwirkungen oder Probleme entstanden sind
      • Ob die Leistung erhalten bleibt oder nachlässt
  • 6.Feedback als Lernchance nutzen
    • Auch gescheiterte Veränderungen sind wertvolle Lernressourcen.
    • Es sollte daten- und feedbackbasiert analysiert werden, was schiefgelaufen ist, und dies muss in den nächsten Versuch einfließen.
    • Wichtig ist auch eine Kultur, die das Team dazu ermutigt, Misserfolge als Lernchance zu begreifen.

Beyond the steps: Make the playbook work for you

• Anpassung

  • Entsprechend den Eigenschaften der Organisation werden zu messende Kennzahlen und Methoden (Telemetry vs. Umfrage) ausgewählt.
  • Messen sollte nicht Selbstzweck sein, sondern als Werkzeug für echte Verbesserungen genutzt werden.

• Change Management

  • Es ist wichtig, mit Change-Management-Frameworks wie ADKAR oder dem Kotter-Modell dabei zu helfen, dass sich die Organisation gut an Veränderungen anpasst.

• Growth Mindset

  • Jeder Versuch sollte als Lernchance verstanden werden; eine Haltung, die Scheitern akzeptiert, ist zentral für kontinuierliche Verbesserung.

• Gamification

  • Motivationsbasierte Belohnungssysteme können positive Effekte haben, bei schlechtem Design jedoch im Gegenteil Qualitätsverluste oder Ungleichgewichte verursachen.

Alternatives to the GitHub Engineering System Success Playbook

• Je nach Situation sind statt ESSP auch einfache Analysen mit Fokus auf die Nutzung einzelner Features oder Verbesserungsstrategien auf Basis einzelner Tools möglich.
• Entscheidend sind ein realistischer Ansatz passend zu Team und Organisation sowie kontinuierliche Verbesserungsbemühungen.