Oft werden bei einer Software-Modernisierung in erster Linie technische Aspekte wie Tech Stack, Architektur, UX/UI, Performance, Skalierbarkeit oder Sicherheit für den Erfolg verantwortlich gemacht. Es gibt aber einen anderen Bereich, der noch vorgelagert einen enormen Einfluss auf so ein Vorhaben hat … Was genau ich damit meine, möchte ich mit einer Geschichte als Metapher einleiten.
Es geht um die Geschichte des Turmbau zu Babel. Hier eine kurze Zusammenfassung:
Turmbau zu Babel
„Die Menschen versuchten, einen Turm zu bauen, der den Himmel erreichen sollte. Doch ihre Pläne wurden durch die Verwirrung ihrer Sprache durchkreuzt, wodurch sie nicht mehr miteinander kommunizieren konnten. Dies führte zum Abbruch des Turmbaus und zur Entstehung einer Vielfalt von Sprachen und Kulturen, symbolisiert durch den Namen Babel, was ‚Verwirrung‘ bedeutet.“
Was hat diese Geschichte nun mit Software zu tun? Und ist sie nicht ein bisschen zu angestaubt, um noch als zeitgemäße Metapher zu gelten?
Das dürft ihr am Ende meines Artikels selbst entscheiden.
Das Brook’sche Gesetz: mehr Ressourcen heißt nicht schnellere Fertigstellung
Die Erzählung habe ich natürlich nicht zufällig gewählt. Ich beziehe mich dabei auf das Buch „The Mythical Man Month“ von Frederick P. Brooks. Der genau diese Geschichte als Metapher gewählt hat, um seine Kernaussage zu verbildlichen. Auf den Arbeitskontext bezogen ist es so, als würden unterschiedliche Abteilungen bzw. Bereiche eine andere Sprache sprechen; und oft wird das auch genauso empfunden. Das Buch erschien im englischen Original bereits 1975. Es ist also, mit IT-Maßstäben verglichen, steinalt.
Um so erstaunlicher, dass es bis heute als moderner Klassiker gilt, der sich mit den menschlichen Faktoren im Bereich der Softwareentwicklung auseinandersetzt.
Die Kernaussage des Buchs ist als Brook’sche Gesetz bekannt:
Es besagt, dass das Hinzufügen von Personal zu einem verzögerten Softwareprojekt die Fertigstellung weiter verzögern kann. Dies liegt an der exponentiell steigenden Kommunikations- und Koordinationslast mit mehr Teammitgliedern, bekannt als der „The Mythical Man Month“.
Aber natürlich war Frederick P. Brooks nicht der Einzige, der sich mit diesem Thema auseinandergesetzt hat.
Bewährte Organisationsmuster und deren Beitrag für erfolgreiche Softwareprojekte
Das Buch „Organizational Patterns of Agile Software Development“ von James O. Coplien (aka Cope) und Neil B. Harrison wurde im Jahr 2004 veröffentlicht. Cope hat beachtliche Erfolge als renommierter Informatiker, Softwareentwickler, Autor, Redner und Dozent im Bereich der Softwareentwicklung vorzuweisen.
Neil B. Harrison ist ebenfalls im Bereich Softwareentwicklung als Berater und Autor tätig. Sein Schwerpunkt liegt im Bereich der agilen Methoden sowie den Schnittstellen zwischen Technologie und Geschäftsprozessen.
Beide Experten kommen in ihrem Buch zu folgendem Schluss:
„Bewährte Organisationsmuster sind für erfolgreiche agile Softwareprojekte enorm wichtig. Sie verbessern Effizienz, Kommunikation und Zusammenarbeit in Teams und helfen, agile Praktiken zu optimieren, um bessere Ergebnisse zu erzielen.“
Conway’s Law und der Crazy Code
Bleibt noch, last but not least, Conway’s Law.
Die vermutlich berühmteste und zugleich älteste Nennung in diesem Blogpost. Es stammt aus dem Jahr 1968 und ist nach dem Informatiker Melvin Edward Conway benannt. Zudem findet es auch heute noch regelmäßig Anwendung innerhalb der Softwareentwicklung. Es lautet:
„Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.“
Frei übersetzt: Organisationen entwerfen Systeme, deren Design die Kommunikationsstruktur der Organisation widerspiegelt.
![](https://blog.mayflower.de/wp-content/uploads/2024/05/conways-law.png)
Oder eben: Crazy Company = Crazy Code
Darauf kommt es wirklich an
Vergleich man diese drei Konzepte, weisen sie folgende Übereinstimmungen auf:
Effektive Kommunikation, Zusammenarbeit und geeignete organisatorische Struktur sind für den Erfolg von Softwarelösungen enorm wichtig!
Besonders hinterhältig ist die Tatsache, dass Fehlentscheidungen – seien sie technischer oder organisatorischer Natur – erst Jahre später ihre negativen Auswirkungen zeigen. Der damit verbundene Handlungsbedarf nimmt aber von Jahr zu Jahr zu.
Obwohl diese Erkenntnisse nicht wirklich neu sind, tritt das beschriebene Verhalten nach wie vor regelmäßig auf. Im nächsten Kapitel, gehe ich näher darauf ein, wie man dafür sorgen kann, dass sich dieses Verhalten nicht wiederholt.
Warum Modernisierung scheitert
Ein Leitfaden für Projektverantwortliche
Dieses Whitepaper gibt Dir einen umfassenden Überblick über die wirklichen Herausforderungen der Softwaremodernisierung und zeigt Dir praktische Lösungswege auf. Als besonderes Extra findest Du eine Checkliste, die Dir dabei hilft, die Modernisierung erfolgreich umzusetzen.
Problem erkannt, Problem gebannt – ein Lösungsansatz
Wir wissen jetzt, welche Aspekte bei einem Softwaremodernisierungsvorhaben tunlichst nicht vergessen werden sollten. Aber was genau kann dabei unterstützen, solche Vorhaben von Beginn an mit den richtigen Rahmenbedingungen einzuleiten?
Ein entscheidender Punkt ist sicher, alle unterschiedlichen Aspekte einer Modernisierung nicht als entkoppelte, getrennte Bereiche zu betrachten. Sowohl Technik als auch Kommunikation, Organisation, Flexibilität und Kollaboration spielen bei dieser Gleichung eine große Rolle.
An dieser Stelle kann die agile Arbeitsweise gute Dienste leisten. Betrachten wir die oben genannten entscheidenden Faktoren für den Erfolg von Softwarelösungen separat und was die agile Arbeitsweise in diesen Bereichen ermöglichen kann: Effektive Kommunikation, Zusammenarbeit und eine geeignete organisatorische Struktur.
Kurze Feedbackschleifen, transparenter und offener Austausch, Kollaboration und Teamarbeit, regelmäßige Meetings, Flexibilität, Anpassungsfähigkeit, multidisziplinäre Teams, Förderung von flachen Hierarchien, cross-funktionale Teams, iterative Entwicklung und Anpassung, Kundenorientierung.
Also genau die oben beschriebenen benötigten Grundvoraussetzungen.
Summary
Die Erkenntnis, dass eine Software-Modernisierung nicht alleine von der Wahl und dem Einsatz moderner, passgenauer Technologie abhängt, ist nicht neu. Was natürlich keinesfalls bedeuten soll, dass diese zu vernachlässigen sind. Dafür gibt es genügend Literatur und Erfahrungswerte, die dies belegen.
Und doch wird besonders in der Anfangsphase solcher Vorhaben vergessen, dass unterschiedliche Felder bzw. Bereiche, die es zu berücksichtigen gilt, als großes Ganzes zu betrachten.
Unterstützungsleistung bietet die agile Arbeitsweise. Sie fördert das Zusammenspiel von Technik und Organisation. Dadurch werden Barrieren reduziert und die Basis für erfolgreiche Entscheidungen gesetzt.
Wenn ihr euch für das Thema Softwaremodernisierung interessiert, empfehle ich euch unser Whitepaper zum Thema „Darum scheitern Modernisierungs-Projekte“. Darin erfahrt ihr noch weitere Fallstricke und Abhängigkeiten, die es zu beachten gilt.
Schreibe einen Kommentar