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.

Freitag, 30. August 2019

Kommentierte Links (LII)

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

Montag, 26. August 2019

Epics

FS
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 vorgetragen1. 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 verfolgen2, in einfacher, verständlicher Sprache geschrieben sein, einen Anwender nennen3, 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.


1Danke 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.
2D.h. es sollte keine ausgelagerten Konzeptions-, Umsetzungs-, (Regressions)Test-, Dokumentations- oder Release-Epics geben
3Anwender ≠ Auftraggeber

Donnerstag, 22. August 2019

Andon

FS
Bild: Pxhere - CC0 1.0
Zu den grossen Inspirationsquellen für jeden der seinen agilen Prozess verbessern will gehört zweifellos das Toyota Production System (TPS). Selbst wenn es ursprünglich für die Industrieproduktion von Autos vorgesehen war enthält es zahlreiche Elemente, die auch in der Software-Programmierung oder Wissensarbeit von Nutzen sein können. Eines dieser Elemente ist das so genannte Andon (行灯, übersetzt rote Laterne, bzw. Papierlaterne).

Unter diesem Begriff versteht man Systeme oder Prozesse mit denen ganze Produktionsketten (in der Regel Fliessbänder, aber auch alles andere) schlagartig zum Stillstand gebracht werden können sobald ein Fehler auftritt. In den meisten Fällen erfolgt das durch Zugschnüre oder grosse Druckknöpfe (auch bekannt als Toyota-Buttons) die überall entlang der Fertigungsstrassen zu finden sind. Im weiteren Sinn gehören auch Signaltöne und Datenerfassungssysteme zu den Andon-Installationen dazu.

Bemerkenswert sind an diesem Konzept vor allem zwei Aspekte. Zum einen wird das Wesen eines Fehlers hier anders verstanden als üblich. Der Fehler ist nicht mehr die Beschädigung oder Minderwertigkeit des "fehlerhaften" Produkts sondern die Dysfunktion des vorhergegangenen Herstellungsprozesses. Dementsprechend folgt auf das Anhalten der Produktionskette auch eine Neukonfiguration des Prozesses und nicht eine Reparatur des Produkts (die soll überflüssig werden).

Zum anderen sind die Zugschnüre oder Druckknöpfe nicht nur überall angebracht sondern auch für jeden zugänglich - und es hat auch jeder die Berechtigung sie zu benutzen. Darüber hinaus ist ihre Benutzung auch prinzipiell nicht mit negativen Folgen verbunden, auch dann nicht wenn der Produktionsausfall auch Gewinnrückgänge nach sich zieht. Es soll alles vermieden werden was von ihrer Benutzung abhält, damit nichts der Idee einer möglichst fehlerfreien Auslieferung im Weg steht. Die Idee dahinter: der langfristige Nutzen ist weit grösser als ein kurzfristiger Verlust.

Übertragen auf die Softwareentwicklung wären vor allem die Tolerierung "unkritischer Bugs" oder die dauerhafte Durchführung zu vieler (potentiell fehlerhafter) manueller Prozesse Gründe für das Auslösen eines Andon-Systems. Da derartige Verhaltensmuster fast immer die Durchführung von langen, nachgelagerten Regressionstest- und Bugfixing-Phasen zur Folge haben verhindern sie die kontinuierliche Auslieferung von Geschäftswert und sind damit kritisch genug für einen Produktionsstop.

Das Gegenargument ist an dieser Stelle das selbe wie in der Fabrik: "Aber damit verhindert man doch das Einhalten der Produktionsquote, bzw. der Deadline!" Allerdings ist das nur bedingt richtig. Wenn zwar die Menge und das Zieldatum stimmen, die Arbeitsergebnisse aber defekt sind, dann ist der Erfolg nur ein scheinbarer. In Wirklichkeit sind Kosten und dauer sogar höher, sie werden nur in späteren Phasen versteckt.

Um das nicht geschehen zu lassen macht ein roter Knopf an jedem Arbeitsplatz absolut Sinn.

Montag, 19. August 2019

Rebound-Effekt

FS
Grafik: Public Domain Pictures / Witali Smoligin - CC0 1.0
In Change-Vorhaben (egal ob agil oder klassisch) gibt es Phänomen das gleichermassen häufig wie ärgerlich ist: ineffektive Prozesse haben in der Vergangenheit dazu geführt, dass sich vor den umsetzenden Einheiten (Fertigung, IT, etc) ein Rückstau gebildet hat, dessen Sichtung und Verwaltung Ressourccen bindet und zu Bürokratie führt. Prozessverbesserungen sollen helfen diesen Stau durch schnellere Bearbeitung abzubauen, und tatsächlich wird der Durchsatz erheblich gesteigert. Und trotzdem: die Menge an wartender, unerledigter Arbeit bleibt gleich.

Die dahinter stehende Ursache ist der so genannte Rebound-Effekt. Ursprünglich aus der Energiewirtschaft kommend lässt er sich folgendermassen beschreiben: ein Verbraucher konsumiert eine bestimmte Ressource. Eine Effizienzsteigerung des Ressourcenverbrauchs sorgt dann dafür, dass der Verbraucher weniger konsumieren muss als bisher. Da sein Budget aber unverändert bleibt benutzt er die frei gewordenen Mittel um zusätzliche Ressourcen zu konsumieren, wodurch der Gesamtverbrauch gleich bleibt.

Dieses Phänomen lässt sich auf Fertigungsprozesse übertragen. In der alten, ineffizienten Prozesswelt hatten der Produktion vorgelagerte Einheiten (Vertrieb, Innovation, etc.) einen doppelten Aufwand: sie mussten zum einen neue Anforderungen erstellen und zum anderen den sich anstauenden Berg der fertigen, aber auf die Umsetzung wartenden Anforderungen dokumentieren, aktuell halten und umpriorisieren. Wenn dieser Berg jetzt durch effizientere Produktionsprozesse verschwindet haben die vorgelagerten Einheiten plötzlich mehr Zeit, die sie nutzen können um noch mehr Anforderungen ins System zu geben, durch die sich trotz der schnelleren Abarbeitung ein neuer Stau bildet, der neue Bürokratie generiert.

Da eine solche Entwicklung sämtliche effizienz- und effektivitätssteigernden Massnahmen wirkungslos machen kann ist ein Gegensteuern dringend nötig. Die zunächst einfach klingende Massnahme: die Menge der neuen Anforderungen darf nur so stark steigen, dass kein neuer Rückstau entsteht. Der Fachbegriff dafür ist das Work in Progress Limit. Das umzusetzen kann aber zu einer Herausforderung werden, da die freigewordenen Kapazitäten ja auch nicht ungenutzt bleiben sollen. Die Konsequenzen (Versetzungen, Umschulungen, Personalabbau in den vorgelagerten Einheiten  oder Personalaufbau in den nachgelagerten Einheiten) sind schwerwiegend, zur Vermeidung des Rebound-Effekts aber nötig.

Donnerstag, 15. August 2019

Denn sie wissen nicht, wen sie rekrutieren (IV)

FS
Bild: Flickr / Amtec - CC BY-SA 2.0
Angeregt vom neuesten Artikel des geschätzten Marcus Raitner wird es Zeit die etwas eingeschlafene Reihe "Denn sie wissen nicht, wen sie rekrutieren" wieder fortzuführen. Im Artikel geht es um die (autobiografische?) Geschichte eines Menschen der sich zum ersten mal im Leben bei einem Konzern bewirbt, und von seinem Befremden angesichts der ihm dort begegnenden Formalismen und Bürokratien. Obwohl er natürlich nur einen Einzelfall beschreibt ist er symptomatisch für ein grundlegendes Phänomen.

Seit auch die grossen Organisationen die Agilität für sich entdeckt haben (und umgekehrt) prallen bei den Ausschreibungs- und Einstellungsprozessen zwei Welten aufeinander. Auf der einen Seite die Personalabteilungen, die mit grösster Selbstverständlichkeit davon ausgehen, dass das "seit langem bewährte" Vorgehen auch weiterhin das Richtige ist, auf der anderen Seite die in der agilen Bewegung sozialisierten Fachkräfte, die diesen von ihnen als anachronistisch empfundenen Routinen mit Fassungslosigkeit gegenüberstehen.

Beide Sichtweisen lassen sich nachvollziehen. Die Personalstellen sind jahrzehntelang durch Taylorismus und (Pseudo-)Lean Management so optimiert worden, dass sie die eingehenden Bewerbungen in möglichst einheitlichem Format erwarten. Das ist schliesslich die Voraussetzung dafür, dass sie alle möglichst schnell den selben Bearbeitungsvorgang durchlaufen können. Branchenerfahrung? Check. Führungserfahrung? Check. Budgetverantwortung? Check. Ab in die zweite Auswahlstufe. Um sich jeden Kandidaten genau anzusehen fehlt einfach die Zeit.

Darüber hinaus sind sie (oft unbewusst) in einen beruflichen Standesdünkel hineinsozialisiert worden. Bei einem Automobilbauer zu schaffen, Banker zu werden oder bei einem Verlag zu arbeiten ist Errungenschaft und Ehre, dafür soll sich der Bewerber ruhig anstrengen, und zwar so, dass man es sieht. Mit makellosem Lebenslauf und überzeugenden Argumenten warum man denn gerade ihn nehmen sollte. Flüssig formuliert, ansprechend formatiert und auf hochwertigem Papier eingereicht bitteschön.

Auf der anderen Seite die vom Fachkräftemangel selbstbewusst gemachten Bewerber. Im eigenen Projektportfolio steht doch übersichtlich und nachvollziehbar drin was man gemacht hat, welchen Wert soll es haben das chronologisch anzuordnen? Und dann die Kategorien. Budget- und Führungsverantwortung sind doch für Lead Developer und Scrum Master irrelevant. Und warum gibt es trotz so vieler geforderter Pflichtangaben keine in die die Mob Programming Skills und der Link zum eigenen Open Source-Projekt passen würden?

Auch der Standesdünkel ist da, allerdings umgekehrt. Konzern? Allein der Begriff klingt schon nach Cobol. Da kann man gespannt sein ob die auch nur annähernd den gleichen Techstack bieten können wie das Fintech in der Innenstadt. Und hoffentlich halten die nicht an solchen Relikten des 19. Jahrhunderts fest wie Krawatten und festen Arbeitsplätzen. Zumindest kann man ja wohl erwarten, dass für Bewerbungen auch eine 40 Jahre alte Technologie wie die Email akzeptiert wird.

Sollte es dann trotz all dieser Hindernisse doch zu einem Job-Interview kommen, werden die Differenzen häufig erst richtig sichtbar. Während die Konzern-Seite davon ausgeht, dass der Bewerber hier nach seiner Lebensstellung sucht will dieser nur "ein paar spannende Jahre" erleben, und während die Personalerin stolz von der Betriebsrente und der Betriebssportgemeinschaft erzählt will ihr Gegenüber über Homeoffice und Slacktime reden. Das alles gerinnt in Wortwechseln wie diesem hier: "Wo sehen sie sich in drei Jahren?" "Keine Ahnung, so lange will ich hier nicht bleiben."1

Bis vor nicht allzulanger Zeit hätten diese Differenzen dazu geführt, dass diese "unpassenden" Bewerber einfach aussortiert wurden. Aber das ist vorbei, die zunehmende Agilisierung, Digitalisierung, Automatisierung und Cloudifizierung sorgt dafür, dass grosse Firmen froh sein können wenn sie ihren Bedarf überhaupt gedeckt bekommen. Und jetzt stehen die Personalabteilungen vor einem Problem: nicht nur können sie die Ansprüche der begehrten Fachkräfte kaum befriedigen ohne die eigenen, "seit langem bewährten" Vorgehensweisen in Frage zu stellen, oft wissen sie gar nicht welche Ansprüche das sind. Und dann das Schlimmste: sobald diese ermittelt wurden ändern sie sich.

Um die in der agilen Bewegung sozialisierten Arbeitnehmer verstehen zu können und um auf ihre Ansprüche eingehen zu können bleibt den Personalern letztendlich nur ein Weg übrig: selbst agil werden. Das ist nicht immer einfach und nicht immer angenehm, wenn es nicht stattfindet drohen aber immer mehr Geschichten wie die von Marcus Raitner. Und dann mit der Pointe dort nicht angeheuert zu haben.


1Der Verfasser dieser Zeilen war amüsierter Zeuge.

Montag, 12. August 2019

You need to stop implementing someone elses model

FS
Ein mitreissend vorgetragener Vortrag mit einigen bedenkenswerten Ideen, aber auch einer bei dem Sander Hoogendoorn es sich sehr einfach macht. Irgendwo zwischendrin sagt er, dass er nicht für grosse Firmen arbeitet - damit braucht er sich folgerichtig auch nicht damit beschäftigen, dass vieles von dem was er vorstellt (kurz gesagt: Strukturen abschaffen) dort nicht funktionieren würde. Trotzdem ein sehenswerter Auftritt. Und er sagt es selbst: man sollte ohnehin nicht einfach die Ideen anderer Leute zu sich übernehmen sondern vorher überprüfen ob sie in der aktuellen Situation passen.


Donnerstag, 8. August 2019

FLEAT - die agile Flotte

FS
Bild: Wikimedia Commons / U.S. Department of Defense Current Photos - CC0 1.0
Viel Neues tut sich in den letzten Jahren nicht mehr im Bereich der Agilität. Seit der Vorstellung von Nexus im Jahr 2015 hat es keine nennenswerten Versuche mehr gegeben ein neues Vorgehensmodell zu entwickeln, weshalb im letzten Monat die Einladung zum Kölner PO-Meetup sofort Aufsehen erregt hat.
Dieses Mal geht es um "FLEAT", ein neues agiles Enterprise Framework: Das Enterprise-Unternehmen als Flottenverband ... eine vielversprechende Metapher. Das Buch von Thorsten Schaar und Uwe Habicher dazu kommt gerade in den Handel. Praktiziert wird FLEAT bei haufe schon. Aber was steckt dahinter?
Freundlicherweise hat Uwe mir im Anschluss auch ein Exemplar seines Buches zukommen lassen, das ich in letzter Zeit durchgelesen habe und jetzt besprechen kann.

Was ist FLEAT?

Ein bei Haufe-Lexware erfundenes agiles Framework, dessen Name unabgekürzt "Fluid Enterprise Agility Transformation" lautet. Was es interessant macht: es konzentriert sich auf einen Bereich der von den gängigen Ansätzen noch nicht besetzt ist. Während es in Scrum, SAFe, Nexus und LeSS um Lieferzyklen, Rollen und Meetings geht, in Design Thinking um Kreativität, in Kanban um die Optimierung von Arbeitsflüssen und in XP um technische Praktiken steht bei FLEAT etwas anderes im Vordergrund: Investitionsentscheidungen.

Die verschiedenen "Schiffstypen"

Je nach Fortschrittsgrad wird unterschieden zwischen der Startbahn, dem Floss, dem Ruderboot, dem Dampfschiff und dem Kreuzfahrtschiff. Ideen für ein neues Fahrzeug darf dabei jeder im Unternehmen haben, ob darin investiert wird ist aber eine Management-Entscheidung. Die Investition in die Startbahnphase besteht noch aus der Arbeitszeit die den Mitarbeitern für die Ausarbeitung von Ideen zur Verfügung steht, das Floss enthält eine Frühfinanzierung (die ggf. klein genug für eine schmerzfreie Abschreibung ist), das Ruderboot erhält bereits in nennenswertem Ausmass Ressourcen, das Dampfschiff ist schon eines der wichtigen Investments, das Kreuzfahrtschiff ist gross genug um Kern einer eigenen, neuen Flotte zu werden.

Wer ist die Zielgruppe?

Auf den ersten Blick "Leute mit Budget". Ob das die Geschäftsführung ist, der Chief Innovation Officer oder sonst jemand - er muss die Investitionen tätigen (und ggf. die Verluste verantworten) können auf denen der Ansatz beruht. Hier liegt eine Stärke von FLEAT, da sich diese Gruppe in den anderen, eher operativen Frameworks nicht immer wiederfindet. Auf den zweiten Blick stehen aber auch die Mitarbeiter im Mittelpunkt, denen es durch das Einbringen und Verwirklichen von ihren Ideen ermöglicht wird zu Intrapreneuren zu werden.

Ist das denn agil?

Ja, ist es. Es mag eine andere Art der Agilität sein als die die man mit Scrum, Kanban, XP und den Skalierungsframeworks verbindet, es hat aber das entscheidende Element: Reaktionsgeschwindigkeit. Neue Ideen sollen schnell aufgegriffen werden, schnell validiert werden und schnell (und früh) scheitern können - überwiegend schon in den frühen Phasen. Um das zu erreichen sollen die "Schiffe" an den aus anderen Frameworks bekannten Prinzipien ausgerichtet sein: kundenzentriert, End-to-End-verantwortlich, autonom, sich kontinuierlich verbessernd, etc.

Ist es wirklich neu?

Nur eingeschränkt. Die Idee durch die Investition in kleine, innovative Einheiten das Risiko von grösseren Verlusten zu minimieren ist aus Ansätzen wie der Effectuation schon länger bekannt, Konzepte wie Intrapreneurship und Minimum Viable Products (möglichst früh validierbare Produktumfänge) kommen auch im Lean Startup vor, autonome und crossfunktionale Teams gibt es auch in Scrum, bzw. seinen Skalierungsframeworks. Was man FLEAT lassen kann ist, dass diese Elemente zu einem in sich konsistenten Ganzen paketiert wurden. Und was ist schon wirklich neu?

Gibt es Probleme?

Wo gibt es die nicht? Ins Auge springt vor allem, dass die Mitarbeiter in den frühen Evolutionsstufen (Startbahn, Floss, Ruderboot) nur in Teilzeit für das Vorhaben arbeiten und in der restlichen Zeit in ihren bisherigen Jobs. Die damit verbundenen Effizienzverluste (durch Kontextwechsel, Terminüberschneidungen, Priorisierungskonflikte, etc.) haben dazu geführt, dass derartige Arbeitsmodelle in der agilen Bewegung eigentlich verpöhnt sind. Auch die geringe Kompatibilität mit den typischen Organisationsprinzipen von Konzernen (organisatorische Silos, "mittelfristige" Finanzplanung, funktionale Querschnittsorganisationen) dürfte eine Herausforderung werden. Und die angestrebte Kommerzialisierung (siehe hier) dürfte bei weiten Teilen der anti-komerziell entstandenen agilen Community zu Abstossungsreaktionen führen.

Wie gross/erfolgreich wird FLEAT werden?

Eine spannende Frage. Sicherlich würde vielen Firmen dieser Ansatz mehr als nur gut tun (und das Ansetzen an der Finanzierung hätte eine gewaltige Hebelwirkung), die zuvor genannten Probleme dürften aber in den meisten Fällen beachtliche Hindernisse für eine öffentlichkeitswirksame Umsetzung sein. Sollte trotzdem eine gelingen wäre das ein Verkaufsargument auf dem sich aufbauen liesse. Eine "Massenbewegung" wie Scrum oder Kanban dürfte aufgrund der oben genannten anti-komerziellen Reflexe zwar auch dann nicht entstehen, aber vielleicht muss es das auch gar nicht. Und selbst wenn es nur dazu kommen sollte, dass FLEAT als weitere verfügbare Alternative dafür sorgt, dass "Enterprise Agility" nicht mehr automatisch mit SAFe gleichgesetzt wird - allein das wäre ein grosser Fortschritt.

Montag, 5. August 2019

Ein Bild sagt mehr als 1000 Worte (XXVI)

FS

Mittwoch, 31. Juli 2019

Kommentierte Links (LI)

FS
  • DACH30: Agile Rollen - Kompetenzen

  • Wenn man auf die Verbreitung, das Verständnis und die Akzeptanz agiler Vorgehensweisen blickt gibt es im deutschsprachigen Raum zunehmend Grund zum Optimismus. So auch hier: Vertreter von über 50 Unternehmen aus Deutschland, Österreich und der Schweiz haben gemeinsam versucht Mindeststandards für agile Rollen aufzustellen, mit einem Ergebnis das sich sehen lassen kann. Für die (Framework-neutral benannten) Rollen des Team Facilitators, des Value Verantwortlichen, des Umsetzungsteams und der Agilen Führungskraft gibt es jetzt grundlegende Tätigkeitsbeschreibungen und Shu Ha Ri-Stufen. Sollte sich das so durchsetzen wäre damit einen grosser Schlag gegen die Verbreitung von Cargo Cult gelungen.

  • Ron Jeffries: Fixed-Everything - Agile?

    Keine andere Website kommt so häufig in den kommentierten Links vor wie die von Ron Jeffries, und das aus gutem Grund. In gewohnter Weise eloquent und langatmig erörtert er die Frage ob es innerhalb eines "eisernen Dreiecks" aus unveränderbarem Umfang, Zeitrahmen und Budget noch Agilität geben kann. Seine Antwort: ja. Was man an dieser Stelle allerdings anmerken muss - er beschreibt hier die gelebte Realität, in der es eben doch zu der teilweisen Aufweichung der drei Dimensionen kommt. Dann wiederum - womit, wenn nicht mit der Realität, soll er sich auch auseinandersetzen? Ein echtes eisernes Dreieck ist schliesslich ähnlich häufig wie ein Albino-Panda.

  • Joe Dunn: Tribes And Tribal Conflicts In A Tech Company

    Der Mensch ist ein irrationales Wesen, trotz aller Zivilisiertheit getrieben von Instinkten, Gruppendynamiken und unbewussten Verhaltensmustern. Das zu erkennen gehört zu den Voraussetzungen guter Organisationsentwicklung, und zu diesen Erkenntnissen gehört auch die, dass grosse Organisationen in "Stämme" zerfallen die ähnliche Konflikte austragen wie vor langer Zeit ihre Vorfahren. Statt den Goten, Langobarden und Vandalen stehen sich heute Vertrieb, IT und Rechtsabteilung gegenüber und begegnen sich mit Vorurteilen und Feindseligkeit. Joe Dunn versucht sich an der Deutung interner Auseinandersetzungen als Stammeskonflikte und an der Frage wie sie aufzulösen sind. Und das Ganze hat nichts mit Spotify zu tun.

  • J. Meadows: Waste Not, Want Not - A Simplified Value Stream Map for Uncovering Waste

    Ein Blick auf die Lean Management-Seite der Softwareentwicklung. Ausgehend von den Mudas des Toyota Production System stellt J. Meadows zwei fiktive Unternehmen einander gegenüber: Wasteful Inc. und Efficient Inc. Ein schönes Beispiel für die Möglichkeiten des Flussoptimierung, aber auch eines das mit Vorsicht zu betrachten ist. Bei zu unbedachter Weiterverwendung droht die grosse Gefahr des Lean Management: dass auch ein vom Markt gar nicht nachgefragtes Produkt immer schneller und effizienter produziert wird, mit genau dem Ergebnis das eigentlich vermieden werden soll - Waste.

  • Dagmar Bott: Agiles Bar Camp – oder einfach Agile Session Time

    Bar Camps und Open Spaces gelten als eines der besten Werkzeuge für die selbstorganisierte Durchführung von (Un)Konferenzen, Workshops und Wissenstransfer-Veranstaltungen. Wie das in der Praxis aussehen kann erklärt Dagmar Bott anhand der in ihrem Unternehmen stattfindenden Agile Session Time. Ein Ansatz den man jeder anderen Firma sehr zur Nachahmung empfehlen möchte. Um die Klammer zum ersten kommentierten Link zu schlagen: auch die zunehmende Etablierung derartiger Formate trägt dazu bei, dass man die agile Transition der deutschen Unternehmenslandschaft mit Optimismus beobachten kann.

Montag, 29. Juli 2019

Raus aus dem Hamsterrad

FS
Bild: Wikimedia Commons / Mylius - CC BY-SA 3.0
Wenn Scrum irgendwo neu eingeführt wird kann man davon ausgehen, dass es eine der ersten aufkommenden Diskussionen sein wird: müssen denn diese Rollen Product Owner und Scrum Master wirklich sein? Können diese Aufgaben nicht von jemand anderem nebenher gemacht werden? Die Antwort: wenn das Ergebnis wirklich Scrum sein soll, dann nicht. Allerdings nicht als Selbstzweck sondern weil es Sinn macht.

Welcher das ist zeigt sich vor allem dort wo das "nebenher machen" stattfindet, etwa wenn die PO-Aufgaben von einem Business Analysten oder Fachabteilungs-Mitarbeiter übernommen werden und die Scrum Master-Aufgaben von einem Teammitglied. Wie gesagt, nebenher, also zusätzlich zu dem was ohnehin schon zu dem bisherigen Job gehört. Das Ergebnis wird fast immer das gleiche sein - die neuen Aufgaben werden stark vernachlässigt werden. Und das mit gutem Grund.

Der entscheidende Punkt ist hier, dass die Arbeit der Product Owner und Scrum Master im Gegensatz zu der der meisten anderen Mitarbeiter zu einem nicht Grossteil nicht anlassgetrieben ist. Sowohl die Konzeption und Validierung neuer Produktumfänge als auch die Evolution eines Teams in Richtung Crossfunktionalität und Selbstorganisation brauchen in der Regel Monate um umgesetzt zu werden, Sprints oder operative Tätigkeiten erfordern dagegen die Konzentration auf die Gegenwart.

Die Folgen sind immer die gleichen. "Um die langfristigen Themen kümmern wir uns wenn es mal im täglichen Betrieb nicht so viel zu tun gibt" heisst es dann. Dieser Zeitpunkt kommt aber praktisch nie, denn zu tun gibt es immer. Die Verschiebung der PO- und Scrum Master-Themen führt sogar zu mehr Arbeit im Alltag, da die stockende Weiterentwicklung des Teams und die unklare Produktstrategie den Beteiligten immer wieder auf die Füsse fallen und neue kurzfristige Reaktionen erforderlich machen. Ein Teufelskreis.

Um eben das zu verhindern ist es nötig in kurzen, regelmässigen Abständen aus dem operativen Hamsterrad herauszusteigen, einige Schritte zurückzutreten, das Große Ganze auf sich wirken zu lassen und sich Sinn- und Perspektivfragen zu stellen. "Wird das neue Feature wirklich so angenommen wie wir dachten?" "Wird der aktuelle Arbeitsmodus auch in einem Vierteljahr noch so funktionieren?" Etc. Wenn die Antwort darauf unklar ist sollten auch die anderen Teammitglieder aus dem Rad herausgeholt werden um sie auf das aufmerksam zu machen was von dort aus nicht sichtbar ist.

Den Product Ownern und Scrum Mastern diese Möglichkeit zu geben ist eine der Grundvoraussetzungen dafür, dass Scrum wirklich zum Greifen kommt. Und da das im Rahmen einer Zusatzaufgabe nicht funktioniert sollte die Rolle so eingeführt und ausgestaltet werden wie sie gedacht ist.

Donnerstag, 25. Juli 2019

Big Bang-Releases

FS
Bild: Pexels / Rawpixel - CC0 1.0
Es ist die IT-Story des Monats, des Sommers und vermutlich auch des Jahres - die Einführung eines neuen Enterprise Resource Planning-Systems beim Motoröl-Hersteller Liqui Moly aus Ulm. Was eine derartige Software-Einführung bewirken kann? Zum Beispiel das: falsch angezeigte Lagerbestände, verspätete Lieferungen, zunehmende Kundenbeschwerden, Gewinneinbruch um 30 Prozent.

Ferndiagnosen sind in derartigen Situationen immer schwierig, aber die Recherchen der FAZ und der Wirtschaftswoche zeichnen ein eindeutiges Bild: nachdem Liqui Moly jahrzehntelang auf eine immer weniger zeitgemässe und immer stärker veraltende Software gesetzt hatte sollte die letzten Endes abgelöst werden. Der angedachte Ersatz war eine Standardsoftware, die im so genannten "Big Bang-Verfahren" eingeführt werden sollte. Big Bang bedeutet, dass von jetzt auf gleich "mit einem Schlag" von der alten auf die neue Software umgeschaltet wird. Und den Big Bang gab es, siehe oben.

Derartig fehlgeschlagene "Auf einen Schlag-Einführungen" sind kein Einzelfall, erst diesen Frühling gab es einen ähnlichen Fall bei Hertz, letztes Jahr bei Lidl, je weiter man sucht desto mehr werden es. Hinter diesen wiederkehrenden Geschichten verbergen sich erfahrungsgemäss ähnliche Ursachen, die sich in vielen (wahrscheinlich fast allen) Big Bang-Vorhaben wiederfinden lassen. Wegen ihnen ist ein solches Vorgehen mit grösster Vorsicht zu betrachten.

Zunächst sind die meisten älteren Grossanwendungen über die Jahre "kaputtentwickelt" worden. Um die Investitionen klein zu halten werden neue Funktionen irgendwo an bestehende angedockt, selbst wenn dadurch die internen Abläufe so verkompliziert werden, dass sie kaum noch nachvollziehbar sind. Mit der fehlenden Nachvollziehbarkeit wird dann die Dokumentation widersprüchlich, das Wissen wie alles funktioniert besteht irgendwann nur noch in den Köpfen der älteren Mitarbeiter (laut FAZ hielt bei Liqui Moly nur noch ein Entwickler das Altsystem am Laufen).

Für die Ablösungs-Vorhaben bedeutet dass, das in solchen Fällen gar nicht mehr klar ist was da abgelöst werden soll. Die Anforderungen an das Neusystem beruhen auf veralteten und unvollständigen Informationen, schlimmstenfalls auf Vermutungen. Die Folge - selbst wenn das neue System genau so funktioniert wie es konzipiert wurde wird es trotzdem nicht das können was eigentlich notwendig wäre. Eine "kaputtenwickelte" Software wird dann durch eine ersetzt die "kaputt entwickelt" wurde.

Es wird noch schlimmer. Eine weitere Fehlerquelle entsteht dort, wo es sich bei der neuen Anwendung um Standard-Software handelt. Anders als es der Name vermuten lässt ist das keineswegs ein Standard der überall funktioniert. Um mit den Schnittstellen und Prozessen des neuen Einsatzgebietes kompatibel zu sein sind in der Regel umfangreiche Anpassungen nötig. Finden diese unter Zeit- und Kostendruck statt (wo ist das nicht so?) kommt es auch hier zu den sprichwörtlichen "quick and dirty"-Lösungen.

Selbst das ist aber noch nicht alles. Alle gerade genannten Probleme lassen sich nämlich erst dann feststellen wenn es zu spät ist. Genau das ist das grosse Risiko eines Big Bang-Releases: wenn alles erst ganz zum Schluss gleichzeitig auf Produktion geschoben wird, dann ist der früheste Zeitpunkt an dem Realitätskontakt stattfindet und sich Fehlkonzeptionen und -funktionen feststellen lassen genau dann - ganz zum Schluss, wenn alles Live geschaltet ist und alle Mitarbeiter und Kunden bereits betroffen sind.

Wie es besser gehen könnte? Durch einen mehrstufigen Prozess1. Zuerst sollte durch Reverse Engineering herausgefunden werden was die alte Anwendung wirklich tut. Als nächstes sollte versucht werden einen ihrer Teile so zu modifizieren, dass er nur noch durch fest definierte Schnittstellen mit dem restlichen System kommuniziert. Dieser Teil kann dann separat ersetzt werden, mit deutlich überschaubareren Konsequenzen wenn hier etwas schiefläuft. Danach kann das Selbe mit dem nächsten Teil passieren, dem übernächsten, etc.

Häufige Einwände an dieser Stelle sind, dass das doch eine Eigen-Entwicklung von Software wäre. Das wäre doch viel teurer als sich fertige Software zu kaufen. Es wäre interessant zu hören was die Leute von Liqui Moly heute darauf antworten würden.

1Alle Wasserfall-Witze bitte jetzt

Montag, 22. Juli 2019

Eisenbahnscheinbewegung

FS
Zum Thema Fake Agile, unsinnige Zertifizierungen und darüber wie man es besser machen kann gibt es mittlerweile viele Vorträge die man sich ansehen kann. Der hier ist aber definitiv einer der unterhaltsamsten.

Donnerstag, 18. Juli 2019

Agile Reden

FS
Bild: Flickr / European Parliament - CC BY 2.0
Vor meiner Karriere in der IT habe ich einige Jahre in der politischen Verwaltung gearbeitet und hatte dort reichlich Gelegenheit mir die Auftritte verschiedener Politiker anzuhören. Auch die neue EU-Kommissionspräsidentin Ursula von der Leyen gehörte dazu, über deren Vorstellung vor dem EU-Parlament es hiess, es sei die "Die fast perfekte Rede" gewesen. Ohne diesen Auftritt im Einzelnen würdigen zu wollen - reden kann sie, genau fast alle hochrangigen Politiker. Und faszinierenderweise kann man bei näherer Betrachtung in dieser politischen Redekunst etwas wiederfinden was man dort nicht vermuten würde: Agilität.

Um das einordnen zu können macht zunächst eine kurze Definition von Agilität Sinn: Agilität bedeutet in meinem Verständnis, in kurzen Abständen liefer- und reaktionsfähig zu sein. Das ist nicht nur in der IT eine Notwendigkeit sondern auch bei politischen Reden. Auch hier ist die Vorbereitungszeit häufig kurz (im aktuellen Beispiel von der Leyen nur wenige Tage) und auch hier muss oft kurzfristig auf geänderte Rahmenbedingungen eingegangen werden. Dass das Ergebnis trotzdem fast immer gut klingt hat seinen Ursprung in Techniken die sich auch in der agilen Softwareentwicklung wiederfinden.

Zuerst wäre unter diesen Techniken die Modularisierung zu nennen. Die Reden von Spitzenpolitikern mögen zwar in ihrer Gesamtheit immer wieder anders sein, einzelne Abschnitte in ihnen sind sich aber immer wieder sehr ähnlich und wiederverwendbar. Ein Erläuterung zu den "abendländischen Werten", eine Anekdote aus der eigenen Kindheit, ein Bekenntnis zur Klima-Politik - es sind nahezu identische Passagen, die auswendig gelernt abrufbar sind und die sich oft auch in beliebiger Reihenfolge anordnen lassen. Die meisten Politiker-Reden bestehen grösstenteils aus solchen Bausteinen.

Als zweite Technik wird häufig die Parametrisierung eingesetzt. Dahinter verbirgt sich nichts anderes als der Trick, durch das Austauschen einzelner zentraler Begriffe den Eindruck zu erwecken, spezifisch auf die jeweilige Situation einzugehen. "Für mich war [Berlin / Hannover / Brüssel] immer ein besonderer Ort", "Die Zukunft von [Deutschland / Europa / der CDU] ist ohne Werte nicht denkbar", etc. Die Wiederverwendbarkeit und Anschlussfähigkeit der auswendig gelernten Module wird auf diese Weise deutlich erhöht, genau wie die Geschwindigkeit in der sie auf die jeweilige Situation angepasst werden können.

Als dritte Technik kommt die Automatisierung dazu. Vor allem in Interviews und Diskussionen kann der Eindruck von Kompetenz und Schlagfertigkeit dadurch hervorgerufen werden, dass Antworten und Erwiderungen (scheinbar) spontan und ohne Verzögerung erfolgen. Dass das möglich ist liegt an antrainierten Automatismen. Mit häufigen Fragen oder Schlüsselbegriffen werden bestimmte, parametrisierte Rede-Bausteine verknüpft, die reflexartig abgespult werden können. Beispielsweise können viele Politiker Vorwürfe der Untätigkeit in bestimmten Politikfeldern sofort mit Konjunktur- oder Investitionsdaten kontern, die vom Aufbau ähnlich, aber je nach Fall mit unterschiedlichen Zahlen gefüllt sind.

Als vierte Technik kommt ein durchgehendes Live-Monitoring der Ergebnisse dazu. Seien es die direkten Zuhörer-Reaktionen in Parlamenten oder auf Wahlkampfauftritten oder die Signale des persönlichen Referenten im Interview - sobald erkennbar ist, dass eine bestimmte Wirkung sich aufbaut lässt diese sich durch das Abspulen bestimmter Bausteine verstärken (z.B. mit dem Modul "emotional aufgeladene Anekdote") oder abschwächen (z.B. mit dem Modul "komplizierte technokratische Erläuterung"). Auch hier kann eine Parametrisierung ("Der wissenschaftliche Dienst des Bundestages sagt ..." vs. "Eine von der Altersarmut bedrohte Rentnerin erzählte mir ...") zusätzlich wirken.

Natürlich sind diese Techniken nicht aus der IT übernommen worden, sie wurden parallel zu ihr und unabhängig von ihr in der Politik entwickelt. Dass sie einander trotzdem so ähnlich sind ist ein starker Indikator dafür, dass es sich um übergreifende Grundmuster handelt, die überall da anwendbar sind wo Agilität im Sine von Liefer- und Reaktionsfähigkeit von Vorteil ist.

Montag, 15. Juli 2019

Deine Muda: Defects

FS
Bild: Pixabay / EME - CC0 1.0
Achter Teil der Deine Muda-Serie. Die letzte der sieben klassischen Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Erzeugung fehlerhafter Produkte, so genannter Defects. Bei diesem Muda-Typ sind zwei Ausprägungen möglich: die versehentliche und die absichtliche Erzeugung.

Für jeden nachvollziehbar ist die versehentliche Erzeugung: dort wo Menschem am Werk sind werden Fehler gemacht und manchmal haben diese Fehler zur Folge, dass nicht (oder nur eingeschränkt) funktionierende Produkte erzeugt werden. Sobald das auffällt müssen Nacharbeiten stattfinden, was an sich schon ärgerlich ist. Wenn die Fehler es ausserdem noch unentdeckt durch die Qualitätskontrolle geschafft haben kommt noch der Image-Schaden dazu.

Weniger nachvollziehbar aber häufiger als man denkt ist die bewusste Produktion fehlerhafter Ergebnisse. Sei es, dass die Fertigung nicht funktioniert wie sie soll oder dass einzubauende Komponenten nur in minderer Qualität vorliegen - dort wo Quoten oder Deadlines eingehalten werden müssen ist die Verlockung gross das Problem nach hinten zu verschieben und zu reparieren "sobald Zeit dafür da ist" (was schlimmstenfalls nie der Fall sein wird).

Die offensichtlichste Folge von fehlerhaft erzeugten Produkten sind zusätzliche Kosten. Sowohl die Reparaturaufgaben als auch die nachgelagerte Qualitätssicherung kosten Arbeitszeit (und damit auch Geld), dazu kommen noch weitere Faktoren: die Verlängerung der Zeit in der Fertigung oder Reparatur verzögert auch den den Zeitpunkt des Verkaufs (→ totes Kapital, Cost of delay), schlimmstenfalls kommen Vertragsstrafen oder Materialkosten dazu.

Weniger offensichtlich aber von ähnlich schweren Auswirkungen ist die Störung des Arbeitsflusses. Immer wieder müssen bereits begonnene Arbeiten unterbrochen werden um Reparaturen vorzunehmen oder die Qualität zu überprüfen, im schlimmsten Fall müssen Dokumentationen ergänzt, Warnhinweise angebracht oder Kundenservice-Aufgaben übernommen werden. Sowohl die dadurch verursachten Konzentrationsstörungen als auch die ständigen Kontextwechsel verlangsamen die Abläufe und können weitere Fehler verursachen.

Die Massnahme zur Vermeidung fehlerhafter Produktion gehört zu den Elementen die das Toyota Production System berühmt gemacht haben: sobald ein Fehler entdeckt wird, wird die gesamte Produktion angehalten und der Produktionsprozess einschliesslich aller vor- und nachgelagerter Schritte wird repariert und verbessert. Das Besondere daran: die Berechtigung zum Anhalten der Produktion hat nicht nur das Management sondern jeder einzelne Angestellte. Nur so lässt sich der Reparatur-Prozess so schnell beginnen, dass möglichst wenig fehlerhafter Ausstoss entsteht.

Donnerstag, 11. Juli 2019

Agile Bauprojekte

FS

"Jaa, in der Software-Entwicklung, da mag das gehen. Aber in anderen Branchen ist Agilität nicht anwendbar, da passt Wasserfall viel besser!" Derartige Aussagen darf sich so ziemlich jeder Agile Coach regelmässig anhören. Und selbst wenn es mittlerweile zahlreiche andere Anwendungsbeispiele gibt, vom Flugzeugbau über den Krankenhausbetrieb bis zum Schul-Unterricht, ein letzter Rückzugsort bleibt allen Skeptikern: "Aber in der Baubranche, da geht das nicht! Agile Bauprojekte sind unmöglich!" Aber sind sie das wirklich?

Tatsächlich gibt es Bauprojekte in denen Inspect & Adapt nicht nur ausprobiert wird sondern die ohne dieses Vorgehen sogar undenkbar wären. Die klassischen Voraussetzungen für agiles Arbeiten treffen bei ihnen zu - Komplexität, Unberechenbarkeit und Änderungsanfälligkeit. Und es handelt sich dabei keineswegs um verstreute Einzelfälle sondern um solche die regelmässig vorkommen. Um ein häufiges Beispiel zu nennen: die Sanierung von Altbauten. 

Vor dem Hintergrund des steigenden Wohnungsbedarfs in den grossen Städten werden zur Zeit viele der Gründerzeit-Gebäude aus der vorletzten Jahrhundertwende renoviert oder umgebaut, wobei es zu zahlreichen ungeplanten Hindernissen kommen kann: Leitungen verlaufen anders als in den veralteten Plänen eingezeichnet, Rohre sind marode, in den Wänden werden Stahlträger entdeckt, auszutauschende Metallgitter sind tief im Mauerwerk verankert, Stuckverzierungen erweisen sich als denkmalgeschützt.

Die ursprünglichen Pläne einzuhalten ist nach Entdeckung derartiger Hindernisse schwierig bis unmöglich. Sei es, dass die ursprünglich vorgesehenen Umbauten jetzt zu langfristig geworden sind, zu teuer oder wegen Statik und Denkmalschutz nicht zulässig -  es geht gar nicht anders als Änderungen an ihnen vorzunehmen. Und da vieles erst im Rahmen laufender Bauarbeiten offensichtlich wird bedeutet das auch, dass Pläne geändert werden müssen während bereits mit ihrer Umsetzung begonnen wurde.

Sogar ein iterativ-incrementelles Vorgehen ist in derartigen Zusammenhängen häufig anzutreffen. Auf jeden Umbau eines Flügels, Stockwerks oder Zimmers folgt jeweils eine kurze, auf den im Umbau gewonnenen Erkenntnissen beruhende Aktualisierung der Statik-, Elektronik- oder Leitungspläne sowie ein Anpassen des Plans für die nächste Bauphase. In vielen Fällen sind diese Iterations-Zyklen sogar kürzer als ein Monat, so dass man das Bauprojekt sogar nach Scrum organisieren könnte.

Natürlich heisst das nicht, dass Agilität in allen Bauvorhaben Sinn machen würde, in vielen Fällen sind andere Ansätze besser geeignet. Aber um zum Anfang zurückzukommen: dass Agil und Bauen grundsätzlich nicht zusammenpassen ist ganz sicher falsch.

Montag, 8. Juli 2019

Humanity above Bureaucracy

FS
Wann immer ein Beispiel für Organisationen gesucht wird die dezentral und selbstorganisiert strukturiert sind ist die Wahrscheinlichkeit gross, dass der Name Buurtzorg fällt. Wie dieser Pflegedienst-Anbieter entstanden ist und funktioniert erklärt hier sein Gründer, Jos de Blok.

Donnerstag, 4. Juli 2019

Die Produktbeschreibung als Pressemitteilung

FS
Bild: Pexels / Rawpixel - CC0 1.0
Draussen in der Welt gibt es die Inspirationen. Letzte Woche durfte ich den Vortrag eines Amazon-Mitarbeiters hören, in dem vorgestellt wurde wie in diesem Unternehmen gearbeitet wird. Einiges davon war bereits bekannt, etwa die Micoservice-Architektur oder die 2 Pizza-Teams, anderes noch nicht. Zu den eher unbekannten Aspekten gehörte die Formulierung von Produktbeschreibungen, die bei Amazon in einer ungewöhnlichen Variante existieren: als Pressemitteilung.

Natürlich handelt es sich dabei nicht um Pressemitteilung im eigentlichen Sinn, sie sind nur für die interne Kommunikation gedacht. Ihr Inhalt ist immer so formuliert, dass er den in der Zukunft liegenden Produktions-, bzw. Vermarktungsstart beschreibt. Ob jemals eine dieser Pressemitteilungen wirklich an die Medien verschickt wurde ist unklar, es ist aber auch nicht weiter von Relevanz. Wichtig sind die Inhalte, die durch das Format erzwungen werden.

Pressemitteilungen sind kurz. Die (bei Amazon) übliche Länge ist eine Seite. Der Verfasser ist also gezwungen längliche Ausführungen zu unterlassen und sich auf das Wesentliche zu konzentrieren. Sie haben ein Datum. Dafür muss eine Idee existieren bis wann eine Fertigstellung einer ersten Version realistisch wäre. Und ganz wichtig: sie erfordern bestimmte Arten der Formulierung und des inhaltlichen Aufbaus.

Da Pressemitteilungen sich an eine breite Öffentlichkeit richten müssen sie einfach und verständlich formuliert sein, es darf kein Fachchinesisch geben. Auch inhaltlich gibt es klare Vorgaben: von oben nach unten müssen sie abnehmend relevant und zunehmend detailliert werden. Das klingt zwar abstrakt, wird bei genauerer Betrachtung aber schnell konkret.

Oben (direkt nach dem Datum) steht die Überschrift. Die sollte nicht länger als eine Zeile sein und einen ersten Eindruck geben worum es geht (z.B. "Stadt Bonn stattet Parkautomaten mit Chatbots aus"). Ggf. kann ergänzend noch eine Unter- oder Dachzeile dazukommen die weiteren Kontext gibt (z.B. "Diskussionen mit Politessen werden unnötig"). Darunter steht der so genannte Teaser, ein hervorgehobener Textblock in dem Produkt und Produktmehrwert zusammengefasst werden.

Eilige Leser sollten an dieser Stelle abbrechen können und trotzdem alle wesentlichen Informationen haben. Für alle anderen folgen in den nächsten Absätzen weitere Hintergründe. Was war das initiale Problem, bzw. der ursprüngliche Marktbedarf? Wie sah die erste Lösungsidee aus? Wie erfolgte die Konkretisierung? Was waren die ersten Schritte? Was war der Umfang der ersten Version? (zur Erinnerung, die Pressemitteilung ist aus Sicht eines in der Zukunft liegenden Release formuliert)

Neben diesen Kerninformationen können noch weitere Elemente von Pressemitteilungen genutzt werden, zum Beispiel (fiktive) Zitate des Produktverantwortlichen oder begeisterter Kunden, Infografiken oder FAQ-Boxen. Durch deren Freistellung vom Fliesstext wird das Dokument zwar länger, auch jetzt sollte es aber anderthalb Seiten nicht überschreiten um nicht unübersichtlich zu werden.

Das fertige Ergebnis kann dann in der für Produktbeschreibungen üblichen Form genutzt werden: als Unterlage für einen Pitch oder eine Genehmigung, als Ausgangslage für Workshops oder als Fokussierungshilfe für das Umsetzungsteam. In späteren Umsetzungsphasen können auch weitere Dokumente dazukommen, sie sollten aber immer auf die Pressemitteilung verweisen und ihr nicht widersprechen.

Montag, 1. Juli 2019

Kommentierte Links (L)

FS
  • Sam McAfee: Leaders, The Problem Is Not Your Agile Teams — It’s You.

  • Die hier beschriebene Ausgangslage ist häufiger anzutreffen. Ein Unternehmen holt sich einen agile Coach an Bord (egal ob intern oder extern) und gibt ihm den Auftrag "die Teams schneller zu machen". Wie von Sam CAfee richtig beschrieben liegt dahinter häufig das Missverständnis, dass Agilität ein Vorgehen wäre das im Rahmen eines (oder mehrerer) Teams umsetzbar ist, ohne dass das beauftragende Management sich selbst ändern müsste. Seine Annahme, dass der Grund dafür unqualifiziertes oder oberflächliches Handeln der oberen Ebenen ist, sollte zwar hinterfragt werden, grundsätzlich hat er aber recht- eine Transition nur auf Teamebene wird nicht funktionieren.

  • Takeshi Yoshida: Single Sprint Scrum Pilot

    Ein interessanter Kontrapunkt zur häufigen Annahme, dass iterative Vorgehensmodelle wie Scrum erst durch Übung ihre wirkliche Wirksamkeit entfalten. Takeshi Yoshida geht davon aus, dass selbst ein einziger, singulärer Sprint bereits grossen Mehrwert hat, und zwar sowohl für die Produktenticklung als auch als Showcase für das was in der Unternehmensentwicklung möglich ist. Damit hat er zwar definitiv recht, die Frage stellt sich aber ob in einem solchen Konstrukt nicht eines der zentralen Elemente von Scrum ind Agile verlorengeht: die Übernahme von regelmässigem Kundenfeedback in die weitere Produktentwicklung.

  • Helen Wassef: 5 ways Modern Agile Can Take SAFe Out of a Rut

    Um mal einen anderen Herangehensansatz an SAFe zu haben als den üblichen, sehr kritischen: genau wie andere agile Ansätze ist dieses Framework ein an sich neutraler Container, der sehr unterschiedliche Vorgehensweisen, Werte und Praktiken enthalten kann. Wenn man von dieser Prämisse ausgeht kann man durch ein spezifisches Befüllen dieses Containers dafür sorgen, dass das sehr häufige Abrutschen in starre, komplizierte und bürokratische Strukturen unwahrscheinlicher wird. Vor diesem Hintergrund ist Helen Wassefs Idee zu verstehen, Elemente von Modern Agile mit SAFe zusammenzuführen. Auf jeden Fall wäre es ein interessantes Experiment: das schwergewichtigste und das leichtgewichtigste agile Framework miteinander kombiniert.

  • Dan Ray: How to Have 15-Minute Sprint Planning Meetings

    Genau das ist es was ich meinen Teams auch immer sage! Wenn ein vernünftig priorisiertes Product Backlog vorliegt, dass gemeinsam mit dem Umsetzungsteam in einem Refinement verfeinert wurde, dann wird das Sprint Planning in wenigen Minuten durchführbar sein (ich glaube sogar, dass es in unter 10 Minuten geht). Allerdings gibt es dafür noch weitere Voraussetzungen, die Dan Ray nicht erwähnt: es sollten keine grösseren Restaufwände aus dem letzten Sprint übrig sein, es sollte keine kurzfristigen Planungsänderungen gegeben haben und das Team sollte möglichst wenig Abhängigkeiten nach aussen haben. Dann geht es.

  • Gustavo Razzetti: Dumb Rules Are Frustrating Your Best People

    Bürokratie lähmt und demoralisiert, das ist ein allgemein bekanntes Phänomen. Gustavo Razzetti versucht sich an Ratschlägen zu ihrer Vermeidung und kommt auf insgesamt fünf:
    1. Halte die Regeln einfach
    2. Bestrafe nicht die sich rational verhaltende Mehrheit durch Detailvorgaben die für eine irrationale Minderheit gedacht sind
    3. Regeln sollten ermächtigen und nicht einengen
    4. Vertraue den Menschen und sie werden es erwidern
    5. Behandle Menschen wie Erwachsene
    Es wären sicher noch weitere Ratschläge möglich, aber mit diesen anzufangen würde vielen Organisationen bereits helfen.

Donnerstag, 27. Juni 2019

Change Fatigue (II)

FS
Bild: Pixabay / TotumRevolutum - CC0 1.0
Altersbedingt (Ende der 70er geboren) gehöre ich zu der Generation deren Erwachsenwerden mit dem endgültigen Siegeszug der Digitalisierung zusammengefallen ist. Bedingt dadurch habe ich auch die letzten Rückzugsgefechte der Menschen erleben dürfen, die glaubten dem mit Einmal- oder Teilaufwänden begegnen zu können. An meiner Universität etwa beharrten manche Professoren auf der Nutzung von WordPerfect. Ein Textverarbeitungsprogramm gelernt zu haben sollte ihrer Meinung nach für den Rest ihres Lebens reichen, das Erlernen eines zweiten (MS Word) lehnten sie ab. Auch in meinem ersten Job traf ich vergleichbare Menschen. Word und Outlook hatten sie sich unter Schmerzen beibringen lassen, der Nutzung von Excel und Powerpoint verweigerten sie sich. Die Begründung: irgendwann müsse es doch genug sein mit "diesen immer neuen Computerprogrammen".

Zwar sind das Anekdoten der Vergangenheit, man kann sie aber auch als Parabel für die Gegenwart einsetzen. Damals wie heute werden die Menschen in ihrem Berufsleben mit immer neuen Tools konfrontiert. Damals Outlook, heute Slack. Damals Word und Excel, heute Jira und Confluence. Et cetera. Und sowohl bei den vergangenen als auch bei den gegenwärtigen Neuerungen sind die irgendwann auftretenden Ermüdungserscheinungen vergleichbar. "Schon wieder ein neues Tool?" "Das alte funktioniert doch noch!" "So viel mehr kann das Neue doch auch nicht!" "Können wir uns nicht endgültig auf eine Lösung einigen und dabei bleiben?" Diese und ähnliche Äusserungen dürften sich quer durch die Arbeitswelt der letzten 25 Jahre ziehen (übrigens auch quer durch alle Altersklassen).

Was die Erzählung von der Word-, Outlook- und Excel-Ablehnung besonders macht ist ihr im Rückblick besonders deutlich erkennbarer Anachronismus. Aus heutiger Sicht erscheint sie genauso irrational wie eine Ablehnung von Kugelschreibern, Notizblöcken und Briefmarken, so sehr sind die Office-Programme mittlerweile in den Alltagsgebrauch übergegangen. Es lohnt sich ein Gedankenexperiment: wie anachronistisch wird die heutige Ablehnung neuer digitaler Werkzeuge in 15 oder 25 Jahren wirken? Wie vorgestrig werden diejenigen erscheinen die nicht mit Chatprogrammen arbeiten wollen, da sich doch alles mit Emails verschicken lässt? Wie aberwitzig wird die Aussage herüberkommen kein Wiki zu brauchen, da es doch gemeinsame Laufwerke gebe?

Natürlich, für jeden der heute das Gefühl hat sich an immer neue Tools gewöhnen zu müssen sind solche Gedanken nur bedingt tröstlich. Und ja, nicht alles was zur Zeit neu eingeführt wird werden wir in 10 Jahren noch benutzen. Ist es demnach nicht ein vertretbarer Mittelweg sich erstmal zurückzuhalten, andere die ersten Erfahrungen machen zu lassen und erst dann mit einzusteigen wenn sich die neue Idee durchgesetzt hat? So verlockend das auch klingen mag, eine Option ist es leider nicht. Konsequent durchgezogen würde es die eigene Firma zum Nachzügler der Modernisierung machen, bei dem neue Möglichkeiten erst als letztes genutzt werden können und um das alle mit Pioniergeist und Zukunftsoffenheit ausgestatteten Arbeitskräfte einen grossen Bogen machen werden. Ein solches Unternehmen wird kaum wirtschaftlich erfolgreich sein.

Es bleibt das finale Argument: "Aber ich kann nicht mehr!" "Die ganzen Veränderungen sind zu viel für mich!" "Nimmt den hier keiner Rücksicht auf mich?" Ein Aufschrei dem man kaum begegnen kann ohne hartherzig zu wirken, oder? Das kann man auch anders sehen. Nur weil einige nicht mehr dazulernen wollen soll eine ganze Organisation ihre Zukunfsfähigkeit aufs Spiel setzen, und mit ihr auch die aller anderen Angestellten, die in einer veraltenden Arbeitswelt eingekapselt sein würden? Das kann nicht die Lösung sein. Ohne die Bereitschaft zur Veränderung sind die meisten Jobs heute nicht mehr ausübbar. Diese Erkenntnis ist nicht für jeden schön, an ihr vorbeikommen wird man aber genausowenig wie die zu Beginn erwähnten Damen und Herren an Word und Excel vorbeigekommen sind.

Donnerstag, 20. Juni 2019

Agiles Change Management (III)

FS
Bild: Pexels / Rawpixel - CC0 1.0
Es ist eine der kleineren Meldungen, die im grossen Nachrichtengeschehen kaum Aufmerksamkeit finden: zum ersten mal seit dem Krieg hat die CDU die Landratswahl in Osnabrück verloren. Gewonnen hat stattdessen eine Anna Kebschull von den Grünen. Was diese Lokalmeldung besonders macht ist eine ihrer Aussagen nach der Wahl: "Mein Stil sieht vor allem Transparenz und eine Kommunikation vor, die nicht vorgefertigte Pläne vorlegt und dann durch Sprachregelungen anderen Leuten erklärt, warum sie sie gut zu finden haben. Ich will offen Probleme ansprechen, Lösungen vorschlagen, Expertisen einholen und Akteure vor Ort einbeziehen, um gemeinsamen Pläne zu stricken." Das ist etwas Besonderes.

Klassisches Change Management funktioniert in seiner Kommunikation genau umgekehrt, nämlich so wie Kebschull es mit ihren treffenden Worten beschreibt: den Menschen wird nur noch erklärt warum sie das fertig festgelegte und geplante Vorgehen gutzufinden haben. Das gibt es in der Politik (mit der berüchtigten Formulierung alternativlos), das gibt es aber auch in der freien Wirtschaft, bei Umstrukturierungen, Strategiewechseln, Entlassungen, etc. Der Grund dafür ist, dass dieses Vorgehen wunderbar zur alten Top-Down- oder Wasserfall-Welt passt. Planung, Durchführung, Verkündung - das ist idealtypische Sequenzialität. Und idealtypisch in mehr als eines Hinsicht: für die Realität ist sie kaum geeingnet.

Selbst wenn man annimmt, dass es vielleicht wirklich alternativlose Entscheidungen gibt - die meisten sind es nicht, mit ihnen sollte man anders umgehen. Dort wo die Zukunft nocht nicht klar absehbar ist (und damit dort wo Agilität und agiles Change Management Sinn machen) kann das blosse "Durchkommunizieren" bereits beschlossener Pläne keine Option sein. Stattdessen muss die Durchführung frühzeitig und regelmässig durch Überprüfung und Feedback validiert werden, mit der begleitenden Kommunikation als zentralem Faktor. Wenn diese nämlich nicht nur von oben nach unten sondern auch von unten nach oben verläuft kann sie wertvolle Informationen zu Sinnhaftigkeit und Akzeptanz eines Vorgehens enthalten.

Oben angekommen sollten diese Rückmeldungen die Grundlage eines Inspect & Adapt-Prozesses sein, dessen Ergebnisse wieder nach unten weitergegeben werden, als Grundlage für weiteres Feedback nach oben. Etc., etc. Um im Rahmen dieser Kommunikationsschleifen nicht zu erstarren muss aber eine weitere Voraussetzung gegeben sein: Geschwindigkeit. Nur wenn die Feedbackschleifen kurz sind kann auch die Reaktion auf Veränderung rechtzeitig erfolgen, sind sie zu lang wird nur an den Problemen der Vergangenheit gearbeitet, nicht an denen der Gegenwart. Und ja, derartig schnelles Feedback ist auch in grossen Organisationen möglich, dafür gibt es Beispiele.

Für Change Management-Einheiten die bisher nur auf Verkündung ausgerichtete Einwegkommunikation gewöhnt waren bedeutet ein derartiges Vorgehen eine fundamentale Neuausrichtung, weg von gewohnten und lieb gewonnen Mustern. Das kann weh tun. Allen die davon betroffen sind kann man aber raten sich durch diese Schmerzen zu arbeiten. Die Alternative wäre noch unangenehmer: irgendwann feststellen zu müssen gar kein Change Management zu sein sondern ein Planwirtschafts- oder Stillstandsmanagement.
Powered by Blogger.