Negative Velocity: Erhöhen der Komplexitätsgrenze
Anzeichen und Abhilfe für zu hohe organisatorische Komplexität bei Softwareteams
Andrew Boyagi
Senior Evangelist
Eines der häufigsten Ziele in der Softwareentwicklung: die schnelle Bereitstellung von hochwertiger Software.
Schau dir das Vision Statement deines CIO oder CTO an und höre ihnen zu. Die Chancen stehen gut, dass sie dieses Ziel in einer gewissen Art verfolgen. Während es ein häufiges Ziel ist, reicht das Spektrum von Teams, die es erreichen, bis zu Teams, die ewig mit der Softwarebereitstellung kämpfen. Einige Teams bringen ständig neuen Code in die Produktion, wobei es nur zu wenigen Vorfällen oder negativen Auswirkungen auf die Kunden kommt, während andere schon Probleme mit vierteljährlichen Releases haben.
Teste Compass kostenlos
Als Unterstützung beim Entwickeln, zum Katalogisieren von Diensten und zum Optimieren des Softwarezustands.
Was verursacht diesen Leistungsunterschied?
Bei der Softwarebereitstellung macht die Komplexität den Unterschied zwischen einer schnellen Bereitstellung von hochwertiger Software und… dem Gegenteil davon. Sie macht den Unterschied zwischen dem wöchentlichen Klingeln der Siegesglocke nach einem erfolgreichen Release und einem unengagierten Softwareteam, das darüber frustriert ist, dass die monatelange Arbeit am neuesten Release zu sechs neuen Bugs und einem Rollback geführt hat.
Vergleiche die Geschwindigkeit und Qualität der neuen Produkte und Funktionen von Startups mit denen eines etablierten, großen Unternehmens. In der Finanzbranche werden großen, etablierten Banken beispielsweise immer mehr Marktanteile von FinTech-Startups abgerungen. Große Banken nennen oft die unfairen Vorteile von FinTech-Startups, die mit weniger regulatorischer Aufsicht arbeiten und keine traditionellen, monolithischen Anwendungsbestände verwalten müssen. Kleinere Teams bieten mehr Flexibilität und die Möglichkeit, sich an die Kundenbedürfnisse anzupassen. Im Wesentlichen haben FinTech-Startups nicht die Komplexität etablierter Banken, wodurch sie schneller und mit geringerem Risiko agieren können. Doch während sie Softwareteams bremsen kann, ist Komplexität nicht immer eine schlechte Sache.
Zugehöriges Material
Software unter Kontrolle
Lösung anzeigen
Verbesserte Entwicklung mit Compass
Komplexität bei der Softwarebereitstellung
Komplexität kann eine gute Sache sein: Wenn schwierige Probleme gelöst werden, erzeugt das große Glücksgefühle. Das motiviert Teams, mit der Herausforderung zu wachsen, schwierige Probleme anzugehen und eine Branche auf den Kopf zu stellen. Doch es gibt auch einen Punkt, an dem es bei Komplexität nicht mehr darum geht, ein schwieriges Problem zu lösen, sondern negative Auswirkungen auf Softwareteams entstehen.
Organisatorische Komplexität spielt eine Schlüsselrolle bei einer verringerten Effektivität von Softwareteams. Komplexität lässt sich definieren als ein Zustand, in dem viele verschiedene Teile komplizierte Verbindungen oder Beziehungen zueinander aufweisen. In der Praxis ist organisatorische Komplexität die Summe von Informationen, Abhängigkeiten, Änderungen, anderen Teams, Tools und Anfragen, die Softwareteams berücksichtigen müssen, wenn sie mit der restlichen Organisation zusammenarbeiten.
Höhere organisatorische Komplexität macht es natürlich schwieriger, hochwertige Software schnell bereitzustellen, weil Teams mehr Zeit damit verbringen, sich in der Organisation zurechtzufinden, als schwierige Probleme zu lösen. Wachsende Unternehmen bemerken schnell, dass Softwareteams eine Komplexitätsgrenze erreichen – die Komplexität, die Teams bewältigen können, bevor sie sich auf die Arbeitszufriedenheit sowie die Qualität und Geschwindigkeit der Softwareproduktion auswirkt. Es mag also logisch erscheinen, dass die Verringerung der organisatorischen Komplexität es Teams ermöglicht, sich darauf zu konzentrieren, schwierige Probleme zu lösen und hochwertige Software schneller bereitzustellen. Sehen wir uns an, warum das nicht unbedingt der Fall ist.
Auswirkungen der Komplexität auf ein Softwareteam
Die Einführung einer Microservice-Architektur ist ein gutes Beispiel für die Auswirkungen, die Komplexität auf Softwareteams hat. Die Definition von Komplexität ist auch eine gute Beschreibung für eine Microservice-Architektur: ein Zustand, in dem viele verschiedene Teile komplizierte Verbindungen oder Beziehungen zueinander aufweisen. Es stimmt, dass Microservices es Teams ermöglichen, unabhängig voneinander zu agieren, Systeme schneller bereitzustellen und sicher zu skalieren – ich bin ein großer Fan von Microservices –, aber die Komplexität nimmt mit ihnen sicher deutlich zu.
Sehen wir uns die Effektivität der Softwareteams bei Atlassian auf dem mehrjährigen Weg zur Einführung einer Microservice-Architektur an.
Zu Beginn der Microservices-Einführung bei Atlassian sahen die DORA-Metriken großartig aus! Kleinere Codeblöcke erleichterten Tests und Bereitstellungen, die Teams kamen schneller und sicherer voran und die Arbeitszufriedenheit war hoch. In dieser Phase profitierten die Teams von den erwarteten Vorteilen einer Microservice-Architektur. Auch wenn die Komplexität zunahm, waren keine negativen Auswirkungen auf die Teams zu beobachten.
Abb. 1. Einführung von Microservices
Angesichts der Vorteile begannen weitere Teile der Organisation, eine Microservice-Architektur einzuführen, wodurch die organisatorische Komplexität natürlich zunahm. Mehr autonome Teams erforderten mehr Zusammenarbeit, und mehr Microservices bedeuteten mehr Abhängigkeiten. Das Tempo der Veränderungen ging durch die Decke – alle Anzeichen von Software-Sprawl waren zu erkennen. Durch die erhöhte Komplexität stagnierte die Effektivität der Softwareteams, was zu einer verminderten Änderungsgeschwindigkeit führte, und die kognitive Belastung wurde zu einem Problem für die Softwareteams.
Abb. 2: Der Effektivitätsgewinn von Teams stagniert mit zunehmender Komplexität.
Ohne Intervention erreichte die Organisation schließlich eine Komplexitätsgrenze und die Effektivität der Softwareteams nahm ab. Brachten die Microservices zu Beginn noch höhere Geschwindigkeit, Autonomie und Qualität, zeigte sich bald das gegenteilige Bild. In Folge nahm die Zufriedenheit der Entwickler verständlicherweise ab. Diese Anzeichen deuten darauf hin, dass eine Organisation ihre Komplexitätsgrenze erreicht hat. Softwareteams ringen dann mehr mit organisatorischer Komplexität, als sich mit ihren eigentlichen Aufgaben zu befassen. Das frustriert.
Abb. 3: Die Effektivität von Teams nimmt ab, wenn die Organisation die Komplexitätsgrenze erreicht.
Indikatoren der Komplexitätsgrenze
Die Komplexitätsgrenze scheint unausweichlich zu sein, aber es gibt einige Indikatoren dafür, dass sich Teams ihrer Grenze nähern. Ich muss vorwegnehmen, dass es keine absolute Metrik dafür gibt, wie weit die Komplexitätsgrenze entfernt ist, aber diese Indikatoren können dir dabei helfen, deinen Abstand zu ermitteln.
Wenn ein Team mehr Zeit damit verbringt, sich in der organisatorischen Komplexität zurechtzufinden, als schwierige Probleme zu lösen, ist das der deutlichste Indikator dafür, dass es die Komplexitätsgrenze erreicht hat. Die Trends von den Metriken der DORA-Vorlaufzeit für Änderungen (Geschwindigkeit) und der Änderungsfehlerrate (Qualität) zeigen, ob Teams im Laufe der Zeit langsamer oder schneller werden. Auch wenn es noch andere Faktoren gibt, die diese Metriken beeinflussen, sind sie ein guter Indikator für die Effektivität des Teams.
Die Zufriedenheit der Entwickler ist ein weiterer Indikator für das Ausmaß der organisatorischen Komplexität bei den Softwareteams. Entwickler haben eine besonders starke Tendenz dazu, gerne an schwierigen Problemen zu arbeiten und zugleich unnötige Aufgaben zu verabscheuen, die ihnen im Weg stehen. Deshalb ist eine geringe Zufriedenheit der Entwickler ein guter Indikator dafür, dass die organisatorische Komplexität ein Problem für dein Softwareteam ist.
Vereinfachung ist die falsche Strategie
Wenn Unternehmen erkennen, dass ihre Teams in der Komplexität versinken, starten sie oft ein "Vereinfachungsprojekt", das die Einfachheit in ihrer Organisation wiederherstellen soll. Vereinfachung ist aus zwei Gründen die falsche Strategie: Die Komplexität nimmt schneller zu, als jede Organisation ihre Umgebung vereinfachen kann, und diese "Vereinfachungsprojekte" werden in genau der komplexen Umgebung ausgeführt, die sie vereinfachen sollen.
Die Vereinfachung beginnt typischerweise damit, dass die Anzahl der Anwendungen reduziert wird, indem sie nach Möglichkeit eingestellt oder konsolidiert werden. Um eine Anwendung einzustellen, muss das Team alle vor- und nachgelagerten Abhängigkeiten verstehen: Wer verwendet die Anwendung? Wie wird ihre Funktion ersetzt? Wo und wie werden die Daten archiviert oder migriert? Und das Team muss sich mit vielen weiteren Komplikationen auseinandersetzen, die damit einhergehen. Leider wird der erforderliche signifikante Aufwand nicht mit einer ebenso signifikanten Reduzierung der Komplexität belohnt. Es gibt eine Grenze für die Anzahl der Anwendungen, die ein Unternehmen ohne Auswirkungen auf das Kerngeschäft oder die Benutzererfahrung einstellen kann, aber es gibt keine Grenze dafür, wie viele neue Softwarekomponenten erstellt werden können. In den 12 Monaten, in denen eine Anwendung eingestellt wurde, wurden wahrscheinlich Hunderte neue Microservices erstellt. Da eine gesunde IT-Umgebung mit der Zeit wächst, ist es nicht sinnvoll, sie auf eine feste Anzahl von Anwendungen oder Softwarekomponenten zu beschränken, um die Komplexität zu reduzieren.
Vereinfachungsprojekte beinhalten in der Regel die Überarbeitung der Organisationsstruktur, um die Komplexität der Kommunikation zu verringern. Die unkompliziertesten Organisationsstrukturen bestehen aus großen hierarchischen Teams, bei denen sich alle Mitarbeiter am gleichen Standort befinden. Die kompliziertesten Organisationsstrukturen bestehen aus kleinen, verteilten und autonomen Teams. Nach dem Gesetz von Conway produzieren große hierarchische Teams wahrscheinlich monolithische Anwendungen, während kleine, verteilte Teams wahrscheinlich Anwendungen mit modularen Architekturen wie Microservices produzieren. Da modulare Architekturmuster wie eine Microservice-Architektur die schnelle Produktion von hochwertiger Software fördern, führt die komplexere Organisationsstruktur mit größerer Wahrscheinlichkeit zum Erfolg. Die "Vereinfachung" kann die Organisationsstruktur zwar übersichtlicher machen, aber sie ist kontraproduktiv für das letztendliche Ziel des Vereinfachungsprojekts.
Vereinfachung ist wichtig und lohnenswert, eignet sich aber am besten als Bestandteil der kontinuierlichen Verbesserung von Softwareteams (und Teams von Teams) und nicht als einmalige Aktivität. Vereinfachung kann das Erreichen der Komplexitätsgrenze verzögern, aber sie wird einer Organisation nicht die agile Freiheit einer Startup-Umgebung verschaffen.
Erhöhen der Komplexitätsgrenze
Um die Effektivität des Softwareteams wiederherzustellen, müssen Organisationen die Komplexitätsgrenze erhöhen. Und um die Komplexitätsgrenze zu erhöhen, muss das Ausmaß der organisatorischen Komplexität gesteigert werden, die ein Team bewältigen kann, bevor die Arbeitszufriedenheit, Qualität und Geschwindigkeit der Softwareproduktion darunter leiden.
Platform Engineering ist ein wichtiges Konzept für die Erhöhung der Komplexitätsgrenze einer Organisation. Starke Platform-Engineering-Teams reduzieren die kognitive Belastung von Softwareteams, indem sie ihnen die Komplexität der Organisation bei der täglichen Arbeit abnehmen. Wenn Platform Engineering korrekt implementiert wird, wenden die Teams weniger Zeit für die organisatorische Komplexität auf und können sich stattdessen auf das Lösen schwieriger Probleme konzentrieren.
Abb. 4: Erhöhen der Komplexitätsgrenze
Genau deshalb hat Atlassian Compass, eine Developer-Experience-Platform, entwickelt. Compass ermöglicht es, die Komplexitätsgrenze zu erhöhen, indem es Softwareteams erleichtert wird, die organisatorische Komplexität mithilfe des Komponentenkatalogs, der Metriken und Scorecards zu bewältigen und sich auf eine gesunde Entwicklungskultur zu konzentrieren. Der wichtigste Punkt dabei ist, dass die organisatorische Komplexität bei Atlassian nicht abgenommen hat. Sie ist sogar weiter gewachsen, da immer mehr Bestandteile der Organisation auf eine Microservice-Architektur umstiegen sind. Wir haben es den Softwareteams ermöglicht, weniger Zeit für diese Komplexität aufwenden zu müssen, was eben der Unterschied zwischen einem Vereinfachungsprojekt und dem Erhöhen der Komplexitätsgrenze ist.
Atlassian hat über 10.000 Mitarbeiter und über 17.000 Softwarekomponenten, aber seine Softwareteams arbeiten größtenteils mit der Freiheit eines Startups und stellen hochwertige Software schnell bereit. Der Schlüssel zum Erfolg? Das Erhöhen der Komplexitätsgrenze, um die Effektivität der Softwareteams zu verbessern.
Hier sind zwei erste Aktionen, um deine Komplexitätsgrenze zu erhöhen:
- Verfolge und bewerte deine DORA-Metriken. Wie sehen die DORA-Metriken für dein Team aus? Falls du sie noch nicht verfolgst: Die DORA-Metriken sind bei Compass sofort einsatzbereit.
- Analysiere und bewerte die Zufriedenheit der Entwickler. Wie geht es den Entwicklern in deinen Softwareteams? Die meisten Organisationen führen Umfragen zur Mitarbeiterzufriedenheit durch. Frag nach den Meinungen, aufgeschlüsselt nach Funktionsbereichen, um einen Einblick in die Zufriedenheit der Entwickler zu erhalten. Zu den wichtigsten Fragen zählen Bewertungen der folgenden Aussagen:
- Ich bin stolz auf die Bereitstellung
- Der Stress bei meiner Arbeit ist zu bewältigen
- Ich verstehe, wie meine Arbeit zu den Unternehmenszielen beiträgt
Alternativ erfasst Compass diese Informationen während des CheckOps-Rituals, bei dem die Teams erklären, wie sie die letzte Woche fanden und was besser gewesen wäre.
Um die Komplexitätsgrenze zu erhöhen, ist eine Kombination aus Tools, Prozessen und Ritualen erforderlich. Eine Developer-Experience-Platform wie Compass kann dir dabei helfen, den Systemzustand zu verstehen, Abhängigkeiten abzubilden und regelmäßige Rituale zu entwickeln, um die Komplexitätsgrenze zu erhöhen und das wahre Potenzial der Softwarebereitstellungsteams in deiner Organisation zu nutzen.
Teste Compass noch heute kostenlos.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.