Wie misst man eigentlich wie gut Softwareentwicklung funktioniert? Und wenn wir schon dabei sind: Wie entwickelt man schnell und zuverlässig Software? Hier in Deutschland wissen wir ganz gut, wie das für Autos funktioniert. Wir haben Einzelteile, die in die Produktion gehen und als fertiges Auto wieder herauskommen. Wir können also messen, wie viele Ressourcen in die Produktion gegeben werden, wie lange die einzelnen Arbeitsschritte dauern, wie oft das fertige Auto in die Wartung muss und welchen Marktpreis es erzielt. So weit, so einfach...
Meine Einschätzung zur Bedeutung der Metriken, Fähigkeiten und Praktiken, die ich in diesem Artikel vorstellen beruht, auf wissenschaftlich erhobenen Daten und den daraus abgeleiteten Erkenntnissen. Sie entspringen der Auswertung des State of DevOps Reports, der jährlich von Puppet und Circle CI angefertigt wird. Im Jahr 2020 wurden hier ca. 35.000 Technical Professionals befragt. Wir können hier also davon ausgehen, dass die Ergebnisse eine hohe Relevanz haben.
Als Unternehmen stehen wir im Wettbewerb. Eine hohe Performance in der Softwareentwicklung verschafft uns einen Wettbewerbsvorteil. Das trifft zu, wenn wir Software benötigen, um unsere Geschäftsprozesse zu ermöglichen. Noch viel mehr trifft das auf Unternehmen zu, die digitale Produkte anbieten oder komplett auf digitalen Geschäftsmodellen beruhen.
Wie können wir das nun anstellen, wenn wir keine Einzelteile, keine wiederholbaren Schritte und keine zu veräußernden Autos haben? Wir müssen uns anderer Maßstäbe bedienen. Diese Maßstäbe sollten in der Softwareentwicklung zwei wichtigen Kriterien entsprechen:
Schauen wir im Folgenden doch kurz darauf, was diese beiden Kriterien bedeuten.
Hierbei ist es wichtig, dass wir ein Softwareprodukt nicht im Kontext eines einzelnen Teams messen - zum Beispiel des Entwicklungsteams. Vielmehr sollten wir das Softwareprodukt im Kontext der Organisation oder des Unternehmens betrachten. Es reicht zum Beispiel nicht aus eine hochkomplexe und elegante Software zu entwickeln, wenn sie von einem anderen Team nicht gewartet oder weiterentwickelt werden kann.
Es ist völlig unerheblich wie viele Stunden Entwicklungszeit oder wie viel Budget in die Entwicklung einer Software geflossen sind. Es kommt darauf an, wie stark die Wirkung der Software in Bezug auf die Ziele der Organisation oder des Unternehmens ist. Umso stärker die Software zur Erreichung meiner Ziele beiträgt, umso besser.
Die folgenden vier Metriken machen sichtbar, wie gut die Entwicklung von Software funktioniert. Sie sind stark inspiriert von dem Buch Accelerate von Nicole Forsgren, Jez Humble und Gene Kim. Ebenso werde ich kurz auf eine Reihe von Praktiken eingehen, die die Leistungsfähigkeit von Softwareentwicklung erhöhen und erläutern, warum sie wichtig sind. Auch diese Praktiken finden sich in Accelerate wieder. Nun aber zurück zu den vier Metriken:
Vorsicht bei der Durchlaufzeit (1): Hier schleicht sich schnell eine falsche Vorstellung ein. Es geht hierbei um die Durchlaufzeit von der Anforderung eines Kunden bis zu dem Zeitpunkt, an dem die Anforderung in Produktion deployt ist. Die erste Phase der Durchlaufzeit bezieht sich auf die Anforderungsanalyse, Hypothesenvalidierung, Design und User-Testing - also Dinge, die vor dem Schreiben des Codes stattfinden. Erst in der zweiten Phase der Durchlaufzeit geht es um das Coding, Testing, Build und Deployments.
Oft rücken wir als Softwareentwickler lediglich den zweiten Teil der Durchlaufzeit in unseren Fokus. Dabei vergessen wir schnell, dass wir im ersten Teil auch enormes Potenzial für Verbesserungen finden können. Das Ziel hierbei ist es, schnell Feedback zu bekommen und unsere Arbeit zu evaluieren. Umso kürzer die Durchlaufzeit - in beiden Phasen - umso besser.
Die Frequenz der Deployments (2) stellt eine Stellvertretermetrik dar. Sie misst das, was wir im Lean-Paradigma als Batch Size bezeichnen. Dabei geht es darum die Arbeitsschritte, die an einem Werkstück ausgeführt werden müssen, möglichst kleinhalten. Übersetzt in die Softwareentwicklung, heißt das, dass wir möglichst kleine Features oder Funktionsumfänge entwickeln wollen, diese dann aber schnell in deployt werden. Das verringert die Durchlaufzeiten, sorgt wiederum für schnelles Feedback und verringert das Risiko von Fehlentwicklungen. Umso kleiner die Batch Size, umso öfter können wir deployen.
Die Durchlaufzeit und die Frequenz der Deployments messen maßgeblich die Geschwindigkeit. Die schnelle Softwareentwicklung soll aber nicht zulasten der Stabilität gehen. Die zwei weiteren Metriken stellen sicher, dass diese auch gewährleistet ist. Da Fehler in komplexen Systemen unvermeidlich sind, messen wir mit der Wiederherstellungszeit (3), wie lange es dauert die Funktionalität nach einem Fehler wiederherzustellen. Darüber hinaus gibt uns die Fehlerrate (4) Aufschluss über die Qualität unserer Änderungen. Je weniger fehlerhafte Änderungen deployt werden, umso stabiler ist unsere Software.
Wie können wir nun unsere Software Delivery Performance steigern? Dazu sollten wir uns eine Sammlung von organisatorischen und technischen Fähigkeiten anschauen. All diese Fähigkeiten haben, wenn sie gut umgesetzt werden, einen signifikanten Einfluss auf die Performance. Wir teilen sie in die folgenden fünf Bereiche ein:
Lasst uns nun einen genaueren blick auf diese fünf Bereiche werfen. Wir starten mit der Continuous Delivery.
Der Begriff Continuous Delivery beschreibt eine Sammlung an technisch orientierten Methoden, die uns helfen besser mit Software-Releases1 umzugehen. Sie helfen dabei Releases öfter, in einer höheren Qualität und mit weniger Risiko durchzuführen.
Neben dem starken positiven Einfluss auf die oben beschriebenen Metriken, reduziert gut betriebenes Continuous Delivery auch den Deployment-Schmerz, den Softwareentwickler zum Beispiel bei großen Big Bang-Releases erleben. Releases werden eine Alltäglichkeit. Dadurch reduziert sich der Stress-Level innerhalb der Organisation. Das führt wiederum zu einer höheren Identifizierung mit der eigenen Organisation und hat dadurch auch positiven Einfluss auf die Organisationskultur.
Continuous Delivery kann in 8 konkrete Praktiken heruntergebrochen werden:
Es ist heute schon weitreichend bekannt und akzeptiert, dass Source Code in einem Versionskontrollsystem eingecheckt sein sollte. Was aber darüber hinaus noch zu selten umgesetzt wird, ist das Versionieren von anderen Artefakten. Dazu gehören die Systemkonfiguration, die Anwendungskonfiguration und Skripte zur Automatisierung von Build und Deployment.
Ein Beispiel dafür können wir aus dem Fibi App Kundenprojekt der Biberei ableiten. Hier nutzen wir Google Firebase als Backend. Die Security-Regeln für Datenbankzugriffe haben wir als Code in GitHub abgelegt (Systemkonfiguration). Die Mobile App liefern wir in verschiedenen Flavors aus - Produktions-Flavors sowie weitere zum Testen. Diese Anwendungskonfiguration ist auch komplett im Code in GitHub enthalten. Das Bauen und Deployen der verschiedenen Flavors ist mit Fastlane automatisiert.
Ziel bei der Automatisierung ist es Fehler zu vermeiden und repetitive Aufgaben aus der Verantwortung der Softwareentwickler zu nehmen. Dazu gehören zum Beispiel der Build und das Deployment. Durch konsequente Automatisierung gewinnen wir zusätzliche Zeit, die mit dem Lösen von Kundenproblemen verbracht werden kann, anstatt sie mit simplen Aufgaben zu verschwenden.
Auch hier können wir wieder die Fibi App als Beispiel heranziehen. Der Build und das Deployment zu Apple Testflight, Firebase App Distribution und der Google Play Console sind komplett automatisiert. Die Abläufe sind in Fastfiles beschrieben und werden von GitHub Actions automatisiert. Ein Deployment in eine Test-Umgebung ist damit nichts weiter als ein Push auf einen bestimmten Branch.
Beim Betreiben von Continuous Integration geht es darum Änderungen am Code so oft wie möglich auf den aktuellen Stand zurückzuführen. Änderungen sollten dabei stets automatisierte Tests auslösen, welche dem Softwareentwickler sofort Feedback über die Qualität seines Codes geben. Daraus resultiert ein verkürzter Feedback-Zyklus und eine höhere Qualität.
Durch das Nutzen von Trunk-based development Methoden können wir erreichen, dass wir kleine Änderungen in einer höheren Frequenz bekommen. Dazu sollte es in einem Repository nicht mehr als drei aktive Branches geben, die jeweils nicht länger als einen Tag aktiv sind (Ausnahme: langwierige Projekte mit Teilzeitarbeit). Dadurch erreicht man, dass es keine längeren Phasen des Stillstandes gibt, in denen zum Beispiel große Merge-Konflikte gelöst werden müssen oder es zu Feature-Freezes vor Releases kommt.
Eine gute Testautomatisierung umfasst verlässliche (Fehler werden entdeckt; wenig falsch Positive werden erzeugt) Tests, die bei jeder Änderung am Code ausgeführt werden. Die Verlässlichkeit spielt hier eine große Rolle, da Tests, die falsch Positive erzeugen oder Fehler gar nicht erst aufdecken, wenig Wert haben und von Entwicklern vernachlässigt werden.
Hier sollte man auch darauf achten, dass Tests (Unit Tests, Integrationstest und Systemtests) von Entwicklern geschrieben und weiterentwickelt werden sollten. Hierbei geht es darum, dass der Code testbar geschrieben wird und es auch bleibt. Daneben sollte die Verantwortung für die Testbarkeit (= Qualität) der Software nicht auf andere Teams wie ein Test- oder QA-Team ausgelagert werden.
Zur Umsetzung einer umfangreichen Testautomatisierung bietet sich das Test-Driven Development (TDD) an. Das ist eine Vorgehensweise, bei der zuerst die Tests entwickelt werden und anschließend der Code.
Um unsere Software mit Testautomatisierung abdecken zu können, brauchen wir natürlich auch Testdaten. Bei automatisierten Testen ist es wichtig, mit gleichbleibenden Daten zu testen. Das heißt, das ich zum Beispiel wiederholt prüfen kann, ob sich ein bestimmter Text an der vorgesehenen Stelle befindet (zum Beispiel das Weiter-Label eines Buttons). Dazu benötigt man stabile und verlässliche Testdaten.
Wichtig ist hier mit einem minimalen Set an Daten zu arbeiten und sich einen Prozess zu überlegen, wie man die Daten innerhalb eines Tests bereitstellen kann. Bei der Umsetzung der Fibi App haben wir zum Beispiel mit einer Test-Datenbank gearbeitet, die Daten für die Testautomatisierung bereitstellt.
Der Begriff Shift Left Security beschreibt das Verschieben von Security-relevanten Praktiken wie Reviews oder Security-Gates nach links - also damit weiter nach vorn im Softwareentwicklungsprozess. So kann Sicherheits- relevantes Feedback schnell wieder in den Entwicklungsprozess zurückgegeben werden.
Die Implementierung von Continuous Delivery ist gewissermaßen das Destillat der vorher beschriebenen Praktiken. Das Ziel hier ist es, die Software zu jeden Zeitpunkt in einem deploybaren Zustand zu halten. Um das zu können, muss man die oben erwähnten Dinge umsetzen. Dadurch hält man die Feedback-Schleifen sehr kurz und stellte verringert das Risiko, dass Dinge entwickelt werden, die nicht zu den Zielen der Organisation beitragen, bzw. keinen oder wenig Kundennutzen haben.
Bei der Implementierung von Continuous Delivery schließt sich der Kreis. Ein kleines Beispiel zur Verdeutlichung: Ich nehme Änderung am Code vor, welche einen Fehler verursachen. Ich arbeite mit einem kurzlebigen Branch, welchen ich also am Ende des Arbeitstages zusammenführe. Das löst automatische Tests aus, die den Fehler entdecken. Ich erhalte innerhalb von Minuten Feedback und kann den Fehler beheben, bevor die Software deployt ist. Durch die Automatisierung vom Deployment, ist die neue Version einige Minuten später verfügbar und kann mit Kunden getestet werden.
Wenn man in der IT von Architektur spricht, meint man alle Arten von Entscheidungen, die von dauerhafter Natur sind und einen Einfluss auf viele Teile eines Systems oder einer Anwendung hat. Diese Entscheidungen können auch über technische Aspekte hinausgehen und zum Beispiel im Bereich der organisatorischen Prozesse angesiedelt sein. Die Entscheidung über ein zentrales Logging- und Monitoringtool hat zum Beispiel Einfluss auf mehrere Anwendungen, die eine Organisation betreibt.
Wir wollen im Folgenden darauf schauen, welche Charakteristika solche Entscheidungen haben sollten. In Bezug auf die Software Delivery Performance sollten sie vor allem zwei Charakteristika widerspiegeln:
Gut getroffene Entscheidungen über Software-Architektur stellen sicher, dass Organisationen langfristig gut funktionierende Systeme aufbauen kann. Durch weitreichende organisatorische und technische Selbstbestimmtheit eines Teams kann sichergestellt werden, dass organisatorisches Wachstum nicht zu Instabilität und langen Wartezeiten (aufgrund von Abhängigkeiten) führt. Hinzu kommt, dass eine freie Wahl der eingesetzten Tools zu einem höheren Kundennutzen führt. Das ist verständlich, da Teams die Möglichkeit haben das beste Tool für ihren Zweck auszuwählen.
Wir wollen im Folgenden darauf schauen, welche Charakteristika solche Entscheidungen haben sollten. In Bezug auf die Software Delivery Performance sollten sie vor allem zwei Charakteristika widerspiegeln:
Eine zu hohe Kopplung (Abhängigkeit) gegenüber anderen Teams, der Organisation oder anderen Systemen sorgt für langwierige Prozesse. Das können zum Beispiel das Warten auf Freigaben, benötigte Rücksprachen mit anderen Teams oder das Warten auf Deployments dritter sein. Software - ebenso wie Teams - sollten daher lose gekoppelt sein. Das zeigt sich zum Beispiel in der Fähigkeit Tests außerhalb einer integrierten Umgebung ausführen zu können und Deployments und Releases unabhängig von anderen Teams ausführen zu können.
Eine hohe Selbstbestimmtheit von Teams führt zu einem hohen Kundennutzen. Das ist darauf zurückzuführen, dass die Teams selbst Experten ihrer Domäne sind. Als Experten wissen sie am besten, wie sie die vorliegenden Probleme im Sinne ihrer Kunden lösen können. Dieser große Vorteil überwiegt im Allgemeinen (es gibt natürlich Ausnahmen) den Nachteil fehlender Standardisierung. Daher sollten wir bei Architekturentscheidungen darauf achten, im Sinne der Freiheit des umsetzenden Teams zu entscheiden.
Das Lean Product Development ist organisatorischer Counterpart zu den Continuous Delivery Fähigkeiten zu verstehen. Hierbei geht es um die Vorgehensweise, die angewandt wird, um neue Produkte zu entwickeln. Es geht dabei darum bestimmte Annahme in Bezug auf ein neues Produkt oder Geschäftsmodell schnell zu validieren. Das passiert möglichst früh im Lebenszyklus eines Produktes.
Wie oben bereits erwähnt, stehen das Lean Product Development und Continuous Delivery in einer Wechselwirkung zueinander. So sind die technischen Fähigkeiten des Continuous Delivery Voraussetzung zur Umsetzung des Lean Product Development in der Softwareentwicklung. Die Denkmodelle des Lean Product Development tragen dazu bei Produkte und Geschäftsmodelle schnell zu validieren. Sie wirken sich also positiv auf das Erfüllen der Organisationsziele aus, indem sie verhindern, dass über eine lange Dauer die falschen Dinge entwickelt werden.
Zur Umsetzung der Denkmodelle des Lean Product Development können wir vier wichtige Praktiken betrachten:
Das regelmäßige Sammeln von Kundenfeedback hilft dabei bestimmte Annahmen über eine Software und deren Nutzung zu validieren. Das konsequente Auswerten und Umsetzen (sofern es sich um sinnvolles Feedback handelt) von Kundenfeedback hilft die richtigen Funktionen zu entwickeln und vermeidet das Verschwenden von wertvoller Zeit.
Es ist wichtig, dass Teams ein Gefühl dafür haben, wie Anforderungen innerhalb ihrer Organisation entstehen und über die Entwicklung schlussendlich in das Produkt einfließen. Nur mit einer entsprechenden Sichtbarkeit können eventuelle Flaschenhälse oder Fehlentscheidungen aufgedeckt werden.
Im Idealfall sind die zu entwickelnden Features in Teile zerlegt, die in weniger als einer Woche bearbeitet werden können. Das ist notwendig um regelmäßige Deployments und damit die Möglichkeit zum Einholen von Feedback sicherzustellen. Das trifft nicht nur auf Features, sondern auch auf das Produkt zu. Umso kleiner ein Produktumfang gewählt wird, umso schnelle kann er validiert werden. Das verringert das mit der Entwicklung verbundene Investitionsrisiko.
Teams die Software entwickeln, sollten einen Spielraum haben neue Dinge auszuprobieren. Hierbei sollten vor allem keine langwierigen Freigaben oder eine fehlende Akzeptanz für das Begehen von Fehlern im Weg stehen. Ein Experiment kann zum Beispiel das Ausprobieren einer neuen Technologie oder Vorgehensweise sein, die besser zu jeweiligen Situation oder den Kundenanforderungen passen.
Anders als beim Lean Product Development geht es beim Lean Management darum Arbeitsabläufe zu gestalten. Der Fokus liegt hier also mehr auf dem Wie als auf dem Was. Das Lean Manangement in der Softwareentwicklung geht auf die Lean-Bewegung der japanischen Autohersteller zurück. Sie zielte darauf ab eine hohe Variabilität bei kleinen Stückzahlen und hoher Qualität fertigen zu können. Da es in der Softwareentwicklung um ähnliche Ziele geht, sind diese Praktiken übertragbar.
Zur Umsetzung dieses Ziels bedarf es einer hohen Sichtbarkeit und Transparenz in den Arbeitsabläufen. Im Bereich der Software erreichen wir diese Sichtbarkeit mithilfe von Monitoring. Das heißt, dass wir den Zustand unserer Systeme, als auch unserer Arbeitsabläufe stets im Blick haben und auf Probleme schnell reagieren können.
Neben der gesteigerten Software Delivery Performance, hat das Lean Management einen großen Einfluss auf die Organisationskultur. Das konsequente Sichtbarmachen von Engpässen zum Beispiel fördert einen konstruktiven Umgang mit Fehlern. Teams die mit WIP Limits arbeiten und Gründe für Engpässe aus dem Weg räumen arbeiten auch mit einem geringeren Stresslevel. Das fördert die Zufriedenheit bei der Arbeit.
Im Rahmen der Umsetzung von Lean Management und System Monitoring sollte man auf die folgenden fünf Praktiken wert legen.
Weiter oben haben wir schon gelernt, dass selbstbestimmte Teams bessere Architekturentscheidungen treffen können. Die Selbstbestimmung ist auch bei Freigaben von Änderungen an der Software sehr wichtig. Teams sollten innerhalb von leichtgewichtigen Reviews selbst über die Freigabe von Änderungen entscheiden können.
Das kann zum Beispiel im Rahmen von Pair Programming mit der Übereinkunft passieren, dass jegliche im Pair programmierte Änderung implizit freigegeben ist. Daneben können auch unkomplizierte, kurze Peer Reviews als Mittel genutzt werden. Das Team muss hierfür das Vertrauen der Organisation genießen.
Entscheidungen über Features oder andere Änderungen an einer Software sollte auf Daten beruhen. Solche Entscheidungen, die den Kundennutzen beeinflussen, dürfen nicht auf persönlichen Meinungen beruhen, sondern auf Daten, die während der Nutzung der Software entstanden sind. Gleiches gilt für technische Änderungen, wie zum Beispiel Performance-Verbesserungen. Diesen Änderungen sollte Performance-Monitoring und die Feststellungen eines realen Problems vorangegangen sein.
Systeme sollten aktiv überwacht sein. Automatische Prozesse sollten anhand von Schwellenwerten Warnungen produzieren. Damit kann sichergestellt werden, dass man reagieren kann, bevor ein Fehlerfall eintritt. Idealerweise können Fehlerbehandlungen auch automatisiert werden. So kann zum Beispiel die Besucherzahl einer Website gemessen werden. Werden Besucherzahlen über einem bestimmten Schwellenwert registriert, so kann ein Entwickler benachrichtigt und ein weiterer Server automatisiert gestartet werden.
Beim Arbeiten mit WIP Limits geht es darum Engpässe möglichst schnell aufzuzeigen. Sind Engpässe bekannt, dann können sie behoben und Arbeitsabläufe dadurch verbessert werden. Die Limits können sich dabei auf einen bestimmten Arbeitsschritt, wie zum Beispiel die Freigabe von Änderungen (siehe oben), beziehen.
Stellt man also fest, dass sechs Änderungen (bei einem angenommenen WIP Limit von vier) im Status Freigabe festhängen, kann man sich den Freigabe-Prozess anschauen und vereinfachen. Man kommt also von einer Überschreitung des WIP Limit s zur Verbesserung der Arbeitsabläufe.
Die Visualisierung der Arbeitsabläufe ist quasi die notwendige Bedingung, um mit WIP Limits arbeiten zu können. Wenn ein Team keinen gemeinsam geteilten Überblick über seine Arbeitsabläufe hat, dann können auch keine Probleme aufgedeckt werden.
Organisationen, welche eine hohe Software Delivery Performance aufweisen, haben bestimmte kulturelle Merkmale besonders ausgeprägt. Dabei geht insbesondere um den Umgang mit Informationen, wie Zusammenarbeit zwischen Teams organisiert ist sowie um Wertvorstellungen im Bereich des Lernens und der Führung. Diese verschiedenen Aspekte können eine Kultur schaffen, die maßgeblich zur Performance einer Softwareorganisation beiträgt.
Sind die unten aufgeführten kulturellen Aspekte innerhalb einer Organisation besonders stark ausgeprägt, so trägt das nicht nur zur Software Delivery Performance bei, sondern steigert auch die Zufriedenheit der Mitarbeiter. So trägt zum Beispiel ein guter Umgang mit Informationen dazu bei, dass Vertrauen in die Organisation als ganzes ebenso wie Vertrauen zwischen verschiedenen Teams gesteigert aufgebaut wird.
Es stellt sich nun also die Frage, wie man Kultur verändern kann. Es ist nur sehr schwer möglich, auf Gedanken und Einstellungen anderer Personen direkt Einfluss zu nehmen. Der Versuch Kultur durch Vorschriften oder rationales Erklären zu ändern, wird also in den meisten Fällen scheitern. Daher sollten wir Kultur durch Handlungen beeinflussen. Wir müssen die Kultur, die wir in einer Organisation haben wollen vorleben. Das Anwenden von Lean Product Development und Lean Management kann als konkrete Umsetzung von transformationaler Führung verstanden werden. Daneben kann ein gut funktionierender Fluss von Informationen mithilfe von Continuous Delivery umgesetzt werden. Es gilt also mit Handlungen und Praktiken Kultur zu gestalten.
Die Aufzählung zeigt fünf Bereiche, in denen wir Einfluss auf die Kultur unserer Organisation nehmen können und sollten.
Ein effektiver Umgang mit Informationen bemisst sich anhand von drei Charakteristika. Erstens, die Fragen des Informationsempfängers sollten beantwortet werden. Was sich trivial anhört, ist oft nicht einfach. Wir müssen uns überlegen, welche Informationen der Empfänger von uns braucht und unsere Kommunikation darauf ausrichten, mögliche Fragen zu beantworten. Das äußert sich zum Beispiel in effektiven, kurzen Meetings mit einer klaren Agenda. Zweitens, sollten Informationen zur richtigen Zeit zur Verfügung stehen. Veraltetet oder verfrühte Informationen haben wenig Wert. Letztlich, müssen Informationen so präsentiert werden, dass der Empfänger Handlungen daraus ableiten kann.
Eine Organisation sollte sich darauf verständigt haben, dass kontinuierliches Lernen einen großen Wert hat. Das Lernen von neuen Fähigkeiten oder Technologien muss als Investition in die Zukunft angesehen werden, nicht als ein Kostenblock.
Wir haben oben bereits einzelne Beispiele besprochen. So zum Beispiel die Security, welche in den Entwicklungsprozess integriert wird. Die Trennung zwischen Entwicklung und Operation wird mit der Umsetzung von Continuous Delivery verwischt. All das fördert die Zusammenarbeit zwischen Teams. Nur so, lässt sich hohe Qualität bei gleichzeitiger schneller Geschwindigkeit aufrechterhalten.
Wir sollten darauf achten, dass Arbeit an Software als sinnvoll empfunden wird. Das kann zum Beispiel durch Interaktion mit den Benutzern, ein gut verstandenes gemeinsames Ziel oder aber auch intellektuelle Herausforderung erreicht werden. Außerdem muss eine Organisation gewährleisten, dass die Werkzeuge wie zum Beispiel Software und Hardware angemessen für die zu verrichtende Arbeit sind. Ist das nicht der Fall, wird die eigene Arbeitszeit oft als ineffektive Verschwendung angesehen.
Menschen in Führungsrollen spielen eine große Rolle bei der Software Delivery Performance. Die transformationale Führung ist notwendig, um die oben beschriebenen Aspekte umzusetzen. Dabei geht es unter anderem darum eine Vision aufzuzeigen, die auf das Empfinden von sinnvoller Arbeit Einfluss hat. Außerdem fördert transformationale Führung das ständige Lernen und animiert dazu neues auszuprobieren sowie das Risiko dabei Fehler zu machen einzugehen. Zuletzt gehört auch das Anerkennen von guter Leistung zur Führung und trägt stark zur Zufriedenheit bei.
Wir befinden uns mitten im Übergang vom industriellen Zeitalter zum Zeitalter der Informationen. Die Geschwindigkeit, in der sich unser persönliches und wirtschaftliches Umfeld ändert, steigt rasant an. Organisationen, die Schritt halten wollen, müssen für eine hohe Software Delivery Performance sorgen - und das betrifft nicht nur Organisationen, die Software verkaufen.
Im ersten Abschnitt haben wir gelernt, wie man Software Delivery Performance eigentlich misst und warum das wichtig ist. In den darauf folgenden Abschnitten haben wir kurz angerissen, welche Fähigkeiten wir benötigen, um Software schnell und in einer guten Qualität zu entwickeln.
Also - los geht's. Nehmen wir diese Übersicht als Startpunkt, um an unserer Performance zu arbeiten. Es wird uns helfen im Zeitalter der Informationen anzukommen und gestalten zu können.
1Software-Releases: Ein Software-Release wird oft als Veröffentlichung einer bestimmten Version einer Software verstanden. Die Veröffentlichung bezieht sich dabei auf das Zugänglich-Machen für Kunden. Ich meine hier aber auch das Zugänglich-Machen in Form von Prototypen, Click-Dummies, Vorab-Versionen und Ähnlichem, die den Zweck verfolgen, Feedback von Nutzern einzuholen.
Erzähle uns in einem kostenlosen Erstgespräch mehr über dein individuelles Projekt. Wir helfen dir bei den nächsten Schritten und teilen unser Wissen.
Nachricht schreiben