Heute arbeiten Entwickler bei Microsoft viel autonomer und effizienter

Mit mehr als 100.000 Entwicklern ist Microsoft einer der größten Software-Hersteller der Welt. Die Produktgruppen waren auch die Keimzelle der digitalen Transformation von Microsoft, die um 2006 begann und sich über Jahre erstreckte. Der Grund für den Wandel: Auch die Software-Branche steht seit gut 20 Jahren unter dem Druck des digitalen Wandels.

Dem gleichen Druck unterliegen heute Unternehmen aus jeder Branche, denn die Zukunft gehört dem Geschäft mit digitalen Produkten. Unternehmen werden zum Softwareanbieter und bauen ihr Geschäft um. Agilität und Innovationskraft spielen dabei eine große Rolle. Auf dieser Reise hat Microsoft schon ein großes Stück zurückgelegt. Und die Geschichte dieses Wandels birgt interessante Lehren für die Produktivität von Unternehmen.

Jeden zweiten Dienstag eines Monats war Patchday

Anfang des Jahrtausends arbeiteten Microsofts Produktgruppen rund dreieinhalb Jahre daran, Visual Studio 2005 aus der Tür zu bekommen. Die Windows-Entwicklungszyklen erstreckten sich im Schnitt auch über drei Jahre, SQL dauerte noch länger. Aufgrund der langen Produktionszyklen war es für Software-Unternehmen nicht einfach, die Anforderungen an künftige Releases zu definieren.

Starre und komplizierte Prozesse taten ihr übriges. Es war an der Tagesordnung, dass Kunden manch neue Funktion nicht nutzen konnten, weil die Software unausgereift oder falsch geplant war - auch weil sich der Markt in der Zwischenzeit weiterentwickelt hatte. Jeden zweiten Dienstag im Monat lieferte Microsoft daher gesammelt ein Update mit Aktualisierungen.

Unter dem neuen CEO Satya Nadella fällte Microsoft 2014 die Entscheidung, den traditionellen Zyklus der Branche endgültig zu durchbrechen und die heterogenen Entwicklungsumgebungen zu vereinheitlichen sowie zu modernisieren. "Das war der Startschuss für das One Engineering System (1ES), das so gut sein musste wie die Entwicklungssysteme der bekannten Cloud-Companies", erinnert sich Sam Guckenheimer, der 2003 zu Microsoft kam. Zuvor war der Manager für die Produktlinienstrategie bei Rational zuständig, einem Anbieter von Entwicklungs-Tools.

Eat your own dogfood

Seit jeher setzt Microsoft seine eigenen Produkte selbst ein und so basiert auch das One Engineering System auf den eignen Produkten. Microsoft verfügt über ein umfangreiches Portfolio an Plattformen und Tools für die Entwicklung: von der Cloudplattform Azure über GitHub bis zu Visual Studio. "Die Verbindung der Produktlinien von Azure DevOps und der Open-Source-Plattform GitHub ist die Grundlage unserer eigenen Transformation", erklärt Guckenheimer. "Und die Erfahrungen aus unserem eigenen Change gingen natürlich in die Anforderungen unserer Tools und Services ein."

Der Wandel bei Microsoft basiert auf fünf Grundpfeilern: konsequente Orientierung am Kunden, volle Verantwortlichkeit ("You Build It, You Love It"), Team-Autonomie, ein neues Qualitätsparadigma sowie Infrastruktur als flexible Ressource. Und er war erfolgreich: Heute bearbeiten die Entwickler täglich etwa 85.000 Deployments, 500.000 Work Items werden aktualisiert, so Guckenheimer.

Ping-Pong statt langer Abschlag

Grundlage ist ein kontinuierliches Feedback der Anwender, aus dem sich ein optimaler Regelkreis entwickelt: Statt langer Abschläge wie beim Golf spielen sich Produktgruppen und Nutzer die Bälle in schneller Folge zu und verbessern so die Produkte. "Nun liefern wir kontinuierlich innerhalb von Tagen und Wochen aus." Möglich wird dies vor allem durch das stetige Feedback der Nutzer und die Fähigkeit, die notwendigen Verbesserungen in kurzer Zeit zu entwickeln, zu testen und freizugeben.

Der Best Case? Heute könne innerhalb eines Tages auf einen Twitter-Post reagiert werden, wenn Nutzer nach einem Feature fragen. Dann meldet sich beispielsweise das Visual Studio Code Team am Nachmittag mit der Nachricht zurück, dass die Funktion nun zur Verfügung steht. "Das ist nicht die Norm", sagt Guckenheimer, "aber es zeigt, was inzwischen möglich ist".

Laut Software-Manager Guckenheimer hilft das Feedback von außen dabei, die Prioritäten und Ressourcen richtig zu setzen. Seine Daumenregel: In einem Drittel der Annahmen zu den Kundenwünschen hat man recht, ein Drittel der Annahmen bringt eine Verbesserung ohne signifikanten Nutzen für den Kunden, das letzte Drittel der Innovationen erfüllt die Erwartungen der Anwender nicht. "Wir wissen das, weil wir das alles messen."

Kundenfeedback digital in die Wertschöpfung integriert

Die Konsequenz für Microsoft lag darin, Feedback gezielt zu sammeln, auszuwerten und so die Trefferrate zu steigern. Heute wird hinter den Kulissen akribisch analysiert, was für die Nutzer funktioniert und was nicht, mit jedem Lieferzyklus werden die Programme aktualisiert und kontinuierlich verbessert. Und je höher die Frequenz der Auslieferung ist, desto mehr steigt der Nutzen der Programme für den Anwender. Was nicht funktioniert, wird möglichst frühzeitig wieder abgestellt. "Telemetriedaten zeigen uns, inwieweit unsere Hypothesen zu den Veränderungen aufgegangen sind."

Diese Herangehensweise ist inzwischen für Unternehmen aller Branchen relevant, in denen Software und Datenanalysen die Produktentwicklung beschleunigen. Beispiel Automotive mit V-Modell, Automotive SPICE und ISO-Compliance: Im Wettbewerb autonomer Fahrzeuge müssen sechs Monate - von der Definition der Anforderung bis zum Release und Einsatz in der Testflotte - in nur noch einer Woche verdichtet werden.

Auf traditionelle Art - mit Übergaben zwischen allen beteiligten Silos - gelinge dies nicht, argumentiert Guckenheimer: "Ziel ist daher ein kontinuierlicher Feedback-Zyklus mit Telemetrie aus dem Auto sowie OTA-Updates." Diese Art der Disruption - wie von Tesla bekannt - alarmiere die meisten Unternehmen, selbst aus konservativen Industriezweigen. "Das Mantra, dass sich jede Firma in eine Software-Company verändert, ist wahr. Sie müssen die Grundlage schaffen, um künftig auf Basis von Daten zu messen, zu validieren und zu entscheiden."

Verantwortung führt zu Aktivität

Die von Guckenheimer gewählte Analogie vom Golfspiel mit seinen langen Abschlägen und dem Tischtennis mit schnellen Ballwechseln erstreckt sich auch auf den Betrieb der Anwendungen. So ist jeder Entwickler eines Feature Teams regelmäßig verantwortlich für den produktiven Service und den Support. "Wenn es einen Live Site Incident gibt", berichtet Guckenheimer, "muss dieser Entwickler innerhalb von fünf Minuten an dem Problem arbeiten beziehungsweise innerhalb von 15 Minuten außerhalb der normalen Arbeitszeiten."

Dies habe aber auch zur Folge, dass man als Entwickler die Schmerzen der Kunden sieht und eigene Defizite in der Telemetrie, den Tests oder dem Troubleshooting erkennt. Alle fehlenden Stücke aus dem Life Site Incident werden gesammelt als Improvement Items, für das "validierte Lernen". Mit Work Items wiederum wird die Quality of Service verbessert, und das Ticket für den Incident kann erst geschlossen werden, wenn wie die Repair Items aus dem Backlog erfasst und in einem Sprint abgearbeitet wurden. "Durch die Feedback-Schleife entwickeln sich Probleme aus allen Bereichen der Software-Entwicklung zu Chancen zum Lernen, um das Leben der Kunden zu verbessern."

Aktivität führt zur Zufriedenheit

Die Umstellung brachte jedoch nicht nur für die Anwender der Tools Vorteile, sondern wirkte sich auch positiv auf die eigenen Mitarbeiter aus. Die Zufriedenheit der Entwickler und die Attraktivität als Arbeitgeber entwickelten sich zu einem konkreten Ziel. So drehen sich die heutigen Top-Metriken für den Erfolg bei Microsoft um die Zufriedenheit der Mitarbeiter, berichtet Guckenheimer aus der Praxis: "Wir fragen unsere Developer regelmäßig, wie glücklich sie mit Prozessen, Tools oder Arbeitsumgebungen sind und wie gut sie dadurch bei der Arbeit unterstützt werden."

Ein Indikator für die Reife von Teams und Organisationen ist der Grad der Autonomie. Hier empfiehlt Oppenheimer eine Kennzahl, mit der Entwickler ihre Autonomie bestimmen können: 1 geteilt durch die Anzahl der Genehmigungen außerhalb des Feature-Teams, um den Code-Change in die Produktion zu bringen. Könne das Team den Code selbst prüfen und die Freigabe erteilen, sei das "Infinite Autonomy", so Guckenheimer. "Eine Autonomie von 1 mit nur einer Genehmigungsschleife ist großartig - allerdings extrem selten. Zehn Freigaberunden bedeuten einen Grad von 0,1 - das ist heute nicht mehr zeitgemäß."

Auch Microsoft-CEO Satya Nadella hat die Befindlichkeiten der Mitarbeiter aufgriffen und zur Chefsache erklärt. So machte er den Wandel der Unternehmenskultur und das 1ES zum Gegenstand des monatlichen Town Hall-Meetings in Redmond - ein Projekt, das wegen diverser Anpassungen rund drei Jahre gedauert hatte. "Nadellas Ansprache unter anderem über die Verbesserungen für unsere Software-Entwickler war ein starkes Symbol dafür, dass das Management auf die eigenen Entwickler gehört und die alten Tools und Prozesse modernisiert hat." Heute nutzen rund 105.000 interne Entwickler Azure DevOps, mehr als 25.000 setzen GitHub ein.

Guckenheimer zufolge stellt CEO Nadella erfolgreiche Projekte bewusst ins Rampenlicht, damit die anderen Abteilungen sich fragen, "warum sie nicht zu der Party eingeladen sind". Ein mächtiges Werkzeug: "Indem man dieses Verlangen bei Kreativen weckt, lassen sich traditionelle Strukturen leichter aufbrechen und modernisieren."