Entwicklungs-Performance optimieren

Niedrige Entwicklungs-Performance ist eines der häufigsten - und schmerzhaftesten - Probleme, die ich in Engineering-Organisationen sehe. Features dauern zu lange, Bugs stapeln sich, das Business ist frustriert. Als CTOs und Engineering-Leader stehen wir unter Dauerdruck von CEO und Stakeholdern: schneller liefern, mehr shippen, und das mit weniger Leuten. Der Ruf nach mehr Performance hört nie auf, aber der Weg zu besserer Performance ist selten offensichtlich. Reden wir darüber, warum Performance niedrig ist, warum das so weh tut, und wie du anfängst, es zu drehen.

Meine Geschichte

Als CTO und Engineering Manager stand ich jahrzehntelang unter Performance-Druck. Es gab immer die Erwartung, schneller zu werden. Es gab immer die Erwartung, dass der Firmenerfolg zurückgehalten wird, weil die Entwicklung “zu langsam” ist.

Ich sehe CTOs mit Entwicklungs-Performance kämpfen, vor allem weil die Faktoren komplex sind und sich Entwicklung wie ein Wasserballon verhält: Du drückst hier, und es beult dort aus.

Das Vier-Schritte-Framework

Meine Erfahrung aus all den Jahren habe ich in ein Framework gegossen, um Entwicklungs- und Engineering-Performance zu optimieren. Es hat vier Schritte:

1. Effektivitäts-Level
2. Zustand des Codes
3. Motivation
4. Messen & Optimieren

Zuerst legst du das Effektivitäts-Level der Features fest, die ihr entwickelt. Steve Jobs war berühmt dafür, über Features zu iterieren, bis sie perfekt waren. Wenn du das Effektivitäts-Level deiner Features nicht festlegst, kannst du Performance nicht optimieren: Für ein großartiges Feature brauchst du vielleicht fünf Sprints. Für eine Version, die niemand mag und niemand nutzt, reicht einer. Dann ist die Entwicklungs-Performance 5x höher!

• Effektivität/Impact von Features auf das gewünschte Level bringen
• Effektivität/Impact messen
• Effektivität auf dem Level halten, während du Performance optimierst

Als Nächstes bewertest du den Zustand des Codes. Zwei Teams bauen ein ähnliches Feature, eines braucht 2 Sprints, das andere 8. Das zweite Team ist schlecht und faul? Nein - das erste Team hat ein Greenfield-Projekt mit sauberem Code, hoher Testabdeckung und wenigen Integrationen, während das zweite auf einer fünf Jahre alten Codebase arbeitet, an der Dutzende Leute gearbeitet haben, mit vielen Framework- und Library-Abhängigkeiten und Dutzenden Integrationen in andere Systeme. Ohne den Zustand des Codes zu verstehen, kannst du die Performance von Teams nicht verstehen.

• Zustand des Codes in Stufen A, B, C, D, E, F bewerten
• Code-Qualität, Code-Alter, technische Schulden
• Technische Komplexität
• Abhängigkeiten
• Zustand des Codes halten oder verbessern, während du optimierst

Manager tun so, als hinge Entwicklungs-Performance nicht von Menschen ab. Dabei ist Entwickler-Motivation der größte Hebel auf den Output. Jedes Team und jedes Teammitglied ist anders. Ohne Motivation zu verstehen, kannst du die Performance von Teams nicht verstehen.

• Entwickler-Motivation hat großen Einfluss auf Performance
• Motivation verstehen
• Frustrationen beheben
• Ownership geben

Jetzt kannst du anfangen, Performance zu optimieren. Miss den Output (z.B. Umsatz pro Entwicklertag) und optimiere von dort aus. Gib dem Team Ownership für seine Performance - und behandle ein Team wie ein Team.

• Output messen, nicht Aktivität
• Engpässe finden und beheben
• Dem Team Ownership für Performance geben
• Nicht Einzelne gegeneinander ausspielen