Kleinvieh macht auch Mist. Mit Micro-Feedback Loops in der Softwareentwicklung sind auch kleine Verbesserungen von Nutzen, wenn diese sich aufsummieren.
Das Konzept der Micro-Feedback Loops lernte ich über den Artikel Maximizing Developer Effectiveness kennen. Dieser stellt dar, wie sich einfache Verbesserungen bei Aufgaben, die Entwicklerinnen dutzende oder vielleicht sogar hunderte Mal pro Tag erledigen, in Summe auf die Gesamtproduktivität auswirken.
In meinem Beitrag hier gehe ich das Thema aus Sicht einer möglichen Analyse an. Welche Fragen können gestellt werden rund um die acht Schlüsselpunkte, die im oben zitierten Artikel identifiziert wurden? Und Deine Antworten zeigen Dir potenzielle Hebel für erste Verbesserungen.
Wie lange dauert es in Deinem Unternehmen, bis ein Softwareentwickler produktiv im Projekt oder am Produkt arbeiten kann?
Es gibt Unternehmen da draußen, die darauf zielen, dass neue Entwicklerinnen am ersten Tag ihren ersten eigenen Code in die Produktionsumgebung deployen.
In meiner Zeit in einer Dienstleistungsfirma war unser Ziel, neue Entwickler nach spätestens drei Tagen produktiv im Projekt mitarbeiten zu lassen.
Und ich kenne Firmen, die neue Entwicklerinnen vermeintlich erst monatelang aufgleisen müssen, bevor irgendwas herumkommt.
Welches Signal senden bei der Einarbeitung etwa diese Punkte:
Dazu im Vergleich diese Möglichkeiten:
Teamänderungen kommen immer wieder aus den unterschiedlichsten Gründen vor. Entsprechend ist die Notwendigkeit eines guten Onboardings keine Seltenheit.
Und eine effektive und effiziente Einarbeitung hat einen positiven Einfluss auf die Teamproduktivität und die Motivation jedes Teammitglieds.
Wie lange dauert es in Deinem Unternehmen, bis ein Softwareentwickler eine Antwort auf eine interne Frage bekommt?
Kann die Entwicklerin das Thema innerhalb des Entwicklungsteams klären? Wenn nein, wieso eigentlich nicht? Welchen Teil ihrer Arbeit hat das Team hier nicht unter der eigenen Verantwortung?
Wenn die Frage außerhalb des Teams beantwortet werden muss:
Produkt- und prozessbezogene sowie technische Fragen wird es in der Softwareentwicklung natürlich immer geben. Die Frage ist, wie lange die Klärung dauert.
Antwortzeiten bringen Verzögerungen bei der Fertigstellung mit sich. Sie führen zu Unterbrechungen, somit zu Taskwechseln und damit zu zusätzlichen geistigen Rüstzeiten.
Und diese „Verlustleistung“ kann reduziert werden, um die Teamproduktivität zu steigern.
Wie lange dauert es in Deinem Entwicklungsteam, bis ein Entwickler prüfen kann, ob seine lokale Codeänderung funktioniert?
Reden wir von wenigen Sekunden? Geht es in den Minutenbereich? Noch länger? Oder wird am Ende gar nicht validiert?
Woran es liegen könnte und wo Verbesserungsmöglichkeiten bestehen:
Dauern die Validierungszyklen bei Änderungen länger, besteht einmal mehr die Gefahr einer Unterbrechung, die den Fokus raubt.
Ein paar Sekunden oder wenige Minuten hin oder her klingt nach wenig. Doch die Summe dieser Unterbrechungen kann die Nadel in Hinblick auf die Gesamtproduktivität bewegen.
Wie lange dauert es in Deinem Unternehmen, bis ein Entwicklungsteam die Integration von Komponenten prüfen kann?
Sind es wenige Stunden? Oder zieht es sich Tage bis Wochen hin?
Die möglichen Ansatzpunkte für Verbesserungen decken sich viel dem vorhergehenden Punkt zu lokalen Tests und gehen natürlich noch darüber hinaus:
Wie mit Tests auf allen Ebenen der Testpyramide gilt auch beim Thema Integration: Je früher es knallt, umso besser. Denn andersherum: Je später es raucht, desto teurer wird es.
Und bei Verbesserungsmöglichkeiten aus diesem Blickwinkel wird es dann auch mit der Produktivität – zumindest als ein Baustein unter vielen.
Wie lange dauert es in Deinem Entwicklungsteam, bis es prüfen kann, ob eine Änderung die nichtfunktionalen Anforderungen an die Lösung erfüllt?
Bewegen wir uns hier im Bereich von Tagen? Wochen? Oder sprechen wir eher von Monaten?
Und ihr habt diese Non-Functional Requirements (NFRs) doch irgendwo erfasst, oder? (Das ist eine sehr ernst gemeinte Frage, denn mir begegnen diese erschreckend selten explizit niedergeschrieben.)
Hier eine kleine Auswahl an Fragen, um die Produktivität des Teams aus dem Blickwinkel der NFRs zu betrachten:
Spätestens jetzt wird deutlich, dass die Verbesserung eines Entwicklungsteams nicht an den Teamgrenzen enden sollte. Denn die Devs können noch so schnell entwickeln – wenn das gefertigte Artefakt dann hinten raus stecken bleibt, hat niemand einen Wert davon.
Ein gutes Team kann möglichst vieles selbst erledigen. Und niemand sagt, dass punktuell nötige Rollen und wichtige Expertise nicht auch kurzfristig und kurzzeitig in das Team aufgenommen werden können. Okay, doch, das wird gesagt und lasse Dich davon nicht aufhalten, es trotzdem zu tun.
Wie lange dauert es in Deinem Unternehmen, bis ein Entwicklungsteam einen neuen Service auf der Produktionsumgebung einführen kann?
Geht das innerhalb von Tagen? Oder dauert es mehrere Monate?
Einige Denkanstöße, um das Thema „Release auf Prod“ zu analysieren:
Auch hier wird wieder deutlich, dass es an und hinter den Teamgrenzen viel Raum für Produktivitätsverbesserungen gibt. „Done“ ist eine Aufgabe eben erst wirklich dann, wenn sie live ist, genutzt werden kann und Wert schafft.
Wie lange dauert es in Deinem Unternehmen, bis ein Entwicklungsteam die Ursache für einen Fehler in der Produktivumgebung findet?
Einen Tag oder weniger? Oder eher eine Woche?
Hier eine Auswahl an Fragen, um dieses Thema näher zu beleuchten:
Natürlich wäre es schön, wenn produktiv einfach alles laufen würde. Doch wir wollen ja realistisch bleiben 😉
Und die Fragen oben bringen potenzielle Ansätze ans Licht, um die Produktivität eines Entwicklungsteams in Hinsicht auf den Betrieb zu steigern.
Wie lange dauert es in Deinem Unternehmen, bis ein Entwicklungsteam Rückmeldung von Kunden oder echten Anwenderinnen bekommt?
Einen Monat oder weniger? Ein halbes Jahr? Versackt die Information an anderer Stelle im Unternehmen? Oder gibt es am Ende überhaupt kein Feedback?
Hat die Lösung ein Problem behoben? War sie nützlich? Wurde eine interne Hypothese bestätigt oder widerlegt?
Für die vergangenen zwei Jahrzehnte kann ich vermutlich an einer Hand abzählen, in wie vielen Projekten meine Teams tatsächlich Austausch mit echten Anwendern hatten.
Eines der prominentesten positiven Beispiele ist ausgerechnet eine Behörde. Vor vielen Jahren war ich an mehreren Entwicklungsabschnitten eines Projekts für ein Bundesamt beteiligt. In zarten Schritten haben wir dort eine Vorgehensweise eingeführt, die heute als „agil“ bezeichnet würde.
Ein Baustein davon: regelmäßige Zwischenreleases, statt eines Big Bang. Und unsere Ansprechpartner im Fachbereich taten alles dafür, dass für die Tests dieser Releases Friendly User bereitstanden aus dem Pool von Menschen, die das System später auch tatsächlich im Echtbetrieb nutzen werden. Das war pures Gold!
(Es gab lustigerweise übrigens auch fleißige „Unfriendly User“ im laufenden Betrieb, die nicht müde wurden, auf die Fehler und Probleme hinzuweisen – wobei sie dabei meist sachlich blieben. Hat das genervt? Ja. War das wertvoll? Absolut!)
Alle vorherigen Kapitel bezogen sich auf den ersten Blick auf das Thema Effizienz.
Doch Produktivität dreht sich zentral auch um die Effektivität. Es braucht beide Sichtweisen. Die Kernfrage ist: tun wir das Richtige richtig?
Und der keinesfalls zu vernachlässigende Aspekt dabei sind diese Fragen: braucht das eigentlich wer? Wie gut ist unsere Lösung? Schaffen wir einen Wert und verdient das Unternehmen damit Geld?
Denn ohne echte, unmittelbare und ungefilterte Antworten auf diese Fragen kann man sich alles Vorherige auch sparen.
Dieser Artikel liefert Dir Fragen zur Analyse und neue Sichtweisen auf acht Alltagsaufgaben eines Softwareentwicklungsteams:
Diese Micro-Feedback Loops erlauben Deinem Team möglichst schnell zu lernen. Der Effekt bei Verbesserungen wirkt sich dabei v.a. in der Summe aus – Viele kleine Schritte bringen ein Team eben auch weiter. Zudem betrachten die Micro-Feedback Loops nicht nur Aspekte der Effizienz, sondern auch die Effektivität.
Und schlussendlich zahlen diese Punkte ebenso auf die gefühlte Wirksamkeit und damit auf die Zufriedenheit der Entwicklerinnen und Entwickler ein.
Buchen Sie jetzt eine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Sie am wirkungsvollsten unterstützen kann.