Die systematische Organisation der Softwareentwicklung
Eine ingenieurtechnische Perspektive auf die Gestaltung von Softwareentwicklungsorganisationen
Bei der Gestaltung leistungsfähiger und wandlungsfähiger Softwareentwicklungsorganisationen gehen viele Unternehmen wenig strukturiert und systematisch vor. Sie legen z. B. den Fokus auf die Arbeit an dem agilen Mindset oder setzen Standardlösungen ohne Rücksicht auf konkrete Gegebenheiten ein und merken erst spät, dass sie damit ihre Ziele verfehlen.
In diesem Beitrag möchte ich Ihnen zeigen, wie es besser geht.
Ich beschäftige mich seit 30 Jahren mit Softwareentwicklung und der Optimierung von Softwareentwicklungsorganisationen. Als Ingenieur mit Leib und Seele und als systemischer Coach kenne ich beide Seiten:
- Die ingenieurmäßige und damit eher strukturierte Herangehensweise und
- den menschenzentrierten, systemischen Ansatz oder wie wir in der Schweiz sagen “Gspürsch mi, Fühlsch mi” – sinngemäß übersetzt mit “Spürst du mich, fühlst du mich”.
Für viele Ingenieure und Techniker ist der menschenzentrierte, systemische Ansatz bei der Gestaltung von Softwareentwicklungsorganisationen weniger sichtbar und greifbar und damit schwerer zugänglich. Nach meiner Erfahrung lässt sich eine Softwareentwicklungsorganisation aber ähnlich wie eine strukturierte Softwareentwicklung “ingenieurmäßig bauen”. Dadurch wird sie objektiver und nachvollziehbarer, was gerade für Menschen mit technischem Hintergrund sehr hilfreich ist.
Eine Softwareentwicklungsorganisation ist ein komplexes System
Die folgende Abbildung zeigt in abstrahierter Form eine Softwareentwicklungsorganisation:
Abbildung 1: Die Elemente einer Softwareentwicklungsorganisation
Im Mittelpunkt steht das Softwareentwicklungsteam. Es hat die Aufgabe, ein Softwaresystem oder ein Teilsystem zu entwickeln. Meist interagiert es mit anderen Abteilungen, externen Partnern oder auch Stakeholdern und dem Management. Es bestehen Abhängigkeiten und es ist nicht trivial, diese zu organisieren und für eine reibungslose Zusammenarbeit zu sorgen.
Wir sprechen von einem komplexen System!
Grundsätzlich gibt es drei wesentliche Aspekte, um ein komplexes System zu beherrschen:
- Systemverständnis sicherstellen.
- Interaktionen sicherstellen und optimieren.
- Selbstmanagement beachten und zielorientiert steuern.
Abbildung 2: Die drei wesentlichen Aspekte zur Beherrschung eines komplexen Systems
Die Visualisierung zeigt eine Zweiteilung: Auf der einen Seite das Systemische, das den Menschen in den Mittelpunkt stellt (Thema Selbstmanagement) und auf der anderen Seite die Interaktionen, bei denen es um Elemente, Strukturen, Prozesse, Verbindungen und Schnittstellen geht.
Der Aspekt des Systemverständnisses ist wiederum zweigeteilt. Das Verständnis von Umfang, Elementen, Strukturen und Schnittstellen gehört zum strukturierten und systematischen Vorgehen. Das Sichtbarmachen und Visualisieren der relevanten Energien und Felder durch eine Systemaufstellung gehört zur systemischen Welt.
Im Rahmen agiler Transformationen beobachte ich häufig Situationen, in denen agile Prozesse, Methoden oder Frameworks wie Scrum, Scaled Agile oder LeSS eingeführt werden und dabei begonnen wird, mit den Beteiligten am agilen Mindset zu arbeiten – oft jedoch wenig erfolgreich. Es reicht nicht aus, nur Coaching zu betreiben, am agilen Mindset zu arbeiten und die Strukturen und Schnittstellen nicht anzupassen. Es reicht aber auch nicht aus, nur Strukturen, Methoden, Schnittstellen und Kommunikationswege zu betrachten und zu optimieren und die systemischen, d.h. menschenzentrierten Aspekte zu vernachlässigen.
Der strukturierte Aufbau einer Softwareentwicklungsorganisation
Wie lässt sich nun in Anlehnung an ein strukturiertes und systematisches Vorgehen beim Bau einer Software bzw. der Erstellung einer Softwarearchitektur auch eine Softwareentwicklungsorganisation strukturiert und systematisch aufbauen?
Stellen Sie sich folgende Aufgabenstellung vor: Entwickeln Sie eine Software zur Addition von zwei Zahlen.
Wie die nachfolgenden Beispiele zeigen, lässt sich diese Aufgabe mithilfe verschiedener Ansätze lösen:
Abbildung 3: Verschiedene Softwarelösungen zum Addieren von zwei Zahlen
Welche ist die beste Lösung?
Die Frage lässt sich kaum im Konsens beantworten, denn obwohl die Lösungen völlig unterschiedliche Eigenschaften besitzen, erfüllen alle die gestellte Aufgabe. Hier zeigt sich ein typischer Denkfehler, der bei der Erstellung von Software häufig gemacht wird: Es reicht nicht aus, nur funktionale Anforderungen zu definieren. Rahmenbedingungen und Qualitätsanforderungen gilt es ebenfalls zu bestimmen, denn nur so lässt sich sicherstellen, dass eine Software erwartungsgemäß gebaut werden kann.
Ohne entsprechenden Input lässt sich lange über verschiedene Lösungen diskutieren, eine konstruktive Einigung ist aber praktisch unmöglich. Ohne definierte Rahmenbedingungen und explizite Qualitätsanforderungen lässt sich nicht entscheiden, ob bspw. die dialogbasierte Anwendung oder die Variante mit einem einzigen Eingabefeld (wie bei Google) die bessere Lösung ist.
Die folgende Visualisierung verdeutlicht diese Thematik:
Abbildung 4: Anforderungsraum und Lösungsraum
Mit den funktionalen Anforderungen wird ein Anforderungsraum aufgespannt. Die blaue, die rote und die grüne Lösung erfüllen alle diese Anforderungen. Allerdings auf völlig unterschiedliche Weise. Die Unterschiede liegen in der Erfüllung von Qualitätsanforderungen wie z. B. Wartbarkeit (Maintainability) oder Geschwindigkeit (Performance). Um ein System zu entwickeln, müssen diese Eigenschaften spezifiziert werden. Zusätzlich gibt es auf der Lösungsseite oft Rahmenbedingungen, die ebenfalls eingehalten werden müssen. Dies kann bspw. eine zu verwendende Technologie sein.
Und was hat das alles mit Organisationsentwicklung zu tun?
Auch beim Aufbau einer Organisation sollte man ähnlich vorgehen und die gleichen Inputs berücksichtigen. Auch hier gibt es funktionale Anforderungen, bspw. die Aufgaben und Tätigkeiten von Personen oder Teams. Aber auch hier ist es mit diesen funktionalen Anforderungen nicht getan. Es reicht in der Regel nicht aus, dass Personen und Teams ihre Aufgaben erledigen. Oft sind qualitative Anforderungen wie Performanz, also Effizienz und Effektivität, oder auch Skalierbarkeit wichtig, um eine optimale Organisation aufzubauen. Und ähnlich wie bei der eigentlichen Entwicklung von Software finden sich auch bei der Entwicklung einer Softwareorganisation Rahmenbedingungen.
Strukturierte und systematische Erstellung einer Architektur
Basierend auf den relevanten Inputs werden sogenannte Architekturelemente erstellt, welche die Anforderungen bestmöglich erfüllen. Hier ist Kreativität oder auch Erfahrung gefragt, um verschiedene Lösungsmöglichkeiten zu finden.
Architekturelemente sind generische Lösungsbausteine. Sie strukturieren die Lösung – bei einer Software können dies verschiedene Subsystem, bei einer Organisation bspw. Teams, Abteilungen oder Personen sein. Die Eigenschaften dieser Elemente müssen explizit definiert werden. Sobald mehrere Elemente vorhanden sind, müssen auch die Abhängigkeiten, d.h. die Schnittstellen und Kommunikationsprotokolle (bei Softwareelementen technische Protokolle, bei Organisationselementen eher kommunikative Protokolle) definiert werden. Man spricht hier von Designentscheidungen.
Die folgende Abbildung zeigt die Erstellung von Architekturelementen und notwendige Designentscheidungen (für eine Softwarearchitektur):
Abbildung 5: Notwendige Designentscheidungen für zwei Architekturelemente (für eine Softwarearchitektur)
Die folgende Tabelle listet die notwendigen Designentscheidungen für eine Softwarearchitektur und ihre Analogien für eine Organisationsarchitektur auf:
Tabelle 1: Analogien der notwendigen Designentscheidungen einer Softwarearchitektur und einer Organisationsstruktur
Ein reales Beispiel könnte dann so aussehen:
Abbildung 6: Reale Softwareentwicklungsorganisation mit (Architektur-) Elementen und deren Schnittstellen
Mit einer solchen Sichtweise ist der Aspekt Systemverständnis, wie in Abbildung 2 dargestellt, bereits gut erfüllt. Ausgehend von einem solchen Diagramm sollten nun die Designentscheidungen aus Tabelle 1 durchgegangen und geklärt werden. Ist dies geschehen, kann die Eignung der Lösung bewertet werden. Dazu wird die Erfüllung der relevanten Inputs überprüft.
Ein solches Vorgehen stellt sicher, dass eine Organisationsentwicklung nachvollziehbar ist. Es zeigt deutlich, warum welche Veränderungen vorgenommen wurden und stellt sicher, dass die Anforderungen auch tatsächlich umgesetzt werden können. Diese Klarheit sollte idealerweise bestehen, bevor alle Veränderungen vorgenommen, Teams gebildet und Mitarbeiter in Teams versetzt werden. Genauso, wie ein Softwaresystem aufgebaut sein sollte: Performance, Wartbarkeit oder Skalierbarkeit sollten bereits beim Entwurf der Software berücksichtigt werden und nicht erst, wenn die Software vollständig implementiert wurde.
Fazit
Eine Softwareentwicklungsorganisation ist ein komplexes System. Jede Veränderung oder Optimierung der Organisation bedarf auch einer systemischen Betrachtung. Es reicht jedoch nicht aus, nur menschenzentrierte Aspekte zu beachteten, auch Strukturen, Prozesse, Methoden und Werkzeuge müssen strukturiert und systematisch angegangen werden.
Zuerst gilt es, ein gemeinsames Systemverständnis sicherzustellen. Mit einfachen Diagrammen, die mit den Beteiligten abgestimmt werden können, kann dies effizient geschehen. Darauf aufbauend müssen die relevanten Inputs strukturiert erfasst werden: Neben den Aufgaben und Funktionen, welche die Organisation und jedes Element zu erfüllen hat, müssen auch qualitative Aspekte und Rahmenbedingungen definiert und transparent aufgenommen werden. Erst dann können in einem zweiten Schritt Aufgaben, Verantwortlichkeiten und Schnittstellen der Organisation zielgerichtet optimiert und bereits in der Planung überprüft werden.
Mit diesem für alle Beteiligten nachvollziehbaren Vorgehen wird der anschließende Veränderungsprozess leichter gelingen!
Extra-Bonus
Hier finden Sie 3 zusätzliche Fragen zu Softwareentwicklungsorganisationen, die Matthias Künzi beantwortet (bitte auf Plus drücken):
Woran erkennt eine Softwareentwicklungsorganisation, dass sie ein gutes Systemverständnis entwickelt hat?
Matthias Künzi: Das erkennt man an einer klaren Sprache. D. h. relevante Elemente und Verbindungen der Organisation werden eindeutig und unmissverständlich benannt. Es ist klar, was die Elemente bedeuten wo es Schnittstellen gibt und wie diese ausgestaltet sind. Konkret sind das Elemente wie Teams, Personen oder auch Prozesse, Prozessschritte und sonstige relevante Artefakte. Auch über Hilfsmittel oder Werkzeuge und den entsprechenden Einsatzbereichen sollte Klarheit bestehen. In der Summe führt dies bei allen Beteiligten zu mehr Verständnis und einer effizienten und effektiven Zusammenarbeit.
Welchen zusätzlichen Denkfehler gibt es bei der Entwicklung einer Softwareentwicklungsorganisation?
Matthias Künzi: Ein weiterer Denkfehler ist, dass eine Organisationsentwicklung in einem Schritt umgestaltet und damit optimiert werden kann. Mit dem oben dargestellten Vorgehen lassen sich nachvollziehbare Handlungsoptionen ableiten. Die Umsetzung sollte dann aber mit Bedacht und vor allem iterativ und inkrementell erfolgen. D.h. nur wenige Veränderungen auf einmal, um deren Wirkung in der Organisation beurteilen zu können. Auch das ist ingenieurmäßiges Vorgehen:
- Messbarkeit sicherstellen.
- Veränderung durchführen.
- Wirkung anhand der Messung beurteilen.
- Erkenntnisse für die nächsten Schritte ableiten.
Selbstmanagement adressiert viele Aspekte, die bei Menschen individuell ausgeprägt sind. Sollten diese individuellen Ausprägungen auf Teamebene adressiert werden?
Matthias Künzi: Selbstmanagement hat viele Aspekte, die sehr individuell sein können. Für mich ist die Frage zweigeteilt:
- Welche individuellen Aspekte sind überhaupt relevant für die Teamebene, also die Zusammenarbeit – oder sind persönlich und nicht relevant?
- Was sollte auf Teamebene adressiert werden?
Auf die erste Frage gibt es eine einfache Antwort: Aus systemischer Sicht ist jeder Aspekt jedes Individuums im System für das System relevant. Etwas detaillierter ausgedrückt: Je zentraler die Rolle im Team ist, desto relevanter und einflussreicher sind die Eigenschaften des entsprechenden Individuums für das Team. Das mag für eine Führungskraft einleuchtend und nachvollziehbar sein – in der Praxis wird aber bspw. immer wieder unterschätzt, dass langjährige, angesehene Mitarbeiter einen sehr großen Einfluss auf ein System (Team) haben können, selbst wenn sie hierarchisch “normale” Teammitglieder sind. Wird dies nicht berücksichtigt, kann der Widerstand oder die Skepsis einer solchen Person ganze Veränderungsvorhaben zum Scheitern bringen.
Ob ein individueller Aspekt auf Teamebene adressiert, d. h. offen angesprochen werden soll, hängt meiner Meinung nach sehr von der Reife des Teams ab. Idealerweise wird ein “störendes” Thema von jemandem aus dem Team selbst angesprochen und dann im Team diskutiert. Von der Führungskraft initiiert, wäre es ein Thema für ein Mitarbeitergespräch.
Hinweise:
Mit steigender Vielfalt, Dynamik und Vernetzung nimmt die Komplexität von Projekten insbesondere Projekte mit Software immer weiter zu. Mitarbeiter mit unterschiedlichsten Voraussetzungen müssen effektiv zusammenarbeiten, um die Projektziele zu erreichen. Es wird zunehmend schwieriger, die Übersicht zu behalten. Matthias Künzi unterstützt Sie gerne dabei, Struktur, Systematik und Methodik in Ihre Vorhaben zu bringen. Sprechen Sie ihn bei Interesse einfach an. Und wenn Sie für reibungslose Softwareentwicklung und gut konstruierte Software interessieren, dann lohnt sich auch ein Blick in den Blog von visuellklar.
Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!
Matthias Künzi
Matthias Künzi (Dipl. El. Ing. HTL, Dipl. Software Ing. FH, Systemischer Coach) hat in den letzten 30 Jahren als Softwareentwickler, Software- und Systemarchitekt sowie als Führungskraft viel Erfahrung in der Entwicklung und Organisation von Softwaresystemen im Embedded- und kommerziellen Umfeld gesammelt. Mit seiner Firma “visuellklar” unterstützt er Softwareunternehmen bei der Optimierung ihrer Organisation und Produktentwicklung. Sein Ziel ist es, Komplexität zu beherrschen und Unternehmen systematisch zu einer reibungslosen Softwareentwicklungsmaschinerie zu entwickeln.