Die Geschichte aus der griechischen Mythologie ist ein bekanntes Paradoxon: Ein Wettrennen zwischen Achilles und einer Schildkröte. Beide starten zum selben Zeitpunkt, aber die Schildkröte bekommt einen Vorsprung, da sie vermeintlich langsamer ist. Obwohl Achilles schneller ist, wird er die Schildkröte nicht einholen können. Auch im Scrum sind die Schildkröten die Achillesferse, allerdings findet hier kein wirklicher Wettlauf statt und es handelt sich nicht um tatsächliche Schildkröten, sondern um IT-Prozesse.Was nützt jemand, der schnell mauern kann, wenn derjenige, der die Steine anreicht, eine lahme Schildkröte ist?
Scrum beschreibt ja nur einen Teil der IT-Prozesse, nämlich den der Softwareentwicklung, um eine Software erfolgreich einzusetzen benötigt man jedoch auch die angrenzenden IT-Prozesse wie Release-Management, Testmanagement, Service Desk oder Infrastruktur Management. Auch diese Prozesse muss ich „agilifizieren“ oder aber zumindest klare Schnittstellen zu ihnen definieren. Warum das so ist, mache ich gerne an einem Beispiel klar. Wir wollen ein Haus bauen und unser Scrum Entwicklerteam ist ein Maurer, der unglaublich schnell mauern kann. Dieser nützt mir aber nichts, wenn derjenige, der ihm die Steine zum Mauern anreicht eine lahme Schildkröte ist. Der Maurer wird nie in der Lage sein, seine Schnelligkeit ausspielen zu können, sondern die meiste Zeit auf neue Steine warten.
Warum diese Prozesse so wichtig sind in der agilen Entwicklung zeige ich anhand einiger Beispiele. Da der Punkt Infrastruktur managen sehr weit weg von den Entwicklungsprozessen von Scrum zu sein scheint, zeige ich hier mal die erste IT-Schildkröte auf.
Mal eben eine neue virtuelle Testumgebung bestellen? Hardware bei Amazon bestellen, geht schneller…
Folgendes Szenario: Für ein neues Feature benötige ich zwingend eine neue Version der Programmiersprache. Da in der Produktion aktuell diese Version nicht läuft, ich aber bis zu deren Upgrade auch Bugfixes auf dieser Version erstellen muss, muss ich parallel auf verschiedenen Testumgebungen arbeiten. Dauert die Bestellung einer solchen Testumgebung sechs bis acht Wochen, wie ich es schon erlebt habe, kann ich drei bis vier Sprints diese Funktionalität nicht implementieren, obwohl hoch priorisiert und auch genügend Kapazität bei den Entwicklern vorhanden ist. Die schnellste Bereitstellung, die ich bislang bei Banken erlebt habe, war eine Bereitstellung innerhalb von 24 Stunden, aber kaum eine Bank schafft dies. Das Zauberwort an dieser Stelle ist Infrastructure as a Service, kurz IaaS, also die Bereitstellung einer Infrastruktur „per Knopfdruck“.
Die Hardware ist da, aber ich teste nach dem Chinesenprinzip…
Aber bleiben wir mal realistisch und sagen, die Umgebung steht nach sechs Wochen bereit und ich beginne nun dieses Feature zu entwickeln. Jetzt kommt aber mein Testmanager und sagt, ich müsse aufgrund der neuen Version einen kompletten Regressionstest der Anwendung durchführen. Glücklicherweise stehen gerade zehn Fachbereichstester zum Testen bereit. Und falls mich jetzt jemand fragt, in welchem Universum ich lebe, dass zehn Tester „Gewehr bei Fuß“ bereitstehen, das ist eine rein hypothetische und unrealistische Annahme. Aber selbst mit dieser unrealistischen Annahme bräuchte man mindestens zwei Sprints, um die Regressionstests durchzuführen. Damit wäre die Software nicht fertig und damit nicht releasefähig. Viel schlimmer noch, in den zwei Sprints kann ich ausschließlich Bugs in der Produktion fixen und keine neuen Features entwickeln.
Wenn der Releasetrain von Vogonen geleitet wird, renne ich diesem sechs Monate hinterher…
Aber denken wir den Prozess ruhig weiter. Die Regressionstests sind nach zwei weiteren Sprints erfolgreich durchgeführt worden und das Scrum Team sagt stolz, dass die Software nun releasefähig für die Produktion ist. Freudestrahlend begibt sich der Product Owner zum Release Management und möchte seine Software in Produktion bringen. Dieser entgegnet aber nur lapidar, man hätte den Termin zur Anmeldung zum Release leider um eine Woche verpasst und könne erst zum übernächsten Release in sechs Monaten seine Software in Produktion bringen. In solchen Situationen fühle ich mich übrigens häufig an eine Figur aus dem Buch „Per Anhalter durch die Galaxis“ erinnert, den Vogonen: Mies gelaunt, bürokratisch und gefühllos. Geht das eigentlich nur mir so? Um die Kollegen aus dem Release Management mal in Schutz zu nehmen, bei den IT-Prozessen zur Produktivstellung von Software wäre ich auch mies gelaunt, würde mich auf die miesen Prozesse zurückziehen und alle Sonderanfragen rigoros ablehnen.
Von der Entwicklung bis zum Go Life, eine schwere Geburt…
Schauen wir in diesem Beispiel mal auf die Zeitschiene. Zuerst habe ich sechs Wochen gewartet, bis ich die erforderliche Infrastruktur bekommen habe, dann hatte ich in zwei Wochen das Feature entwickelt, um dann weitere vier Wochen auf die Regressionstests zu warten und schließlich 24 Wochen auf die Produktivstellung zu warten. In Summe also 36 Wochen, also neun Monate, für die produktive Nutzung eines Features. In dieser Zeit werden auch ganze Kinder geboren. Natürlich habe ich es in diesem Beispiel ein wenig auf die Spitze getrieben, aber so ganz unrealistisch ist es leider auch nicht. Vielleicht wird jetzt besser klar, was ich mit den Schildkröten meine.
Wie ich die Schildkröte knacke
Das Zauberwort für deren Beschleunigung heißt Automatisierung. Haben Banken bislang immer die Fachlichen Prozesse im Fokus, Stichwort Industrialisierung, rücken mehr die IT-Prozesse in den Vordergrund, da die Produktivstellung neuer Features oder Produkte für den Kunden immer mehr zum Wettbewerbsvorteil wird. FinTechs machen es vor, hier wird nicht nur schnell entwickelt, die IT-Prozesse sind schlank und meistens auch automatisiert. Ziel muss es sein, die Industrialisierung der IT-Prozesse zeitnah zu ermöglichen, um fachliche Prozessänderungen schnell umsetzen zu können. Scrum ist hier nur ein Teilprozess, Fokus müssen aber immer die End-to-End Prozesse sein, genau wie bei allen fachlichen Prozessen. Das heißt ich muss z.B. auch Infrastrukturen, Tests und Deployments bestmöglich automatisieren, um neue Features zeitnah produktiv einsetzen zu können.
Mein Fazit zu IT-Schildkröten-Prozessen: IT-Prozesse sind ein wesentlicher Faktor bei der Anpassung von fachlichen Prozessen, da diese immer weniger manuelle Tätigkeiten beinhalten. Ziel ist es, die IT-Prozesse durch Standardisierung und Automatisierung zu industrialisieren, um sich dauerhaft gut im Wettbewerb aufzustellen. Grenzen sind hier teilweise durch die Regulatorik gegeben. Darauf gehe ich im nächsten Beitrag ein.
#agil #scrum #it-prozesse #schildkröte #industrialisierung #automatisierung #continuusdeployment #iaas #automatisiertestesten #prozessautomatisierung #agileprozesse
Beste Grüße
Andreas Milanese
PS: Wer nicht abwarten kann oder an einer Beratung interessiert ist, darf auch gerne meine Website besuchen unter: http://www.ppi.de/banken/compliance/agiles-projektmanagement/
