Deadlines zerstören Entwickler Produktivität

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 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.

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.

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. 

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!

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.

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.

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.

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.

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.

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.