„Das Team ist zu langsam.“ Der erste Verdacht lautet dann oft: zu wenig Motivation, zu viel Homeoffice. In 25 Jahren Softwareentwicklung haben wir das fast immer anders erlebt. Die Entwicklerproduktivität sinkt meist nicht, weil Menschen nicht wollen, sondern weil Werkzeuge und Abläufe sie ausbremsen. Dieselben sieben Fehler tauchen dabei immer wieder auf.

Die Ursache liegt selten bei den Menschen

Das Argument „Im Homeoffice macht keiner mehr was“ hat sich bei uns nicht bestätigt. Die Produktivität blieb nach der Umstellung auf Remote Work konstant, wie der Beitrag Remote Work nach 5 Jahren beschreibt. Wenn ein Team langsam ist, lohnt sich deshalb zuerst der Blick auf das System, in dem es arbeitet.

Sieben Produktivitätsbremsen

1. Keine Versionsverwaltung

Eine Versionsverwaltung hält fest, wer wann was am Code geändert hat, und ermöglicht paralleles Arbeiten. Fehlt sie, oder arbeiten alle ohne Strategie auf demselben Stand, entstehen ständig Konflikte. Das kostet Zeit und Nerven.

2. Fehlendes oder schlechtes Task-Tracking

Excel-Listen und E-Mails als Projektmanagement führen dazu, dass selbst die Geschäftsführung den Überblick verliert, und damit auch die Motivation. Aufgaben, Verantwortliche und Stand gehören in ein System, das alle sehen.

3. Sicherheitsprüfungen von Hand

Wer Sicherheitsprüfungen manuell durchführt, vergisst sie oder braucht ewig dafür. Fehler schleichen sich so fast automatisch ein. Automatisierte Prüfungen laufen bei jeder Änderung, ohne dass jemand daran denken muss.

4. Lange Wartezeit nach jeder Änderung

Eine minimale Änderung im Code, dann eine Minute warten, testen und wieder von vorn. Das wirkt harmlos und summiert sich. Ein Rechenbeispiel mit angenommenen Werten: Bei einer Minute Wartezeit, 30 Durchläufen am Tag und 10 Entwicklern sind das 300 Minuten täglich, also fünf Stunden Wartezeit für ein Team. Nicht eingerechnet ist, dass jede Wartepause die Konzentration unterbricht.

5. Schwache Hardware am Arbeitsplatz

Wenn Arbeitsplatzrechner für Word und Excel gedacht sind, kann niemand effizient entwickeln. Das ist Sparen an der falschen Stelle: Das Gehalt eines Entwicklers übersteigt die Kosten eines guten Rechners um ein Vielfaches, und jede Minute Wartezeit kostet das Gehalt, nicht den Rechner.

6. Überlastete gemeinsame Build-Systeme

Läuft das gemeinsame System, das Änderungen automatisch baut und prüft, ständig am Limit, wartet jeder. Im schlechteren Fall wird es gemieden, und dann fehlen die Prüfungen, für die es da ist. Teams sollten ihre Auslastung kennen und rechtzeitig Kapazität erweitern.

7. Meeting-Overload

Status-Meetings, in denen die meisten nichts beizutragen haben, blockieren kreative Arbeit mehr als fast alles andere. Eine Rückfrage nach dem Zweck jedes Termins und eine Streichung der Termine ohne Ergebnis bringen oft schon viel. Das Prinzip dahinter beschreibt der Beitrag Prozesse optimieren: zuerst fragen, ob es den Ablauf überhaupt braucht.

Was Entwicklerproduktivität wirklich bestimmt

Der Verdacht gegen die Menschen ist für Führungskräfte bequem, weil er nichts kostet. Die Ursachen in Werkzeugen und Abläufen dagegen verlangen Investitionen und Entscheidungen, und die liegen bei der Unternehmensleitung. Wer ein Team langsam nennt, sollte deshalb zuerst prüfen, ob es unter denselben Bedingungen schneller arbeiten könnte.

Alle sieben Punkte haben dasselbe gemeinsam: Sie sind Entscheidungen des Unternehmens, keine Eigenschaften der Entwickler. Wer sie ändert, braucht keine Motivationsreden. Entwickler wollen Probleme lösen, nicht Probleme verwalten. Wenn aktuelle Werkzeuge und einfache Abläufe die Hindernisse beseitigen, geht vieles schneller, ohne dass jemand härter arbeitet.

Nach unserer Erfahrung aus hunderten Projekten hängt Produktivität zu einem sehr großen Teil an Ausstattung und System, nicht an Persönlichkeit.

So gehen Entscheider vor

• Das Team fragen, was beim Arbeiten am meisten Zeit kostet. Die Liste der Antworten zeigt meist schnell, welche der sieben Punkte zutreffen.
• Wartezeiten messen und in Stunden pro Woche umrechnen. Damit lässt sich eine Investition in Rechner oder Build-Kapazität rechtfertigen, wie Technische Schulden es für Altlasten beschreibt: in der Sprache des Controllings, also in Euro.
• Mit dem günstigsten und wirksamsten Punkt beginnen. Oft ist das die Meetingkultur.
• Nach einigen Wochen erneut fragen, ob es spürbar besser geworden ist.

Fazit

Wenn ein Team langsam ist, liegt die Ursache selten bei den Menschen. Versionsverwaltung, Aufgabenverwaltung, automatische Prüfungen, schnelle Rückmeldung, gute Hardware, ausreichende Build-Kapazität und wenige Meetings entscheiden mehr über die Entwicklerproduktivität als jede Motivationsmaßnahme.