Das beste agile Skalierungs-Framework der Welt: Reden

Bild: Pexels / Christina Morillo - CC0 1.0

In den nächsten Tagen werde ich an einer Podiumsdiskussion teilnehmen dürfen, die den etwas reisserischen Titel "Battle of the Frameworks" trägt. Das Ziel: verschiedene agile Skalierungs-Frameworks nebeneinander zu halten, Vorteile und Nachteile zu vergleichen und wenn möglich herauszufinden welcher Ansatz in welcher Situation hilfreich sein könnte und welcher eher nicht.

In der Vorbereitung habe ich mir durch den Kopf gehen lassen welche der bekannten Skalierungs-Frameworks ich schon im Einsatz gesehen habe und bin auf einige gekommen: Scrum@Scale, LeSS, Nexus, SAFe, (Pseudo)Spotify, Flightlevel-Kanban und einige Hybrid-Modelle aus Agile und Wasserfall waren dabei, alle mit Aspekten die gut funktioniert haben und solchen bei denen das nicht der Fall war. Mir ist aber auch klar geworden, dass ich einen absoluten Favoriten habe - einfach miteinander reden.

Bis zu einer Größe von mindestens fünf Teams kommt man damit erstaunlich weit (und ich kenne nicht viele Fälle in denen mehr als fünf Teams Sinn gemacht haben). Wenn die Produktmanager und Product Owner den gemeinsamen Release zusammengehörender Features planen wollen können sie das tun indem sie miteinander reden. Wenn die Entwickler Coding-Standards und Schnittstellen definieren wollen können sie miteinander reden. Wenn die UX-Designer ein übergreifendes Look and Feel herbeiführen wollen können sie miteinander reden, etc.

Das passiert grundsätzlich zwar auch in allen anderen Frameworks, der Unterschied ist, dass Zeit, Ort und Gruppe dabei reglementiert sind. Planung findet im PI-Planning statt, die Klärung von Abhängigkeiten im Scrum of Scrums, die Erarbeitung von Konventionen in der Community of Practice - für nahezu jedes Anliegen lässt sich ein passendes Format finden, dass dann aber auch Risiken in sich birgt: wenn für ein Anliegen kein Format da ist oder wenn dieses erst zu einem anderen Zeitpunkt stattfindet, dann findet eine Klärung oft nicht statt.

Die Alternative: sobald der Bedarf nach Abstimmung aufkommt kann man einfach zu den Betroffenen hingehen, kann sie fragen ob sie einen Beitrag zum Thema liefern können, wann sie Zeit dafür haben und wen sie sonst noch dazuholen würden. Wenn es soweit ist spricht man miteinander, einigt sich und klärt welche nächsten Schritte zu welchem Zeitpunkt gemeinsam angegangen werden sollen. Und das ist es, mehr als das ist in den meisten Fällen nicht nötig.

Dass dieses verblüffend einfache Modell in der Realität kaum vorkommt hat natürlich Gründe: räumliche Trennung, Überplanung durch zu viele Termine, fehlende Entscheidungskompetenzen, fehlende Einsicht in grössere Zusammenhänge und zu viele Abhängigkeiten. Aber an dieser Stelle gibt es auch gute Neuigkeiten - all das kann man ändern, man muss es nur wollen. Und wenn das geschafft ist kann man alle komplizierten Zusammenarbeitmodelle den Grossprojekten überlassen und sich auf das gemeinsame Reden beschränken.

Making things better for everyone

Es ist ein Thema über das man lange diskutieren kann: gehören "weiche Themen" wie Augenhöhe, Diversität, etc. zur agilen Organisationsentwicklung dazu? Wenn sie dazugehören droht das Begriffsverständnis sehr in die Breite zu gehen, wenn sie nicht dazugehören kann das Folgen für die geistige Beweglichkeit der Belegschaft haben. Einen weiteren Aspekt kann man aus diesem Vortrag von Jill Wetzler mitnehmen: durch ihre diversitätsfördernden Massnahmen zeigen Unternehmen wie offen, datengetrieben oder feedbackorientiert sie sind - oder nicht sind.

Agile Bauprojekte (II)

Bild: Wikimedia Commons / Koma Modular Construction - CC BY-SA 3.0

Manchmal ist es erstaunlich durch welche Artikel besonders heftige Reaktionen ausgelöst werden. Der über agile Bauprojekte gehört definitiv dazu. Das würde doch alles gar nicht stimmen, hiess es mehrfach, das wäre am Thema vorbei und irreführend. Denn: dort ginge es gar nicht um Bauvorhaben im eigentlichen Sinn sondern nur um Renovierungen. Dort wo wirklich neu gebaut würde, da wären agile Ansätze nicht anwendbar. Nun ja. Vermutlich nicht überall, aber das hatte auch niemand behauptet. Grundsätzlich geht es aber sehr wohl, wenn man es denn will und sich auf bestimmte Voraussetzungen einlässt.

Beginnen wir mit der Problem-, bzw. Aufgabenstellung. Unter welchen Umständen könnte es dazu kommen, dass Gebäude in kurzer Zeit aufgebaut, umgebaut, abgebaut und an anderer Stelle neu errichtet werden müssen? Etwa dann wenn ihr Eigentümer häufig umzieht und seine Heimat mitnehmen möchte. Oder dann wenn sich der Bedarf nach Wohn- und Arbeitsraum häufiger ändert. Oder dann wenn es Schwankungen bei der Nutzungsintensität gibt oder unterschiedlich schnellen Verschleiss unterschiedlicher Gebäudeteile.

Sich an diese sich ändernden Gegebenheiten anzupassen wäre zwar mit den klassischen, sprichwörtlich fest gemauerten Baustilen nur schwer möglich, es gibt aber einen anderen mit dem sich diese Herausforderung bewältigen lässt: mit der Modulbauweise. Das Gebäude besteht in diesem Fall aus mehreren vorgefertigten Modulen, die sich je nach Bedarf kombinieren, neu arrangieren, anbauen oder entfernen lassen. Die Bauarbeiten bestehen dann nur noch aus dem Ebnen des Bodens, dem Aufstellen und Verbinden der Module und dem Anschliessen von Rohren und Leitungen.

Agilität wird so in verschiedenen Weisen ermöglicht: bis relativ spät im Baufortschritt können die Pläne angepasst werden. Grösser, kleiner oder anders angeordnet, verschiedene Modifikationen sind möglich. Auch ein schnelles Vergrössern oder Verkleinern fertiger Gebäude ist möglich, etwa wenn die Kinder ausziehen oder wenn in einem gewerblich genutzten Gebäude mehr Arbeitsplätze entstehen oder in einem Wohnheim mehr Zimmer gebraucht werden. Einzelne Module lassen sich austauschen, z.B. wegen Brandschutz, und da jedes Modul auf einen Laster passt kann sogar das ganze Haus versetzt werden.

Soweit die Theorie, aber gibt es das auch in der Realität? Ja, gibt es. Nicht zu oft aber vorhanden und erprobt. Eher selten sind modular aufgebauter Wohnhäuser, die sich bei Bedarf erweitern und verkleinern lassen. Häufiger sind temporäre Häuser, mit denen etwa München oder Brüggen am Niederrhein Wohnraum für zugezogene Studenten schaffen, die am Anfang keine Wohnung finden. Auch während der Flüchtlingswelle 2016 wurden Modulbauten genutzt, etwa in Hannover, Gelsenkirchen, Augsburg und Marburg. Und ein besonderer Fall sind schnell auf- und umbaubare Krankenhäuser in Krisengebieten.

Natürlich lässt sich nicht alles in Modulbauweise bauen. Keller zum Beispiel nicht, und auch andere Begrenzungen bestehen. Was aber klar ist: diese Bauweise ermöglicht grundsätzlich das Übertragen agiler Prinzipien auf den Neubau von Gebäuden. Ob das die jeweils beste Lösung ist muss dann im Einzelfall entschieden werden.

Den Maschinenpark in Ordnung halten

Bild: Wikimedia Commons / Mixabest - CC BY-SA 3.0

Stellen wir uns die folgende Situation vor: eine Firma besitzt zur Herstellung ihrer Produkte eine grosse Produktionshalle voller Maschinen. Diese sehen auf den ersten Blick gut aus, bei näherer Betrachtung finden sich aber zahlreiche Beschädigungen. Keilriemen sind rissig, Schrauben haben gebrochene Gewinde und Verstrebungen sind stark verrostet. Solche Dinge. Die Schäden sind offensichtlich und allgemein bekannt, repariert wird aber nichts. "Dafür ist keine Zeit" heisst es als Begründung, "wir sind voll damit beschäftigt Güter zu produzieren." Was wäre von dieser Firma zu halten?

Nicht viel, wäre die Antwort. Denn selbst wenn die Auftragslage für eine Vollauslastung aller Maschinen sorgt ist eine unterlassene Instandhaltung fahrlässig. Mit zunehmendem Verschleiss wird es schwerer die Schäden zu reparieren, ab einem bestimmten Punkt weiten sie sich aus auf bisher nicht betroffene Teile, irgendwann bricht der Betrieb zusammen und muss in einer langen und aufwändigen Reparaturphase wieder aufgebaut werden - mit Kosten die wesentlich höher sind als es die kleinen Reparaturen zu Beginn gewesen wären.

Und doch ist es so, dass dieses widersinnige Verhalten permanent stattfindet, und zwar in zahlreichen Unternehmen, quer durch alle Branchen. Allerdings gibt es dabei eine Besonderheit: was hier nach und nach verfällt sind keine Maschinen sondern Software. Bugs werden nicht gefixt, schlechte Architektur wird nicht geradegezogen, fehlende Lastfähigkeit wird ignoriert. Die Folgen sind dagegen die selben wie bei der Maschine: die Probleme häufen sich und verstärken sich gegenseitig, bis irgendwann Nichts mehr geht und alles generalüberholt werden muss.¹ Umsatz gibt es in dieser Zeit keinen mehr.

Bereits bei einem sich nicht verändernden System wäre das alles ein Grossproblem, dort wo regelmässig Um- und Ausbauten stattfinden müssen wird es zu einem riesigen. Dort wo intensiver Wettbewerb oder gesetzliche Regulierungen häufige Änderungen erfordern wird die Arbeit an einem nicht gewarteten System das Auftreten von Problemen wahrscheinlicher machen. Es ist wie bei einem Jenga-Turm - es ist nicht mehr die Frage ob eine Modifikation zum Zusammenbruch führt sondern nur noch wann das passiert. Und wenn dadurch Zieldaten verfehlt werden werden die Wettbewerber erfreut reagieren - und die Aufsichtsbehörden verärgert.

Schon in einem stabilen Umfeld macht es also grossen Sinn "den Maschinenpark in Ordnung zu halten", in einem dynamischen ist das erst recht der Fall. Und doch - häufig passiert es nicht. Das kann vielfältige Gründe haben: eine übermässige Focussierung auf kurzfristige Ziele, fehlendes technisches Verständnis der entscheidenden Personen und falsch verstandene Sparsamkeit dürften die häufigsten sein. Das in den grossen Kontext zu setzen und in vernünftigere Bahnen zu lenken muss in solchen Fällen ein vorrangiges Ziel sein. Sonst wird schon bald auch von diesen Firmen nicht mehr viel zu halten sein.


¹Was schlimmstenfalls Monate dauern kann.

Demographie

Bild: Pixabay / Geralt - CC0 1.0

Irgendein Algorithmus ist Schuld. Ohne danach gesucht zu haben hatte ich plötzlich das Video vom Vortrag The Scribe's Oath von Bob Martin auf dem Bildschirm. Es ist mittlerweile über zwei Jahre alt, und nach dem Ansehen möchte ich die englischen Bewertung, "it aged well" vergeben. Was dieses mal bei mir hängen geblieben ist, ist aber nicht der eigentliche Inhalt (eine Art Hippokratischer Eid für Software-Entwickler) sondern eine Nebenbemerkung: ab Minute 17 versucht er nachzuvollziehen wie sich die Gesamtzahl der Software-Entwickler auf der Erde entwickelt und kommt auf einen atemberaubenden Schluss: die Zahl verdoppelt sich alle zwei bis fünf Jahre.

Seine daraus folgende Erkenntnis: solange das so bleibt (und nichts spricht dagegen, dass es sich ändert) wird die Mehrheit der Entwickler immer eine Berufserfahrung von nur wenigen Jahren haben. Man kann das kritisch sehen, so wie Bob Martin es tut, und ethische Richtlinien fordern. Man kann aber auch die Chance darin sehen. Wer erst wenige Jahre im Beruf ist wird in der Regel noch offen sein für Neues, nicht auf Gewohntem beharren, nicht alles so machen wollen "wie immer" und Veränderung nicht als Störung empfinden. Vermutlich ist das einer der grossen, unterschätzten Faktoren dafür, dass agile Ansätze vor allem in der IT entstanden sind und hier auch bestehen bleiben.¹

Weitergedacht bedeuten diese Faktoren aber nicht, dass die "jugendliche Wechselbegeisterung" ein Charakteristikum aller IT-Unternehmen und Abteilungen sind - in kaum einer Firma steigt die Anzahl der Beschäftigten bremskurvenartig an. Ab einer bestimmten Grösse wird kaum noch neu eingestellt, so dass es zu einer demographischen Polarisierung kommt: auf der einen Seite die relativ junge Belegschaft in Startups und Neugründungen, auf der anderen Seite die älteren Mitarbeiter der Firmen die schon in den 80ern und 90ern auf Digitalisierungslösungen gesetzt haben. Selbst in der scheinbar immer modernen IT findet man hier Strukturkonservativismus, Sicherheitsfixierung, Groupthink und ähnliche Phänomene, die häufig zu verkrusteten, bürokratischen Strukturen führen.

Noch einmal weitergedacht ergibt sich für die nächsten Jahre aber ein gegenläufiger Trend. Dort wo IT-Abteilungen in den 80ern und 90ern aufgebaut worden sind steht in absehbarer Zeit ein Generationenwechsel an. Bei manchen Mittelständlern und in vielen IT-Abteilungen von Grossunternehmen sind die Entwickler im Schnitt Mitte bis Ende 50, die nächste Verrentungswelle ist also absehbar.² Da die nächste, bereits in den Startlöchern stehende Generation deutlich jünger sein wird bedeutet das aber, dass die Offenheit für Neues bald wieder deutlich grösser sein wird. Und da die Unternehmen für die gefragten Fachkräfte attraktiv sein wollen werden auch sie nicht umhinkommen das zuzulassen und zu fördern. Die immer zahlreicher werdenden "New Work"-Programme sind Teil dieser Entwicklung.³

Natürlich besteht bei solchen Betrachtungen immer die Gefahr unzulässiger Verallgemeinerungen, trotzdem deuten die Faktoren aber darauf hin: die demographische Entwicklung sorgt dafür, dass die Agile Bewegung sich ständig erneuert, und dass zur Zeit der nächste "Agilisierungs-Schub" auf die IT-Branche zurollt.


¹Ja, es gibt auch junge unflexible Entwickler und alte die hochagil sind. Es geht aber um Mittelwerte.
²Genaugenommen ist es in der IT fast überall die erste.
³Wobei der Unterschied zwischen Agilität und New Work nochmal ein eigenes Thema wäre.

Chaos doesn't cause problems, it reveals them

Alleine das Wort schreckt viele ab - Chaos Engineering, das klingt nach Unordnung, nach Unvorhersehbarkeit und nach Kontrollverlust. Das kann keiner wollen! Das Problem: diese Zustände existieren trotzdem, und zwar überall (solange wir von IT und anderen komplexen Produkten reden). Nora Jones gibt einige Einblicke wie dem begegnet werden kann, wertvoll ist aber vor allem die andere Seite ihres Vortrags: wie sich eine Kultur des Chaos Engineering in einem Unternehmen etablieren lässt.

Kommentierte Links (LII)

• Mark Lambertz - Warum der Begriff VUCA nicht taugt

Für jeden der sich im Umfeld der agilen Frameworks und Vorgehensmodelle bewegt ist das Konzept der Komplexität dauerpräsent. Komplexität wird regelmässig als Ursache, Gegenspieler oder Rahmenbedingung von Agilität genannt, bleibt aber angesichts dieser zentralen Bedeutung erstaunlich unkonkret in der Beschreibung. Mark Lambertz macht sich die Mühe und beleuchtet den Begriff ausführlich von verschiedenen Seiten - und wer mich kennt wird wissen, dass es die Exkurse in die Geisteswissenschaften sind die mir gefallen. Was ich an der Stelle ausserdem interessant finde ist seine Einordnung der über-trivialisierenden Begriffsverwendung in die Kategorie "Beratersprech". Ich selber habe das eher bei autodidaktischen und voreilig selbstsicher gewordenen Kunden erlebt, deren gestrandete agile Pilotprojekte ich aus dem Jammertal herausbegleiten durfte. Letzten Endes ist wohl beides subjektiv.

• Marcus Raitner: Der Hofnarr an der Seitenlinie

  Der Begriff des Hofnarrs reizt mich zwar immer noch zum diskutieren, abgesehen davon hat Marcus Raitner aber recht. Wenn der Scrum Master seine Rolle als Servant Leader so missversteht, dass er im Team und/oder im Unternehmen die unangenehmen Aufgaben übernimmt, ist irgendetwas ordentlich schiefgelaufen. Egal ob als Mini-PMO, als "Teamsekretärin" oder als Dev-Support, das alles sind Varianten einer schlechten Rollen-Interpretation die es so nicht geben sollte. Dass es doch immer wieder dazu kommt hat so viele Gründe wie Varianten, gültig ist aber hier der unsterbliche Satz von Franz-Josef Strauss: Everybody's darling is everybody's Depp.
  

• John Cutler: So You Want to Fix Something?

  Service-Durchsage: John Cutler hat einen neuen Blog mit der skurrilen URL https://cutle.fish. In einem seiner ersten Einträge geht er gleich wieder in die Tiefe und reflektiert was er besser schon früher gewusst hätte um erfolgreiches Change- und Innovationsmanagement zu betreiben. Im Grossen und Ganzen ist es das was der gesunde Menschenverstand nahelegt (zumindest der in agilen Projekten sozialisierte gesunde Menschenverstand). Überschaubare Experimente, Begrenzung paralleler Arbeit, iteratives Vorgehen, nicht alles auf eine Karte setzen. Was aus Sicht eines Agile Coaches ungewöhnlich ist, ist der Ratschlag nicht mit einem speziellen Ansatz identifizierbar zu sein. Der Gegenentwurf zur Fokussierung auf SAFe, Kanban, Scrum, etc.

• Willem-Jan Ageling: How Managers slowly got removed from Scrum

  Das ist interessant - der Anti-Management-Touch den Scrum heute hat war nicht von Anfang an gegeben. Dass es in der Anfangszeit noch eine Übergangsphase mit deutlich erkennbaren Management-Rollen gegeben haben muss ist zwar naheliegend, in welchem Ausmass das der Fall war ist aber im Rückblick bemerkenswert. Ein Satz wie "[The] Management deals with backlog, risk, and release content” würde heute als schweres Antipattern gelten. Auch dass die letzten Spuren der Management-Rollen erst 2011 aus dem Scrum Guide entfernt wurden überrascht, gefühlt hätte das früher der Fall sein müssen. Vor allem sticht aber die Gegenläufigkeit zweier Tendenzen ins Auge: je mehr das Management aus seinen Regeln verschwunden ist, desto erfolgreicher ist Scrum geworden.
  (siehe auch: Ist der Scrum Master ein Manager?)

• Katharin Tai: So geht Widerstand

  Mal wieder ein Blick über den Tellerrand. Wie geht man damit um in einem technologisch hochgerüsteten Überwachungsstaat von der Regierung verfolgt zu werden? Mit einer bis ins extrem getriebenen dezentralen Organisationsform. Dieser Artikel aus der Zeit bietet einen faszinierenden Einblick in die Strukturen der demokratischen Proteste in Hong Kong, die so un-hierarchisch sind, dass es nicht mehr gelingt sie durch die Verhaftung von Führungsfiguren zu schwächen.

Epics

Bild: Wikimedia Commons / Sarah Welch - CC BY-SA 4.0

Zu den Begriffen aus dem agilen Umfeld die immer wieder kontrovers diskutiert werden gehört das Epic. Es gibt zwar in den meisten Fällen die Übereinstimmung, dass es sich dabei um eine grössere Anforderungs- oder Planungseinheit handelt, alles was darüber hinausgeht wird aber sehr unterschiedlich verstanden. Zeit um Klarheit zu schaffen.

Ein Epic ist zunächst nichts anderes als eine User Story die zu gross ist um umgesetzt zu werden ohne vorher aufgeteilt worden zu sein. Wann, wo und in welchem Kontext diese Verwendung entstanden ist lässt sich vermutlich nicht mehr genau klären, bereits 2004 wird diese Verwendung vom Scrum-Pionier Mike Cohn in seinem Buch User Stories Applied aber schon mit grosser Selbstverständlichkeit vorgetragen¹. Aber was ergibt sich aus dieser Bedeutung?

Zunächst, dass Epics genau wie normale User Stories verschiedene Voraussetzungen erfüllen müssen. Sie sollten einen End-to-End-Ansatz verfolgen², in einfacher, verständlicher Sprache geschrieben sein, einen Anwender nennen³, den gewünschten Use Case, bzw. das zu lösende Problem beschreiben und auch nachvollziehbar darstellen welcher Mehrwert neu geschaffen werden soll. Die Gleichartigkeit von User Story und Epic lässt sich bereits daran erkennen, dass die Begriffe sich alleine durch eine Neuschätzung des Aufwandes vertauschen können.

Genau wie im Fall von User Stories ist es auch bei Epics möglich sie durch Zusatzinformationen anzureichern. Das können Akzeptanzkriterien sein, Personas oder Kundenfeedbacks, es gibt aber auch eine Form der Zusatzinformation die Epic-spezifisch ist: die Benennung der an der Umsetzung beteiligten Teams. Wenn das mehrere sind (wofür es verschiedene Gründe geben kann) erleichtert das die Nachverfolgung und Koordination des Arbeitsfortschritts.

Zuletzt ist es noch wichtig, dass Epics in überschaubarer Zeit abschliessbar sein müssen. Ohne die Begrenzung des Scrum-Sprints oder der XP-Iteration ist es ein verlockender Fehler den Rahmen so weit zu ziehen, dass am Ende eher ein Anforderungs-Kategorie als eine Anforderung steht (z.B. "Benutzerverwaltung" oder "Shop". Das ist nicht im Sinn der Idee und sollte vermieden werden.


¹Danke für die Hinweise auf Mike Cohns Buch, allerdings wurde der Begriff dort nicht erfunden oder eingeführt. Auf Seite 6 heisst es "When a story is too large it is sometimes referred to as an epic." Die Verwendung gab es also auch schon früher.
²D.h. es sollte keine ausgelagerten Konzeptions-, Umsetzungs-, (Regressions)Test-, Dokumentations- oder Release-Epics geben
³Anwender ≠ Auftraggeber