9Ein Plan, um zu den High Performern ­aufzuschließen

Von Martin Fowler
Chief Scientist, ThoughtWorks

Vor einigen Jahren las ich einen Bericht, der besagte, dass »wir nun selbstbewusst behaupten können, dass eine starke IT-Performance mit einer starken Unternehmensleistung korreliert und hilft, Produktivität, Rentabilität und Marktanteile zu steigern«. Wenn ich so etwas lese, ist mein erster Reflex, das Ganze mit voller Wucht in den Mülleimer zu feuern, weil das normalerweise nur erfundener Bullshit ist, der sich als Wissenschaft tarnt. Doch dieses Mal zögerte ich, da es der 2014 State of DevOps Report war. Einer seiner Autoren war Jez Humble, ein Kollege und Freund, von dem ich wusste, dass er genauso allergisch auf so ein dummes Zeug reagiert. (Ich muss allerdings gestehen, dass ein anderer Grund, es nicht wegzuwerfen, war, dass ich es auf meinem iPad gelesen habe.)

Stattdessen schrieb ich also Jez eine E-Mail, um herauszufinden, was hinter dieser Aussage steckte. Einige Wochen später telefonierte ich mit ihm und Nicole Forsgren, und sie führten mich geduldig durch die Argumentation. Obwohl ich kein Experte für die Methoden bin, die sie angewendet haben, sagte Nicole genug, um mich zu überzeugen, dass hier eine richtige Analyse stattfand, die weit über das hinausging, was ich normalerweise sehe, selbst in wissenschaftlichen Arbeiten. Ich verfolgte die nachfolgenden State of DevOps Reports mit Interesse, aber auch mit wachsender Frustration. Die Berichte enthielten die Ergebnisse ihrer Arbeit, aber nie die Erklärungen, die Nicole mit mir am Telefon durchgegangen ist. Das untergrub ihre Glaubwürdigkeit erheblich, da es wenig Hinweise gab, dass diese Berichte auf mehr als Spekulationen gründeten. Schließlich überzeugten diejenigen von uns, die hinter die Kulissen geblickt hatten, Nicole, Jez und Gene, ihre Methoden mit diesem Buch offenzulegen. Ich musste lange warten, aber ich bin glücklich, dass ich jetzt etwas habe, das ich wirklich empfehlen kann. Es ist eine Möglichkeit, die Effektivität von IT-Bereitstellung zu durchleuchten – eine, die auf mehr als einigen vereinzelten Erfahrungen von Analysten beruht.

Das Bild, das sie zeichnen, ist überzeugend. Sie beschreiben, wie effektive IT-Unternehmen ungefähr eine Stunde benötigen, um einen Code von »Committed to Mainline« bis zu »Running in Production« zu bringen. Ein Weg, für den unbedeutendere 10Unternehmen Monate benötigen. Effektive Unternehmen aktualisieren ihre Software also mehrmals am Tag, statt einmal alle paar Monate und steigern so ihre Fähigkeit, Software zu nutzen, um den Markt zu erschließen, auf Ereignisse zu reagieren und schnellere Feature-Releases durchzuführen als die Konkurrenz. Dieser massive Anstieg der Reaktionsfähigkeit geht dabei nicht auf Kosten der Stabilität, da die Updates dieser Unternehmen einen Bruchteil der Ausfälle verursachen, im Vergleich zu ihren weniger guten Mitbewerbern – und diese Ausfälle werden normalerweise innerhalb einer Stunde behoben. Ihre Belege widerlegen die bimodale IT-Auffassung, dass man sich zwischen Geschwindigkeit und Stabilität entscheiden müsse. Stattdessen hängt die Geschwindigkeit von der Stabilität ab, sodass gute IT-Praktiken Ihnen beides bieten.

Wie Sie sich also vorstellen können, freue ich mich sehr über dieses Buch, und ich werde es in den nächsten Jahren wohl oder übel empfehlen. (Ich habe bereits einige Teile des Manuskripts in meinen Gesprächen genutzt.) Ich möchte jedoch einige Warnungen aussprechen. Die Autoren erklären sehr gut, warum ihre Umfragemethode ihnen eine gute Datengrundlage bietet. Dennoch fangen diese Umfragen immer noch subjektive Wahrnehmungen ein, und ich frage mich, inwieweit ihre Bevölkerungsstichprobe die IT-Welt im Allgemeinen widerspiegelt. Ich werde mehr Vertrauen in ihre Ergebnisse haben, wenn andere Teams, die andere Ansätze nutzen, ihre Argumentation bestätigen können. Das Buch bietet bereits einiges davon, da die Arbeit von Google in Bezug auf Teamkultur weitere Belege bietet, die ihre Beurteilung stützen, dass generative Unternehmenskulturen nach Ron Westrum wichtig für effektive Softwareteams sind. Weitere Arbeit dieser Art würde mich auch dahingehend beruhigen, dass ihre Schlussfolgerungen den Großteil meiner Fürsprache bestätigen – die Bestätigungstendenz ist eine treibende Kraft (obwohl ich das eigentlich meistens bei anderen feststelle S). Wir sollten ebenfalls daran denken, dass sich ihr Buch auf die IT-Bereitstellung fokussiert, also den Weg vom Commit zur Produktionsumgebung, nicht auf den gesamten Software-Entwicklungsprozess.

Diese Spitzfindigkeiten sollten uns aber nicht von der Hauptrichtung dieses Buches ablenken. Diese Umfragen und deren sorgfältige Analyse bieten einige der besten bestehenden Begründungen hinsichtlich der Praktiken, die die meisten IT-Unternehmen erheblich verbessern können. Jeder, der ein IT-Team leitet, sollte einen genauen Blick auf diese Techniken werfen und daran arbeiten, sie zu verbessern. Jeder, der mit einer IT-Gruppe arbeitet, entweder intern oder mit einem IT-Unternehmen wie unserem, sollte nach diesen Praktiken und einem ständigen Programm kontinuierlicher Verbesserung, das damit einhergeht, streben. Forsgren, Humble und Kim haben ein Bild entworfen, wie effektive IT im Jahr 2017 aussieht, und IT-Fachleute sollten es als einen Plan benutzen, um zu den High Performern aufzuschließen.

157TEIL III
TRANSFORMATION

Wir haben unsere Erkenntnisse darüber, welche Kompetenzen für bessere Softwarebereitstellung und Unternehmensergebnisse wichtig sind, dargestellt. Diese Informationen dann für eine Veränderung Ihres Unternehmens anzuwenden, ist eine komplexe und gewaltige Aufgabe. Daher waren wir sehr erfreut, dass Steve Bell und Karen Whitley Bell einverstanden waren, ein Kapitel über Leadership und Unternehmenstransformationen zu schreiben und ihre Erfahrungen und Einsichten zu teilen, um die Leser auf ihrem eigenen Weg anzuleiten.

Steve und Karen sind Pioniere auf dem Gebiet der Lean IT. Sie wenden Prinzipien und Praktiken mithilfe eines methodenunabhängigen Konzepts an und greifen dabei auf verschiedene Verfahren zurück – DevOps, Agil, Scrum, Kanban, Lean Start-up, Kata, Obeya, Strategie­umsetzung und andere –, jeweils angepasst an die Kultur und die Situation, um Führungskräfte zu coachen und dabei zu unterstützen, leistungsstarke Praktiken und Kompetenzen für organisationales Lernen zu entwickeln.

Hier greifen sie auf ihre Erfahrungen bei ING Niederlande zurück, einer globalen Bank mit mehr als 34 Millionen Kunden weltweit und 52.000 Angestellten, darunter mehr als 9.000 Software-Ingenieure, um das ›Warum‹ und das ›Wie‹ von Leadership, Management und Team-Praktiken zu zeigen, die einen Kulturwandel unterstützen. Das wiederum ermöglicht eine nachhaltige starke Performance in einer komplexen und dynamischen Umgebung.

Steve und Karen erweitern unsere Perspektive über Zusammenhänge von Team-, Management- und Führungspraktiken, über die nützliche Einführung von DevOps und das Einreißen der Silos hinaus – alles notwendig, aber nicht ausreichend. Hier sehen wir die Entwicklung einer ganzheitlichen, durchgehenden Unternehmenstransformation, umfassend und auf den Unternehmenszweck ausgerichtet.

11Ignorieren Sie nicht die wissenschaftlichen Aspekte in diesem Buch

Von Courtney Kissler
VP Digital Platform Engineering, Nike

Meine Reise begann im Sommer 2011. Ich arbeitete bei Nordstrom, und wir hatten die strategische Entscheidung getroffen, uns auf die Digitalisierung als Wachstumsmotor zu fokussieren. Bis zu diesem Punkt war unser IT-Unternehmen auf Kostenoptimierung ausgerichtet. In meiner Präsentation auf dem DevOps Enterprise Summit 2014 berichtete ich, dass einer meiner »Aha«-Momente der Übergang zur Optimierung der Geschwindigkeit gewesen sei. Ich habe viele Fehler auf diesem Weg gemacht und wünschte, ich hätte damals Zugang zu den Informationen in diesem Buch gehabt. Eine Falle, in die wir getappt sind, war zu versuchen, mithilfe einer Top-down-Verfügung agile Methoden einzuführen, nach dem Motto ›passt schon‹. Dabei haben wir uns nicht auf Messungen fokussiert (oder darauf, die richtigen Dinge zu messen), Führungsverhalten nicht geändert und den Übergang wie ein Programm behandelt, statt eine lernende Organisation zu schaffen (das hat nie stattgefunden).

Während der Reise verschob sich der Fokus auf ergebnisorientierte Teamstrukturen, darauf, unsere Zykluszeiten zu kennen (indem wir unsere Wertstromkarte verstehen), die Druckwelle klein zu halten (mit einem oder zwei Teams starten, statt sich zu übernehmen), Daten zu nutzen, um Aktionen und Entscheidungen zu lenken, anzuerkennen, dass Arbeit Arbeit ist (legen Sie keinen Backlog mit Features und keinen Backlog mit technischen Schulden und keinen Backlog mit operativer Arbeit an, stattdessen nur einen Backlog, weil nicht-funktionale Anforderungen (NFRs) Features sind und die Reduzierung technischer Schulden die Stabilität des Produkts verbessert). Nichts davon passierte über Nacht, und es waren viele Experimente und Anpassungen auf dem Weg nötig.

Was ich aufgrund meiner Erfahrung als wahr ansehe, ist, dass, wenn Sie die Leit­linien aus diesem Buch annehmen, Ihr Unternehmen tatsächlich leistungsstärker wird.

Es funktioniert für alle Arten von Softwarebereitstellung und folgt einer Methodologie. Ich habe es persönlich erfahren und viele Beispiele davon, wie diese Praktiken innerhalb von Mainframe-Umgebungen, in Teams für traditionelle Softwarepakete 12und Produktteams angewendet werden. Es kann über die gesamte Bandbreite funktionieren. Man braucht Disziplin, Ausdauer, transformationale Führung und einen Fokus auf die Menschen. Schließlich sind die Menschen der größte Wert eines Unternehmens. Allerdings verhalten sich Unternehmen oft nicht entsprechend. Obwohl der Weg nicht einfach werden wird, kann ich sagen, dass es sich definitiv lohnt. Sie werden nicht nur bessere Ergebnisse erreichen, auch Ihr Team wird zufriedener sein. Als wir beispielsweise begannen, den eNPS (Employee Net Promoter Score) zu messen, hatte das Team, das diese Praktiken anwendete, den höchsten Score in unserem Technologieunternehmen.

Etwas anderes, das ich auf diesem Weg gelernt habe, ist, wie wichtig es ist, durch die oberste Führungsebene unterstützt zu werden. Und zwar nicht nur in Worten, sondern auch in Taten. Die leitenden Führungskräfte müssen ihre Verpflichtung auf dem Weg zu einer lernenden Organisation leben. Ich werde die Handlungsweisen teilen, die ich mit meinem Team zu entwickeln versuche. Ich glaube leidenschaftlich daran, die Realität anzuerkennen und zu nutzen. Wenn ich eine leitende Führungskraft bin und mein Team sich nicht wohl dabei fühlt, Risiken zu verteilen, werde ich die Realität niemals vollständig kennenlernen. Wenn ich nicht wirklich neugierig bin und mich nur zeige, wenn es einen Ausfall gibt, dann scheitere ich als Führungskraft. Es ist wichtig, Vertrauen aufzubauen und zu zeigen, dass ein Ausfall zu einer Untersuchung führt (siehe das Westrum-Modell in diesem Buch).

Sie werden auf dem Weg Skeptikern begegnen. Ich habe Dinge gehört wie: »DevOps ist das neue Agil«, »Lean hat nichts mit Softwarebereitstellung zu tun«, »Für das Mobile-App-Team hat es natürlich funktioniert. Die sind blauäugig.« Wenn ich diese Skeptiker getroffen habe, habe ich versucht, externe Beispiele anzuführen, um die Diskussion zu beeinflussen. Ich habe die Hilfe von Mentoren erfolgreich in Anspruch genommen – ohne sie, wäre es sehr schwierig geworden, fokussiert zu bleiben. Die Informationen aus diesem Buch zu haben, wäre äußerst hilfreich gewesen, und ich ermuntere Sie sehr, sie innerhalb Ihres Unternehmens zu nutzen.

Ich habe die meiste Zeit meiner Karriere im Einzelhandel verbracht. In dieser Branche ist es immer wichtiger geworden, sich weiterzuentwickeln, und Software bereitzustellen ist mittlerweile Teil der DNA eines jeden Unternehmens. Ignorieren Sie die wissenschaftlichen Aspekte in diesem Buch nicht. Sie werden Ihnen helfen, Ihre Transformation in ein leistungsstarkes Technologieunternehmen zu beschleunigen.

15Einleitung

 

Ende 2013 begannen wir eine vierjährige Forschungsreise, um zu untersuchen, welche Kompetenzen und Praktiken wichtig sind, um die Entwicklung und Bereitstellung von Software und damit den Nutzen für Unternehmen zu verbessern. Diese Ergebnisse werden hinsichtlich ihrer Rentabilität, Produktivität und Marktanteile betrachtet. Ähnlich starke Effekte beobachten wir bei den nicht-kommerziellen Auswirkungen von Effektivität, Effizienz und Kundenzufriedenheit.

Diese Forschung befriedigt ein Bedürfnis, das derzeit am Markt nicht bedient wird. Unser Ziel ist es, Softwareentwicklung und -bereitstellung zu verbessern. Dafür haben wir die von uns angewandten exakten Forschungsmethoden, die traditionell nur im akademischen Bereich zu finden sind, der Branche zugänglich gemacht. Indem wir die Branche unterstützen, die Kompetenzen zu identifizieren und zu verstehen, die tatsächlich Leistungsverbesserungen in einer statistisch sinnvollen Weise bewirken – mehr als nur episodisch und jenseits der Erfahrungen von nur einem oder wenigen Teams –, können wir ihr helfen, sich zu verbessern.

Um die Forschung aus diesem Buch durchführen zu können (zusätzlich zu der Forschung, die wir immer noch aktiv fortführen), verwenden wir Querschnittstudien.

Dieselben Methoden werden bei der Forschung im Gesundheitswesen angewandt (z. B. um den Zusammenhang zwischen Bierkonsum und Fettleibigkeit zu untersuchen, Bobak et al. 2003), in der Arbeitsplatzforschung (z. B. um den Zusammenhang zwischen dem Arbeitsumfeld und kardiovaskulären Erkrankungen zu untersuchen, Johnson und Hall 1988) und in der Gedächtnisforschung (z. B. um Unterschiede zwischen der Entwicklung und dem Verfall des Gedächtnisses zu untersuchen, Alloway und Alloway 2013). Da wir die Branche eingehend auf sinnvolle Art untersuchen wollen und verstehen möchten, was zu einer Verbesserung der Softwareperformance und der Unternehmensleistung führt, verwenden wir exakte wissenschaftliche Forschungsmethoden und veröffentlichen große Teile unserer Arbeit in wissenschaftlichen, durch Peer-Review begutachteten Magazinen. Weitere Informationen über die von uns angewandten Methoden finden Sie in Teil II: Die Forschung.

16Die Forschung

Unsere Forschungen umfassen mehr als 23.000 Umfrageantworten aus der ganzen Welt. Wir haben mit mehr als 2.000 einzelnen Unternehmen gesprochen, von kleinen Start-ups mit weniger als fünf Angestellten, bis zu großen Unternehmen mit mehr als 10.000 Mitarbeitern. Wir haben Daten von Start-ups und modernen Internetunternehmen erhoben, genauso wie solche aus hochregulierten Branchen, wie Finanzen, Gesundheitswesen und Regierungen. Unsere Daten und Analysen umfassen Software, die auf brandneuen »Greenfield«-Plattformen entwickelt wurde, genauso wie die Pflege und Entwicklung von Legacy Codes.

Die Erkenntnisse in diesem Buch gelten unabhängig davon, ob Sie eine traditionelle »Wasserfall«-Methode anwenden (bekannt als abgeschlossen, strukturiert oder plangesteuert) und gerade Ihre technologische Transformation beginnen oder ob Sie schon seit Jahren agile Methoden und DevOps-Praktiken nutzen. Das liegt daran, dass Softwarebereitstellung bedeutet, sich kontinuierlich zu verbessern, und unsere Forschungen zeigen, dass die Besten Jahr für Jahr besser werden und diejenigen, die es nicht schaffen, sich zu verbessern, immer weiter zurückbleiben.

Verbesserung ist für jeden möglich Unser Streben danach, zu verstehen, wie man Softwarebereitstellung misst und verbessert, war voll von Erkenntnissen und Überraschungen. Die Moral der Geschichte, die aus den Daten entstand, ist diese: Verbesserungen in der Softwarebereitstellung sind für jedes Team und in jedem Unternehmen möglich, solange die Führung kontinu­ierliche Unterstützung bietet – wie Zeit, Aktivitäten und Ressourcen –, eine wahrhafte Verpflichtung zur Verbesserung demonstriert und die Teammitglieder sich ebenfalls der Arbeit verpflichtet fühlen.

Mit diesem Buch möchten wir das Gelernte teilen, um Unternehmen zu helfen, sich abzuheben und zufriedene Teams aufzubauen, die schneller bessere Software entwickeln. Wir möchten sowohl den Einzelnen als auch das ganze Unternehmen dabei unterstützen, erfolgreich zu sein. Der Rest dieser Einleitung beschreibt kurz die Forschung, wie alles begann und wie sie durchgeführt wurde. Weitere Einzelheiten über den wissenschaftlichen Hintergrund der Untersuchung beschreiben wir in Teil II dieses Buches.

Der Weg und die Daten

Wir werden oft nach der Entstehungsgeschichte dieser Forschung gefragt. Sie basiert auf zwingender Neugier, zu erfahren, was leistungsstarke Technologieunternehmen so großartig macht und wie Software Unternehmen verbessert. Jeder von uns hat 17Zeit damit verbracht, überlegene technische Performance zu verstehen, bevor wir uns Ende 2013 zusammenschlossen:

• • Nicole Forsgren hat einen PhD in Management Information Systems. Vor 2013 hat sie einige Jahre damit verbracht, die Faktoren zu erforschen, die Technologien in Unternehmen wirkungsvoll machen, insbesondere unter den Fachleuten, die Software entwickeln und die die Infrastruktur unterstützen. Sie hat Dutzende durch Peer-Review begutachtete Artikel zu diesem Thema geschrieben. Vor ihrem PhD arbeitete sie als Software- und Hardwareentwicklerin sowie als Systemadministratorin.

• • Jez Humble ist Ko-Autor von Continuous Delivery, Lean Enterprise und The DevOps Handbook. Er startete nach dem College im Jahr 2000 bei einem Start-up in London. Von 2005 – 2015 arbeitete er bei ThoughtWorks in der Softwarebereitstellung und als Berater für Infrastruktur, als Entwickler und Produktmanager.

• • Gene Kim untersucht seit 1999 leistungsstarke Technologieunternehmen. Er war Gründer und 13 Jahre lang CTO von Tripwire und ist Ko-Autor vieler Bücher, darunter The Phoenix Project und The Visible Ops Handbook.

Ende 2013 haben Nicole, Jez und Gene begonnen, zusammen mit dem Team bei Puppet zu arbeiten, um den 2014 State of DevOps Report vorzubereiten.1 Indem es praktische Expertise und wissenschaftliche Exaktheit kombiniert hat, war das Team in der Lage, etwas Einzigartiges in der Branche zu schaffen: einen Bericht, der Erkenntnisse darüber enthielt, wie Technologie hilft, Mitarbeitern, Unternehmen und Kunden einen vorhersagbaren Wert zu bringen. Für die nächsten vier Berichte arbeiteten Nicole, Jez und Gene weiter mit dem Team von Puppet, um das Forschungsdesign zu wiederholen und kontinuierlich das Branchenverständnis darüber zu verbessern, was zu einer ausgezeichneten Softwarebereitstellung beiträgt, was großartige technische Teams ausmacht und wie Unternehmen leistungsstark werden können und im Markt dadurch gewinnen, dass sie Technologie wirksam einsetzen. Dieses Buch deckt Forschungserkenntnisse aus vier Jahren ab, die mit dem Report begannen (2014 – 2017).

Um die Daten zu erheben, haben wir jedes Jahr Einladungen an unsere E-Mail-Kontakte versendet und Social Media wie Twitter, LinkedIn und Facebook genutzt. Unsere Einladungen richteten sich an Profis im Technologiebereich, besonders aber an diejenigen, die mit Softwareentwicklung und Bereitstellungsparadigmen wie 18DevOps vertraut waren. Wir ermutigten unsere Leser, Freunde und Kollegen, zudem jene einzuladen, die vielleicht auch in der Softwareentwicklung und -bereitstellung arbeiten, um unseren Wirkungskreis auszuweiten. Das nennt man Schneeballverfahren, und wir sprechen in Kapitel 15 »Die Daten für das Projekt« darüber, warum das eine angemessene Methode der Datenerhebung für dieses Forschungsprojekt war.

Die Daten für unser Projekt stammten aus den Umfragen. Wir nutzten Umfragen, weil sie der beste Weg sind, von tausenden Unternehmen in kurzer Zeit große Datenmengen zu erheben.

In Teil II, der die Wissenschaft und Forschung hinter diesem Buch behandelt, findet sich eine ausführliche Diskussion darüber, warum aus Umfragen eine gute Forschung entstehen kann, sowie eine Beschreibung der Schritte, die wir unternommen haben, um sicherzustellen, dass die erhobenen Daten vertrauenswürdig und akkurat sind.

Hier ist eine kurze Abhandlung unserer Forschung und wie sie sich im Lauf der Jahre entwickelt hat.

2014: Die Grundlage schaffen. Bereitstellungs- und Unternehmensperformance

Unsere Forschungsziele im ersten Jahr waren, eine Grundlage zu schaffen, um Softwareentwicklung und -bereitstellung in Unternehmen zu verstehen. Einige Schlüsselfragen waren:

• • Was bedeutet es, Software bereitzustellen und lässt sich das messen?

• • Hat Softwarebereitstellung Auswirkungen auf Unternehmen?

• • Hat die Unternehmenskultur eine Bedeutung, und wie messen wir sie?

• • Welche technischen Praktiken scheinen wichtig zu sein?

Wir waren von vielen Ergebnissen im ersten Jahr freudig überrascht. Wir entdeckten, dass Softwareentwicklung und -bereitstellung auf statistisch sinnvolle Weise gemessen werden können und dass leistungsstarke Unternehmen das durchgehend gut machen, und zwar deutlich besser als viele andere Unternehmen. Wir haben ebenfalls herausgefunden, dass Durchlauf und Stabilität zusammengehen und dass die Fähigkeit eines Unternehmens, Software zu entwickeln, sich positiv auf die Rentabilität, Produktivität und Marktanteile auswirkt. Wir haben erkannt, dass die Unternehmenskultur und die technischen Praktiken eine Rolle spielen und herausgefunden, wie man sie misst. Das wird in Teil I dieses Buches behandelt.

Das Team prüfte ebenfalls die Art, wie die meisten Daten in der Vergangenheit gemessen wurden, indem es von einfachen Ja/Nein-Fragen zu Fragen des Likert-Typs überging (in denen die Antwortenden aus einer Reihe von Möglichkeiten auswählen: 19von »trifft gar nicht zu« bis »trifft vollständig zu«). Durch diese einfache Änderung der Fragen konnte das Team nuanciertere Daten sammeln – Grautöne statt schwarz-weiß. Das ermöglichte eine detailliertere Analyse. In Kapitel 14 »Warum eine Umfrage?« findet sich die Diskussion darüber, warum sich die Autoren entschieden, Umfragen für das Forschungsprojekt zu verwenden und warum man den umfragebasierten Daten trauen kann.

2015: Die Arbeit ausweiten und die Analyse vertiefen

Wie bei Technologietransformationen und Geschäftswachstum geht es auch in der Forschung um Iterationen, inkrementelle Verbesserungen und Neubewertung wichtiger Ergebnisse. Ausgestattet mit unseren Erkenntnissen aus dem ersten Jahr, waren unsere Ziele im zweiten Jahr, einige wesentliche Ergebnisse neu zu validieren und zu bestätigen (z. B. Softwarebereitstellung kann auf statistisch sinnvolle Weise definiert und gemessen werden, Softwarebereitstellung hat Auswirkungen auf die Unternehmensperformance). Darüber hinaus wollten wir das Modell ausweiten.

Dies waren einige der Forschungsfragen:

• • Können wir erneut validieren, dass Softwarebereitstellung Auswirkungen auf die Unternehmensperformance hat?

• • Haben technische Praktiken und Automatisierung Auswirkungen auf die Softwarebereitstellung?

• • Haben Lean Management-Praktiken Auswirkungen auf die Softwarebereitstellung?

• • Haben technische Praktiken und Lean Management-Methoden Auswirkungen auf Aspekte der Arbeit, die unsere Belegschaft beeinträchtigen – so wie Sorgen, die mit Code Deployments und Burn-out zusammenhängen?

Nochmal, wir erfuhren einige großartige Bestätigungen und einige Überraschungen. Unsere Hypothesen wurden unterstützt, indem sie unsere Arbeit des vergangenen Jahres bestätigten und erweiterten. Diese Ergebnisse finden sich in Teil II.

2016: Unseren Blick auf technische Praktiken erweitern und das Fuzzy Front End erforschen

Im dritten Jahr haben wir uns wieder auf die wesentliche Grundlage unseres Modells gestützt und sie erweitert, um die Bedeutung zusätzlicher technischer Praktiken zu erforschen (wie Sicherheit, trunk-basierte Entwicklung und Testdaten­management). Durch Gespräche mit unseren Kollegen aus dem Produktmanagement 20inspiriert, bauten wir unsere Untersuchungen weiter aus, um zu erkennen, ob wir die Auswirkungen der derzeitigen Bewegung weg vom traditionellen Projektmanagement hin zu Lean-Methoden im Produktmanagement messen könnten. Wir erweiterten unsere Untersuchungen, um Qualitätsmaßnahmen einzuschließen, wie Fehler, Nachbesserung und Wiederherstellung von Sicherheitsfunktionen. Schließlich fügten wir weitere Fragen hinzu, um zu verstehen, wie technische Praktiken das ­Humankapital beeinflussen: Employee Net Promoter Score (eNPS) und Arbeits­identität – ein Faktor, der wahrscheinlich zu weniger Burn-out führt.

Dies waren unsere Forschungsfragen:

• • Hilft die Integration von Sicherheit in die Softwareentwicklung und -bereitstellung dem Prozess oder verlangsamt sie ihn?

• • Trägt trunk-basierte Entwicklung zu einer verbesserten Softwarebereitstellung bei?

• • Ist ein Lean-Ansatz im Produktmanagement ein wichtiger Aspekt der Softwareentwicklung und -bereitstellung?

• • Tragen gute technische Praktiken zu einer starken Loyalität für das Unternehmen bei?

2017: Architektur einbeziehen, die Rolle der Führungskräfte erforschen und Erfolg in nicht-kommerziellen Organisationen messen

Im vierten Jahr unserer Forschung kamen Fragen darüber auf, wie Systemarchitektur aussieht und welchen Einfluss sie auf die Fähigkeit von Teams und Unternehmen hat, Software und Nutzen zu liefern. Wir haben unsere Untersuchungen ebenfalls erweitert, um Wertmaßstäbe einzubeziehen, die über Rentabilität, Produktivität und Marktanteile hinausgehen. Dadurch wendet sich die Analyse auch an ein nicht-kommerzielles Publikum. Die Forschung in diesem Jahr hat auch die Rolle von Führungskräften untersucht, um den Einfluss transformationaler Führung in Unternehmen zu messen.

Unsere treibenden Forschungsfragen im vierten Jahr waren:

• • Welche Architekturpraktiken bringen Verbesserungen in der Performance der Softwarebereitstellung?

• • Wie beeinflusst transformationale Führung die Softwarebereitstellung?

• • Hat die Softwarebereitstellung einen Einfluss auf nicht-kommerzielle Ergebnisse?

21Fazit Wir hoffen, dass Sie bei der Lektüre dieses Buches, ob als Ingenieur oder Technologie-Führungskraft, wichtige Komponenten erkennen, um Ihr Unternehmen zu verbessern – angefangen mit der Softwarebereitstellung. Indem wir unsere Fähigkeit, Software bereitzustellen, verbessern, können Unternehmen Features schneller zur Verfügung stellen. Sie können sich bei Bedarf neu ausrichten, auf Veränderungen in der Compliance und Sicherheit reagieren und Vorteile aus einem schnellen Feed­back ziehen und so neue Kunden anziehen sowie bestehende begeistern. In den folgenden Kapiteln identifizieren wir die Schlüsselkompetenzen, die die Performance der Softwarebereitstellung vorantreiben (und definieren, was Performance der Softwarebereitstellung überhaupt ist). Wir sprechen kurz die wesentlichen Punkte jeder Kompetenz an. In Teil I des Buches finden sich unsere Ergebnisse, in Teil II werden die Wissenschaft und Forschung hinter unseren Ergebnissen diskutiert und in Teil III findet sich schließlich eine Fallstudie über die Möglichkeiten, die sich ergeben, wenn ein Unternehmen diese Kompetenzen übernimmt und implementiert, um die Performance voranzutreiben.

23TEIL I
UNSERE ERGEBNISSE

Ausgestattet mit exakten Techniken zur Datenerhebung und zur statistischen Analyse (wird detailliert in Teil II besprochen), waren wir in der Lage, signifikante und manchmal überraschende Ergebnisse zu erzielen, während wir die letzten Jahre am State of DevOps Report gearbeitet haben. Wir konnten die Performance der Softwarebereitstellung, ihren Einfluss auf die Unternehmensleistung und die verschiedenen Kompetenzen, die zu diesen Ergebnissen beigetragen haben, messen und quantifizieren.

Diese Kompetenzen fallen in verschiedene Kategorien, wie Technik, Prozess und Kultur. Wir haben den Einfluss von technischen Praktiken auf die Kultur gemessen und den Effekt der Kultur auf die Performance der Bereitstellung und die Unternehmensleistung. Bei Kompetenzen, die so verschiedenartig sind wie Architektur und Produktmanagement haben wir deren Beitrag zu diesen und anderen wichtigen nachhaltigen Auswirkungen wie Burn-out und Deployment Pain untersucht.

In diesem Teil des Buches stellen wir unsere Ergebnisse vor.