So plant Microsoft mit DevOps

Microsoft ist eines der größten Unternehmen der Welt, das Agile-Methoden einsetzt. Im Laufe der Jahre hat Microsoft einen DevOps-Planungsprozess entwickelt, der von den kleinsten Projekten bis hin zu großen Projekten wie Windows reicht. In diesem Artikel werden viele der gewonnenen Erkenntnisse und Praktiken beschrieben, die Microsoft bei der Planung von Softwareprojekten im gesamten Unternehmen implementiert.

Instrumentelle Änderungen

Die folgenden wichtigen Änderungen tragen dazu bei, Entwicklungs- und Versandzyklen fehlerfreier und effizienter zu gestalten:

• Kulturelle Ausrichtung und Autonomie fördern
• Den Fokus von Einzelpersonen in Teams ändern
• Neue Planungs- und Lernstrategien erstellen
• Ein Multi-Crew-Modell implementieren
• Die Codeintegritätspraktiken verbessern
• Transparenz und Verantwortlichkeit fördern

Kulturelle Ausrichtung und Autonomie fördern

Peter Drucker sagte: „Kultur isst Strategie zum Frühstück.“ Autonomie, Meisterschaft und Zielstrebigkeit sind zentrale menschliche Motivationen. Microsoft versucht, PMs, Entwicklern und Designern diese Motivatoren zur Verfügung zu stellen, damit sie die Möglichkeit haben, erfolgreiche Produkte zu entwickeln.

Zwei wichtige Faktoren für diesen Ansatz sind Ausrichtung und Autonomie.

• Die Ausrichtung erfolgt von oben nach unten, um sicherzustellen, dass Einzelpersonen und Teams verstehen, wie ihre Verantwortlichkeiten mit den umfassenderen Geschäftszielen übereinstimmen.
• Autonomie erfolgt von unten nach oben, um sicherzustellen, dass Einzelpersonen und Teams Einfluss auf alltägliche Aktivitäten und Entscheidungen haben.

Es besteht ein empfindliches Gleichgewicht zwischen Ausrichtung und Autonomie. Zu viel Ausrichtung kann eine negative Kultur schaffen, in der Menschen nur das tun, was ihnen gesagt wird. Zu viel Autonomie kann zu einem Mangel an Struktur oder Richtung, ineffizienter Entscheidungsfindung und schlechter Planung führen.

Den Fokus von Einzelpersonen in Teams ändern

Microsoft organisiert Personen und Teams in drei Gruppen: PM, Design und Engineering.

• PM definiert, was Microsoft erstellt und warum.
• Design ist für die Gestaltung dessen verantwortlich, was Microsoft erstellt.
• Engineering baut die Produkte und stellt ihre Qualität sicher.

Microsoft-Teams weisen die folgenden Hauptmerkmale auf:

• Interdisziplinär
• 10–12 Personen
• Selbstverwaltend
• Klare Charta und Ziele für 12–18 Monate
• Physische Teamräume
• Eigene Funktionsbereitstellung
• Eigene Funktionen in der Produktion

Vertikale Teams sind das Ziel

Früher waren Microsoft-Teams horizontal und deckten die gesamte Benutzeroberfläche, alle Daten oder alle APIs ab. Jetzt sind vertikale Teams das Ziel von Microsoft. Die Teams sind durchgängig für ihre Bereiche des Produkts verantwortlich. Strenge Richtlinien auf bestimmten Ebenen sorgen für Einheitlichkeit zwischen den Teams im gesamten Produkt.

Das folgende Diagramm verdeutlicht den Unterschied zwischen horizontalen und vertikalen Teams:

Selbstauswahl von Teams zulassen

Ungefähr alle 18 Monate führt Microsoft eine „Übung mit gelben Haftnotizen“ durch, bei der Entwickler auswählen können, an welchen Bereichen des Produkts sie in den nächsten Planungszeiträumen arbeiten möchten. Diese Übung bietet Autonomie, da die Teams entscheiden können, woran sie arbeiten möchten, und organisatorische Ausrichtung, da sie das Gleichgewicht zwischen den Teams fördert. Ungefähr 80 % der Mitarbeiter in dieser Übung bleiben in ihren aktuellen Teams, fühlen sich jedoch gestärkt, weil sie die Wahl hatten.

Neue Planungs- und Lernstrategien erstellen

Dwight Eisenhower sagte: „Pläne sind wertlos, aber die Planung ist alles.“ Die Microsoft-Planung lässt sich in die folgende Struktur unterteilen:

• Sprints (3 Wochen)
• Pläne (3 Sprints)
• Saisonzeiten (6 Monate)
• Strategien (12 Monate)

Ingenieure und Teams sind hauptsächlich für Sprints und Pläne verantwortlich. Die Führungskräfte sind in erster Linie für Saisonzeiten und Strategien verantwortlich.

Das folgende Diagramm veranschaulicht die Planungsstrategie von Microsoft:

Diese Planungsstruktur trägt auch dazu bei, den Lernerfolg bei der Planung zu maximieren. Teams können Feedback einholen, herausfinden, was Kunden wünschen, und Kundenwünsche schnell und effizient umsetzen.

Ein Multi-Crew-Modell implementieren

Frühere Methoden haben eine „Unterbrechungskultur“ von Fehlern und Live-Site-Vorfällen gefördert. Microsoft-Teams haben ihre eigene Methode entwickelt, um Fokus zu bieten und Ablenkungen zu vermeiden. Teams organisieren sich für jeden Sprint in zwei unterschiedliche Crews: Funktionen (F-Crew) und Kunden (C-Crew).

Die F-Crew arbeitet an festgelegten Features, und die C-Crew beschäftigt sich mit Live-Site-Problemen und Unterbrechungen. Das Team legt einen rotierenden Rhythmus fest, mit dem Mitglieder Aktivitäten einfacher planen können. Weitere Informationen zum Multi-Crew-Modell finden Sie unter Produktive, kundenorientierte Teams erstellen.

Die Codeintegritätspraktiken verbessern

Vor der Umstellung auf Agile-Methoden haben die Teams es zugelassen, dass sich Codefehler ansammeln, bis der Code am Ende der Entwicklungsphase abgeschlossen war. Die Teams haben dann Fehler entdeckt und daran gearbeitet, sie zu beheben. Diese Vorgehensweise führte zu einer Achterbahnfahrt der Fehler, die sich negativ auf die Teammoral und die Produktivität auswirkte, da die Teams an Problembehebungen arbeiten mussten, anstatt neue Funktionen zu implementieren.

Teams implementieren jetzt eine Fehlergrenze, die durch die Formel # of engineers x 5 = bug cap berechnet wird. Wenn die Fehleranzahl eines Teams am Ende eines Sprints die Fehlerobergrenze überschreitet, muss es die Arbeit an neuen Funktionen einstellen und Fehler beheben, bis die Obergrenze unterschritten ist. Teams müssen nun im Prozess Zeit zur Problembehandlung aufwenden.

Transparenz und Verantwortlichkeit fördern

Am Ende jedes Sprints sendet jedes Team eine E-Mail, in der es berichtet, was es im vorherigen Sprint erreicht hat und was es im nächsten Sprint plant.

Ziele und wichtige Ergebnisse (OKRs)

Teams sind am effektivsten, wenn ihnen klar ist, welche Ziele die Organisation erreichen möchte. Microsoft bietet Klarheit für Teams durch Ziele und wichtige Ergebnisse (OKRs).

• Zielsetzungen definieren die zu erreichenden Ziele. Zielsetzungen sind bedeutsame, konkrete, handlungsorientierte und idealerweise inspirierende Absichtserklärungen. Zielsetzungen stellen große Ideen dar, keine tatsächlichen Zahlen.
• Wichtige Ergebnisse definieren Schritte zur Erreichung der Ziele. Die wichtigsten Ergebnisse sind quantifizierbare Ergebnisse, die den Fortschritt auswerten und erfolgsbezogene Ziele in einem bestimmten Zeitraum angeben.

OKRs spiegeln die bestmöglichen Ergebnisse wider, nicht nur die wahrscheinlichsten Ergebnisse. Führungskräfte versuchen, ehrgeizig und nicht vorsichtig zu sein. Teams zu ermutigen, herausfordernde Schlüsselergebnisse zu verfolgen, beschleunigt das Erreichen von Zielen und priorisiert Arbeiten, die auf größere Ziele hinarbeiten.

Die Einführung eines OKR-Frameworks kann Teams aus den folgenden Gründen helfen, die Leistung zu verbessern:

• Jedes Team ist am Plan ausgerichtet.
• Teams konzentrieren sich auf das Erreichen von Ergebnissen und nicht auf das Abschließen von Aktivitäten.
• Jedes Team ist regelmäßig für seine Anstrengungen verantwortlich.

OKRs können auf unterschiedlichen Ebenen eines Produkts vorhanden sein. Beispielsweise kann es Produkt-OKRs auf oberster Ebene, OKRs auf Komponentenebene und OKRs auf Teamebene geben. Die Ausrichtung von OKRs ist relativ einfach, insbesondere, wenn Ziele von oben nach unten festgelegt werden. Auftretende Konflikte sind wertvolle Frühindikatoren für organisatorische Fehlausrichtungen.

OKR-Beispiel

Ziel: Eine starke und zufriedene Kundenbasis aufbauen

Schlüsselergebnisse/Ergebniskennzahlen:

• Erhöhen Sie den externen Net Promoter Score (NPS) von 21 auf 35.
• Erhöhen Sie die Zufriedenheit mit Dokumenten von 55 auf 65.
• Der neue Pipeline-Flow hat einen Apdex-Score von 0,9.
• Die Warteschlangenzeit für Aufträge beträgt 5 Sekunden oder weniger.

Weitere Informationen zu OKRs finden Sie unter Geschäftsergebnissen anhand von Zielen und Schlüsselergebnissen messen.

Die richtigen Metriken auswählen

Wichtige Ergebnisse sind nur so nützlich wie die Metriken, auf denen sie basieren. Microsoft verwendet führende Indikatoren, die sich auf Veränderungen konzentrieren. Im Laufe der Zeit bilden diese Metriken ein Arbeitsbild der Produktbeschleunigung oder -verzögerung. Microsoft verwendet häufig die folgenden Metriken:

• Veränderung der monatlichen Wachstumsrate der Einführung
• Leistungsänderung
• Änderung der Lernzeit
• Änderung der Häufigkeit von Vorfällen

Teams vermeiden Kennzahlen, die keinen Mehrwert für die Ziele bieten. Auch wenn sie bestimmte Verwendungszwecke haben, sind die folgenden Metriken nicht hilfreich, um den Fortschritt bei der Erreichung von Zielen zu verfolgen:

• Genauigkeit der ursprünglichen Schätzungen
• Absolvierte Stunden
• Codezeilen
• Teamkapazität
• Teamburndown
• Teamgeschwindigkeit
• Anzahl der gefundenen Bugs
• Codeabdeckung

Vor Agile und nach Agile

In der folgenden Tabelle sind die Änderungen von Microsoft-Entwicklungsteams zusammengefasst, die bei der Einführung von Agile-Praktiken vorgenommen wurden.

Vorher	After
Meilensteine von 4 bis 6 Monaten	3-Wochen-Sprints
Horizontale Teams	Vertikale Teams
Persönliche Büros	Teamräume und Remotearbeit
Lange Planungszyklen	Kontinuierliche Planung und Schulung
PM, Dev und Test	PM, Design und Engineering
Jährliche Kundenbindung	Kontinuierliche Kundenbindung
Featurebranches	Jeder arbeitet in der Hauptfiliale
Teams mit mehr als 20 Personen	Teams mit 8–12 Personen
Geheime Roadmap	Öffentlich freigegebene Roadmap
Zeitaufwand zur Behebung von Fehlern	Kein Aufwand
Spezifikationsdokumente mit 100 Seiten	PowerPoint-Spezifikationen
Private Repositorys	Open Source oder Inner Source
Umfassende Organisationshierarchie	Flache Organisationshierarchie
Installationszahlen bestimmen den Erfolg	Die Benutzerzufriedenheit definiert Erfolg
Funktionen werden einmal pro Jahr ausgeliefert	Funktionen werden bei jedem Sprint ausgeliefert

Wichtige Erkenntnisse

• Nehmen Sie die agile Wissenschaft ernst, aber seien Sie nicht zu streng. Agile kann zu streng ausgelegt werden. Lassen Sie die Agile-Denkweise und -Kultur wachsen.
• Feiern Sie Ergebnisse, keine Aktivität. Die Bereitstellung von Funktionalität überwiegt den Aufwand an Codezeilen.
• Liefern Sie bei jedem Sprint aus, um einen Rhythmus und eine Kadenz festzulegen und alle Aufgaben zu finden, die erledigt werden müssen.
• Bauen Sie eine Kultur auf, in der Sie die gewünschte Verhaltensweise erreichen.