Darauf kommt es bei der agilen Entwicklung an

Vor vielen Jahren habe ich einmal eine Masterarbeit betreut, die sich mit dem Verfügbarkeitsmanagement eines großen CRM-Systems (Customer Relationship Management) beschäftigte. Die Lösung bestand darin, aus dem Server-Monitoring ein Service-Monitoring abzuleiten.

Der verantwortliche Student war nicht nur talentiert und fleißig, sondern er war auch frech: So schloss er seine Masterarbeit mit der Aussage, dass seine Lösung nicht praxistauglich sei. Für ihre Umsetzung sei es nämlich notwendig, dass die Architektur­abteilung, die Entwicklungsabteilung und der IT-Betrieb miteinander sprechen – und das sei ausgeschlossen. Deshalb solle man das Content-Relationship-Management-System lieber in mehrere Teile zerlegen.

Was damals nur vorwitzig klang, erscheint heutzutage sogar noch zu wenig radikal gedacht. In den letzten Jahren haben einige Unternehmen sehr erfolgreich auf lose gekoppelte Architekturen mit Microservices umgestellt.

Hierfür haben sie Applikationen mit mono­lithischem Charakter in viele kleine Teile zerlegt, die dafür aber von der grafischen Bedienoberfläche bis zum Datenzugriff alles implementieren. Zusätzlich haben sie ihre Entwicklungsteams einige Aufgaben des IT-Betriebs übernehmen lassen. Im Extremfall führen die einzelnen Entwicklungsteams das Deployment dieser Microservices sogar selber durch.

Ziel und Zweck der skizzierten Umgestaltung der IT ist es, die Time-to-Market zu minimieren. Die Zeit von der Geschäftsidee bis zur Inbetriebnahme der Software-Umsetzung soll möglichst kurz werden.

Erfolgreiche Umsetzungen gehen häufig mit einer Kostenreduktion und einem Wissenszuwachs unter den Mitarbeitern einher, wobei einige der Vorreiter mit der Umgestaltung schlicht ihr Überleben retten wollten, das von explodierender Komplexität bedroht war.

Hinter den neuen Architektur- und Organisationskonzepten steht die Erkenntnis, dass gute Kommunikation in der Praxis sehr schwierig ist. Jede Abstimmung und jede Arbeitsübergabe mehr schafft Potenzial für Verzögerungen, Fehler und Disparitäten.

Nach dem Motto „Tue das, was du schlecht kannst, möglichst selten“ minimiert man die Notwendigkeit, zwischen Teams zu kommunizieren. Stattdessen findet Kommunika­tion, die früher zwischen den Teams geführt wurde, jetzt innerhalb der einzelnen Teams statt. Zum Teil wird sie auch ganz überflüssig, wenn eine Person mehrere Fachaufgaben übernimmt.

Damit dieser Kampf gegen das viele „Kommunizieren-Müssen“ aufgeht, sollten die Teams klein bleiben, nur maximal 15 Mitglieder umfassen und stets für die gleiche Business-Abteilung arbeiten.

Die vergangenen Jahre haben neben spektakulären Erfolgen aber auch gezeigt, dass die beschriebene Umstellung der Firmen-IT per se keine Verbesserungen bringt, wenn nicht auch die notwendigen Voraussetzungen dafür geschaffen werden.

Zu diesen Voraussetzungen gehört unter anderem die Fähigkeit, innerhalb von wenigen Stunden Entwicklungs-, Test- und Produktivumgebungen bereitzustellen. Wichtig ist aber auch die Bereitschaft des Unternehmens, in Projekte ohne Geschäftsnutzen zu investieren, die lediglich die Software-Qualität verbessern. Vor allem aber muss die IT-Abteilung im Unternehmen aufhören, eine Expertenorganisation zu sein.

Mein frecher Student von damals meinte übrigens, dass er erst während der Masterarbeit begriffen habe, dass der Inhalt meiner Vorlesungen tatsächlich stimme. Ursprünglich hätten er und seine Kollegen das vermittelte Wissen lediglich für „reine Theorie“ gehalten. So etwas grämt mich kaum: Im Software-Engineering zählt nicht der Glaube, sondern das Mitdenken und Experimentieren.