Maximieren Sie Ihre Investitionen in Technologie durch Engineering Effectiveness

Schöpft die Softwareentwicklung in Ihrem Haus Ihr volles Potenzial aus? In den mehr als 30 Jahren Erfahrung, in denen wir mit unseren Kunden Agile-, DevOps- und Plattformtransformationen vorangetrieben haben, haben wir festgestellt, dass die meisten Unternehmen weniger als 30 % dieser Möglichkeiten nutzen.

Die meisten Unternehmen haben zwar Initiativen wie DevOps, Plattformen und agile Transformation in irgendeiner Form gestartet, die Forschung zeigt jedoch, dass — während die erfolgreichsten Organisationen weiterhin schnell vorankommen —, die Transformation vieler Unternehmen stagniert.

Und so hat sich denn auch eine ganze Reihe von Strategien für Patentrezepte und Denkschulen entwickelt, die sich dieser Probleme annehmen. ‚Entwickler:innenerfahrung (DX)’. ‚Technische Exzellenz.’  ‚Entwickler:innenproduktivität.’  Jede von ihnen hat ihre eigenen Vorzüge, aber letztendlich befasst sich jede nur mit einer Teilmenge der Aspekte des übergeordneten Ziels — der durchgängigen Engineering Effectiveness. 

Was fehlt, ist ein in der Praxis erprobtes und datengesteuertes Framework und eine ebensolche Methodik, die die verschiedenen Plattformtechnologien, Entwicklungspraktiken und Ansätze für die Developer Experience unter einem übergreifenden Mess- und Governance-Modell miteinander vereinen. Mit einem ganzheitlichen Framework und einer ganzheitlichen Methodik können Entwicklungsleiter:innen ihre Software-Wertschöpfung transformieren, um den Impact ihrer Investitionen schneller zu maximieren und zu beschleunigen.

Mit unserer jahrzehntelangen Erfahrung in der Bereitstellung von technischen Transformationen für Unternehmen aller Größen verfügen wir bei Thoughtworks über einzigartige und praktische Einblicke in die wichtigsten, aber oft übersehenen Bereiche und die ‚versteckten‘ Formen von Verschwendung und Reibung, welche die Produktivität von Entwickler:innen beeinträchtigen. Beispiele für diese versteckten, aber äußerst weitreichenden Ursachen sind:

• Herausforderungen bei unternehmensweiten Tests und der Qualitätssicherung, wie zum Beispiel, dass Fehler erst sehr spät im Prozess (oder in der Produktion) erkannt werden, und Verzögerungen durch unzuverlässige, nicht synchronisierte und überbelastete gemeinsame Umgebungen. 

• Probleme mit dem Betriebsmodell, wie unzureichend definierte Workflows zwischen den Produkt- und Entwicklungsfunktionen, teaminterne Abhängigkeiten, die zu Wartezeiten führen, und eine geringe Akzeptanz der Plattformkapazitäten aufgrund eines mangelnden Schwerpunkts und fehlender Ressourcen im technischen Produktmanagement sowie ein hohes Maß an kognitiver Belastung bei den Schlüsseltalenten.

• Ineffektives Wissensmanagement, einschließlich unzureichender oder fehlender Dokumentation, kognitiver Überlastung, übermäßiger Kommunikation zwischen den einzelnen Personen und den Teams aufgrund von Problemen beim Wissentransfer und fehlender Klarheit, wer für die Systeme, APIs etc. verantwortlich ist.

• Stark gekoppelte Alt-Architekturen, welche die Bemühungen um einen „domainorientierten“ Ansatz aufgrund begrenzter Erfahrungen im Aufbau moderner Microservices-Architekturen im großen Maßstab sowie gescheiterter Bestrebungen zur Umstellung auf einen moderneren API-Ansatz (z.B. „REST“) verlangsamen oder verzögern.

• Die „neue eingefrorene Mitte“: Teams, denen es an Entwicklungsleiter:innen und Direktor:innen fehlt, die wissen, wie sie talentierte Entwickler:innen führen und inspirieren, und die sich auf Praktiken, die echte Ergebnisse produzieren, und nicht auf Metriken wie „Geschwindigkeit“ und „Codeabdeckung“ konzentrieren, die letztlich nur dem Selbstzweck dienen (ja — diese Metriken sind schlechte Kennzahlen für eine effektive Softwareentwicklung).

Das folgende Framework für Engineering Effectiveness ist das Ergebnis jahrzehntelanger Erfahrung in der Transformation großer Unternehmen. Anders als die „Cargo-Kult“-Ansätze für DevOps und Agile Transformation wurde dieses Framework von Grund auf dazu entwickelt, Verschwendung und Reibung dort zu identifizieren, wo sie am größten sind, und anschließend zu beheben.

Unser Ziel ist es, einen Ansatz bereit zu stellen, um die Time-to-Value zu verkürzen, die Produktivität zu steigern und die Zufriedenheit der Entwickler und Entwicklerinnen zu steigern. Somit lässt sich zu einer berechenbareren, effizienteren und effektiveren Softwareorganisation beitragen.

Produktivität lässt sich schwer messen*. Verschwendung zum Glück nicht.

Um Engineering Effectiveness am smartesten zu realisieren, müssen wir uns zunächst darüber im Klaren sein, was Ihr Unternehmen erreichen möchte, und auf welche Weise eine hochleistungsfähige, effektive 

Softwareentwicklung Ihrem Business dient. Die vier wichtigsten Treiber für die Übernahme von Engineering-Effectiveness-Strategien sind:

• Senkung der Gesamtkosten für die Entwicklung, typischerweise durch Steigerung der Produktivität in der Entwicklung und durch die Ermittlung von Diskrepanzen zwischen den Qualifikationen und Fähigkeiten und den gewünschten Ergebnissen. 

• Toptalente für die Entwicklung gewinnen und binden, durch zufriedenstellende Erfahrungen und den Abbau von Barrieren für die  individuelle, team- und organisationsübergreifende Zusammenarbeit 

• Verkürzte Time-to-Value und schnelle Einführung von neuer Software, um disruptiven Marktakteuren und Wettbewerbern einen Schritt voraus zu sein.

• Verbesserte Vorhersagbarkeit der Delivery, um eine genauere, strategische und langfristige Entscheidungsfindung und Planung zu ermöglichen.

Der rote Faden, der sich durch alle diese Ziele zieht, ist die Produktivität. Unternehmen wollen hochproduktive Entwicklungsteams aufbauen und erhalten, die die erforderliche Software schnell, kostengünstig und auf einem gleichbleibend hohen Standard bereitstellen. Das Problem ist, dass sich Produktivität aus der Perspektive der Verbesserung sehr schwer messen lässt.

Wir können sie natürlich anhand des Teamoutputs und der Commits messen. Aber im Softwarebereich ist der reine Output kein wirklicher Hinweis auf das Ergebnis für die Nutzer:innen oder die Wertschöpfung fürs Business, und traditionelle Metriken wie die Geschwindigkeit sind relative Messgrößen, die sich leicht manipulieren lassen. Die verschiedenen Definitionen von Produktivität und die unterschiedlichen Arten, sie zu messen, erschweren eine konsistente Steigerung und können sich leicht demoralisierend auf die Teams auswirken oder unabsichtlich zu falschen Verhaltensweisen ermutigen.

Daher haben wir das Thema neu aufgerollt und den Schwerpunkt weg von trügerischen „absoluten“ Produktivitätsmessgrößen und stattdessen auf alle Formen von Verschwendung und Reibung verlagert, welche die Produktivität verringern können. Anders als die Produktivität lassen sich sowohl Verschwendung als auch Reibung sehr einfach nachverfolgen und messen (wenn Sie wissen, wo Sie suchen müssen). 

Zunächst müssen die größten Ursachen von Verschwendung erfasst werden. Anschließend müssen die Strategien zur Vermeidung priorisiert werden, basierend auf quantifizierbaren Auswirkungen auf die Wertschöpfung, und unter Berücksichtigung von Kosten und Komplexität,. Unternehmen greifen nur allzu oft gerne nach den „low hanging fruits“, einfach, weil es leicht ist, obwohl der Effekt dieser Abhilfemaßnahmen häufig sehr gering ist.  Dies lässt sich zum Teil darauf zurückführen, dass man in die Falle tappt, wenn man sich auf das konzentriert, was leicht zu messen ist oder bereits gemessen wird, anstatt sich die Mühe zu machen, das zu messen, was wichtig ist und einen hohen Wert hat.

Der Schlüssel zur Bekämpfung von Verschwendung und Reibungsverlusten liegt in der Visualisierung. Und darin liegt der entscheidende Denkansatz, der die Grundlage für die Engineering-Effectiveness-Lösung von Thoughtworks bildet. 

Wenn es uns gelingt, die Verschwendung und Reibungsverluste in den Wertströmen von Software und Technik sichtbar und quantifizierbar zu machen, können wir Teams und Führungskräfte dazu befähigen, diese zu verringern oder sogar zu beseitigen. Damit verbessern wir die Zufriedenheit von Entwickler:innen und tragen entscheidend dazu bei, Business Value zu generieren.

* Laut Google Engineering und vielen anderen ist die Produktivität zwischen Teams und sogar innerhalb eines Teams sehr subjektiv und l und im Laufe der Zeit nur schwer zu messen Unbestreitbar ist jedoch, dass jede Verschwendung, die Sie beseitigen, in Kapazität umgewandelt wird, die Sie wieder für mehr Durchsatz oder zur Deckung von Kosten einsetzen können.  Ein Beispiel für diese Argumentation eines für die Produktivität zuständigen Ingenieurs bei Google finden Sie hier.

Inside the Framework

Wir haben unser Engineering-Effectiveness-Framework basierend auf den spezifischen Techniken, Praktiken, kulturellen Normen und Betriebsmodellen aufgebaut, die in Top Softwareorganisationen und bei Digital Natives großen Impact geschaffen haben. So kann jedes Unternehmen einfach und schnell seine eigenen Rezepte für mehr Performance umsetzen. Hier sehen Sie, wie diese Denkweise sich im Framework niederschlägt.

Die Grundlage für die Ausführung des Frameworks ist eine durchgängige, quantitative Analyse der Produkt- und Entwicklungswertstroms und seiner Auswirkungen. Dies ist der erste Schritt, um reale und oft versteckte Ursachen von Verschwendung und Reibung zu ermitteln.   Indem wir sie in den technischen Abläufen eines Unternehmens aufdecken, können wir die besten Maßnahmen und Investitionen ermitteln, um sinnvolle, dauerhafte und systemische Veränderungen zu bewirken.

Das Framework unterteilt diese Interventionen in sechs Schwerpunktbereiche:

• Plattform- und Entwicklungskapazitäten: Sicherstellen, dass Plattformen, Pipelines, Beobachtbarkeit und andere Ressourcen zur Unterstützung von Entwickler:innen einfach zugänglich sind und eine produktive Entwicklung fördern, anstatt sie einzuschränken oder täglich Frustrationen bei den Teams zu verursachen.

• DevEx- und Produktivitätsbeschleuniger: Hier liegt der Fokus auf „Starter-Kits“, Referenzimplementierungen, benutzerdefinierten gemeinsamen Tools und Funktionen, die von Entwickler:innen für Entwickler:innen erstellt wurden. Diese sollen die Erfahrungen von Entwickler:innen verbessern und ihnen ihre Arbeit so einfach wie möglich machen, indem sich manuelle und fehleranfällige Aufgaben schnell und effektiv automatisieren lassen.

• Strategie und Befähigung zum Testen im Unternehmen:  Sicherstellen, dass Strategien und Testverfahren auf die Herausforderungen beim Testen von Legacy-, Cloud-nativen und Microservice-Ökosystemen abgestimmt sind, und Sicherstellen der Interoperabilität zwischen diesen Systemen, in großem Umfang und innerhalb Ihres Unternehmens.

• Domainorientierung und Cloud-Architektur: Unterstützung von Unternehmen beim erfolgreichen strategischen domainorientierten Design, bei der Entwicklung einer Plattformarchitektur und der Abstimmung von Teambegrenzungen, die eine echte Autonomie ermöglichen. Diese ist erforderlich, um sowohl die Softwaresysteme als auch die Integration in komplexen Umgebungen zu verbessern.

• Skalierung von Wissen und Führung: Verbesserung der Qualität der Dokumentation und der Datenkatalogisierung sowie Schaffung neuer Strukturen wie Kompetenzzentren, um die Zugänglichkeit der Informationen zu verbessern, die für eine herausragende Tätigkeit als Entwickler:in erforderlich sind.

• Ausrichtung und Governance des Betriebsmodells: Verbesserung des Arbeitsflusses, der Vorhersagbarkeit und Time-to-Value durch organisatorische, an den Ergebnissen ausgerichtete Entwicklungs- und Führungsstrukturen, eine wertorientierte Bereitstellungsgovernance sowie wertorientierte Praktiken für das Portfoliomanagement. Hierzu gehört auch eine Verankerung des Produktdenkens auf allen Ebenen einer Organisation.

Die Umsetzung der Prozesse und der Veränderungen in der Governance und Führung, die in den meisten Unternehmen notwendig sind, um die Engineering Effectiveness im großen Maßstab zu realisieren, erfordert umfassende Strategie- und Change Management Ressourcen. Aus diesem Grund beinhaltet unser Engineering-Effectiveness-Framework die entscheidenden organisatorischen Voraussetzungen für das Change Management — Kommunikation, strukturierte Weiterbildung von sowohl einzelnen Mitarbeitenden als auch von Führungskräften sowie das Talentmanagement.

Obwohl viele Unternehmen über einige dieser Ressourcen verfügen, haben wir erkannt, dass ein effektiver Wandel in Software Departments nur dann möglich ist, wenn die Führungskräfte aus der Entwicklung eng mit ihren organisatorischen Change Management- und HR-Funktionen zusammenarbeiten. Dies dient einerseits dazu, gegenüber den Entwickler:innen glaubwürdiger zu sein, und andererseits, die vielen individuellen Ideen zur Veränderung der Kultur im Engineering und der Kommunikation zu bewältigen. 

In manchen Unternehmen können die Methoden der Kommunikation, die Kultur und ein Mangel an disziplinierter, datengestützter strategischer Praxis in der Tat Quellen von Verschwendung und Reibung darstellen. Ein häufiges Beispiel sind unklare Befehlsketten, die eine effektive Kommunikation und Agilität einschränken. Um die Leistung zu steigern, sind – anstelle von Best-Effort- oder Selfservice-Lernressourcen – häufig formalisierte Weiterbildungs- und Selbstlernprogramme erforderlich, um Talente schnell und einheitlich in den verschiedenen Bereichen der Entwicklungsorganisation einzuarbeiten. 

Support beim Talentmanagement und der -rekrutierung kann dafür sorgen, dass Unternehmen eine attraktive Arbeitgebermarke aufbauen, die wiederum die richtigen Talente anzieht. Dabei ist es bei der Einstellung von Führungskräften für den Entwicklungsbereich besonders wichtig, dass sie die erforderlichen Fähigkeiten und Erfahrungen mitbringen, um die organisatorische Transformation voranzubringen. 

Wir haben festgestellt, dass viele großartige Entwickler:innen und technische Führungskräfte, die in Digital-Native-Unternehmen gearbeitet haben, sehr wohl „wissen, was gut aussieht“. Dafür fehlt ihnen oft das Wissen, wie sie den Change leiten und begleiten.

Auf den Punkt gebracht: Es braucht effektive, zielgerichtete und eigenständige Entwickler:innen

Entscheidend ist, dass es sich bei dem Framework nicht um einen „Einheits“-Plan zur Verbesserung der Engineering Effectiveness in jeder beliebigen Organisation handelt. Jede Umgebung hat einzigartige Herausforderungen, die unterschiedliche Prioritäten erfordern. Zu berücksichtigen sind dabei der aktuelle Reifegrad, die geschäftlichen Prioritäten und die Fähigkeit zur Veränderung. Es gibt Situationen, in denen es am meisten Sinn ergibt, zunächst nur einen oder zwei der sechs Schwerpunktbereiche aus dem Framework anzugehen. In anderen Situationen können wir unter Umständen alle sechs Bereiche gleichzeitig angehen, wobei wir mit den Initiativen mit dem größten Impact beginnen und dann den Schwerpunkt im Laufe der Zeit verfeinern und vertiefen.

Aber ganz unabhängig davon, welche Interventionen nun erforderlich sind, arbeiten wir jedes Mal, wenn wir das Framework anwenden, auf das gleiche Kernziel hin – effektive, gut koordinierte und eigenständige Entwicklungsteams für das gesamte Unternehmen aufzubauen.

Wir wenden unsere Expertise an, um Unternehmen dabei zu helfen, Verschwendung und Reibung innerhalb ihrer Prozesse zu visualisieren, und genau zu ermitteln, wo und wie sie eingreifen müssen, um diese Probleme zu lösen und schnell wichtige Schlüsselfunktionen zu schaffen. Damit trägt Thoughtworks zu Entwicklungsumgebungen bei, in denen:

• die Entscheidungsfindung in der gesamten Organisation gebündelt ist, um zu gewährleisten, dass die Teams agil und effektiv und zugleich auf die Geschäftsstrategie ausgerichtet bleiben.

• Kosten minimiert werden, weil es weniger Fehler und zeitraubende Hindernisse für die Delivery gibt.

• die Delivery dank geringerer Reibungsverluste im gesamten Software-Wertstrom wirklich „agil“, schneller und besser vorhersagbar ist.

• die Entwickler:innen jeden Tag Freude an ihrer Arbeit haben, ihre Ziele kennen und in der Lage sind, diese auf reibungslose Art und Weise zu realisieren.

Tipps für eine effektive Transformation

Nr. 1) Sorgen Sie dafür, dass Sie wissen, wie „gut“ wirklich aussieht

Wenn Sie Maßnahmen ergreifen, um die Effektivität Ihrer Entwickler:innen zu steigern, ist es wichtig, sich darüber im Klaren zu sein, welchen Zustand Sie anstreben. Die bewährten Verfahren im Engineering entwickeln sich ständig weiter, und wenn Sie versuchen, eine veraltete Definition wie „DevOps-Erfolg“ anzustreben, werden Sie nicht annähernd die Wirkung erzielen, die Sie mit demselben Aufwand erreichen könnten, wenn Sie wüssten, wie der Stand der Technik wirklich ist.  

Um ehrlich zu sein – die „High Performer“ unter den Entwicklungsorganisationen verwenden den Begriff DevOps schon seit Jahren nicht mehr. Wenn Sie noch über eine „DevOps“-Transformation sprechen, greifen Sie unter Umständen auf ein mehr als 5 Jahre altes Erfolgsmodell zurück.  Sie müssen nicht die ausgetretenen Pfade Ihrer Vorgänger:innen beschreiten, sondern können viele anstrengende Jahre überspringen, wenn Sie wissen, wie „hohe Leistung“ heute aussieht.

Nr. 2) Unterschätzen Sie nicht den Einfluss von Führung und Governance

Wenn Sie versuchen, die Effektivität von Entwickler:innen zu verbessern, mag es verlockend erscheinen, Ihre Aufmerksamkeit in erster Linie auf die einzelnen Mitarbeiter:innen und die Teamebene zu richten. Viele Faktoren, welche die Effektivität in der Entwicklung einschränken, haben jedoch ihren Ursprung weiter oben in der Organisation.

Die Engineering Effectiveness erfordert eine signifikante Transformation der Kultur, der Prozesse und der Organisation – und all das muss von der Führungsebene aus gesteuert werden. Ohne die Vision und die Unterstützung der Führungskräfte auf allen Ebenen der Entwicklungsorganisation (und manchmal darüber hinaus) ist es nahezu unmöglich, deutliche Verbesserungen in der Engineering Effectiveness zu erzielen. 

Darüber hinaus ist eine „Bottom-up“- oder „organische“ Transformation erforderlich, aber die Bemühungen an der Basis kommen meist zum Erliegen, wenn sie nicht über die gesamte Führungskette hinweg aufeinander abgestimmt sind. Der Faktor, der am häufigsten übersehen wird, ist die Entwicklungsversion der berühmten „eingefrorenen Mitte“ – Führungskräfte in der Entwicklung, deren Anreize und Fähigkeiten nicht mit den Veränderungen übereinstimmen, die sie leiten sollen. 

Das „Bindeglied“ aus Führungskräften auf der Ebene der Direktor:innen und leitenden Entwickler:innen muss sowohl über fundierte technische und architektonische Kenntnisse als auch über Erfahrung in der Führung von Mitarbeiter:innen und der Verbesserung der Organisation verfügen. Damit wird gewährleistet, dass die Vision der obersten Führungsebene in die Strategien einfließt, die auf Teamebene umgesetzt werden müssen, und dass das Feedback aus den Bereichen, in denen die Arbeit erledigt wird, wieder in die Strategie auf oberster Ebene einfließt.   

Dies ist möglicherweise der größte Einzelfaktor, den wir bei verzögerten oder gescheiterten Transformationsbemühungen beobachtet haben – eine eingefrorene (oder sogar fehlende) mittlere Führungsebene.  Selbst wenn mutige Führungskräfte in der Entwicklung den Wandel vorantreiben und die Mitarbeiter:innen an der Basis innovativ und aktiv sind, ist eine erfahrene und effektive mittlere Führungsebene der entscheidende Faktor, um die gesamte transformative Energie konstruktiv zu halten und in die gleiche Richtung zu lenken.