Donnerstag, 19. September 2019

Das beste agile Skalierungs-Framework der Welt: Reden

FS
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.

Montag, 16. September 2019

Making things better for everyone

FS
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.


Donnerstag, 12. September 2019

Agile Bauprojekte (II)

FS
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.

Montag, 9. September 2019

Den Maschinenpark in Ordnung halten

FS
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.1 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.


1Was schlimmstenfalls Monate dauern kann.

Donnerstag, 5. September 2019

Demographie

FS
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.1

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.2 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.3

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.


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

Montag, 2. September 2019

Chaos doesn't cause problems, it reveals them

FS
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.

Powered by Blogger.