Dev/Non-Dev Ratio

Bild: Pixabay / Louise Hoffmann - Lizenz

Grundsätzlich ist es zwar so, dass die Situation jeder Organisation irgendwie einzigartig ist, trotzdem gibt es bestimmte Rahmenbedingungen, die durchgehend Einfluss auf das jeweilige "Agilitätspotential" haben. Eine davon (zumindest in Software entwickelnden Firmen) ist das Verhältnis von Software-Entwicklern zu Nicht-Entwicklern. Je höher der Anteil an Nicht-Entwicklern an der Belegschaft ist, desto schwerer wird sich die Firma mit Agilität tun.

Um Missverständnissen vorzubeugen: in kaum einem Unternehmen nennenswerter Grösse werden die Software-Entwickler hundert Prozent des Personals ausmachen. Es wird so gut wie immer den Bedarf nach Buchhaltung, Einkauf, etc. geben. Zu einem Problem kann das aber werden, sobald die Anzahl dieser Leute an die der Software-Entwickler heranreicht oder sie übersteigt. Dann sind nämlich meistens einige (oder alle) der folgenden Konstellationen gegeben:

Es existieren organisatorische Silos

Wenn Teams und Abteilungen nicht crossfunktional aufgestellt sind enstehen permanent Koordinations- und Eskalationsaufwände. Im besten Fall müssen die verschiedenen Silos (Fachabteilung, Anwendungsentwicklung, Betrieb, etc.) ihr Vorgehen ständig miteinander abstimmen, gegebenenfalls gibt es sogar abweichende und gegenläufige Planungen, die regelmässig in Konflikten münden. Im schlimmsten Fall stellen sich die Silos ihre Leistungen gegenseitig in Rechnung, mit allem was das an Verhandlungen und Spar-Lösungen zur Folge hat.

Es existieren Wasserfall-artige Prozessketten

Ein ähnliches Phänomen, allerdings innerhalb der Anwendungsentwicklung. Wenn verschiedene Teams für Anforderung, Konzeption, Entwicklung, Test und Rollout tätig sind, dann führt das zu den gleichen Problemen wie im Fall der organisatorischen Silos. Zusätzlich dazu kommt das Phänomen, dass frühere Prozesschritte (Anforderung und Konzeption) in der Regel einen höheren Output haben als spätere (Entwicklung, Test und Rollout), wodurch es zu Stau, Multitasking und Priorisierungskonflikten kommt.

Es existieren vielstufige Hierarchien

Zum Teil eine Folge des letzten Punktes. Bei Konflikten greift noch zu häufig der Reflex, diese durch eine übergeordnete Eintscheidungsinstanz (das Management) lösen zu lassen statt durch die Beteiligten selbst. Das Weiterleiten vieler Entscheidungen nach oben kann aber nur zu zwei Ergebnissen führen: entweder entsteht dort ein weiterer Flaschenhals durch den alles verlangsamt wird, oder es werden immer mehr Entscheider/Manager eingestellt, die zwangsläufig einen immer grösseren Anteil ihrer Zeit dafür verwenden müssen, sich untereinander zu koordinieren.

Es existieren viele nicht automatisierte oder digitalisierte Arbeitsschritte

Ein etwas anderer Fall als bei den letzten Punkten - hier geht es um die eigentliche Produktion. Je geringer der Automatisierungs- und Digitalisierungsgrad beim Testen, Dokumentieren, Berechtigungsmanagement, etc. ist, desto mehr Zeit geht an diesen Stellen verloren. Die Anzahl an Nicht-Entwicklern wie z.B. manuellen Testern und Business Analysten ist an diesen Stellen ein Indikator für langsame und schwerfällige Prozesse.


Dass derartige Konstellationen existieren hat seine Ursache fast immer in einem falsch verstandenen Effizienzdenken. Die zuvor genannten Phänomene gehen oft auf die Annahme zurück, dass Software-Entwickler produktiver sind wenn sie nur Code schreiben und nichts anderes tun. Die Auslagerung von allem anderen in eigene Silos, Prozesschritte, Hierarchie-Ebenen und (Hilfs-)Teams ist die Folge davon. Dass stattdessen die Effizienz sinkt ist dann eine unangenehme Überraschung.