1. Einleitung

„Developer Experience“? Entwicklung ist nicht unser Business!

Ihr skaliert euer Projektteam: Endlich ist der neue Entwickler da! Doch neue Features werden kaum schneller fertig. Auf Nachfrage erhaltet ihr das Feedback: „Die Developer Experience ist schlecht”. Eure erste Reaktion ist: „Wir tun, was wir können…“ Das Thema erhält ein Feature-Ticket in eurem Planungstool mit der Dringlichkeit „Niedrig“ und wird aufgrund eurer kritischen Prioritäten monatelang verschoben, bis auch der letzte Entwickler es vergessen hat.

So sieht leider häufig die Realität aus. Doch viele Unternehmen beweisen, wie transformativ eine gute Developer-Experience (DX) sein kann und bauen sogar eigene Teams für DX auf und stellen eigene Software dafür her:

• Dell: Wie mit DX die IT-Entwickler-Produktivität um 275% verbessert wurde
• Etsy: Warum 20% ihrer Entwickler an DX arbeiten
• Spotify: Wie sie mit „Backstage“ die DX von über eine Million Entwicklern transformieren
• Airbnb: Warum ihr DX-Team entstanden ist
• IBM: Wie 100.000 Entwickler vom internen „Director of DX“ ermächtigt werden

Es liegt in der Natur von Entwicklern, Verbesserungen an der DX anzustoßen. Doch Projektleiter fühlen sich häufig gezwungen zu sagen:

• „Wir haben jetzt nicht die Kapazität für sowas“
• „Das funktioniert nicht bei uns“
• oder sogar „Es funktioniert auch ohne ganz gut…“

Für die meisten Unternehmen ist Software-Entwicklung eben nicht das Kerngeschäft! Und wenn man auf den größten Nutzen schaut, verliert DX ganz klar gegen Business-Features. Dabei fällt aber leider unter den Tisch, was für einen immensen Schaden schlechte DX verursachen kann — besonders dann, wenn Software-Entwicklung bei euch eben nicht das Kerngeschäft ist! Und Zusammenarbeit mit Dritten und Externen macht Entwicklung dann extra teuer, weil sich dieses Problem nicht outsourcen lässt.

Beachte deshalb: DX ist mehr als ein Feature. Es ist ein Multiplikator:

Schalte in den nächsten Gang mit DX: Projektleitungen erhalten hier im Artikel eine Art Röntgen-Blick, um komplexe Zusammenhänge zu vereinfachen und Potenziale in Projekten und im gesamten Unternehmen freizulegen! Deshalb sollte jeder Projektleiter DX im Auge haben.

Ich durchleuchte für euch dieses Thema mit einer Serie von Artikeln, damit ihr eure Projekte kürzer, günstiger und mit höherer Qualität abliefern könnt. Kurz gesagt: Um eure Innovationskraft steigern zu können - eine Leitlinie der „Cloudkoloss-Methode“.

Einordnung: DX besteht doch nur aus Tools, oder?

Am häufigsten werden mit DX technische Aspekte in Verbindung gebracht:

• Tools, welche für die Prozesse, Planung, Design und Ablauf notwendig sind
• Programme, welche für Entwicklung benutzt werden
• Programme, die im Hintergrund laufen müssen
• Kommunikationstools
• Hardware (Laptops, Server, Cloud)

Zusammen ergeben sie die Arbeitsumgebung, innerhalb der alle Projektarbeiter inklusive Entwickler ihren gesamten Arbeitsalltag verbringen.

Welche Tools ihr einsetzt, ist vollständig eurem Unternehmen überlassen. Aber die Masse an Optionen ist kaum überschaubar und es kommt stetig neues hinzu. Die bloße Anzahl an News zu neuen Tools könnte dich zu dem Schluss bringen, dass DX ausschließlich durch Verbesserungen von Hard- und Software definiert wird. Das beinhaltet auch Game-Changer wie ChatGPT, welches DX massiv beeinflussen kann.

DX wird aber noch durch weit mehr beeinflusst, als die eingesetzten Tools, sondern vor allem durch Prozesse.

Ein gesunder Rahmen: Prozess-DX zuerst!

In Kombination ergeben alle eure Prozesse den Rahmen, innerhalb dessen sich euer Projekt im Unternehmen bewegen kann. Erst wenn ein gesunder Rahmen gesetzt ist, nur dann können neue Tools ihre versprochene Wirkung zeigen. Deshalb gilt: Zuerst eure Prozesse optimieren! Erst wenn ihr bereit seid, eure Prozesse zu modernisieren, nur dann könnt ihr Vorteile von neuen Tools erwarten — alles andere ist 💄 auf einem 🐷.

Das folgende soll euch dabei helfen, eine Perspektive anzunehmen, mit der du diesen gesunden Rahmen selber aufbauen kannst. Meistens werden Prozesse für jedes Projekt individuell aufgesetzt. Denn jeder Blumenstrauß an Prozessen ist so individuell, wie die Leute, die am Projekt beteiligt sind. Deshalb braucht man flexible Werkzeuge, die euch dabei helfen, diesen Blumenstrauß zusammenzustellen. 💐=🌷🌻🌵

Wer kümmert sich darum?

Man könnte vermuten, dass Entwicklungsteams und ihre Leads selbst für ihre Prozess-DX verantwortlich sind. Aber bedenke Folgendes: Developer werden mit allem arbeiten, was ihr ihnen in die Hände gebt! Schlimmer noch: Sie gewöhnen sich daran und finden es dann auch noch „OK“, damit zu arbeiten! Warum ist das schlimm? Weil dann jegliche DX-Innovation kategorisch nicht in euer Projekt und Unternehmen gelangen kann! Developer sind mit ihrer Projektarbeit bereits zu 100% ausgelastet und die wenigsten beschäftigen sich in ihrer Freizeit damit, wie sie ihren Projektalltag verbessern können — vor allem, wenn die Entscheidungen vor vielen Jahren über ihre Köpfe hinweg getroffen wurden. Ein Kampf gegen Windmühlen…

Lead-Entwickler sind in einer einflussreicheren Position und sollten natürlich so viele DX-Verbesserungen an ihr Team weitergeben, wie nur möglich. Im Kern handelt es sich dabei nämlich um pure „Erfahrung“ - eine Schande, solche „Lessons Learned“ nicht umzusetzen. Doch auch hier besteht eine natürliche Grenze, weil sie nur geringen Einfluss auf übergreifende Unternehmensprozesse und Regeln haben wie z.B. veraltete Unternehmens-Policies.

Die Hauptverantwortung liegt zwangsläufig bei der Projektleitung. Für sie schlage ich folgendes Mindset vor: Die Projektleitung sollte seine Entwickler als „Kunden“ betrachten: Wie designen wir unser Kaufhaus, sodass unsere Kunden eine möglichst gute Erfahrung beim Shoppen haben? Sprich: Wie organisieren wir unser Projekt und Unternehmen, damit sich unsere Entwickler auf neue Features konzentrieren können? Am Ende hat die Projektleitung davon mehr als jeder andere.

Man bedenke auch, dass schlechte DX eure Entwickler dazu bringen kann, euer Unternehmen zu verlassen. Oder sie kann ein Symbol dafür sein, wie gut es bei euch läuft und neue Entwickler anlocken — HR (Human Resources) wird sich freuen.

2. Schlechte Prozess-Developer-Experience

„Setze 3 Millionen € auf MEHR ENTWICKLER!“

Wie entsteht Software? Das sehen wir in der Grafik aus der Kategorie „traurig, aber wahr”. Die eigentliche Entwicklung wurde gezielt als „Black Box“ dargestellt, weil für Außenstehende oft nicht klar ist, wie Entwickler eigentlich ihre Zeit verbringen müssen. Oft betrachtet man nur die eigene Perspektive: Man gibt Inputs, Regeln, Auflagen und Anforderungen an die Entwickler, welche sie irgendwie umsetzen müssen und sieht dann langsam zu, wie die finale Software entsteht (natürlich mit extrem vielen Feedback-Loops, welche hier nicht abgebildet sind).

Wenn man dann den Output des Development Teams betrachtet, ist man oft unterwältigt und fragt sich, warum das so langsam geht! Was kann man tun, um die Herstellungsrate zu erhöhen? Das Bauchgefühl sagt: „Mehr Entwickler!“ Doch ist das überhaupt eine mögliche Lösung?

Mehr Entwickler würden unter den gleichen Prozessproblemen leiden und ebenfalls ausgebremst werden. Dazu kommen folgende Probleme:

1. Erfahrene Entwickler sind äußerst knapp durch ihre hochgradige Spezialisierung und den Fachkräftemangel
2. Erfahrene Entwickler sind die teuerste Ressource auf einem Projekt: teurer als Infrastruktur, teurer als Softwarelizenzen, teurer als Computer-Hardware, teurer als so ziemlich alles, was man sich auf einem durchschnittlichen Projekt vorstellen kann! Nur die Zeit von kritischen Wissensträgern kann teurer sein: Wenn sie nicht die notwendigen Inputs für Designs liefern, so führt dies zu Leerlauf bei den Entwicklern. Ihre Zeit ist also im übertragenen Sinne teuer.
3. Entwickler sind im Durchschnitt nicht gut in Kommunikation und Design! Sie haben ein spezielles, unersetzliches Profil an Fähigkeiten, aber Nachteile in folgenden Bereichen: Durchsetzung, Eskalation, Konfliktbewältigung, Delegation, lösen von Missverständnissen und viele mehr dieser Art. Ihr Entwickler-Profil zu kultivieren ist bereits schwer genug. Deshalb sollte man sie nicht doppelt belasten, indem man ihnen unpassende Aufgaben auferlegt — man zahlt nämlich extra durch den erhöhten Zeitaufwand.

Was kann man also tun, um die Herstellungsrate zu erhöhen? Also wie erhält man neue und robuste Features, welche den Business-Value unserer Software erhöhen?

Wenn alle Entwickler von etwas gleichermaßen ausgebremst werden, weiß man, dass die Rahmenbedingungen nicht stimmen. Diese sind vor allem durch Prozesse und ihre implizierten Regeln bestimmt. Deshalb muss man zuerst genau diese optimieren, bevor „mehr Entwickler” eine sinnvolle Option wird. Das ist, worum es bei Prozess-DX geht.

Als Erstes müssen wir die Entwickler-Black-Box durchleuchten. Daraus werden die Variablen klar, die es zu optimieren gilt.

Worst-Case? Recht Normal.

Wir betrachten ein vereinfachtes Beispiel: Wir sehen einen Durchschnitt des Arbeitsalltags von Entwicklern mit schlechter Prozess-DX.

Und hier die zugehörigen Beispiele, welche zu einem solchen Zeitprofil führen:

• Kommunikation: Zugang zu notwendigen Systemen oder Daten liegt nicht vor und Dritte sind schlecht erreichbar, Eskalation ist auch notwendig.
• Kommunikation & Design: Tickets zu Anforderungen oder Design sind nicht vollständig, die Entwickler müssen die Lücken schließen: Ein aufwändiges hin und her mit den Designern, Usern und Dritten beginnt (E-Mails und Meetings).
• Overhead-Prozesse: Standardprozesse fordern Aufmerksamkeit: Reporting, Zeitlogging, E-Mails, Meetings (Dailies, Weeklies, Planung, Status, Agile, Jour fixe, All-Hands, Ankündigungen, …) und viele mehr!
• Folgeproblem: Technische Schulden holen den existierenden Code ein: Statt neuer Features, müssen erst mal die alten Features repariert, Bugs beseitigt und insgesamt Robustheit in die Codebase gebracht werden.
• Folgeproblem: Im schlimmsten Fall sind Entwickler blockiert und können gar nicht implementieren oder müssen Aufgaben erledigen, welche eigentlich von Nicht-Entwicklern erledigt werden sollten (Kommunikation, Design, Budgetplanung, …).
• Overhead: Veraltete Policies und Regeln fordern ihren Tribut: Sie machen den Alltag komplexer als nötig, jeder weiß es, aber keiner glaubt etwas dagegen machen zu können.

Das Schlimmste an diesen einzelnen Fehlerquellen ist aber, dass sie aufeinander aufbauen: Hat man erst mal ein Problem, dann wirkt schlechte Prozess-DX wie ein Brandbeschleuniger und es türmen sich die kritischen Probleme. Man kommt schnell in den berühmten „Feuerwehr-Modus”, aus dem man nur schwer wieder herauskommt.‍🔥🚒

Unterm Strich bleibt somit nur noch wenig Zeit für neue Features, weil einfach so viel anderes zu tun ist oder das System noch gar nicht bereit für neue Features ist, also technisch blockiert ist.

Es ist wie eine Stadt ohne Müllabfuhr: Der Müll wird entstehen — das ist gewiss. Aber hat die Stadtverwaltung Prozesse aufgesetzt, wie Probleme zu beseitigen sind? Oder soll jeder seinen Müll im Garten verbrennen? In diesem Beispiel muss sich jeder Entwickler selbst um „seinen Müll” kümmern — er hat ihn nicht verursacht, aber er ist halt am nächsten dran.

Der Normalzustand: es brennt überall und es geht kaum vorwärts. Probleme werden nicht dort gelöst, wo es am günstigsten ist, sondern wo sie zufällig hinfallen. Man könnte jetzt behaupten: so sieht halt der Alltag in großen und/oder alten Unternehmen aus! Man rationalisiert: „Unsere Arbeit ist halt komplex! Das ist der Preis unserer Komplexität.“ Und viele Unternehmen und auch Entwickler gewöhnen sich genau daran.

Es muss aber nicht so sein.

3. Werkzeuge für bessere Prozess-DX

Der Löwenanteil von Prozesskosten

Weil Entwickler die teuerste Ressource sind, unterscheide ich zuallererst, wie Entwickler von Prozessen beeinflusst werden. Nicht-Entwickler lasse ich absichtlich aus diesen Kosten raus, weil sie ein wichtiger Teil der Lösung sind, wie wir gleich sehen werden. Es genügt zu wissen, dass sie im Vergleich zu Entwicklern günstiger sind. Denn irgendwer muss die Arbeit schließlich erledigen — wir können nichts weglassen, ohne die Qualität zu mindern.

Wir setzen nun die Prozess-DX-Brille auf, indem wir mit dieser Kernfrage beginnen:

Davon interessieren uns folgende unerwünschte Stunden:

Es ist leicht ersichtlich, dass sie sich negativ auf unsere Zielgröße auswirken:

Der wichtigste Anteil der Kosten eines Prozesses ist also, wie viel „Entwicklerzeit in Stunden für neue Features“ man dafür tauschen muss. Aus dieser Tauschrate bilden wir zwei KPIs, welche eine wundervolle Vereinfachung für die Messung von Prozesskosten sind.

Man beachte außerdem: Die Kosten eines Prozesses sind nicht nur die rohe Zeit für Meetings, Kommunikation und Tools, sondern auch, wie es sich auf die „Deep-Work”-Zeit der Entwickler auswirkt: Je mehr Zeit in Meetings/Kommunikation/Tools verbracht wird, desto mehr Unterbrechungen gibt es stündlich bei den Entwicklern, wodurch sie weniger Zeit im „Flow“ verbringen und nochmals weniger produktiv sind.

Unterbrechungen sind also ein negativer Skaleneffekt mit eigenen, weiteren Nachteilen. Idealerweise haben Entwickler große, unterbrechungsfreie Zeitblöcke, frei von Meetings, E-Mails und „dringenden“ Chat-Benachrichtigungen, welche sogenannte „Kontextwechsel“ erfordern — diese müssen minimiert werden.

Neue Prozess-DX KPI’s

NDQ = Neue Features

Unser Ziel ist es, den Anteil der Entwicklerzeit für neue, robuste Features sensibel zu maximieren. Das ist der:

Damit messen wir, ob die Prozess-DX gut ist: In unserem Worst-Case Beispiel ist die NDQ ausgesprochen niedrig. Also schlechte Prozess-DX, weil Entwickler sich um zu viel Anderes kümmern müssen, anstatt neue Features zu entwickeln. Die Zielgröße „New Development Quotient“ (NDQ) ist allerdings nicht frei von Problemen: Sie hat Konfliktpotenzial, wenn man sie durch Priorität forciert — wir betrachten dazu gleich ein Beispiel. Deshalb empfehle ich sie lediglich als „Stimmungsbarometer“ zu verwenden, nicht aktiv zu steuern.

Stattdessen sollte man „alles andere“ reduzieren, was durch den „Developer-Overhead-Quotient“ (DOQ) zusammengefasst wird.

DOQ = Alles Andere

Entwicklerzeit in Stunden für Meetings, Kommunikation und Tools sind die wichtigsten Stellvertreter für die Kategorie „Entwicklerzeit für alles andere“ (es gibt natürlich mehr, aber wir wollen schließlich vereinfachen). Ich nenne es den:

Der DOQ hat zwei Bestandteile:

1. Fundamentale Prozessschritte: Wenn ihr sie weglasst, schadet es eurem Business-Value.
2. Echter Developer-Overhead.

Diese beiden zu unterscheiden, ist eine Kunst! Deshalb fassen wir sie zuerst zum DOQ zusammen, weil man auf diese Weise kontinuierlich hinterfragen muss:

Mit dieser Frage beginnt man bereits, die Prozess-DX zu optimieren, weil man damit echten Developer-Overhead als solchen identifiziert!

Mit der Zeit können aktuell-noch-fundamentale Prozesse outgesourced oder redundant gemacht werden - entweder durch eigenes Redesign oder externe Innovation. Durch diese Minimierung des echten Developer-Overhead sinkt der DOQ und damit steigt letzten Endes der NDQ auf sensible Weise — so und nicht anders.

Aber Moment mal: „Wir vermeiden doch Overhead! Oder?”. Vermutlich nicht: Leider ist das Mantra „Overhead vermeiden“ zu einer leeren Hülle mutiert. Oft wird nur der absolut offensichtliche Overhead gestrichen. Selten werden Projektprozesse so designt, dass die Beteiligten damit glücklich sind. Dazu kommt: Je größer die Organisation, desto wahrscheinlicher habt ihr sogar „Overkill-Prozesse“ (z.B. 20 DIN-A4 Seiten Onboarding-Instruktionen). Wenn es nicht so wäre, würdet ihr bereits einen hohen Anteil an neuen und robusten Features genießen, also einen hohen NDQ über mehrere Jahre hinweg haben.

Addiert ergeben NDQ und DOQ immer 100% eurer Entwickler-Arbeitszeit. Sie ergeben also ein Spektrum. Überlege kurz: Wo landet euer Team jetzt gerade auf diesem Spektrum?

Der Teufelskreis des DOQ

Projektleiter werden jetzt denken: „Unsere Entwickler konzentrieren sich doch auf neue Features! Das leuchtet doch ein!” Man versucht, den  NDQ 

Entwickler werden dabei sofort aufschreien! „Wisst ihr nicht, was wir uns sonst noch alles machen müssen?” Also Widerstand, die Erwartungshaltung eindämmen und sich Zeit einräumen für die vielen Nebenprozesse, sobald etwas schiefläuft. Und wenn Entwickler eines wissen, ist es, dass „alles, was schieflaufen kann, auch schieflaufen wird“ (Murphys Gesetz).

Entwickler müssen also einen höheren  DOQ 

Denn mit jedem neuen Feature steigt die Komplexität und Anfälligkeit des Systems. 0%  NDQ 

Robustheit von neuen Features wird nämlich nur dann erreicht, wenn alle Voraussetzungen stimmen (insbesondere gutes Design ➡ durchdachte Anforderungen). Ansonsten hat man instabile Features entwickelt, welche kurz nach Release ihre Designlücken und technischen Schulden offenbaren.

Es ist also ein Problem, welches nicht durch Priorisierung gelöst werden kann, sondern nur an der Wurzel. Ansonsten wird die Situation in jedem Sprint immer schlechter, bis ihr gefühlt gar keinen Fortschritt mehr machen könnt: Feuerwehr-Modus. Ich nenne es den „Teufelskreis des DOQ“. Die Betrachtung der Prozess-DX macht dieses Problem transparent, weshalb sie kritisch für jedes Projekt ist.

Der Teufelskreis des DOQ in Aktion

1

Der DOQ kann auch als „Wasserstand“ verstanden werden: Alle prozessualen Probleme haben einen negativen Einfluss auf eure Entwicklerproduktivität. Je mehr sich Entwickler mit DOQ-Aufgaben rumschlagen müssen, desto geringer ist der Fortschritt eines Projekts. Wenn man jetzt nicht bereits interveniert, tritt man den Teufelskreis los.

2

Den DOQ zu ignorieren, ist das gleiche wie den NDQ naiv zu priorisieren: Man ignoriert die existierenden Probleme. Die Folge: Ein noch schlechterer DOQ!

3

Durch die prozessualen Kernprobleme, muss mehr Zeit in DOQ-Aufgaben investiert werden (Kommunikation, fehlende Inputs, Prozesse, Overhead). Doch es entstehen auch neue Probleme:

• Technische Schulden (mittel- bis langfristige Nachteile): Früher oder später müssen sie beglichen werden!
• Designlücken und -fehler führen zu redundantem Code — der Code war niemals robust
• Leerlauf: Fehlende Inputs und Nacharbeiten im Design führen zu blockierten Entwicklern

4

Im Endstadium kommen die Entwickler gar nicht mehr dazu, neue Features zu entwickeln. Man ist zu 100% damit beschäftigt die bestehenden Funktionen nutzbar zu halten. Der DOQ hat dann den gesamten Arbeitsalltag der Entwickler eingenommen.
Ist man in diesem Zustand angekommen, so erholt sich ein Projekt nicht einfach davon. Häufig ist man dann am Ende des Projekts angekommen, wo sich alle diese Probleme aufgestaut haben. Oder das Projekt geht dann in eine neue Phase über. Fest steht: In diesem Zustand kann kein Projekt lange operieren.

5

Eine besonders unschöne DOQ-Aufgabe sind Eskalationen. Wenn Entwickler darin verwickelt sind, hat man einen Beweis, dass die Projektprozesse nicht im Unternehmen integriert sind. Anstatt die Effizienz von Projekten zu optimieren, kämpft man nur noch mit einer Frage: „Mit welcher Option vermeiden wir den größten Schaden? “

Lasst es nicht soweit kommen! Brecht den Teufelskreis, kümmert euch früh um den DOQ!

4. Prozess-DX korrekt optimieren

Den DOQ reduzieren

Auf einen Satz reduziert lautet das Ziel der Prozess-DX Optimierung:

Wie minimieren wir, die Projektleitung, den Developer-Overhead-Quotient?

Im Gegensatz dazu steht das alte Mindset, dass Entwickler ungeachtet der Konsequenzen neue Features priorisieren sollen, was schnell zu technischen Schulden führt (besonders bei Junior-Entwicklern). Dazu muss echter Developer-Overhead erkannt und dann geeignete Maßnahmen eingeleitet werden.

Generell empfehle ich, dass man jeden einzelnen Prozessschritt folgendermaßen evaluiert:

Die Tauschrate könnt nur ihr für euch selbst bestimmen. Sorgt aber dafür, dass es eine bewusste Entscheidung ist, deren Kosten ihr euch transparent gemacht habt. Fragt euch aktiv: „Ist der Prozess ‘ABC’ 4 Stunden pro Entwickler pro Woche sein Ergebnis wert?“ Habt ihr eine Kultur, in der sich eure Projektleitung kritisch mit Anforderungen von Kunden und höherem Management auseinandersetzt und diese Kosten zurückmeldet? Vermutlich gibt es so einige Anforderungen, die zurückgezogen werden, wenn den Anfragenden diese Tauschrate vor Augen geführt wird.

Prozesse ganz oder teilweise den Entwicklern abzunehmen ist der wichtigste Schritt, um eure Prozess-DX zu verbessern. Alle anderen Maßnahmen verblassen im Vergleich dazu. Lasst uns dazu auf bereits etablierte Rollen schauen, welche aber immer noch nicht die Norm sind.

Gutes Staffing = Guter DOQ

Die Grundregel lautet: Probleme dort lösen, wo es am günstigsten ist. Nicht-Entwickler sind in der Regel leichter verfügbar und auch günstiger als erfahrene, hochspezialisierte Entwickler. Deshalb sollten alle Prozesse, welche man Entwicklern abnehmen kann, an spezialisierte Nicht-Entwickler abgeben.

Diese haben meist ein vollkommen anderes Profil an Fähigkeiten (insbesondere bessere Kommunikation), was ihnen ermöglicht, Komplexität abzunehmen und bessere Lösungen rund um kommunikative Aufgaben zu designen — auch bei geringerem Erfahrungsstand.

Diese etablierten Nicht-Entwickler-Rollen geben den Entwicklern vor allem Meeting- und Kommunikationszeit zurück. Spezialisierte Nicht-Entwickler bringen durch ihre Erfahrung bessere Prozesse mit, welche weniger Entwicklerinput in Tools benötigen. Durch das alles sinkt der  DOQ 

Konkret empfehle ich folgende Rollen mit mindestens einer Person zu besetzen, welche sich fast alle wegen ihrem hohen Kommunikationsanteil vom Entwickler-Wunschprofil unterscheiden:

Potenzial durch Kommunikation und andere Fähigkeiten:

• Business Analyst: Anforderungsanalyse und -management, eine absolut kritische Rolle, welche von zu vielen unterschätzt wird! Häufig wird sie von bestehenden Projektarbeitern „miterledigt”, wodurch viel Potenzial auf dem Tisch bleibt. Großer Fehler: Es von Entwicklern miterledigen lassen. Der Archetyp für diese Rolle ist „äußerst kommunikativ”, also das Gegenteil vom durchschnittlichen Entwickler.
• Agile-Practitioner: Scrum-Master oder ähnliche, Hauptsache jemand, der alle Prozesse rund um eure wichtigsten Tools verantwortet, insbesondere das Ticket System. Gerade in kleinen Teams eine nicht ernstgenommene Rolle — man vergisst leider, welchen Dienst sie dem gesamten Team langfristig erweisen.
• UI/UX-Designer: Offensichtlich, dass sie eine komplett eigenständige Gruppe mit schnittmengenfreien Fähigkeiten sind. Dennoch werden nicht oft genug Spezialisten eingesetzt, sondern mit Generalisten substituiert. Auch ein beliebter Fehler: Frontend-Entwickler dafür einsetzen.
• Support: Besonders wenn viel Feedback/Bug-Reports und andere Inputs von Nutzern ankommen, macht es Sinn, jemanden für die Kommunikation und Abwicklungsprozesse einzusetzen. Man könnte es auch als „externe Kommunikation“ generalisieren. Dafür ist mit Sicherheit kein Entwickler notwendig.

Potenzial durch Kommunikation & Spezialisierung:

• Quality-Assurance: Manuelles Testing und Testautomation werden häufig von Entwicklern übernommen. Das ist unnötig teuer und das Thema bekommt selbst dann noch nicht genügend Aufmerksamkeit, weil es dann mit neuen Features um die gleiche Ressource buhlen muss: Entwicklerzeit. Die Vorteile diese Rolle zu besetzen, basieren nicht nur auf „Kommunikation”, sondern auch auf Spezialisierung: QA-Mitarbeiter sind günstiger und auch leichter auszubilden, als Entwickler! Ihre Spezialisierung schafft dadurch Kapazität bei den Entwicklern.

Potenzial durch Spezialisierung:

• DevOps/Infrastructure/Cloud Engineer: Die meisten DevOps/Infra Entwickler haben in der Regel Erfahrung als „normale“ Entwickler, aber nicht andersherum. Sie sind auch daher einzigartig in dieser Liste, weil sie noch teurer und knapper als Entwickler sind. Ihr potenzieller Impact ist aber besonders groß, weil sie Einfluss auf den gesamten Workflow der Entwickler haben (Tool-DX). Ein Grund mehr, diese Rolle mit Erfahrung zu besetzen, oder mindestens mit jemandem, der sich voller Enthusiasmus auf diesen Bereich stürzt. Und sobald ein Entwickler in DevOps/Infra angekommen ist, bleibt eigentlich überhaupt keine Zeit mehr für Entwicklung — der Bereich ist einfach zu groß. Übrigens: das alles sind gute Gründe diese Spezialisten in einer eigenen Abteilung zu zentralisieren (Thema „Platform Engineering”), wo sie zentral für alle Projekte hervorragende DX (Tools und Prozesse) implementieren können (dieses Thema wird in einer eigenen Serie von Artikeln behandelt).
• Security Engineer: Idealerweise ebenfalls zentral wie DevOps/Platform Engineering, damit Entwickler sich nicht in dieses komplexe Thema einarbeiten müssen — die Themen sind einfach zu speziell, das notwendige Profil zu unterschiedlich. Denn Entwickler sind keine „Hacker“ und Hacker keine Entwickler! (Ja, Security Engineers sind auch keine Hacker, aber am nahesten dran).

In kleineren Projekten besetzt man sie mit Generalisten mit ausreichend Erfahrung. Die wichtigste Trennung, die ich hier einführen möchte: Entwickler sind keine Generalisten! Es sollte also eine strikte Trennung zwischen Nicht-Entwickler Aufgaben und Entwickler-Aufgaben geben. Ähnliches gilt übrigens für Projektleiter/Product Owner und ähnliche, welche einfach alles übernehmen, was übrig bleibt! Der Definition nach also Generalisten. Meistens reicht ihre Zeit aber nicht, weshalb sie selbst zum Flaschenhals werden, indem sie den Entwicklern nicht schnell genug zuarbeiten können (Anforderungen, Designs, Inputs, …), doch das behandele ich in einem anderen Artikel.

Wenn ihr diese Rollen noch nicht auf dem Projekt (oder zentral) besetzt habt, dann habt ihr jede Menge Potenzial an Geschwindigkeit zuzunehmen! Es bedeutet nämlich im Umkehrschluss, dass eure Developer und „Manager“ (PO’s/PMO’s und ähnliche) das alles übernehmen. Würden sie es nicht tun, dann hättet ihr ein noch größere Folgeprobleme: mehr Bugs, Regression, redundanter Code, Instabilität, wenig Skalierbarkeit, manuelle Prozesse und so weiter.

Wenn jede dieser Rollen besetzt wurde, dann seht ihr, ob euer  NDQ 

5. Fazit

In diesem Artikel haben wir Ursachen und Werkzeuge kennengelernt und die erste große Maßnahme angefangen, mit der man echten Developer-Overhead effizient auslagert: Der Einsatz von spezialisierten Nicht-Entwicklern statt Entwickler-Generalisten. Staffing ist zwar eine Grundlage in jedem Projekt, jedoch haben wir der Sache durch „Developer Experience“ (DX) eine neue Perspektive gegeben. Staffing erhält also keine weitere Nebenbedingung, sondern wird einfacher!

Damit sollte euch DX als Werkzeug vorgestellt werden, welche komplexe Zusammenhänge und Flaschenhälse für die Projektleitung transparent machen kann. Wir haben den Aufschlag mit Prozess-DX gemacht und damit einen gesunden Rahmen gesetzt. Doch es gibt noch sehr viel mehr Potenzial, eure Innovationskraft damit zu erhöhen! Viele Themen wurden hier nur angeschnitten, um diesen Artikel einigermaßen kurzzuhalten. Jedoch wollte ich euch zuerst das Potenzial aufzeigen, wie ihr selbst Prozess-DX einsetzen könnt, ehe wir in die vielen möglichen Maßnahmen eintauchen. Die hergeleiteten Begriffe  NDQ 

Eine wichtige Limitation dieses Artikels: Das Zusammenspiel der Entwickler mit den Nicht-Entwicklern wurde nicht detailliert erläutert. Es sollte nämlich zuerst klargemacht werden, wie wichtig die bloße Existenz der genannten Nicht-Entwickler-Rollen ist. Nicht ohne Grund gehören sie zum Standard bei vielen Unternehmen — eigentlich verdient jede der genannten Rollen einen eigenen Artikel! Trotzdem werden sie zu oft nicht besetzt, weil man glaubt dadurch Kosten sparen zu können — die Ursache dieses Fehlers sollte hier durch die „DX-Brille“ sichtbar gemacht werden: Unterm Strich ist es nämlich teurer, diese Rollen nicht zu besetzen.

In Zukunft werden wir im Detail betrachten, wie Teams optimal zu besetzen sind und wie man weitere komplexe Interaktionen vereinfachen kann. Nicht nur auf Projektebene, sondern wie euer gesamtes Unternehmen dies auf alle eure Projekte ausrollen kann (Thema „Zentralisierung”).

Eine weitere Limitation wurde zu Anfang genannt: Wir haben lediglich Prozess-DX betrachtet. Die anderen DX Bereiche sind Tools, Teamwork und Regeln, welche ebenfalls Potenziale und Overhead in sich verbergen. Dies sind Themen, die ihr in den nächsten Artikeln erwarten könnt. Denn mit der Cloudkoloss-Methode sollen alle diese Potenziale aufgedeckt werden.