Deadlines zerstören Entwickler Produktivität

20 Thesen wie es besser klappt


In diesem Artikel möchte ich erklären warum es extrem produktivitätshemmend ist, Software-Entwickler zu nötigen detaillierte Aufwandsabschätzungen für große und komplexe Software-Projekte abzugeben und dann – basierend auf diesen Schätzungen – Roadmaps mit einem Zeitstrahl für viele Monate zu erstellen.

Viele Manager – und manche Product Owner – haben die absurde Idee, dass ein Softwareprojekt mit einem Gant-Chart von der Ideenphase bis zum finalen Release bis ins kleinste Detail durchgeplant werden sollte. Und wenn etwas nicht funktioniert oder zu lange dauert, versuchen sie noch detaillierter planen zu lassen anstatt die eigentlichen Probleme zu lösen.

Problem 1: Glaskugel

Eigentlich ist es doch ganz klar: Je weiter du in die Zukunft schaust, desto unklarer ist, wie lange es dauern wird ein bestimmtes Feature fertig zu stellen. Das liegt zum einen daran, dass viele Feature-Details oft noch gar nicht feststehen. Zum anderen können diverse Faktoren wie Umstrukturierungen, Quartalsziele, Bugs, Kündigungen, Elternzeiten, Technical Debt, Hiring Freezes, Prioritätsänderungen oder Budgetkürzungen Auswirkungen haben; auch diese müssen mitgeschätzt werden um eine Gesamtschätzung abgeben zu können. Ab einem gewissen Grad an Schätzung-basierend-auf-Schätzungen wird es einfach nur noch unseriös und unverlässlich.

Problem 2: Mangelnde Flexibilität

Langfristiges Planen macht unflexibel. Anstatt schnell auf Änderungen am Markt zu reagieren, wird oft stur die Roadmap abgearbeitet. Weil sie schon intern kommuniziert wurde. Weil Quartalsboni daran geknüpft sind. Weil das Marketing-Team bereits eine Kampagne geplant hat. Weil das Sales-Team die Features schon Kunden versprochen hat. Oder weil gegenüber Investoren "wir haben unsere Roadmap wie geplant abgearbeitet" als Erfolgsmetrik verkauft wurde.

Wichtig: Natürlich brauchst du trotzdem eine Vision, wo es hingehen soll. Aber das ist etwas anderes als ein detaillierter Step-by-Step-Plan. Mehr dazu weiter unten.

Problem 3: Deployen und Vergessen

Es kommt selten vor, dass ein Feature "fertig" ist und sofort funktioniert. Oft merkt man erst nach dem Release, dass mit minimalen Veränderungen der Mehrwert des Features für die Nutzer massiv gesteigert werden könnte. Wenn nach dem Release sofort mit dem nächsten Feature begonnen werden muss, bleibt für solches Feintuning oft keine Zeit. Eine massive Verschwendung. Denn mit diesen 5% mehr Arbeit lässt sich manchmal 50% mehr Nutzen erzeugen!

Problem 4: Schätzungen produzieren keinen Customer Value

Viele Manager können mit Unsicherheit auf der Roadmap nicht umgehen. Dann werden gerne mal mehrere Wochen damit verbracht bereits den Aufwand aller Features der nächsten 3 Monate schätzen zu lassen. Dazu brauchen die Entwickler natürlich Details. Also muss der Product Owner schnell alle Stories schreiben – ohne genug Zeit für Userinterviews und weitere Recherchen zu haben. Und die Frontend-Entwickler wollen sehen wie das fertige Feature aussehen soll. Also wird schnell ein Mock-up erstellet; natürlich ohne Usertests, da es schnell gehen muss.

Der einzige Mehrwert einer solchen Übung ist, dass die Unsicherheit mit falscher Sicherheit ersetzt wurde. Kein Feature ist der Fertigstellung näher gerückt. Kein Mehrwert für Kunden wurde geschaffen.

Die Lösung?

Wem wirklich daran gelegen ist, eine Entwicklungsabteilung produktiver zu machen, dem möchte ich 20 hilfreiche Instrumente an die Hand geben.

Kleinere und häufigere Value-Inkremente

Ich will hier gar nicht groß auf Waterfall vs Agile vs Post-Agile eingehen. Egel welches Framework man benutzt, sollte ein Mantra immer vorhanden sein: Je kleiner ein mögliches Value-Inkrement ist, desto geringer das Risiko das falsche zu entwickeln und desto kleiner die Wartezeit der Kunden oder des Managements bis ein Mehrwert realisiert wird. Fang nicht an, heute einen Microsoft Office Klon zu entwickeln. Fang damit an einen Kern-Workflow einer relevanten Office-Applikation 100x besser zu machen. Wenn du das hast, release es. Dann heißt es rinse and repeat.

Schnelleres Lernen

Schnelles Lernen ist für Produkt-Firmen ein enormer Wettbewerbsvorteil. Wenn Firma A mehr Geld, mehr Entwickler und Martkwissen, sowie einen besseren Kundenzugang hat aber Firma B doppelt so schnell lernt wie Firma A, würde ich immer auf Firma B setzen. Häufig zu lernen und dann die Möglichkeit zu haben, diese Learnings umzusetzen ist für mich eines der wichtigsten Erfolgskriterien im Produktmanagement. Das macht zwar die Software-Entwickler nicht besser oder schneller aber es macht sie effizienter! Dann nur ein rapides Lerntempo stellt sicher, dass immer an den wichtigsten Themen gearbeitet wird.

Metriken, Metriken, Metriken und Logs

 

Gute Metriken helfen. Sie helfen dabei Entscheidungen zu treffen, Fortschritte zu messen und Probleme frühzeitig zu erkennen. Und sehr detaillierte Metriken und Logs (zum Beispiel via DataDog) helfen dabei Bugs schneller zu identifizieren, zu verstehen und zu fixen. 

Dokumentation

Eine gute Dokumentation mit einheitlichen Regeln, was wie zu dokumentieren ist, bringt gewaltige Produktivitätssteigerungen. Sie reduziert Fragen an Kollegen („Wie geht das?“) und hilft beim Onboarding neuer Mitarbeiter. Das Thema schnelles Onboarding ist insbesondere dann relevant, wenn Mitarbeiter im Schnitt nur 2 Jahre bleiben oder regelmäßig Freelancer zum Einsatz kommen.

Story-Time
Leah Farmer (u.a. SVP Product & Technology bei Tourlane und VP Product bei Klarna) hat zum Thema Dokumentation vor einigen Monaten eine super spannende Story aus ihrer Zeit bei Amazon mit mir geteilt. Sie hat mit etwa 50 Kollegen an einem Payment-Produkt gearbeitet. Nach etwa zweieinhalb Jahren Entwicklungszeit (natürlich weit hinter Zeitplan) war die Lösung ein halbes Jahr im Einsatz und wurde dann eingestampft. Allerdings wurde die Arbeitsgruppe nicht einfach aufgelöst. Die Mitarbeiter haben noch mehrere Wochen Arbeitszeit reingesteckt, alles sauber zu dokumentieren. Das ganze lag dann ein paar Jahre in Archiven. Jahre später kaufte Amazon Whole Foods und brauchte eine Payment-Lösung. Anstatt bei 0 anzufangen, haben sie Leahs altes Projekt aus dem Archiv geholt. Ein neues Team wurde geformt und konnte sich innerhalb kürzester Zeit mit den damals geplanten Prozessen und der entwickelten Technologie vertraut machen. Kurze Zeit später war das System im Produktiveinsatz. Dies war nur dank der unglaublich detaillierten Dokumentation möglich. In vielen anderen Konzernen hätte man wieder von Null starten müssen. In diesem Fall hat die gute Dokumentation locker 10 Millionen Euro Neuentwicklungsaufwand gespart!

Company Handbook
Die besten Firmen dokumentieren so gut, dass ihre Prozess-Dokumentation ein komplettes Company Handbook ergibt. Gute Bespiele sind GitLab, Basecamp und Valve (pdf).

Commit Messages
Wo ich schon GitLab in den Beispielen habe, möchte ich noch darauf hinweisen, dass auch Commit Messages Teil der Dokumentation sind. Wie man diese am besten schreibt hat Joel Parker Henderson in einem praktischen Guide zusammengefasst.

Fehlerkultur 

Das schlimmste für eine Entwicklungsabteilung ist Angst vor Fehlern. Jeder Fehler darf gemacht werden. Er sollte aber natürlich nur einmal gemacht werden. Wie erreicht man das? Im dem man ihn offen Anspricht – ohne Schuldzuweisung. Die zwei wichtigsten Instrumente sind Pre-Mortems vor jedem größeren Projekt und Post-Mortems nach jedem Fuckup. Dabei ist wichtig, dass die Ergebnisse aus den Post-Mortems zentral und für alle einsehbar dokumentiert werden. Außerdem müssen die beteiligen Entwickler die Freiheit haben, die Schlüsse aus den Post-Mortems zeitnah umzusetzen!

Spotify Approach 

Spotify hat bereits vor vielen Jahren ein Modell mit Tribes, Chapters, Guilds und Squads geschaffen, welches Alignment und Autonomie maximiert. So können alle Teams mit minimalen Abhängigkeiten untereinander auf die Produktvision hinarbeiten. Dominic Linder hat dazu eine gute Erklärung geschrieben. Nimm das Spotify-Modell gerne als Blaupause. Und – ganz wichtig – iteriere dann alle 3-12 Monate um es an Deine Bedürfnisse anzupassen. Dieses kontinuierliche Anpassen wird leider oft vergessen. Dabei rührt der Erfolg von Spotify nicht aus diesem Modell her. Sondern daher, dass sie vieles ausprobiert haben und irgendwann bei diesem System gelandet sind.

Team-Topologie

Teams. Ihr braucht Teams. Große Development-Abteilungen können nur orchestriert werden, wenn sie in – sinnvolle – Teams unterteilt sind. Und bei dieser Teamstruktur kann unglaublich viel schief gehen. Dass die Teams falsch geschnitten sind, merkt man daran, dass jede Woche darüber gesprochen wird, dass Team A darauf wartet, dass Team B etwas macht. Und Team C wartet darauf, dass Team B ein anderes Projekt abschließt. Und immer wenn Team B die Roadmap anpasst, passen Team A und C ihre Roadmaps an.

Wie macht man es richtig? Dazu gibt es ein spannendes Team-Topologie-Framework von Matthew Skelton und Manuel Pais. Sie sprechen von vier Arten von Teams.

Stream-aligned-Teams – manchmal auch Produkt-Teams oder Feature-Teams (sic!) – sind an einen Arbeitsfluss der Kunden gekoppelt. Sie entwickeln und betreiben die Software, die vom Endnutzer verwendet wird. Da dies irgendwann sehr kompliziert werden kann, gibt es drei Arten von Teams, die sie dabei unterstützen.

Enabling-Teams bestehen aus Experten in einem bestimmten Feld wie Test-Automatisierung, Datenbanken oder Cloud-Architektur. Ein Enabling-Team arbeitet mit den Stream-aligned-Teams zusammen wann immer Bedarf entsteht. Dabei erfolgt meist eine Kombination aus kurzfristiger intensiver Hilfe und langfristigem Wissenstransfer.

Complicated-Subsystem-Teams kommen dann zum Einsatz wenn eines oder mehrere der Stream-aligned-Teams eine Komponente benutzen, die so kompliziert ist, dass nur absolute Experten, die sich mehrere Jahre mit dem Thema auseinandergesetzt haben, diese Komponente sinnvoll weiterentwickeln und betreiben können. Auch wenn wir normalerweise Abhängigkeiten zwischen Teams vermeiden wollen, ist es bei derart komplexen Themen manchmal einfach nicht möglich das Know How in jedem Stream-aligned-Team zu duplizieren.

Plattform-Teams versuchen für alle Schritte des Softwareentwicklungsprozesses die bestmögliche Developer-Experience anzubieten. In der Minimalversion existiert dieses Team gar nicht weil es durch ein kurzes Textdokument ersetzt werden kann, in dem erklärt wird, welcher Cloud Provider verwendet wird, wo die Repositories liegen und wie wie deployed wird. In sehr großen Organisationen kann die darunterliegende Entwickler-Plattform so groß sein, dass "das Plattform-Team" so groß ist, dass es ein eigenes Department ist und selbst auch wieder in Stream-aligned-Teams, Enabling-Teams, usw. geteilt werden muss. Der Kunde ist in dem Fall dann die "eigentliche" Software-Development-Abteilung.

Grundsätzlich sollte man immer mit Stream-aligned-Teams anfangen und die anderen Teams nur hinzufügen wenn sie notwendig sind.

Keine Boni

Bonus-Systeme inzentivieren fast immer individuelle Leistung, stehen Kollaboration im Weg und unterstellen, dass Mitarbeiter ohne zusätzliche finanzielle Anreize nichts ihr Bestes geben. Forschung von Arie de Geus und anderen hat gezeigt, dass die erfolgreichsten Technologie-Firmen nur selten auf Bonus-Zahlungen für individuelle Leistungen setzen.

Sag Deinen Mitarbeitern einfach was die wichtigen Ziele sind und warum – zum Beispiel über OKRs. Dafür braucht es keinen Bonus! 

Purpose 

Ein starker Purpose inspiriert und sorgt gleichzeitig für Motivation und Alignment. In quasi jedem Unternehmen ist den Mitarbeitern klar, was sie machen. Oft, wird das auch das Wie definiert und kommuniziert. Aber nur wenige Organisationen schaffen es ihren Purpose klar zu definieren – warum sie die Dinge tun, die sie tun. Das Prinzip kann niemand besser erklären als Simon Sinek in diesem 5 Minuten Video.

Produktvision

Die Produktvision sollte eine direkte Konsequenz des Purpose sein. Hier ein von ProductPad inspiriertes Template:

Und natürlich auch ein Beispiel für die Kreativlosen:

OKRs 

Objectives and Key Results (OKRs) sind ein Management-System welches sich auf das Setzen von Zielen (Objectives) und die Messung von für diese Ziele relevanten Kennzahlen (Key Results) fokussiert. OKRs sind mitverantwortlich für den Erfolg und die Agilität von Unternehmen wie Intel, Google und Kleiner Perkins.

Werden sinnvolle OKRs definiert, kann dies enorm helfen ein Produkt-Development-Department auf die wichtigen Probleme zu fokussieren und die Erwartung des Managements in klare Key Results zu gießen.

Beispiel OKR für das erste Quartal:

Ich kann an dieser Stelle nur jedem das Buch Measure What Matters von John Doerr ans Herz legen. Es erklärt sehr gut was OKRs sind, wie sie funktionieren und wie man sie richtig einsetzt.

OWKRs

Wer noch einen draufsetzen möchte, nimmt statt OKRs besser OWKRs. Dabei steht das W für Why (warum). Das heißt zu jedem Objective wird ein Satz aufgeschrieben, der erklärt warum es gewählt wurde. Das ist insbesondere dann sinnvoll, wenn nicht im ganzen Unternehmen OKRs eingesetzt werden oder wenn es einen großen Disconnect zwischen Entwicklung und Business-Seite gibt. 

Roadmap 

Wenn eine Roadmap nicht linear-zeit-basiert sein soll, wie soll sie dann aussehen? Es gibt einen ganz stumpfen Weg: Wir bleiben bei der Gant-Chart-artigen Ansicht. Aber wir entfernen die Einheiten von der Zeitachse. Die Roadmap stellt weiterhin da, an welchen Features wir in welcher Reihenfolge arbeiten wollen. Aber es gibt keine künstlichen Deadlines wie "dieses Feature wird im Dezember fertig" oder "an diesem Feature arbeiten wir nächstes Jahr von Juni bis August".

Eine alternativeVariante ist, einfach nur zu betrachten woran jetzt gearbeitet wird, woran als nächstes gearbeitet wird und welche Themen danach die höchste Priorität und Dringlichkeit haben. Dabei wird unterschieden zwischen Themen, die einfach nur im Backlog ganz oben stehen und Themen, die bewusst für das aktuelle Quartal zugesichert wurden. Der große Vorteil ist, dass damit weniger falsche Erwartungshaltungen geweckt werden. Hier ein Beispiel wie das aussehen kann – inklusive zusätzlichen Informationen, die über Labels definiert sind:

Das Backlog (ganz links) ist für mich eine Liste von Chancen. Und das, was für die nächsten 90 Tage geplant ist, sind Wetten. Wetten, dass ein Feature funktioniert oder dass ein Problem es wert ist gelöst zu werden.

Karrieremodell und Rollenbeschreibungen

Ein gutes Karrieremodell mit klaren Anforderungen an Juniors, Mid-Levels, Seniors und Team Leads hilft allen Beteiligten. Mitarbeiter wissen was von ihnen erwartet wird und auch was sie von ihren Führungskräften erwarten können. Hiring Manager und Recruiter haben schnell Einigkeit über die Anforderung an Kandidaten. Und Bewerber wissen worauf sie sich einlassen.

Expert-Track
Ganz wichtig ist hierbei nicht nur einen Pfad vom Praktikum zum Junior zum Mid-Level zum Senior zum Team Lead zu definieren. Nicht jeder Senior Entwickler möchte und sollte Team Lead werden. Daher ist es wichtig neben dem Leadership-Track auch Expert-Rollen wie Technischer Experte, Chief Architect, usw. zu definieren. Mitarbeiter auf diesem Expert-Track werden manchmal auch als Technical Leaders, Specialists oder Fellows bezeichnet.

Rollenbeschreibungen
Ein zentraler Aspekt eines guten Karrieremodells sind Rollenbeschreibungen. Diese sollten nicht nur für jede Rolle (Front End Entwickler, Product Owner, Designer, usw.) definiert werden, sondern auch für jedes Karrierelevel. Die Rollenbeschreibungen helfen in Review Gesprächen um einem Junior Entwickler genau aufzuzeigen an welchen Hard- und Softskills er oder sie arbeiten sollten um die nächsten Karriereschritt zu schaffen. Zusätzlich ist im Hiring mit einer guten Rollenbeschreibung oft schon 80% der notwendigen Stellenbeschreibung fertig. Eine willkommene Zeitersparnis! 

CI/CD und Continuous Deployment

Continuous Deployment (als letzter Schritt einer CI/CD-Pipeline) ist unglaublich mächtig. In vielen Firmen gibt es No Deploy Fridays. Und Entwickler sagen Sätzen wie "morgen deploye ich auf Stage" – weil Deployments große Zeremonien und viel Tamtam sind. Oder es gibt Merge Days an denen Code-Änderungen aller Entwickler gemerged werden – in der Hoffnung, dass dabei nichts kaputt geht.

Viel besser ist eine gut funktionierende CI/CD-Pieline, inklusive dem zweiten CD-Schritt. Denn nur so lässt sich erreichen, dass Deployments etwas ganz normales werden, was gar nicht erwähnt werden muss. Dies spart unglaublich viel Nerven. Und Zeit, die sonst für Koordinierung und Freigaben verschwendet wird. 

Was genaue meine ich mit CI/CD und CD?

Continuous Integration
Regelmäßig – im Idealfall mehrmals am Tag – werden Codeänderungen zusammengeführt und mit Unittests und Integrationstests überprüft. So werden Konflikte zwischen neuem und alten Code (oder zwischen neuem Code aus verschiedenen Teams) frühzeitig erkannt.

Continuous Delivery
Der neue Quellecode wird automatisch ins Repository released und steht für den Production-Einsatz zur Verfügung. Kein Entwickler aus einem Feature-Team muss das Operations-Team informieren, dass es Updates am Repository gab.

Continuous Deployment
Die neue Codebasis (inclusive aller Änderungen aller Entwickler) wird automatisch auf Stag deployed dort End-to-End getestet und anschließend auf Product deployed (und erneut getestet). Damit halbfertige oder ungetestete Features noch nicht beim Kunden ankommen, werden sie natürlich gefeature flagged und nur ausgewählten Nutzern zur Verfügung gestellt – zum Beispiel Product Ownern, interner QA, später Beta-Testern.

Diese Deployments erfolgen ohne Downtime. Wenn notwendig wird dafür ein Blue-Green-Deployment genutzt. Anstatt alle Server des Produktivsystems einzeln anzupassen, werden neue Instanzen mit dem aktuellen Code hochgefahren und übernehmen – nach erfolgreichen bestehen diverser Tests – nach und nach die Aufgaben der bisherigen Instanzen, welche dann runtergefahren werden.

All dies erfordert natürlich eine gute Software-Pipeline, die alle Schritte automatisiert. Ebenso sind – wie oben bereits erwähnt – gute Tests (und eine gute Testabdeckung) notwendig.

Pair- und Mob-Programming 

Mehrere Entwickler arbeiten gleichzeitig am gleichen Problem? Katastrophe! Total ineffizient! Nein, ganz und gar nicht. Denn sowohl Pair-Programming, als auch Mob-Programming, sind wichtige und notwendige Werkzeuge der Software-Entwicklung

Pair-Programming

Pair-Programming sollte jedem geläufig sein. Zwei Entwickler sitzen gemeinsam vor einem Computer. Während einer Code tippt, denkt der andere über die Problemstellung nach und weißt sofort auf Dinge hin, die ihm im Quellcode des anderen auffallen. Das müssen nicht immer – können aber – Fehler sein. Alles angesprochene wird sofort geklärt. Im Idealfall wechseln sich beide regelmäßig in den Rollen ab.

Pair-Programming führt nachweislich zu weniger Fehlern, gesteigerter Disziplin, mehr Spaß bei der Arbeit (aber nicht bei jedem!), weniger Bugs, weniger Inselwissen, besserer Wissensvermittlung, schnellerem Team-Building und (in Großraumbüros) zu weniger Unterbrechungen durch andere.

Mob-Programming

Mob-Programming, auch mobbing genannt, ist noch extremer. Das gesamte Team sitzt vor einem großen Monitor. Ein Entwickler sitzt im Driver Seat und coded. Alle anderen sind Navigatoren; sie können nachdenken und diskutieren. Da der Driver viele Zuschauer hat – was meistens Stress bedeutet – wird ständig gewechselt.

Insbesondere bei Teams, die erst neu zusammenfinden müssen oder große Wissensunterschiede haben, bietet sich Mob-Programming an.

Mobbing kann übrigens auch für das Schreiben von User Stories, das Deployen von Software und andere Tätigkeiten verwendet werden.

Tech Radar

Ein Tech Radar ist ein Framework um aktuell im Unternehmen genutzte Technologien zu kategorisieren und visualisieren. Dabei gibt es vier mögliche Phasen für eine Technologie: Adopt, Trial, Assess und Hold.

  • Adopt bedeutet, dass alle Entwickler-Teams angehalten sind, diese Technologien – falls passen –  zu benutzen. Das Unternehmen hat eine hohe Konfidenz, dass diese Technologien zu Produktanforderungen passen und es gibt viele aktive Nutzer und Experten im Unternehmen.

  • Trial bezeichnet Technologien, die bereits in mindestens einem Projekt erfolgreich eingesetzt worden sind. Sie scheinen ebenfalls gut zu den Anforderungen des Unternehmens zu passen.

  • Technologien, die noch im Assess-Stadion sind, scheinen gut zu passen. Bisher wurde aber noch kein Mehrwert realisiert. Wer mag, soll sie gerne ausprobieren und berichten.

  • Unter Hold werden alle Technologien zusammengefasst, die nicht (mehr) benutzt werden sollen. Insbesondere bei neuen Projekten, sollten sie nicht zum Einsatz kommen.


Das Ganze sah im Dezember 2019  bei Zalando so aus:

Ein vollständiges und gut gepflegtes Tech Radar spart viele unnötige Diskussion darüber, welche Technologien eingesetzt werden sollten. Einmal im Quartal sollten alle Technologien neu bewertet werden.

Individualisierung
Das Framework kann natürlich angepasst werden. Manchen unternehmen reichen Adopt, Trial und Hold. Manche Unternehmen unterteilen in Frameworks, Infrastructure, Data Management und Languages. Andere unterteilen in Libraries, Tools, Messaging und Languages.

Transparenz & Hiring
Übrigens ist ein gut gepflegtes Tech Radar ein gutes Instrument für Transparenz und Erwartungsmanagement im Hiring. Viele Technologie-Unternehmen machen daher ihre Tech Radars öffentliche, so zum Beispiel Zalando, Searchmetrics und MyTaxi.

Wer es selber umsetzen möchte, nutzt am besten diese fertige Lösung von Zalando.

Ich hoffe, dass ich mit diesem Artikel den ein oder anderen Impuls zum Nachdenken - oder Umdenken - geben konnte.