Was Entwickler den ganzen Tag tun

Vor einiger Zeit habe ich bei einem Kunden ein ganz erstaunliches Gespräch mitangehört. In einer Pause haben sich Projektmanager und Product Owner darüber ausgetauscht, welches Team wohl das produktivste sei.

Es fühlte sich wie Konkurrenzkampf an, aber nicht darum, welches Team mehr Wert für den Kunden stiftet, sondern welche Entwickler innerhalb der Teams „am produktivsten“ sind. Die Schlüsselmetrik bei der Bestimmung von „am produktivsten“ war das Verhältnis zwischen „produzierten Codezeilen“ und „verfügbarer Zeit“. Einer der Projektmanager erzählte stolz, dass er die Scrum-Events auf ein Minimum an Zeit reduziert habe, damit die Entwickler weniger abgelenkt seien und (ich zitiere): “sie so 90 % ihrer Zeit vor ihren Bildschirmen verbringen und neuen Code erstellen können”

Für uns mag es ziemlich offensichtlich sein, dass diese Metrik keinen Sinn ergibt. Und trotzdem hat es mich zum Nachdenken gebracht.

Welche Grundüberzeugungen und mentalen Modelle finden wir vor, wenn es um Produktivität geht?

Die oben genannten scheinen ja keine Seltenheit zu sein. Also: Was machen Entwickler, wenn sie mal nicht auf einen Bildschirm starren und auf einer Tastatur hämmern?

Nehmen wir einmal an, Software wäre ein Handwerk, vielleicht Fliesenlegen. Vordergründig erzeugen Fliesenleger:innen nur dann einen Kundennutzen, wenn sie Fliesen auf den Boden legen.

Dennoch braucht es natürlich eine gewisse Vorbereitungs- und Rüstzeit, bevor es sinnvoll ist, die erste Fliese auf den Boden zu legen. Ganz zu Beginn benötigt sie ein gemeinsames Verständnis mit dem Kunden, wie und welche Kacheln der haben möchte – schließlich hat es überhaupt keinen Wert, Fliesen zufällig auf dem Boden oder der Wand zu verteilen. Darüber hinaus wird jede gute Fliesenleger:in bestätigen, dass sie hin und wieder etwas Zeit aufwenden muss, um den Untergrund vorzubereiten, den Mörtel zu mischen und die Werkzeuge zu arrangieren (um nur ein paar zu nennen).

Und um noch einen zusätzlichen Punkt zu machen, sie würde wahrscheinlich ab und an einen Schritt zurücktreten, um zu sehen, wie es aussieht – inspizieren und anpassen (und vielleicht sogar die Arbeit bewundern). Es wäre sehr ungünstig, wenn die Fliesenleger:in dies nicht tun würde. Im Handwerk akzeptieren wir also gewisse Prinzipien, weil sie dem großen Ganzen guttun.

Die Nichtbefolgung dieser Prinzipien sind für Wissensarbeiter* zwar weniger sichtbar, aber nicht weniger eklatant.

Was meine ich damit?

Wir können die Arbeit von Entwicklern grob in drei Kategorien einteilen:

• A Geschäftskontext verstehen: Je mehr Entwickler verstehen, was erreicht werden soll und welche Probleme, Bedingungen und Grenzen sowohl auf der geschäftlichen als auch auf der technischen Seite bestehen, desto besser und wartbarer wird ihre Lösung. Je mehr Entwickler eine aktive Rolle (= mehr als nur Ausführer der Wünsche anderer) einnehmen können, desto besser.
• B Vorhandenen Code lesen: Code existiert nicht in einem Vakuum. Je mehr Entwickler sich ein Bild vom Gesamtsystem machen können und nicht nur über ihren kleinen Ausschnitt reden können, desto besser können sie mit Abhängigkeiten umgehen und desto weniger unerwünschte Nebenwirkungen hat ihr Code.
• Und schließlich C: das Schreiben von neuem Code

Alle drei Dinge konkurrieren miteinander um Zeit und Aufmerksamkeit und beeinflussen sich gegenseitig erheblich. Welche der drei den höchsten Anteil zu einem bestimmten Zeitpunkt hat, hängt von mehreren Variablen ab, aber Entwickler sagen mir, das Verhältnis zwischen dem Lesen von vorhandenem Code und dem Schreiben von neuem Code läge ungefähr bei 10:1**, wenn es richtig gemacht wird.

Aber auch wenn dies zur Erfahrung vieler Entwickler passen mag, mit denen ich gesprochen habe, das genaue Verhältnis unterscheidet sich situativ und spielt am Ende des Tages auch gar keine so große Rolle.

Was zählt

Produktivität ≠ neuen Code schreiben

Der Fokus soll nicht auf individuelle Produktivität gerichtet sein, sondern auf Kommunikation – denn gute Kommunikation ist der Schlüssel zu geteiltem Verständnis und damit wirklicher Produktivität in der Produktentwicklung.

Geteiltes Verständnis ist dann, wenn wir das gleiche Bild haben, was sich eine andere Person vorstellt und warum. Dokumente und Spezifikationen sind KEIN gemeinsames Verständnis, denn obwohl wir Einigkeit und Verständnis annehmen, interpretieren wir Dinge zwangsläufig im Detail anders. Wenn du das nicht glaubst: google die „Exact Instructions Challenge“.  

Richtige Kommunikation ist: zusammenkommen, Ideen gemeinsam kombinieren und verfeinern – bis wir am Ende etwas haben, das die besten Elemente von allen enthält. (Natürlich der ursprüngliche Gedanke von Extreme Programmings CCC: Card-Conversation-Confirmation.)

Wenn du also das nächste Mal gefragt wirst, was Entwickler den ganzen Tag tun: sie sind mit einem der drei Dinge beschäftigt – und alle drei sind notwendig, um ein großartiges Produkt zu liefern.

* Peter Druckers Überbegriff für Arbeit, die aus der Lösung von Problemen besteht.

** basierend auf Beobachtungen von Robert C. Martin. In seinem Buch „Clean Code“ schreibt er: “Tatsächlich beträgt das Verhältnis zwischen Lesen und Schreiben gut 10:1. Wir lesen ständig alten Code, um neuen Code zu schreiben.”