In den letzten Jahren höre ich immer öfter „Wir sind jetzt agil denn wir arbeiten jetzt in Sprints“ oder vor ein paar Wochen traf ich eine Bürokauffrau aus einem Versicherungsunternehmen die mir sagte „Wir sind agil denn wir machen jetzt auch Dailys“
Diese Aussagen bringen mich immer wieder zum Nachdenken und ich frage mich, haben alle das gleiche Verständnis darüber, was denn eigentlich „agil“ ist und warum plötzlich alle denken „agil“ sein zu müssen?
Gibt es hier einen Selbstzweck, also wollen wir einfach so „agil“ sein? Oder wollen wir ein bestimmtes Problem lösen? Oder ist einfach nur der Anspruch unserer Kunden im Zeitalter der Digitalisierung – so stark gewachsen – und damit gleichzeitig auch die zunehmende Geschwindigkeit und Unklarheit der Anforderungen, welche auf IT-Abteilungen zurollen?
Um sich dieser Frage zu nähern, müssen wir uns bewusst, werden welche Art von Arbeit wir erledigen wollen oder welches Problem wir eigentlich lösen wollen.
Um zu verstehen, welches Vorgehensmodell das richtige für die jeweilige Aufgabenstellung oder Tätigkeitsfeld ist, müssen wir uns kurz damit beschäftigen, welche Arten von Arbeit es im IT-Umfeld gibt.
Was sagt Ralph d. Stacey dazu? Ein Wissenschaftler der sich mit der Theorie von Organisationen als komplexe, reaktionsfähige Systeme beschäftigt hat. Oder was sagen Mary E. Boone/Dave Snowden dazu, die sich intensiv mit der Aufgabe beschäftigt haben Probleme, Situationen und Systeme dahinhegend zu analysieren, um ein Modell zu entwerfen, welches Erklärungen oder Lösungen dazu anbieten kann?
Stacey Landscape Diagram
by Ralph D. Stacey
Das Modell von Ralph D. Stacey z.B. unterscheidet in vier unterschiedliche Arten von Arbeit:
1.) simple Arbeit
2.) komplizierte Arbeit
3.) komplexe Arbeit
4.) chaotische Arbeit
Das Prinzip basiert auf der Theorie, dass je unklarer die Anforderung und je unklarer die Technologie oder Methode ist, desto chaotischer das Vorgehen bzw. die Arbeitsweise.
Im Umkehrschluss bedeutet das, je klarer die Anforderung und Technologie / Methode, desto simpler wird die Tätigkeit. Komplizierte- und komplexe Arbeit liegt dann irgendwo dazwischen.
Das bedeutet, dass die Notwendigkeit agiler Arbeitsweisen abhängig ist von der Qualität der Anforderung und das im Team zum Zeitpunkt verfügbare KnowHow bzgl. eingesetzter Technologie bzw. der Methode.
Cynefin Framework
by Mary E. Boone & Dave Snowden
Das Modell geht in eine ähnliche Richtung wie das von Ralph D. Stacey und betrachtet zusätzlich noch Zwischenzustände wie die „Selbstzufriedenheit“ und die „Unklarheit“.
Einfach: erkenne-beurteile-reagiere
Ein Bespiel für einfache Arbeit. Im „On Premise“ Rechenzentrumsbetrieb leuchten die LED der Storageeinheiten rot, sofort ist klar, dass die SSD Platten 1:1 getauscht werden müssen. Über einfache Probleme muss man nicht lange nachdenken. Man erkennt das Problem, beurteilt es und reagiert. Es gibt in der Regel nur eine beste Lösung, die sogenannte „Best Practice“.
Kompliziert: erkenne-analysiere-reagiere
Befindet man sich in einem komplizierten System, braucht man einen Experten. Um bei dem Beispiel des Rechenzentrumbetriebs zu bleiben, fährt ein Server im Rechenzentrum nicht wieder hoch, benötigen wir einen Experten. Dieser Experte gelangt mit oben genanntem Schema zum Erfolg: Er analysiert das Problem, welches viele Ursachen und damit auch Lösungsmöglichkeiten bietet, wählt die passendste Lösung aus und setzt sie um. Schon hier gibt es keine Best Practice mehr, sondern nur noch „Good Practice“: Optionen die jeweils Vor- und Nachteile haben.
Komplex: probiere-erkenne-reagiere
Es starten gerade viele große und innovative Softwareneuentwicklungs-Projekte, große Transformationsprojekte in welchem Monolithen in Microsservices geschnitten werden, jeweils in komplexen Systemen und Umfeldern. Es ist unvorhersehbar und instabil. Es gibt keinen Experten, der mit einer einfachen Analyse zum Erfolg kommt. Bewegt man sich in komplexer Umgebung, muss man Dinge ausprobieren, Experimente machen, auch „Emergent Practice“ genannt.
Chaotisch: handle-erkenne-reagiere
Ein Beispiel für den chaotischen Bereich „Die Produktion steht still“. Es werden sofort Task-Forces gebildet, vorbei an allen Prozessen, es werden schnell außerhalb jeglicher ITIL Prozesse, teilweise nur grob getestete Hotfixes eingespielt um den Betrieb so schnell wie möglich wieder zu gewährleisten. Hier ist es wichtig, dass einer das Heft des Handelns in die Hand nimmt. Darüber hinaus sind kurze & schnelle Entscheidungswege notwendig, um das Problem zu lösen. Mitarbeiter müssen teilweise rund um die Uhr arbeiten, ohne Zustimmung von Betriebsräten oder dergleichen. Für große Diskussionen bleibt keine Zeit, da das Business stillsteht und dieses muss so schnell wie möglich wieder starten. Man kann hier auch von „Novel Practice“ sprechen
Unklarheit: Wenn man nicht weiß, in welchem der Bereiche man ist, läuft man Gefahr, die falsche Vorgehensweise zu wählen.
Selbstzufriedenheit: Manchmal wägt man sich im scheinbar sicheren Bereich, in dem man alles unter Kontrolle zu haben scheint und plötzlich fliegt einem das System um die Ohren. Die Fukushima-Katastrophe kann hier als Beispiel genannt werden.
Im Kern kann man also festhalten, dass eine agile Arbeitsweise nur dann zwingend notwendig ist, wenn man sich in einem komplexen Umfeld bewegt und etwas ausprobieren muss da die Kombination von Anforderungen, Technologie oder Methode unklar und einzigartig ist und keiner damit eine Erfahrung gemacht hat, da es weder Handbücher zum Nachlesen noch klare Handlungsempfehlungen gibt.
Lernende Teams probieren aus, stellen Hypothesen auf, irren sich, machen eine Erfahrung und passen ihre Vorgehensweise an. Wenn Teams also auf Basis von Hypothesen arbeiten und sich irren, dann machen sie per se erstmal keine Fehler. Lediglich wenn sie sich zweimal in derselben Sache irren würden, könnten wir von einem Fehler sprechen. Sich irren ist aber in diesem Kontext auch etwas Positives, weil wir durch den Irrtum lernen und uns weiterentwickeln können.
Es gibt z.B. Softwarewartungsprojekte die teilweise 5-10 Jahre Legacy Code warten und weiterentwickeln, häufig gibt es bei diesen Wartungsteams wenig Fluktuation, d.h. jeder Mitglied des Teams hat sich über die Jahre so ein großes Domain-Wissen über die Applikation aufgebaut und so tiefe Kenntnisse in der verwendeten Technologie gewonnen, sodass jeder im Team sehr gut in die Zukunft planen kann. Hier ist es richtig und zielführend, dass Konzepte geschrieben werden und diese in einem Wasserfall abgearbeitet werden. Diese Teams müssen nicht zwingend iterativ ausprobieren, denn sie kennen Ihr System sehr gut.
Ein anderes Beispiel ist, wenn IT-Verfahren die Version einer Datenbank von x.y auf x.z heben müssen, weil der Datenbankanbieter die alte Version nicht mehr supportet und ein Softwareteam bereits Erfahrung hat, Datenbanken und abhängige Codebestandteile zu erneuern. Auch in diesem Beispiel bewegen wir uns eher in einem komplizierten oder simplen Arbeitsumfeld und müssen nicht zwingend agil vorgehen.
Wenn wir also an dieser Stelle festhalten, dass gerade zu Beginn eines Projektes geprüft werden sollte, mit welchem Vorgehensmodell das Projekt die Aufgaben am besten lösen kann und z.B. die Projektleitung den Vorschlag macht, das Projekt agil zu fahren, haben nicht alle Beteiligten das gleiche Verständnis darüber, wie gut die Qualität der zu Grunde liegenden Anforderung ist.
Das Management sagt: „Ist doch klar was grundsätzlich gemacht werden muss.“ Der Fachbereich sagt vielleicht: “Ist doch klar was in meinem Bereich gemacht werden muss“, dasselbe könnten sicher auch der Betrieb, die Security, die Unternehmensarchitektur und der Operationsbereich sagen. Wie jedoch all diese unterschiedlichen und teilweise widersprüchlichen Anforderungen zusammenpassen, so dass am Ende auch das gewünschte Gesamt-Ergebnis herauskommt, ist zu Beginn eines Softwareprojektes meistens alles andere als klar.
In der IT-Branche existiert gerade dieser „agil Hype“. Alle glauben zwingend agil arbeiten zu müssen. Manchmal kommt es mir sogar vor, als ginge es primär nur um eine Marketingaktion, um praktisch der Außenwelt zu zeigen: „Hey schaut alle her! Wir sind jetzt auch agil“ und damit suggeriert ein Unternehmen dann implizit effizienter, besser oder modern sein zu müssen.
Gleichzeitig gibt es aber meistens innerhalb der Organisation kein agiles denken. Das ist kein Vorwurf an dieser Stelle, sondern viel mehr eine Tatsache. In der agilen Transformation entsteht die Erkenntnis meistens Bottom-Up. Das bedeutet auf Arbeitsebene kommt man schnell zum Erfolg, in den Führungsstrukturen bis zur Geschäftsführung dauert der Prozess oft etwas länger.
Gerade zu Beginn von agilen Transformationen habe ich es erlebt, das Softwareteams sich in wirklich komplexen Umfeldern bewegen und sich zwangsläufig über iteratives Ausprobieren in die Materie reinarbeiten. Wenn dann die Projektpläne, bzw. klassische Projektartefakte aus dem Wasserfall Prozess ausbleiben, bzw. der Prozess nicht ordentlich begleitet wird, kommt ein ungeduldiges Management dazu und fordert von den Teams komplexe Probleme zu lösen, die mit komplizierten Lösungen einhergehen, was nicht funktioniert. Der Wasserfall-Prozess, bzw. das V-Modell ist ein sehr gutes Vorgehensmodell, um komplizierte Aufgabenstellungen zu lösen aber eben keine komplexen.
Für mich der entscheidende Knackpunk – und zwar vom Geschäftsführer über den Abteilungsleiter, bis zum Softwareentwickler. Interessant ist aus meiner Sicht, die Situation in einigen Vorstellungsgesprächen, wenn ich z.B. neue .NET Entwickler oder JAVA Entwickler in einem Bewerbungsgespräch kennenlerne und diese mir die Frage stellen: „arbeitet ihr agil?“, entgegne ich gerne, dass es nicht wichtig ist, nach SCRUM oder KANBAN zu arbeiten, sondern dass es wichtig ist, ob wir agil denken. „Beiing Agile“ anstatt „Doing Agile“. Nur weil viele Organisationen mit „DOING agile“ auf Arbeitsebene versuchen – ein bisschen SCRUM – umzusetzen, heißt das noch lange nicht, dass das Team und damit das die Organisation agil ist.
Wenn wir das richtige Mind-Set mitbringen und die agilen Werte verinnerlichen, dann handeln diese auch so. Agiles Handeln ist harte Disziplin, es gibt keine Code-Heros mehr, es gibt auch keine isolierten Technologie-Experten mehr ohne die nichts geht, sondern das Wissen ist im Team verteilt. Ich als Mitarbeiter folge mit meinem Team einem gemeinsamen Ziel, welches ich inhaltlich verstanden habe und mit welchem ich mich auch identifizieren kann.
Ich bin bereit, mich jeden Tag mit einer neuen Version meiner Selbst dem Team unterzuordnen, mich permanent zu hinterfragen und dabei zu lernen. Nicht ich alleine bin erfolgreich, sondern wir als Team sind erfolgreich, denn nur wir gemeinsam können einen Kundennutzen erfüllen, bzw. ein Business-Problem lösen. Wenn wir als Team und Organisation diese Haltung mitbringen, dann handeln wir auch so.
Wenn Teams ihre Arbeit einer übergeordneten Idee widmen, erzeugt dass Sinn und Zweck und führt wiederum zur Motivation eines jeden einzelnen, da sie sich selbst auch mit der übergeordneten Idee identifizieren können.
Jedes Team kann auf einer Teamebene für ein Softwareprodukt oder für eine Komponente, die beispielsweise ein Produkt unterstützt, eine eigenständige Team-Vision entwickeln und davon Ziele ableiten. Idealerweise gibt es bereits in der Organisation oder im Unternehmen eine übergeordnete Vision, dann können hier die spezifische Produkt- oder Komponentenvision eines Teams einzahlen und ein roter Faden von der Unternehmensführung bis zu den Teams entsteht.
Eine andere Erfahrung, die ich in einem großen IT-Programm gemacht habe, in welchem ich für 13 SCRUM Teams verantwortlich war, geht in eine andere Richtung.
Viele agile Teams verwechseln Agilität mit vollständiger Autonomie, sich an keinerlei Vorgaben halten zu müssen. Sie bestehen darauf, dass der ProductOwner das „Was“ definiert und sie bei der technischen Umsetzung – also beim „Wie“ – tun und machen können was sie wollen. In jedem Unternehmen ob groß oder klein gibt es Rahmenbedingungen, die wir berücksichtigen müssen. In größeren Unternehmen gibt es z.B. ein Enterprise Architektur Management, welches bewusst und unternehmensweit Architekturvorgaben macht mit dem Ziel, das sich die IT-Landschaft nicht in einem Wildwuchs entwickelt bzw. immer zu moderaten Kosten weiterentwickelt werden kann und wartbar bleibt.
Diese übergreifenden Anforderungen sind wichtig und auch zu berücksichtigen, denn ein einzelnes Softwareteam innerhalb eines Unternehmens ist ja nicht allein, sondern hat Einflüsse von außen z.B. Markt, Branche, Kultur und steht immer in einem Kontext zu direkten Schnittstellen wie IT-Operation oder IT-Security.
Ein weiteres Beispiel ist, wie Teams mit dem Thema Clean Code umgehen. Oft scheint die Code-Qualität wichtiger als die Produktivität, bzw. der funktionale-Output des Teams. Wir wollen doch ein Business-Problem lösen und damit den Kundennutzen steigern und nicht in Code-Schönheit sterben. Wenn wir das nicht berücksichtigen, dann laufen wir Gefahr, dass das Projekt irgendwann eingestampft wird, da wir keinen Output bringen. Hier ist also ein Abwägen notwendig, wieviel technische Schuld dürfen und können wir uns leisten.
Dieser Prozess benötige gerade zu Beginn erfahrene Agile Coaches, diese müssen ein feines Fingerspitzengefühl mitbringen. Agile Coaches müssen das DEV Team coachen, ihre Velocity und Qualität zu steigern, aber auch den ProductOwner, sodass dieser gute Anforderungen in Form von Stories erstellt mit klar definierten Akzeptanzkriterien.
Gleichzeitig muss er den intrinsischen Konflikt zwischen DEV Team und ProductOwner moderieren, den das DEV-Team möchte das Produkt in hoher Codequalität in gute Architektur und mit modernsten Tools entwickeln und der ProductOwner möchte maximalen BusinessValue und verlässliche Commitments der DEVs zu den geplanten Sprintergebnissen.
Ein guter Agile Coach oder SCRUM Master sollte „unbequem sein, ohne unangenehm zu sein“.
Agiles Arbeiten z.B. mit SCRUM ist ein Vorgehensmodell, welches immer an die beteiligten Menschen, bzw. an dem jeweils vorhandenen agilen Reifegrad des Umfeldes angepasst werden muss. Agiles arbeiten hat auch etwas mit Vernunft und Augenmaß zu tun, sonst verschrecken wir das Umfeld bzw. die Stakeholder des Softwareteams und das Team selbst.
Diese Art der iterativen Arbeitsweise benötigt aber auch Feedback. Hierbei ist es elementar wichtig, dass in den Reviews die betroffenen Stakeholder anwesend sind und dem Team ein Feedback aus der letzten Iteration geben. Nur dadurch weiß das Team, ob das Sprintziel erfüllt wurde, bzw. ob das, was sie geschaffen haben, von Wert ist. Selten habe ich erlebt, dass der anfordernde Fachbereich oder der Kunde regelmäßig an den Reviews teilnimmt. Als Grund wird dafür dann Zeitmangel bzw. Terminkonflikte genannt, aus meiner Sicht ist es eine Frage der richtigen Priorität.
Ein weiterer wichtiger Punkt ist das Thema Vertrauen. Eine Organisation muss den Softwareteams, bzw. der neuen Art und Weise wie diese inkrementell neue Teile der Anforderungen in Produktionsqualität liefern, zugestehen, dass es gerade am Anfang vielleicht etwas länger dauern darf, langfristig einen funktionierenden Delivery-Prozess aufzubauen, der mit einer verlässlichen Velocity in Qualität, Software liefert. Dieser Vertrauensvorschuss wird das Softwareteam mit Engagement, Flexibilität und Qualität zurückzahlen.
Wenn komplexe Aufgabenstellungen durch agile Arbeitsweise gelöst werden sollen, dann richtig und nicht nur ein bisschen. Die ganze Organisation eines Unternehmens muss bereit sein, sich darauf einzulassen. Agilität braucht Vertrauen, Feedback und etwas Geduld.
Es wäre ineffektiv, einfach lösbare Probleme und Aufgaben agil anzugehen. Anders verhält es sich, wenn die Entscheidungssituation kompliziert, komplex oder gar chaotisch ist. Dann ist es hilfreich, sich vor dem Start eines Projekts bewusst zu machen, welchen Charakter das Vorhaben hat, um sich anschließend für ein mehr oder weniger agiles Vorgehen zu entscheiden.
Wird ein Projekt jedoch unreflektiert agil angegangen, ist die Wahrscheinlichkeit des Scheiterns hoch. Zudem besteht das Risiko, dass die Beteiligten anschließend konstatieren: „agiles Arbeiten funktioniert nicht“.
Agiles Arbeiten setzt also voraus, dass die Projektbeteiligten das Denken verinnerlicht haben: Abhängig vom Charakter eines Projekts und davon, wie klar die Ziele und Anforderungen sowie der Lösungswege sind, ist ein unterschiedliches Vorgehen bei der Projektplanung, -gestaltung und
-durchführung nötig. Dieses Bewusstsein gilt es zu entwickeln.
Für viele C-Level Verantwortliche, die gerade am Start einer agilen Transformation stehen bietet sich damit eine Riesen-Chance. Die Verantwortlichen haben die Möglichkeit mit vielen „Proof of Concept“ Ansätzen Versuchsballone zu starten, um herauszufinden wie Agilität funktioniert und welchen Nutzen ein Unternehmen daraus gewinnt.
Beispielsweise könnte ein Team – mit externem Coaching – agil als DEVOPS Team mit CI/CD Pipelines arbeiten, automatisiert in die Cloud deployen mit automatisierten Tests & Quality Gates. Gleichzeitig werden KPIs definiert und eingeführt, um zu messen, wie sich die Qualität z.B. von Business Value und Kundenzufriedenheit steigert.
Die Verantwortlichen CIOs, CTOs oder CDOs sollten diese „Proof of Concept“ eng begleiten und empowern und können dadurch lernen und überlegen, was von den gemachten Erfahrungen beibehalten werden kann oder für die jeweiligen Aufgabenstellung im Unternehmen angepasst werden muss. Sie könnten ableiten, in welchen Bereichen der Organisation es sinnvoll wäre, nach diesem Modell zu arbeiten und in welchen nicht.
Während diesen Experimenten und dessen Beobachtungen entstünde dann der unternehmensspezifische oder organisationspezifische „Purpose“ und Sie könnten die Frage der Notwendigkeit einer agilen Transformation klar beantworten und damit ihrer Transformation eine Leitidee an die Hand geben.