Dev/Non-Dev Ratio (II)

Bild: Unsplash / Jud Mackrill - Lizenz

Dass es in einer Software entwickelnden Organisation schwierig ist, wenn nur eine Minderheit der Angestellten selbst in der Lage ist zur Software-Entwicklung beizutragen, dürfte nachvollziebar sein. Das Risiko ist in solchen Fällen gross, dass es zu Silo-Bildung, Prozess-Overhead und Arbeits-Rückstaus kommt. In grossen Organisationen ist diese Problemlage aber oft nicht ohne weiteres ersichtlich, so dass ihre Entdeckung oft überraschend wirkt.

Der Grund dafür ist die fehlende Einsicht der meisten Beteiligten in die tatsächlichen Mengenverteilungen. Damit ist weniger gemeint, dass keinem bewusst ist, wie wiele Entwickler im Unternehmen sind und wie gross ihr Anteil an der Gesamtbelegschaft ist, vielmehr geht es darum, dass nur den wenigsten Mitarbeitern ausserhalb der IT klar ist, wer (ausserhalb der eigenen Abteilung) sie regelmässig beauftragt, mit was und in welchem Umfang.

Irgendwo gibt es zwar eine Portfolio- und Aufwandsplanung, aus der man herleiten könnte, für wen alles intern Software entwickelt wird, meistens ist die aber nicht so einfach zugänglich, man sieht nur das was einen selbst betrifft. Und so lange Organisation so aufgebaut sind, dass IT und Fachabteilungen eigene organisatorische Einheiten sind (in der Regel nochmals mit einer auf Funktionen basierenden Aufteilungen in Untergruppen), wäre das Gewinnen eines Gesamtbildes auch relativ aufwändig.

Im Rahmen agiler Transformationen gibt es aber einen Punkt, an dem die Mengenverteilungen schlagartig offensichtlich werden, nämlich dann, wenn versucht wird, die Organisation auf Value Stream- oder Produktorientierung umzustellen. Im Rahmen einer solchen Umstellung werden in der Regel alle Fachspezialisten, Produkt- und Projektmanager, Kundenbetreuer, Marketing- und Vertriebsmitarbeiter und eben Softwareentwickler in einer Einheit oder einer Querschnittsorganisation zusammengefasst.

Dort wo ich derartige Umstellungen in Grossorganisationen erlebt habe, waren am Ende (je nach Produktschnitt) zwischen 10 und 30 Menschen in einer solchen Produkt- oder Value Stream-orientierten Einheit zusammengefasst. wovon (und jetzt kommt es) in fast allen Fällen weniger als 10 Prozent Software entwickeln konnten. Ich kann mich sogar an Fälle in verschiedenen Firmen erinnern, in denen es mehr Value Streams als Entwickler gegeben hat.

Je nach Einzelfall kann man zwar immer argumentieren, dass es immer auch eine Reihe von Nicht-Entwicklungstätigkeiten für das jeweilige Produkt braucht, Fälle wie die gerade genannten (von denen es in grossen Organisationen erstaunlich viele gibt) sind aber offensichtlich dysfunktional und erinnern völlig zu Recht an das Single worker digging hole-Meme. Und dass eine solche Situation nur in einem Nerven- und zeitfressenden Kampf um die knappen Kapazitäten enden kann, dürfte auch klar sein.

Anders als in vielen anderen Fällen ist in einer solchen Situation die Lösung auch realativ klar: man kann entweder die Umsetzungskapazität in der Software-Entwicklung ausbauen (Leute einstellen) oder den umgebenden Overhead abbauen (Leute entlassen oder versetzen). Und wenn man sich dazu nicht durchringen kann sollte man zumindest eines Allen klarmachen - wenn man irgendein Ergebnis nicht so schnell bekommt wie man es gerne hätte liegt das nicht daran, dass die IT so langsam ist, sondern dass die Dev/Non-Dev Ratio völlig unausgewogen ist.