Produktivität und Softwareentwicklung…ein heikles Thema. Manager_innen unterschätzen oft die Komplexität des Entwicklungsprozesses und wollen KPIs einführen, die scheinbar die Produktivität abbilden, aber eigentlich pure Vanity Metrics sind – Stichwort “Geschlossene Tickets”.
Als Teamlead ist man dann in einer Zwickmühle, denn eine Messung von Leistungsindikatoren ist in jeder Abteilung unternehmerische Realität und zumindest Standard in großen Unternehmen. So ist es unabdingbar, dass auch die Softwareentwicklung mit KPIs arbeiten muss. KPIs ermöglichen Optimierungen und eine Bewertung des Erfolgs, sofern Sie gut ausgewählt und interpretiert werden.
In diesem Beitrag geht es deshalb um Produktivitäts-Tools auf Business-, Teamlead- und individueller Ebene, die helfen, Produktivität mit verschiedenen Kennzahlen darzustellen und die Performance bzw. Workflows zu verbessern.
Zuerst beginnen wir aber mit dem “Warum”. Denn oft ist nicht klar, was überhaupt gemessen werden soll und wem diese Messung etwas bringt. Außerdem sollte auch Ihren Entwickler_innen klar sein, warum die Erfassung von bestimmten Kennzahlen wichtig ist.
Dann stellen wir zwei Tools zur Messung der Produktivität vor, die Indikatoren liefern, um Prozesse zu verbessern und Interessant für Sie sind, wenn Sie einen Überblick über die Performance des Teams bekommen wollen und es Ihre Aufgabe ist, KPIs pro Quartal zu präsentieren.
Zusätzlich erhalten Sie eine Liste an Tools, die sich in den Entwicklungsprozess integrieren und direkt den Workflow (positiv) beeinflussen können.
Zum Schluss erhalten Sie einen Überblick über ein extrem unterschätztes Tool: Die Umfrage.
Starten Sie mit dem “Warum”
Wenn es um das Thema Produktivität geht, kommt der Anstoß dafür wahrscheinlich nicht von Ihren Entwickler_innen, sondern ist
- eine Anforderung vom Management
- ein von Ihnen identifizierte Möglichkeit, um den Entwicklungsprozess zu verbessern oder KPIs klar darstellen zu können
Ziel ist, eine Übersicht über Leistungsindikatoren zu haben, die zu Insights führen, um bessere Entscheidungen zu treffen und als Endergebnis zu einer höheren Produktivität führen. Zuerst sollten Sie sich deshalb fragen (und auch ihr Management damit konfrontieren), über welche Prozesse Daten benötigt werden und wie sich das positiv (höhere Produktivität) und negativ auswirken könnte.
Zusätzlich muss bewusst sein, dass Ihre Entwickler_innen wahrscheinlich wenig von einer Datensammlung über Ihre Arbeit angetan sind. Deshalb ist es wichtig, mit Ihrem Team transparent zu kommunizieren und bestmöglich einen echten Benefit darzustellen. Wenn Sie beispielsweise der Meinung sind, dass Ihre Developer_innen zu wenig Zeit fürs Coding haben und immer wieder durch Meetings und Kontextwechsel unterbrochen werden, könnten Sie vorschlagen, ein Zeittracking einzuführen und damit Ihren Vorgesetzten datenbasiert zu überzeugen, eine Fokuszeit einzuführen.
Zu guter Letzt ist auch noch zu beachten, wie das Tool eingeführt werden kann – Muss das mit dem Legal-Team abgeklärt werden? Wer ist noch involviert?
Noch einmal zusammengefasst:
- Welche Daten benötigen Sie?
- Was soll damit erreicht werden?
- Wie wirkt sich das Tracking aus?
- Welchen Benefit gibt es für Ihre Entwickler_innen?
- Abklärung mit welchen Abteilungen notwendig?
Developer Productivity Tools
Wahrscheinlich haben Sie nach “Produktivitäts-Tools für Entwickler” o. ä. gegoogelt. Wahrscheinlich sind Sie auf zahlreiche Posts gestoßen, die wahllos Tools auflisten. Das ist nützlich, um einen Überblick zu bekommen. Ich finde es sinnvoller, Tools in zwei Kategorien einzuteilen:
- Wollen Sie die Produktivität tracken und Kennzahlen zur Hand haben? (Tracking von Kennzahlen)
- Wollen Sie die Produktivität direkt mit Tools verbessern? (Workflow verbessern)
Starten wir mit der Vorstellung von Tools in Kategorie #1.
#1 Entwickler_innen-Produktivität: Tools zum Tracken von Kennzahlen
LinearB
Ein Tool, um Kennzahlen zur Performance zu erhalten, ist LinearB. Mit LinearB können Sie verschiedene Daten in einer einzigen Plattform abbilden.
LinearB basiert auf drei Kernthemen: Developer Experience, Engineering Tempo und Business Alignment. Was bedeutet das?
- Developer Experience: In unserem Glossarbeitrag haben wir den Begriff schon einmal beschrieben: “Der Begriff ‘Developer Experience’ (DevX, DevEx) beschreibt das Umfeld, die Prozesse und die Kultur, in denen Softwareentwicklung stattfindet.” Oder anders ausgedrückt: Wie reibungslos findet Softwareentwicklung statt?
- Entwicklungstempo: Hier geht es um einen Performance-Überblick, um das Monitoring von Kennzahlen und wie Bottlenecks eliminiert werden können.
- Business Alignment: Eine Optimierung der Performance ist nur sinnvoll, wenn es in die richtige Richtung geht. Es geht also darum zu wissen, womit Zeit verbracht wird und wo und wie Ressourcen allgemein eingesetzt werden.
Für jede Kennzahl bietet LinearB Industriestandards und Benchmarks, die auf Daten der unternehmenseigenen Kunden basieren. Dieses Benchmarking hilft Ihnen bei der Bewertung Ihres Teams.
LinearB bietet einen Free-Tier an. Die Nutzung von DORA-Kennzahlen ist hier enthalten. DORA ist ein etablierter Standard zur Messung der Performance.
Jellyfish
Jellyfishes Slogan ist: “Anticipate. Build. Deliver. Ensure alignment throughout the entire engineering organization to anticipate the future, build with efficiency, and deliver business impact.”
Jellyfish sammelt Daten aus Git-Repos sowie Jira und verbindet sie beispielsweise mit individuellen Kalendern und Roadmaps. Damit entsteht ein Gesamtbild, wie das Team “funktioniert”. Zusätzlich werden die Daten kategorisiert.
Sogenannte Engineering Signals dienen dazu, herauszufinden, woran Teams arbeiten. Das können Dinge wie Commits und Pull Requests für Git Repositories sein.
Jellyfish bietet im Gegensatz zu LinearB keine Free Trial Version an.
#2 Entwickler_innen-Produktivität: Tools zur Verbesserung des Workflows
Dann gibt es noch Tools, die direkt in den Software-Entwicklungsprozess eingebunden sind und diesen verbessern sollen. Ich habe mich entschieden, hier keine ausufernde Liste zu erstellen, sondern kurz und knapp Tool-Kategorien zu beschreiben.. (Ausführliche Listen und Beschreibungen finden Sie hier https://marker.io/blog/developer-productivity-tools oder hier https://www.getport.io/blog/developer-productivity-tools)
- Ticketing
- Projektmanagement; Erstellung, Überwachung und Bearbeitung von Aufgaben.
- IDE
- Programm, um effizient Code schreiben zu können. Mehr dazu: IDE
- CDEs
- Remote Entwicklungsumgebungen, die sofort bereitgestellt werden können und alle Tools enthalten, die Entwickler_innen zum Arbeiten brauchen. Mehr dazu: Cloud Development Environments
- Versionskontrollsystem
- Änderungen am Quellcode verfolgen und verwalten.
- CI/CD
- Automatisierung, um Codeänderung schnell in Produktion zu übertragen.
- Dokumentation
- Beschreibung der Software.
Und hier noch Tools, die uns Entwickler_innen in Interviews als “cool” beschrieben haben 😉
- Infrastruktur als “Spielwiese” für Entwickler_innen: Server-Hardware, die Entwickler:innen zur Verfügung steht, auf der z.B. ein interner Kubernetes Cluster läuft oder auf die Entwickler:innen selbst VMs deployen können. Zu meiner Überraschung wurde hier oft von tatsächlich physischer Infrastruktur gesprochen, also Servern, die im Büro aufgestellt wurden o.ä. Grund dafür: Cloud Infrastruktur bringt eine ständige Kostendiskussion mit sich. Im Gegenzug sind Einmalkosten für die Anschaffung von Hardware für Entwickler_innen oft leichter durchzusetzen. Der interne Aufwand für Wartung und Betrieb von eigener Hardware ist zwar signifikant, wird aber nicht als Kostenpunkt getrackt und dem Management daher oft nicht als Kostenpunkt bewusst – im Gegensatz zu monatlichen Cloud-Rechnungen.
- IntelliJ: Die beliebte Java-IDE von JetBrains wurde wiederholt als “Lieblingstool” von Entwickler_innen genannt, die ihnen die Arbeit leichter macht.
- Auth0: Von User-Authentifizierung as-a-Service wurde mir vorgeschwärmt, dass all die Probleme von User-Invites, Multi-Tenancy, Integration mit Single-Sign-On Providern und das User-Management selbst einfach gelöst wird und sie sich das Team nicht mehr darum kümmern muss.
- Github Copilot wurde mir von einem Teamlead als wertvolles Tool für Code-Reviews genannt, da ihm der Copilot dabei hilft, sich schnell in Code zurechtzufinden, den er nicht selbst geschrieben hat. Auch wenn es darum geht, in einer Programmiersprache zu arbeiten, die man schon länger nicht verwendet hat wurde Copilot als wertvolles Tool genannt.
- Datadog: Eine Datenbank mit umfassenden Observability-Features, die zwar aufwändig aufzusetzen sind, aber dann das Arbeitn mit großen Datenmengen ungemein erleichtern. Vor allem, wenn viele Entwickler:innen im Team wenig Erfahrung mit der Optimierung von Datenbank-Abfragen haben und schlicht nicht wissen, ob der Code, den sie schreiben, die Datenbank übermäßig belastet und zu schlechter Performance führt. Wenn richtig konfiguriert kann Datadog genau das sichtbar machen und damit zu einem sehr wertvollen Tool werden, mit dem Entwickler:innen lernen können, Datenbank-optimierten Code zu schreiben.
- Github Actions für monitoring und notifications: Direkt in Slack benachrichtigt werden, ob ein Build fehlgeschlagen ist oder erfolgreich war hilft Entwickler_innen enorm dabei, schnell zu reagieren – und erst einmal zu bemerken – wenn ihre Änderungen zu Fehlern im Build oder Deployment führen.
- Gitlab: Um den Überblick über Code Reviews zu behalten, direkt mit der CI Pipeline zu integrieren und auch am gleichen Ort einen Issue Tracker zu haben, ist für manche Teams sehr wertvoll und macht die Arbeit flotter als das Arbeiten mit vielen verschiedenen Tools.
- Typescript: Für Frontend-Entwickler_innen hilfreich, da es im Hintergrund läuft und hilft, Fehler schnell zu finden.
- Selbst gebaute CI/CD Pipelines, besonders, wenn es ein Frontend gibt, über das Entwickler_innen selbst den Status von Deployments sehen können. Die Tatsache, dass viele Unternehmen so etwas bereits selbst gebaut haben, und das von Entwickler_innen als sehr wertvoll wahrgenommen wird, zeigt deutlich, dass der aktuelle Trend in Richtung “Developer Portals” und platform engineering einen Nerv trifft.
- Renovate Bot: Ein Tools, dass sich um Dependencies von pull requests kümmert. Ein Test Build wird durchgeführt, der überprüft, ob alles funktioniert und wenn ja automatisch bug fixes und minor releases in den master branch merged.
- Snyk: Ein Tool, dass container automatisiert auf Vulnerabilities überprüft und Entwickler_innen damit viel Recherchearbeit abnimmt.
- Augenzwinkernd wurden mir auch der Browser und Google als wichtige Tools im Entwicklungsprozess genannt 🙂
Über 7 Methoden zur Steigerung der Produktivität – ganz ohne Tools – hat übrigens unsere CEO ihre Gedanken dargelegt.
Bonus: Senden Sie eine Umfrage zur Produktivität aus
Ein weiteres und kostengünstiges Tool, um einen Einblick in die tägliche Arbeit Ihres Teams zu erhalten und die Produktivität zu steigern / Blocker zu beseitigen, ist eine klassische Umfrage durchzuführen. Neben dem Tracking von Kennzahlen und dem Einsatz von Tools, die beim Entwickeln unterstützen, bietet die Umfrage eine gute Möglichkeit, regelmäßig nach Problemen / Hindernissen zu fragen, individuelles Feedback zu erhalten und Schrittweise für eine höhere Developer Experience zu sorgen. Sie erhalten zwar keine Echtzeit-Kennzahlen, für viele Unternehmen ist eine regelmäßige Umfrage aber ein erster Schritt, um Teams zu ermöglichen, produktiver zu werden.
Was ist bei der Aussendung einer Umfrage zu beachten?
Was ist dabei zu beachten ? Einen guten Überblick gibt Will Larson, aktuell CTO von Carta. Seine Empfehlungen:
- Umfragen nicht aussenden, wenn die in einer vorhergegangenen Umfrage hervorgegangenen Probleme noch nicht angegangen worden sind.
- Maximal eine quartalsweise Aussendung, wobei dies abhängig von der Größe des Unternehmens ist. Bei großen Unternehmen: Jede Woche einen Teil von Developern befragen.
- Die Fragen vorher testen und bei Bedarf nacharbeiten.
- Auf qualitative, statt quantitative Fragen konzentrieren. Warum? Zitat: “Es ist leicht, sich in die quantitativen Aspekte von Umfragen zu verlieben, aber im Allgemeinen habe ich die Ergebnisse nicht als besonders nützlich empfunden. Interne Umfragen werden oft von so wenigen Personen ausgefüllt, dass Veränderungen statistisch nicht signifikant sind. Die Leute langweilen sich oft beim Ausfüllen von Umfragen, so dass die Zahlen eher die Teilnehmer als die allgemeine Stimmung widerspiegeln.”
Seine Ideen, welche Fragen geeignet sind (Auszug; ein Template stellt er leider nicht zur Verfügung):
- How would you rate our X process from 1 to 10? Where X is every common workflow at the company: test, code review, build, deploy, release, feature flagging, running experiments, reverting, incident management, on-call, debugging, and so on.
- What tools that you’ve previously used do you find yourself missing?
- Where do you feel like you lose time every week?
- Are there tools or areas of our code that you avoid when possible?
Unsere Tipps & Vorlage für eine Umfrage zur Entwickler_innen-Produktivität
Hier sind noch zwei Tipps für eine gelungene Umfrage:
- Vor der Aussendung kommunizieren, dass eine Umfrage ausgesendet wird.
Spaß beiseite, aber ein wertvoller Tipp steckt in dem Meme: Eine anonyme Antwortabgabe sollte möglich sein. 😉
Spaß beiseite, aber ein wertvoller Tipp steckt in dem Meme: Eine anonyme Antwortabgabe sollte möglich sein. 😉Fragen, die wir aussenden würden:
- Wie zufrieden bist du aktuell mit unseren Prozessen im Dev-Team? (1-5)
- Eine Frage zur Zufriedenheit hinsichtlich der implementierten Workflows. Ein Indikator, wie die Organisation der Arbeit insgesamt wahrgenommen wird. “Einfache” Einstiegsfrage.
- Was sind die größten Hindernisse, die deine Arbeit verlangsamen oder erschweren?
- Allgemeine Frage zu Blockern.
- Gibt es spezifische Hard- oder Softwareprobleme, die regelmäßig auftreten?
- Konkrete Frage zu Hindernissen.
- Fühlst du dich produktiv? (1-5)
- Eine Frage zur persönlich wahrgenommenen Produktivität. Messung der individuellen Zufriedenheit. Lässt sich in den letzten Bereich des DevX-Frameworks einordnen (Flow State).
Wir nutzen beispielsweise Typeform für Umfragen auf unserer Website, um darzustellen, welche CDE die individuellen Anforderungen am besten abdeckt. Typeform bietet visuell sofort ansprechende Templates und kann stark individualisiert werden. In der kostenfreien Version gibt es aber Limitierungen, beispielsweise ist die Anzahl an Responses vorgegeben.
Für andere Umfragen nutzen wir Google Forms. Goolge Forms ist ein einfaches Umfrage-Tool, mit dem schnell und ohne Limitierungen gearbeitet werden kann.
Fassen wir zusammen:
- Umfrage erstellen.
- Feedback einholen.
- Bei Bedarf Umfrage anpassen.
- Kommunizieren, dass eine Umfrage ausgesendet wird.
- Aussendung (Alle; Teilmenge).
Wenn die Umfrage durch ist, geht es an die Auswertung. Bei Multiple-Choice-Fragen einfach einen Mittelwert bilden und darstellen. Bei qualitativen Fragen (Textantworten) ist die Auswertung aufwändiger. Entweder Sie werten die Daten manuell aus und kategorisieren Antworten mit Codes (bspw. Antwort: “In meiner täglichen Arbeit sind Meetings ein extremer Blocker.” Kategorisierung: “Meetings”), oder Sie nutzen LLM-Tools wie ChatGPT, um die Antworten schnell zu analysieren.
Was ist nach der Analyse zu tun? Stellen Sie die Ergebnisse nach der Aufbereitung öffentlich zur Verfügung (sofern möglich). Das zeigt ein wirkliches Interesse an der Verbesserung Ihrer Prozesse und dient als Incentive, auch weiter an dieser Umfrage teilzunehmen.
Zusammenfassung
- Bevor Sie Produktivitäts-Tools zur Verbesserung des Workflows oder zum Tracking von Kennzahlen einführen, fragen Sie nach dem “Warum”
- Produktivitätstools fürs Tracking von KPIs
- Linearb
- Jellyfish
- Es gibt extrem viele Produktivitätstools zur Verbesserung des alltäglichen Workflows. Einige davon haben wir im Text vorgestellt.
- Bonus: Senden Sie eine Umfrage aus, um nach Blocker zu Fragen. Machen Sie das regelmäßig, um Fortschritte zu tracken. (Vorlage für Umfrage hier kostenlos herunterladen)
