Softwareentwicklung verliert immer wieder das Ganze aus dem Blick. Das ist auch nicht verwunderlich bei all dem Druck, der in Projekten herrscht. Denn unter Druck blicken wir schnell in einen Tunnel. Dann schauen wir nur noch vor die Füße aufs Vorankommen. Irgendwie.
Unter Druck ist der Blick nach innen auf Details gerichtet. Entwickler starren auf Code - und der Code starrt zurück. Die Außenwelt, das Ganze tritt in den Hintergrund. Das mag positiv mal ein Flow-Zustand sein - häufiger jedoch scheint es mir ein verkrampftes Kreisen umeinander. Die Teile nehmen dann nur noch sich wahr.
Ich denke, wir müssen das erkennen und bewusst dagegen wirken. Damit eine solche Konzentration von Teilen nicht zu lokalen Optimierungen auf Kosten des Ganzen geht, braucht sie ein Gegengewicht.
Der Kraft, die Beziehungen nach innen ausüben, ist eine Kraft entgegenzusetzen, die die Beziehungspartner von einander getrennt hält - damit sie nicht miteinander verschmelzen oder in den in-fight gehen.
Verschmelzung bedeutet Strukturverlust, Aufgabe von Identität und Erhöhung der Entropie. In-fight bedeutet Konflikt und durch drohende Zerstörung ebenfalls Erhöhung von Entropie.
Das Gegengewicht für die Dyade Entwickler-Code ist der Architekt. Er sorgt dafür, dass die Codierung im Detail das Big Picture der Softwaresystemstruktur nicht aus den Augen verliert.
Natürlich entsteht dadurch wieder eine Beziehung, die einen Tunnelblick entwickeln kann. Architekt und Entwickler-Code Dyade sind auch nur Teile eines größeren Ganzen. Sie bilden eine Dyade auf höherer Ebene - die wiederum ein Gegengewicht braucht.
Damit Architekt und Entwickler sich nicht in der Technik verlieren, muss ein Abnehmer [1] ständig an ihnen ziehen. Software ist kein Selbstzweck, sondern soll ihm dienen. Der Abnehmer ist dafür verantwortlich, dass “die Techniker” ein ihm nützliches Ganzes nicht aus den Augen verlieren.
Aber auch diese Dyade braucht ein Gegengewicht. Denn auch diese Dyade kann einen Tunnelblick entwickeln. Nicht jeder Weg zum Ganzen ist ein guter. Abnehmer und Techniker können sich in Konflikten aufreiben. Also braucht es eine Instanz, die auf Fortschritt achtet, d.h. das Ganze des Fortschrittsprozesses im Auge behält: den Prozessbevollmächtigten.
Welchem Prozess die Softwareproduktion folgt, ist mir hier nicht wichtig. Ohne geht es jedoch nicht. Und dass der eingehalten wird, darauf muss jemand achten. Sonst besteht Gefahr, dass die Produktion sich im Hin und Her des Abnahmezugs aufreibt.
Und wie geht es weiter? Braucht nicht auch diese Dyade ein Korrektiv? Natürlich. Doch dann ist ja kein Ende solcher Gegengewichthierarchie abzusehen. Bis zum Bundespräsidenten möchte ich dieses Muster nicht fortsetzen ;-)
Aber mir scheint es praktikabel, die Hierarchie mit einem Kollektiv abzuschließen:
Das macht auch deutlich, dass keines der Gegengewichte bzw. der Teile “besser” oder “mächtiger” ist. Sie unterscheiden sich nur in ihrem Horizont. Das Softwaresystem ist ein Ganzes und so ist auf oberster Ebene auch die Führung des Produktionsprozesses ein Ganzes.
Ich denke, an diesen Rollen geht nichts vorbei. Wir brauchen sie - das sehe ich immer wieder, wenn sie fehlen. Ob sie durch unterschiedliche Personen oder in Personalunion ausgefüllt werden, ist mir an dieser Stelle nicht so wichtig. Ab einer bestimmten Projektgröße ist es immer sinnvoll, Personalunionen aufzugeben.
Wichtiger ist, diese Verantwortlichkeiten als solche zu erkennen und allseitig dafür Bewusstsein zu schaffen.
Endnoten
[1] Begriffe wie “Kunde” oder “Product Owner” oder “Produktmanager” will ich vermeiden. Daran hängen mir gerade zu viele Vorstellungen.