Agile / Projektmanagement / Software-Entwicklung

„Wir wollen auch so agil sein wie ihr!“ 4/5

Die Reise zur bimodalen IT – Station 4: Die Erfolgsgeschichten des agilen Vorgehens verbreiten sich sehr schnell – auch andere Teams und Projekte wollen agil werden und schlussendlich die gesamte IT. Anhand der 12 Prinzipien der agilen Software-Entwicklung möchte ich Ihnen die Skalierbarkeit von Agilität näher bringen.

 

Bimodal_Station_4

In kürzester Zeit bekommen Unternehmen, welche die ersten drei Stationen der Reise zur bimodalen IT gemeistert haben, eine neue Herausforderung und diese heißt: das Skalieren der Agilität. Die gleichen Prinzipien, die uns in einzelnen Teams oder in Projekten Orientierung geben, machen das meiner Meinung nach auch in einem größeren Umfeld. Die Reise zur Agilität ist eine Reise der kontinuierlichen Verbesserung und die Werte und Prinzipien aus dem Agilen Manifesto dienen als gute Orientierungshilfe und Leitfaden zugleich.

 

Die Orientierungshilfe

 

1 – „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“ Agile Alliance (2001)

Die Projekte, die mehrere Teams in der Realisierung benötigen, können sich große Vorteile durch kontinuierliche Auslieferung verschaffen. Das kontinuierliche Feedback gemeinsam mit dem Kunden minimiert nicht nur das Risiko ein falsches Produkt zu bauen, sondern ermöglicht klar zu erkennen, „WAS“ der Kunde wirklich braucht.

 

2 – „Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“ Agile Alliance (2001) 

Die Änderungen aus dem Geschäftsumfeld (z.B. Ihr Mitbewerber hat gerade eine neue Version des Produkts auf den Markt gebracht und es droht die Gefahr, er könnte damit Ihre Kunden mit neuen Funktionalitäten weglocken) werden sofort erfasst und im nächsten Sprint implementiert und ausgerollt. Klingt zu gut um wahr zu sein? In der Realität ist es so, dass die agilen Teams, die in Mode 2 operieren, von den anderen Teams gebremst werden, die

  • entweder in Mode 1 sind
  • oder in Mode 2 sind, aber nicht miteinander abgestimmt sind
  • oder in Mode 2 sind, aber die Architektur des Systems enge Kopplung erweist.

In dieser Situation können regelmäßige Abstimmungen und gezielte Architekturanpassungen den Bremsfaktor deutlich reduzieren. Hier hilft einer der wichtigsten Grundsätze im agilen   Vorgehen – die Transparenz. Die Probleme die dem Team/den Teams im Wege stehen, werden gleich und offen  kommuniziert und es wird nach Lösungen gesucht.

 

3 – „Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.“ Agile Alliance (2001)

Wenn zwei oder mehrere Teams – bevorzugt Feature Teams (siehe auch Punkt 11) – an einem Produkt arbeiten und dabei die funktionierende Software regelmäßig ausliefern, bekommen die unterstützenden agilen Praktiken die entscheidende Bedeutung. Einer der Praktiken mit besonderer Bedeutung ist Continuous Delivery. Dieses Thema wurde im Artikel „DevOps oder wie man Agilität in IT Operations bringt 3/5“ näher betrachtet.

 

4 – „Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.“ Agile Alliance (2001) 

Die Fachexpertise darf auch im skalierten Umfeld nicht fehlen. Um das Richtige zu implementieren, müssen die Teams das „WAS“ verstehen. In einem skalierten Umfeld muss dieses Wissen mehreren Teams gleichzeitig zur Verfügung gestellt werden. Wenn die Teams ihre Fragen  nicht rechtzeitig (bzw. umgehend) beantwortet bekommen, erzeugt das nicht nur unnötige Unzufriedenheit, sondern verursacht auch weniger Fragen in der Zukunft, die aber von Wichtigkeit wären! Das Teammitglied könnte zum Entschluss gelangen: „Die Fragen werden sowieso NIE rechtzeitig beantwortet, deswegen frage ich auch nicht mehr“.

 

5 – „Erreichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“ Agile Alliance (2001)

Um die gesamte IT agil zu orientieren, benötigt man Leute die agiles Vorgehen in allen drei Ebenen verstehen:

  • Werte
  • Prinzipien
  • Praktiken

Um die Mitarbeiter auf diesen Wissensstand zu bringen und ihre Arbeitsweise zu verändern, werden Schulungen und Coachings durchgeführt. Das Wissen über Agilität ist kein Garant für den Erfolg, dennoch ist es eine Grundvoraussetzung die leider oft vernachlässigt wird. Die weiteren Voraussetzungen sind hat mein Kollege Robert Finan in seinem Beitrag in „Einstieg in die Agilität 1/5“ näher beschrieben.

 

6 – „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“ Agile Alliance (2001)

Teams die miteinander komplexe Lösungen bauen, brauchen konstante Abstimmung. Eine einfache Möglichkeit ist Scrum of Scrums zu verwenden. Laut „The 9th Annual State of Agile Survey“ der Firma VersionOne (2014) wird genau diese Methode der Skalierung bei 69% der befragten Unternehmen genutzt. Leute regelmäßig zusammenzubringen, um die gemeinsamen Themen der Implementierung zu diskutieren ist eine einfache Vorgangsweise Problemsituationen vorzubeugen.

 

7 – „Funktionierende Software ist das wichtigste Fortschrittsmaß.“ Agile Alliance (2001)

Große Unternehmungen bringen die Gefahr mit sich Plantreue mit Fortschritt zu verwechseln. Pläne sind hilfreich, um das eigentliche Ziel des Projekts zu erreichen, um ein Produkt oder ein Service zu liefern. Aber die Pläne selber sind nicht ausreichend, um den Fortschritt zu verfolgen, man braucht einfach „funktionierende Software“. Pläne sind notwendig, sollten aber nicht zu sehr in den Mittelpunkt gerückt werden.

 

8 – „Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.“ Agile Alliance (2001)

Entwicklung in einer skalierten Umgebung erfordert eine gewisse Stabilität in Sinne der Planbarkeit. Agilität bedeutet nicht, dass man nicht plant – ganz im Gegenteil – geplant wird sogar oft mehr und das auf mehreren Ebenen. Um die Stabilität zu erreichen, ist ein gleichmäßiges Arbeitstempo eine der Voraussetzungen. Eine stabile Geschwindigkeit hilft nicht nur die Leute vor einem Burn-out zu bewahren, sondern hilft auch bei der High-level Planung, wie zum Beispiel der Release-Planung. Dies ist gerade fürs Management eine enorme Umstellung, der viel Aufmerksamkeit gewidmet werden sollte. Man muss dem Management Alternativen zu herkömmlichen MS-Project Plänen oder Power Point Statusberichten näher bringen, z.B. durch Trendlinien.

 

9 – „Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.“ Agile Alliance (2001)

Mode 2 stellt große Ansprüche an die ganze IT Organisation. Die Geschwindigkeit und die Qualität der Entwicklung braucht eine solide technische Basis. Um diese zu erreichen ist eine bewusste Ausrichtung am technischen Erfolg von agilen Praktiken erforderlich, wie sie auch in „Scrum: Verbesserungen durch agile Praktiken 2/5“ beschrieben wird.

 

10 – „Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.“ Agile Alliance (2001)

Meiner Meinung nach sollte man dieses Leitmotiv in jedem Working Agreement wiederfinden. Eine Strategie für große Projekte ist es „einfach“ zu teilen. Die Teile sind kleiner und als solche auch einfacher zu implementieren. Warum ist das wichtig? Weil die Komplexität eine nicht lineare Beziehung mit der Größe hat. Diese Beziehung wird von Weinberg „Size/Complexity Dynamic“ genannt: „Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the program.“ Size/Complexity Dynamic, Weinberg (1992).

 

11 – „Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.“ Agile Alliance (2001)

Selbstorganisierte Teams, die in der Lage sind ein komplettes, kundenorientiertes Produktinkrement zu bauen, haben auch Mitglieder mit allen dazu notwendigen Fertigkeiten. Wir nennen solche Teams „Feature Teams“. Solche Teams habe nicht nur die Befähigung um das „WIE“ zu bestimmen, sondern übernehmen auch die volle Verantwortung für die erfolgreiche Umsetzung. Und was passiert, wenn etwas nicht funktioniert? Dann wird etwas Neues gelernt und im nächsten Implementierungszyklus wird das ganze System um ein Stück besser sein. Skalieren wir das auf mehrere Teams wird das ganze Potential des Lernens für das Unternehmen deutlich ersichtlich.

 

12 – „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“ Agile Alliance (2001)

Mit mehr als einem Team bekommt die Retrospektive eine neue Dimension. Die Teams fragen sich, wie sie ihre Zusammenarbeit verbessern können. Die Antworten werden zu Experimenten, die im nächsten Lernzyklus validiert werden. Das Wort „Teams“ könnte man hier auch mit der IT oder mit dem ganzen Unternehmen austauschen. Dasselbe Prinzip wird angewandt: betrachten was funktioniert hat und was man hätte besser machen können.

Navigationssysteme

Änderungen sind nicht leicht, Änderungen in größeren Systemen sind noch schwieriger. Um den Mode 2 auf die gesamte IT auszurollen, wird die Unterstützung des gesamten Unternehmen vorausgesetzt – und hier verstehe ich gleichermaßen die Unterstützung vom Top Management und den Basis-Produktiveinheiten (= Teams).

Wo kann man Hilfe finden?

Es gibt mittlerweile mehrere Frameworks die Hilfestellung bieten. Wenn die Prinzipien als die Orientierungshilfe genommen werden können, sind die Frameworks mehr oder weniger eine Ansammlung von kontextabhängigen Verfahren der skalierten Agilität. Die Anwendung eines konkreten Frameworks wird erst dann empfohlen, wenn die konkrete Situation des Unternehmens (oder der IT) ausreichend analysiert wird.

„9th Annual State of Agile Survey“ von VersionOne (2014) listet folgende Methoden des Skalierens (die Liste ist 1:1 aus dem Report übernommen worden, ohne Übersetzung):

  • Scrum/Scrum of Scrums
  • Internally created methods
  • Scaled Agile Framework (SAFe)
  • Lean management
  • Enterprise Agile
  • Enterprise Scrum
  • Agile Portfolio Management (APM)
  • Disciplined Agile Delivery (DAD)
  • Large-Scale Scrum (LESS)
  • Recipes for Agile Governance in the Enterprise (RAGE).

Zusätzlich findet man auch folgende Anwendungen und/oder Methoden:

  • Scaling Agile @ Spotify
  • Scaled Professional Scrum (mit Nexus Framework).

 

Fazit

Ein funktionierender Mode 2 auf Team-Ebene ist eine Voraussetzung für Mode 2 auf der Geschäftsbereichsebene. Er bietet viele Feedback-Möglichkeiten der Korrektur und ein einfaches System zu wissen, ob man das Richtige tut auf die richtige Weise. Die Feedbackzyklen bei Produkt- und Prozess-Reviews sind die Basis des empirischen Prozesses.

Ich möchte an dieser Stelle auch auf folgendes aufmerksam machen: die großen Systeme oder Vorhaben zeigen nicht lineares Verhalten (z.B. das was vier Leute im Team produzieren können, würde man mit acht Leuten nicht ohne zusätzlichen Maßnahmen duplizieren können). Das Problem mit großen Systemen ist, dass man leichter auf „Scaling Fallacy“ reinfallen kann: „Large systems are like small systems, just bigger. (NOT)“ Weinberg (1992).

Umso wichtiger ist es mit empirischen Prozessen, die einer der wichtigsten Rahmenbedingungen des Modes 2 sind, das kontinuierliche Überprüfen und Anpassen in der IT zu etablieren. Die empirischen Prozesse verbinden Theorie und Praxis auf eine Art, die es uns ermöglicht, in kurzen Intervallen Experimente zur Verbesserung zu gestalten.

 

Referenzen

Weinberg, G.M. (1992) Quality Software Management, Volume 1 Systems Thinking, New York, Dorset House Publishing

 

Veranstaltungstipp:
25. ANECON Expertenfrühstück | 29.03.2017

„Zellteilung im agilen Umfeld – so gelingt natürliches Wachstum!“
Anmeldung & Programm: www.anecon.com/ef25

 

Blogreihe „Die Reise zur bimodalen IT“:

Passende Artikel

Kommentare gesperrt.