Das Manifest für Agile Softwareentwicklung hatte ich vor 12 Jahren unterzeichnet. Aus meiner Sicht als Softwareentwickler war das dort niedergeschriebene eine sehr natürliche Sicht darauf, wie man in einem Team Software entwickeln und erhalten sollte.
Seitdem habe ich diese Grundsätze in all meinen Engagements, so gut es ging, etabliert.
Ich habe dies auf viele verschiedene Arten getan, denn Menschen, Technologien, Budgets und Produkte waren immer unterschiedlich. In den meisten Fällen hat sich die Zusammenarbeit im Laufe der Zeit entwickelt. Es gab nie eine Situation, in der ich einfach einen Standardprozess, ein Regelwerk und ein Werkzeug hätte nehmen und es so lassen können. Mein beruflicher Weg bisher war eine kontinuierliche, gemeinsame Reflexion über “ist das was wir tun von Wert?” oder “sollten wir was verbessern, optimieren”?
Ich hielt es für eine gute Idee, für alle an der Produktentwicklung Beteiligten, nicht nach Perfektion zu streben, sondern nach kontinuierlicher Verbesserung.
Dazu war es erforderlich, regelmässig innezuhalten und über die eigenen Arbeitsergebnisse, sowie über die eigene Arbeitsweise und die des Teams nachzudenken. Und wie alles zusammenhängt. Es gab dabei immer eine Akzeptanzkurve in jedem Team, die sich über Monate und manchmal sogar Jahre erstreckte. Und es war immer spürbar, wenn der Effekt eintrat. Das Team war dann mehr als die Summe seiner Mitglieder.
Teil eines Teams zu sein, in dem sich alle dafür einsetzen, ein großartiges Produkt zu entwickeln, schafft eine starke Vertrauensbasis. Neben der eigentlichen Entwicklung von Software interessierte mich daher auch schon immer, wie sie entsteht. Denn meiner Meinung nach hängt beides untrennbar miteinander zusammen.
Aber ebenso oft scheiterte mein Ansatz und ich kämpfte. Weil die Beteiligten Agile Verfahren überhaupt nicht etablieren wollten und lieber bei Projektmanagement / Wasserfall / RUP bleiben wollten, vor allem, weil es sich sicherer anfühlte. Oder sie wollten dieses moderne Agile Ding irgendwie auch haben, aber nicht, was damit einherging.
Vertrauen zu investieren, Führen durch Dienen oder Fehler gemeinsam zu erkennen und lösen, Scheitern im Team aufzuarbeiten, statt Schuldzuweisungen zu pflegen, ist eine große Anforderung für viele und oft eine unmögliche Änderung der Einstellung eines Unternehmens.
Heutzutage ist das agile Arbeiten im Mainstream angekommen. Jedoch hat nicht jedes Unternehmen seine DNA entsprechend verändert. Wir sehen bereits eine riesige und wachsende Zahl von Unternehmen, die mit falsch verstandener Agilität zu kämpfen haben, wie Martin Fowler in seinem Artikel “The State of Agile Software in 2018” beschreibt.
Es dauerte nicht lange, bis sich die ersten Anti-Agile Bewegungen entwickelten. “Programming, Motherfucker!” oder das “Manifest für halbherzige Agile Softwareentwicklung” deuten darauf hin, dass die Menschen sich bereits von dem, was als Verhaltenskodex begann, gestört und behindert fühlen. Und, statt gemeinsam Qualität zu liefern, in ein anderes lästiges Produkt der Beratungsbranche hineingedränt werden.
Wie ist das passiert?
Trauma #1: Agilität als Produkt
Ein grundsätzliches Problem liegt meines Erachtens schon im Begriff der “Agilität”. Agilität ist das Ergebnis. Kein Verfahren.
Sie ist das Ergebnis von vielen kleinen Maßnahmen und auch Sichten, auf die man sich als Unternehmen verständigt.
Doch bei allen anderen guten Bewegungen in der Vergangenheit, ist mit der agilen Bewegung ein Industriekomplex entstanden, der Prozesse und Werkzeuge über die Menschen stellt, um sie zu einem verkaufsfähigen Produkt zu machen. Die Illusion, dass die Menschen nur einen bestimmten Prozess lernen müssen und dann so schnell und cool sind wie all die smarten Internetunternehmen, brachte ein profitables Geschäft hervor.
Im Falle von Agilität ist dies im Grunde sehr schädlich, da es die zentrale und wesentliche Idee völlig ignoriert.
In der agilen Bewegung geht es um Menschen, die um ein Produkt herum organisiert sind und sich darauf einigen, wie sie zusammenarbeiten wollen, um ein gleichbleibendes, qualitativ hochwertiges Ergebnis zu erzielen. Dann treffen Sie Entscheidungen darüber, welche Routinen und Werkzeuge sie unterstützen können. Und stellen das regelmässig wieder in Frage.
Es geht darum, ein Team letztendlich für sein Ergebnis verantwortlich zu machen – ein überzeugendes, hochwertiges und immer relevantes Produkt.
Es ist keine einfache Herausforderung, aber auch keine akademische. Und es ist nichts, was ein Unternehmen im Grunde genommen nicht aus eigener Kraft erreichen könnte.
Aber noch wichtiger – all das kann (und sollte) nicht aus dem Regal gekauft werden. Agilität zu erlangen bedeutet für die meisten heute – mieten Sie einen Scrum Master, besuchen Sie einige Konferenzen und Sie sind fertig. Transformation abgeschlossen, zurück zur Normalität.
Die Wahrheit ist: Diese Sicht- und Vorgehensweise wird mehr Chaos anrichten und Kopfschmerzen bereiten, als das Festhalten an traditionellen, bereits etablierten Methoden.
Trauma #2: Agilität in feindlichen Umgebungen
Agile Prinzipien sind für Geschäftsmodelle gedacht, bei denen ein Softwareprodukt oder eine Dienstleistung häufig in kleinen Schritten umgestaltet wird, um stets die Markttauglichkeit zu gewährleisten oder sogar weitere Märkte zu erschließen. Agilität kam von und für Unternehmen, die ein stets relevantes Produkt erhalten wollen, das schnell auf Marktveränderungen oder -chancen reagiert. Um dies zu erreichen, benötigten sie eine vorausschauende und wachsame Kultur, um jederzeit Chancen und Risiken zu sehen und in der laufenden Produktentwicklung zu berücksichtigen. Oder kurz: Kontinuierliche Verbesserung.
Diese Kultur bringt ein generatives Unternehmen hervor, das genau das Gegenteil von einem Unternehmen ist, das nur seine Geschäfte verwaltet und opportunistisch agiert. Und obwohl dieser Unterschied klein aussieht, schafft er die Voraussetzungen für den Erfolg der Anwendung agiler Prinzipien.
Diese Organisationen, die Bestehendes schützen und verändern, wenn das Alte nicht mehr funktioniert, mögen in den ersten Tagen generativ gewesen sein, haben aber im Laufe der Zeit eine bürokratische oder gar pathologischeKultur entwickelt.
Dies ist nichts, was mit agilen Methoden im ersten Schritt geheilt werden kann. Noch schlimmer ist, dass der Versuch, Agilität in einer solchen Umgebung zu etablieren, entweder ein schreckliches Durcheinander verursacht oder Widerstand und Lethargie erhöht. In diesem Fall sprechen wir von einer feindlichen Umgebung, weil die zugrundeliegenden Prinzipien vom Unternehmen nicht begrüßt und antizipiert, sondern verdrängt werden.
Aber die Beratungsbranche verkauft Agilität als Produkt immer noch so gut, dass jeder es will. Softwareentwickler, die nicht den Anschluss verlieren wollen, Führungskräfte, die meinen, das man es jetzt halt so macht.
Agile Prinzipien eignen sich gut für Unternehmen, die generativ aufgestellt sind. Sie handeln proaktiv, nicht reaktiv.
Sie handeln, um im Markt zu bleiben, nicht um einzelne Konkurrenzkämpfe zu gewinnen. Diese Unternehmen handeln nicht in einer unterwürfigen “Der Kunde ist König” Haltung, sondern entwickeln ihre Produkte oder ihr Leistungsangebot immer einen Schritt voraus.
So ist das Geschäftsmodell und die Art und Weise, wie es umgesetzt wird, das erste, worauf man bei der Entscheidung für Agilität achten sollte.
Wie werden das Geschäftsmodell, die Dienstleistungen, die Kommunikation, die Lieferung, die Finanzierung, von einem agilen Ansatz profitieren? Wie sollte es angepasst werden, um die volle Wirkung der Agilität auszuschöpfen?
Wenn sich die Beratungsbranche auf die eigentliche Herausforderung für das Unternehmen konzentrieren könnte – wie man ein bestehendes Geschäftsmodell an diese grundlegend andere Art der Zusammenarbeit anpasst – könnte das viele Barrieren durchbrechen und echte Auswirkungen zeigen.
Was bedeutet agile Entwicklung für die Bereitstellung von Produkten oder Dienstleistungen? Wie sollten Umsatzströme, Prognosen, Vereinbarungen mit Kunden oder umliegende Prozesse darauf abgestimmt sein? Was ist der neue Verhaltenskodex innerhalb des Unternehmens für die Markteinführung eines Produkts in Bezug auf Vertrauen, Misserfolg, Wachstum und gemeinsame Überzeugungen?
Trauma #3: Kein Wechsel zu einer agilen Architektur
Ich habe bereits erwähnt, dass Agile in reaktiven Geschäftsmodellen nie seine volle Wirkung entfalten wird. Gleiches gilt für die Architektur und der Technologiestack einer Softwareplattform.
Fragile Software, die sorgfältig geändert werden muss, der Bedarf an Spezialisten, schwer zu handhabende Komplexität, unübersichtliche Abhängigkeiten, seltene und große Releases – das alles schafft keinen Raum für Agilität.
Bei Agile geht es im Kern um die Entkopplung. Rekombinierbare Macro- und Microservices, Containerisierung, API’s – all das wurde entwickelt, um die Unabhängigkeit zwischen Einzelpersonen und Teams, die an einem Produkt arbeiten, weiter zu erhöhen. Das Ergebnis ist eine Softwareplattform, die deutlich schneller und weniger kritisch auf Veränderungen und Chancen reagieren kann.
Eine Nebenbemerkung: Eine Anwendung oder Plattform mag in Services getrennt worden sein, aber wenn sie so eng gekoppelt sind, dass sie aus Sicht der Codierung, Technologie und Bereitstellung nicht unabhängig voneinander sind, ist es immer noch ein Monolith.
Ein verteilter Monolith zwar, aber ein Monolith.
Trauma #4: Agile Projekte
Die agile Entwicklung von Produkten und ein Projekt verfolgen unterschiedliche Ziele. Und doch habe ich agile Teams gesehen, die an ein zentrales Projektmanagement-Büro berichten. Wie geht das zusammen?
Ein solches Modell kann durchaus funktionieren für ein Unternehmen, das bereits alle Routinen und Berichtslinien auf das Handling von Projekten installiert hat und so – auf der Ebene des Investments – die zugrundeliegende Initiative steuert. Solange das Projektmanagement die eigentliche Produktentwicklung nicht stört.
Warum?
Ein Projekt schafft die falschen Voraussetzungen für die Planung und Ausführung von komplexer und schwer vorhersehbarer Arbeit.
Es ist paradox: Softwareentwicklung soll zu einem wirtschaftlich wertvollen und nachhaltigen Ergebnis führen, während die Authoritäten in einem Unternehmen es lediglich beenden wollen. Makellos, innerhalb des geplanten Zeit- und Kostenrahmens, so schnell und kostengünstig wie möglich.
Erfolgreiche Softwareentwicklung bedeutet, kompakt anzufangen und sich von dort aus kontinuierlich zu verbessern. Anstatt die Lösung vorher komplett zu planen und dann “fertigzustellen”.
Wie hier die Aufgabe Vorhersehbarkeit gelöst werden kann, bespreche ich in einem zukünftigen Artikel. Wenn man sich schon mal vor Augen führt, dass ein Projektmanagement ab einer gewissen Komplexität ebenfalls keine belastbaren Vorhersagen machen kann, ist das eine gute Verständnisgrundlage.
Trauma #5: Falscher Geiz
Der grösste Drang nach Agilität entsteht oft in den festgefahrendsten Projekten. Dort, wo eine Software schon seit Jahren lediglich noch in der Wartung läuft und jede Erweiterung vom Kunden beauftragt werden muss und letztlich auch direkt durch ihn finanziert wird. Das Produkt wird gut angenommen, der Kunde meckert ab und an mal rum, bezahlt aber letztlich doch seine Rechnungen. Hier gewöhnt man sich schnell an den extrem guten Deckungsbeitrag und nutzt dies nicht selten, um andere finanzielle Fehlentscheidungen zu kompensieren.
Daher steckt hier auch oft der grosse Irrglaube, man könne das bestehende Team nur agil machen und schon ist das Thema erledigt.
In einer solchen Umgebung nun agile Methoden, nebst den entsprechenden Werkzeugen für Continuous Delivery und Containerisierung etablieren zu wollen, ist allerdings erstmal ein grosses Invest.
Warum?
- Ein festes Team zu etablieren, statt die Mitarbeiter ständig zwischen den verschiedenen Projekten hin und her zu schieben, kostet Überwindung.
- Die zusätzliche Zeit für die erforderlichen Routinen und das ständige Lernen zu investieren, halbiert erstmal gefühlt die Produktivität eines Teams
- Die Kosten für den Aufbau einer Auslieferungsumgebung und die Änderungen in der Architektur stehen auch erstmal keinem direkten Deckungsbeitrag gegenüber
In all diesen Punkten steckt sehr viel Ungewißheit für die allermeisten Verantwortlichen, die an solchen Stellen über solche Maßnahmen und deren Budgets entscheiden müssen.
Agilität bekommt man nicht umsonst. Die Komplexität steigt, die Kosten steigen, die Ungewißheit steigt.
Immerhin steht all dies diesmal in direkten zeitlichen Bezug zu konkreten Maßnahmen und formt sich nicht im Hintergrund über die Jahre zu einem gewaltigen Problem, dass dann ein Change Projekt benötigt oder im schlimmsten Fall das Unternehmen beschädigt.
Zusammenfassung
Ein Unternehmen wird nicht agil, weil ein Team Softwareentwickler anfängt in Sprints zu arbeiten.
Es fängt damit an, dass das Unternehmen, oder auch ein Geschäftsbereich seine Leistungen oder Produkte generativ baut, statt sie reaktiv zu verwalten und entsprechende Investitionen plant und ausführt.
Verpflichten Sie sich, ihren internen und externen Kunden kontinuierlich ein großartiges Service- oder Produkterlebnis zu bieten. Immer besser als gestern.
Dann fangen Sie an, Veränderung als einen kontinuierlichen Ansatz und intrinsischen Charakter Ihres Unternehmens zu sehen. Und nicht als etwas, das man angeht, wenn es erforderlich ist.