Agile Methoden erfahren derzeit einen Hype und werden mittlerweile für alle Arten von Projekten eingesetzt. Doch wie funktioniert die Umsetzung in der Praxis wirklich? Die meisten Projekte arbeiten dabei anhand des Scrum-Rahmenwerks. Ursprünglich für die Softwareentwicklung angedacht, wird Scrum in alle möglichen Projekte gepresst und so lange gebogen, bis es passt – Hauptsache, man kann sagen, dass man agil arbeitet. Ein ernüchternder Erfahrungsbericht - der trotzdem Mut macht.
„Agil, alles muss agil sein. Wie gut, dass wir dann nur noch moving targets haben und nichts mehr konstant ist!“*
Diesen Trend beobachte ich derzeit in vielen Projekten. Irgendeinen Hype gibt es immer, und meistens verhält sich dieser wie ein Pendel, das zuerst zu einer Seite stark ausschlägt (alles agil), aber bald zurückschwingen wird und sich dann auf einem realistischen Niveau einpendelt.
Die 4 Stolpersteine bei der Einführung von Agile-Konzepten
Noch schwingt das Agilitätspendel stark zur einen Seite aus. Anlass genug für mich, auf vier kritische Punkte hinzuweisen, die nach meiner Beratungserfahrung die Stolpersteine dieses Themas darstellen:
1. Passt der agile Ansatz zu dem Ergebnis das geliefert werden soll?
Wenn eine Softwareentwicklung inkl. Kunden notwendig ist, umso eher kann dies bejaht werden. Ebenso kann Agil die richtige Wahl sein, falls bei dem Liefergegenstand die Möglichkeit besteht inkrementell vorzugehen.
Meine Beobachtungen dazu sind, dass derzeit die Organisationsform ganzer Unternehmen komplett agil umgebaut werden, anstatt sich auf einzelne Softwarebereiche zu beschränken. Jedoch wird gleichzeitig der agile Ansatz und gerade Scrum zu oft verbogen; in der agilen Community auch als ScrumBut bezeichnet. Dabei geraten jedoch die agilen Werte und Prinzipien aus dem Fokus, welche eigentlich den Begriff „Agil“ seit dem agilen Manifest von 2001 definieren. Scrum ist eine Methode oder auch ein Vorschlag wie agile Prinzipien für ein Projekt genutzt werden können. Bei der Anwendung von Scrum wird allerdings häufig ignoriert, was das agile Prinzip im Kern bedeutet – Ein Beispiel ist die konsequente Ausrichtung an MVP oder non MVP Inhalten.
2. Wird MVP* und non MVP gelebt?
Eine gute Idee ist es inkrementell vorzugehen und die wichtigen (Business) Funktionen erst aufzubauen und diese dann im Markt zu etablieren.
Meine Beobachtungen hierzu sind allerdings, dass keine Klarheit darüber herrscht, was MVP** überhaupt bedeutet. Grundsätzlich geht es hierbei um die Priorisierung der Funktionen, die einem Geschäftszweck dienen und einen Wert erzeugen. Die als wichtig priorisierten Funktionen sollten dann als „Pflicht“ und nicht später als „Kür“ umgesetzt werden. Dabei stellt sich die Frage für wen ist es wichtig? -den Product Owner oder für den Architekten? Doch auch, wenn dieser Schritt geklärt sein sollte, wird dennoch nicht konsequent danach gehandelt. Non MVP Funktionen werden trotz niedrigem Unternehmenswert oftmals so gebogen, dass sie umgesetzt werden müssen.
Das agile Manifest besagt, dass agile Teams Entscheidungskompetenz brauchen und selbstorganisiert sein sollten. Meiner Erfahrung nach wird sich hier allerdings stets alleinig auf den Product Owner verlassen. Product Owner die hier Ihre Rolle bis zum Ende wahrnehmen und deren Aufgabe es ist insbesondere „nein“ sagen zu können, werden entmachtet oder treten gar nicht erst in den Konflikt ein.
Ein neuer Begriff in diesem Zusammenhang ist MMF (Minimum Marketable Feature). Hierbei handelt es sich um Funktion(en), die ich mindestens brauche um ein Produkt vermarkten zu können. Im Gegensatz zum MVP, wobei es eher um schnelles Lernen und Feedback durch den Kunden geht. Der MMF Ansatz bietet somit im Gegensatz zum MVP einen ersten echten Kundennutzen, wenn eben auch nur minimal.
3. Automatisieren und CI/CD?
Einer der Kernpunkte der Agilität: Automatisiertes Testen auf täglicher Basis und die Möglichkeit täglich neu entwickelte Software getestet zu launchen. Das Konzept von Continuous Integration, Development und Deployment kann hier nachgelesen werden.
Das dieses funktioniert habe ich bisher leider noch nicht entdeckt. Das liegt meiner Meinung nach daran, dass zu spät an den Voraussetzungen, die dafür geschaffen werden müssen, gearbeitet wird - oftmals erst, wenn das Projekt schon länger läuft. Dabei gehört das Verstehen und Erlernen der hierzu notwendigen Tools ebenso dazu, wie das Schaffen der Rollenverständnisse und Befähigen von Hauptakteuren (insbesondere Release-/Integrationsmanager, Development Lead, Testing Lead und DevOps).
Man muss eben auch für die Automatisierung Kapazitäten bereitstellen, sowie Zeit und Geld investieren. Die Alternative dazu ist, Manuelles Testen, was dazu auch noch weniger kostet. Andererseits entstehen dadurch oftmals auch Fehler in der Produktion oder Lieferzeiten verlängern sich. Daher muss abgewägt werden, ob sich eine Automatisierung lohnt, da nicht jedes Produkt eine rapide Time-to-Market braucht. Dennoch bin ich davon überzeugt, dass ein möglichst frühes Kundenfeedback in der Entwicklung, z.B. durch Prototyping, sinnvoll ist.
4. DevOps Verständnis und Umsetzung?
Ein weiteres Schlagwort in der agilen Welt ist „DevOps“. Hier werden meiner Meinung nach zu oft lediglich Personen zu DevOps ernannt ohne, dass es dafür einen ersichtlichen Grund gibt, wodurch folglich auch die Umsetzung nur halbherzig erfolgt.
In einer Person die Trennung zwischen Development und Operations aufheben, so wäre meine Kurzdefinition dieser agilen und zentralen Rolle. Der Sinn liegt eben darin, nicht wie in den alten Zeiten, die in einem Projekt von den Developern entwickelten Dinge anschließend dem für die Operation zuständigen Bereich über den Zaun zu werfen und diesen damit den Rest zu überlassen. Wenn die DevOps Rolle richtig angenommen und mit Leben gefüllt wird, können durch dessen Beteiligung bereits in der Entwicklungsphase Fragen und Probleme, welche anderenfalls erst in der Operationsphase auftreten, direkt zu Beginn adressiert werden.
Das konterkarierteste Erlebnis, welches ich hierzu in der echten Welt hatte, waren zwei DevOps Verantwortliche die untereinander abgesprochen haben, dass sich einer um Development und der andere um Operations kümmert. Um solche Fehler zu vermeiden, ist es hilfreich, wenn man sich zuerst mit dem Agile Rahmenwerk beschäftigt und gerade auch am Anfang eine Reifegradmessung durchführt.
Mein Fazit
Agil und DevOps sind keine einfachen Methoden, die man mit Scrum oder der Einführung von Rollen mal eben so einfach „einbaut“. Hier liegen grundsätzliche Prinzipien und Herangehensweisen dahinter, welche häufig eine tiefgreifende Veränderung von bislang eingesetzten Vorgehen erfordern. Richtig und auf die jeweilige Umgebung angepasst sowie mit den entsprechenden Investitionen lassen sich schnellere Reaktionszeiten und höhere Qualität realisieren.
Gerne tausche ich mich mit Ihnen über Ihre konkrete Problematik und dazu passenden Lösungsansätzen aus. One size does not fit all!
*Aussage eines IT Managers eines großen Telekommunikationsunternehmens zur momentan inflationären Nutzung des Begriffes „agil“ in vielen Unternehmen.
**Ein Minimum Viable Product, wörtlich ein „minimal überlebensfähiges Produkt“, ist die erste minimal funktionsfähige Iteration eines Produkts, das entwickelt werden muss, um mit minimalem Aufwand den Kunden-, Markt- oder Funktionsbedarf zu decken und handlungsrelevantes Feedback zu gewährleisten.
