agil

Post-Agil


agil · kanban · post-agil

Vor über 15 Jahren wurde das Agile Manifesto aufgeschrieben und hat damit den Grundstein für eine Idee gelegt, die eine ganze Generation geprägt hat. Doch was ist heute noch von der ursprünglichen Idee übrig? Auf der einen Seite haben wir die stark kommerzialisierte SCRUM Fraktion, auf der anderen eine Vielzahl mehr oder weniger ernst zu nehmenden Derivaten, Erweiterungen und verwandten Methodologien. Einige davon werden teilweise als "post-agil" bezeichnet.
Viele Unternehmen spüren die Notwendigkeit, ihre Prozesse effektiver zu gestalten und versprechen sich von agilen Methoden die entsprechende Verbesserung. Allerdings ist es vor dem Hintergrund der o.g. Aspekte nicht trivial, die richtige Methode zu ermitteln.
Wir helfen unsere Kunden dabei, wirklich agil zu werden. Dabei gehen wir unvoreingenommen in die Bedarfsanalyse und beziehen nicht nur die IT in unserer Empfehlung. Nicht selten schlagen wir dabei ein post-agiles Verfahren vor.

Was ist post-agil eigentlich?

Um die Frage beantworten zu können man sich den geschichtlichen Kontext vor Augen führen. Die agile Bewegung wurden zu einer Zeit ins Leben gerufen, als es Gang und Gebe war, Software-Projekte nach dem Wasserfall Prinzip durchzufühen. Oft vergingen Monate, in denen keine einzige Zeile Code geschrieben wurde, sondern "nur" am Design und Architektur der Anwendung gefeilt wurde. Dies ist heute als BUFD (Big Up-Front Design) bekannt. Damals war der Ansatz, Software in kleinen Inkrementen und kurzen Zyklen zu liefern geradezu revolutionär. Insbesondere der Anspruch der XP-Bewegung (Extrem Programming), zu jeder Zeit ein lieferbares Produkt zu haben, stellte in Paradigmenwechsel dar. Aber wie gesagt, das war vor 15 Jahren. In der Zwischenzeit hat sich einiges getan, was zum Aufkommen des Begriffes "post-agil" geführt hat:

  • Kommerzialisierung. Agile Entwicklung ist heute ein Wirtschaftsfaktor. Man muss immer sehr genau hinschauen, gerade wenn große Consulting-Häuser pauschal SCRUM vorschlagen. Oft sind finanzielle Interessen dahinter. Schließlich kann man gut von SCRUM Zertifizierungen, Workshops, Bücher und Tools leben.
  • Begrifflichkeit. In einem anderen Artikel habe ich schon darüber geschrieben. Wenn vor die Wahl gestellt, wer wird sich schon dafür entscheiden, nicht "agil" sein zu wollen. Das Wort alleine impliziert schon eine Verbesserung, ohne die Tragweite des Commitments erkennbar zu machen.
  • Soziale Aspekte. Die Kritik vor allem an SCRUM als führende agile Methode hat auch eine Konnotation, die stark mit der sozialen Entwicklung der Software-Entwickler verwurzelt ist. Vor 15 Jahren waren Software-Entwickler noch mit dem Image des sozial gehandicapten Nerd verbunden, der das Sonnenlicht meidet und sich nur von Pizza und Cola ernährt. Dieses Bild hat sich gewandelt. Software-Entwickler heute sind meist gut situiert, integriert und sie sind, im Gegensatz zur Jahrtausendwende, recht viele. Es ist gesellschaftlich anerkannt, dass ohne uns nichts mehr funktionieren würde. Ohne Software würde kein modernes Auto fahren, kein Licht angehen, keine Heizung heizen, usw. Diese Macht und die Wahrnehmung in der Gesellschaft verändert auch das Selbstbewusstsein in der Branche. Vor diesem Hintergrund kann man vielleicht gut nachvollziehen, dass Programmierer heute Methoden in Frage stellen, die sie zwingen, mit Spielkarten und fiktiven Punkten zu "spielen", um Aufwende abzuschätzen, oder täglich die gleich klingende Formel des Daily Scrums zu rezitieren.
  • Reife des Berufes. Mit der oben beschriebenen Macht und der gesellschaftlichen Anerkennung kommt aber auch eine größere Verantwortung. Und das ist meiner Meinung nach der entscheidende Scheidepunkt, an dem wir heute stehen. Wir sind Teil einer mächtigen, globalen, wirtschaftlich starken und gesellschaftlich anerkannten Industrie. Es wird Zeit dass wir uns entsprechend verhalten. Die Art und Weise wie heute agile Methoden eingesetzt werden, spiegelt diese Werte nicht wider. Es ist nach wie vor möglich, sich nach den Regeln von bspw. SCRUM absolut korrekt zu verhalten und trotzdem keinen entsprechenden Wert zu erzeugen und die Verantwortung nicht zu übernehmen.

Aus diesen Gründen wird der Ruf nach einem "post-agilen" Ansatz immer lauter.

Post-agil: Definitionen

Um es vorweg klar zu stellen, es gibt keine eindeutige Definition des Begriffes "post-agil". Für einige ist "post-agil" lediglich die Anwendung der urspünglichen agilen Werte, wie sie im agilen Manifesto stehen. Dort wiegen:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Andere wiederum haben ein "post-agiles Manifesto" erarbeitet, dieser lautet, vereinfacht ausgedrückt: wenn es funktioniert, tu es. Wenn es nicht funktioniert, lass es. Und dann gibt es wieder Tendenzen, die Idee von post-agil zu kommerzialisieren, wie z.B. Modern Agile. Dabei wird das Konzept auf mehr als nur die Softwareentwicklung ausgeweitet.

The conventic way

Wir glauben, dass es keine "one-size-fits-all" Methode gibt. SCRUM ist nicht die pauschale Lösung für alle Software-Projekte. Jeder Kunde und jedes Projekt hat eine eigene Historie und steht an einer anderen Ausgangsposition. Für ein Unternehmen, das aus einem Wasserfall-Prozess hinauswachsen möchte mag SCRUM die richtige Wahl sein. Für andere, die schon 5 Jahre SCRUM oder Kanban machen mag Programmer Anarchy, Mob Programming oder Extreme Programming eine Alternative bzw. eine Ergänzung sein. Daher lautet unser Credo:

Context over Convention

Wir analysieren den Kontext des Projektes in der Organisation, um darauf aufbauend die richtige Methode vorzuschlagen. Wir führen dieses Prinzip übrigens konsequent auch bis in die Entwicklung weiter. Somit scheuen wir auch nicht die Diskussion über "religiöse" Themen, wie z.B. "muss ich immer einen Test schreiben bevor ich den eigentlichen Code schreibe?" oder "brauchen wir wirklich eine MicroServices Architektur?". Es ist alles eine Frage des Kontextes, egal welche Konventionen gerade "in" sind.

Ops, DevOps, Chaos?


ops · devops · itil · agil · post-agil

Marcelo ist in seinen letzen Blog-Artikeln hier und hier darauf eingegangen, was Agilität bedeutet und welche Auswirkungen das auf Entwicklungsprozesse hat. Bei der Pulsar Solutions verfolgen wir einen Ansatz, der nach DevOps-Prinzip den gesamten Betrieb vom Entwicklungsprozess bis zum Betrieb der Infrastrukturn abdeckt. Ich werde in den folgenden Blog-Posts darauf eingehen, welche Auswirkungen die post-agilen Ansätze auf den Bau und den Betrieb der Infrastrukturen hat und werde anhand einiger praktischer Beispiele zeigen, wie Lösungen dafür aussehen.

Viele Unternehmen haben den Betrieb ihrer Infrastrukturen heute mehr oder weniger vollständig nach ITIL organisiert. Das eigentliche Doing, also der Lebenszyklus der Infrastruktur vom Aufbau bis zum End-of-Life wird dabei allerdings meist noch größtenteils manuell durchgeführt. Das führt dazu, dass Changes in der Infrastruktur häufig nur langsam oder mit verminderter Qualität umgesetzt werden können. Die Dokumentation von Changes wird dazu meist vernachlässigt, da sie als zu zeitaufwändig empfunden wird. Das Ergebnis ist, dass die Infrastruktur in der Praxis durch viele undokumentierte Ad-hoc-Changes nur noch schwierig zu warten ist. Die Auswirkungen von Änderungen können häufig vorab nicht mehr bestimmt werden sondern manifestieren sich erst bei Durchfürung des Changes. Selbst wenn Testumgebungen existieren, so entspricht der Versionsstand nicht mehr dem der Produktivumgebung und die Aussagekraft von Tests geht gegen Null. Die Auswirkungen davon sind teilweise katastrophal.
Wie können wir also den Lebenszyklus der Infrastruktur so gestalten, dass:

  • flexibel auf Ad-hoc-Changes reagiert werden kann
  • Änderungen dokumentiert sind
  • Änderungen mit geringem Aufwand vorab getestet werden können?

In Zeiten von Infrastructure as a Service und Software-defined-everything kann aus meiner Sicht die Antwort darauf nur sein, den Betrieb von Infrastrukturen weitgehend zu automatisieren. Da dann die Definition der Infrastruktur als Beschreibungsdatei im Textformat vorliegt, spricht nichts dagegen, die Infrastruktur in einem Quellcode-Repository analog zur Softwareentwicklung zu versionieren. Wenn das Repository mit einem Issue-Tracking-System verbunden ist, das heißt, Änderungen im Quellcode können mit den zugehörigen Issues verknüpft werden, ist das Problem der Dokumentation von Änderungen nebenbei gleich mit adressiert.

In den folgenden Blog-Artikeln werde ich näher auf die nötigen Komponenten und den Aufbau eines exemplarischen Beispiels eingehen.