Mittwoch, 30. November 2022

Kommentierte Links (XCIV)

Bild: Pixabay / Buffik - Lizenz
Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Kunal Bhalla: Eating Elephants

Mal wieder ein Artikel bei dem bereits der Entstehungsprozess interessant ist - Kunal Bhalla hat ihn nach und nach in einem öffentlich zugänglichen Google Doc verfasst und so bereits zu frühen Versionen Feedback erhalten können. Das seit diesem Monat weitgehend fertige Ergebnis ist ein ausführlicher Überblick über alle Aspekte die beim Starten und Durchführen grosser IT-Projekte zu beachten sind. Das ist z.T. etwas technisch, viele Passagen beschäftigen sich aber auch mit Organisations-, Kommunikations- und Denkmustern. Und obwohl das Wort Agile kein einziges mal vorkommt würde eine Umsetzung aller Empfehlungen definitiv dazu führen, dass das Projekt in dem sie umgesetzt werden weitgehend agil aufgestellt ist.

Liam Kane: Agile Portfolio Management

Ein häufiges Antipattern in agilen Teams und Projekten ist, dass zu wenig über den nächsten Sprint hinaus geplant wird. Die Motive dafür sind zwar grundsätzlich verständlich, schliesslich würde eine zu detaillierte Langfristplanung auf Kosten der Agilität gehen, zu wenig Planung führt aber oft zu "Fahren auf Sicht" und zu unnötig häufigen Kurswechseln. Liam Kane versucht hier aufzuzeigen wie sich Planungsvorlauf und Agilität kombinieren lassen. Dazu kombiniert er das Drei Horizonte-Modell mit Portfolio-Kanban und dem Weighted Shortest Job First-Modell. Wie immer in solchen Fällen ist zwar davon abzuraten seinen Ansatz unreflektiert zu kopieren, einen interessanten Impuls bieten kann er aber auf jeden Fall.

Kent Beck: Cloud Development Environments Tame Complexity By Reducing State

Noch einmal ein etwas technischeres Thema. Kent Beck, der Erfinder des Extreme Programming, teilt in seinem Blog seine Gedanken zu einem Thema, das selbst die meisten Experten vermutlich nicht als entscheidend für mehr oder weniger Agilität sehen würden: sollte sich die Entwicklungsumgebung eines Entwicklers auf seinem lokalen Rechner befinden oder in der Cloud? Basierend auf vier Faktoren die zu Kontrollverlust in Softwareentwicklungs-Vorhaben führen können (Variabilität, Vernetztheit, Status-(Un)eindeutigkeit, Irreversibilität) kommt er zu dem Ergebnis, dass Cloud-Umgebungen wesentlich besser geeignet sind um schnell arbeits-, liefer- und reaktionsfähig zu sein.

Michael Lloyd: Dysfunction Mapping; A tool for effective Agile Coaching

Wie oben bereits gesagt, methodische Ansätze und Werkzeuge sollten nicht unreflektiert kopiert werden, können aber wertvolle Inspirationen sein. Auch auf das Dysfunction Mapping von Michael Lloyd trifft das zu. Mit ihm hat er eine Möglichkeit gefunden mit Hilfe einer grafischen Zuordnung Dysfunktionen und ihre Symptome voneinander zu differenzieren und mit den verschiedenen Organisationsprinzipien zu verbinden, die von ihnen negativ beeinflusst werden. Auch ein Umsetzungsweg gehört dazu, der die Phasen Themensammlung, Verknüpfung, Zweck-Analyse und Lösungs-Hypothese umfasst. Mit ihm kann man das Dysfunction Mapping nach und nach vor sich entstehen lassen.

Jason Yip: “What improves developer productivity?” is the wrong question

Als letztes wieder ein Klassiker. Jason Yip nimmt sich einmal mehr des Themas an, warum es nicht zielführend ist Organisationen auf maximale Entwickler-Produktivität zu optimieren (was aufgrund des missverständlichen Slogans "Doing twice the work in half the time" immer wieder das Ziel agiler Transitionen ist). Mit Hilfe einer einfachen Wertstrom-Visualisierung zeigt er auf, dass die Effekte im Zweifel sogar das Gegenteil von dem sein werden was gewünscht ist. Die altbekannte Erkenntnis am Ende: wer eine bessere Systemleistung will muss auch das Gesamtsystem optimieren, nicht nur seine Einzelteile.

Montag, 28. November 2022

Chesterton's Fence

Bild: Rawpixel - CC0 1.0

Beim Navigieren und Unbestimmtheit und Komplexität ist es immer hilfreich, ein Set an hilfreichen Verhaltens- und Erkenntnis-Grundsätzen parat zu haben. Als Schutz vor Affekthandlungen und verzerrten Wahrnehmungen können sie dazu beitragen weniger voreilige und wenig durchdachte Entscheidungen zu treffen. Einer dieser Grundsätze ist Chesterton's Fence, benannt nach dem britischen Schriftsteller und Philosophen Gilbert Keith Chesterton.


Chesterton (dem man eine Vorliebe nachsagte, seine Erkenntnisse in Form von Sprichwörtern und Allegorien festzuhalten) wollte mit seinem Zaun-Vergleich seine Leser davor bewahren, bei Reform- oder Erneuerungsvorhaben vorschnell die bisher vorhandenen Regeln und Prozesse abzuschaffen, ohne darüber nachzudenken aus welchem (möglicherweise noch immer relevanten) Grund sie ursprünglich eingeführt wurden. Er lautet stammt aus seinem Buch The Thing und lautet folgendermassen:


In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don't see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.


Was beim Lesen dieser Passage aus Chestertons Buch auffällt ist, dass er sich dem Phänomen der voreiligen Veränderung in zwei Dimensionen annähert. Zum einen der des zu reformierenden Sachverhalts. Wer die Gründe für die Einführung der vorhandenen Regeln und Prozesse nicht kennt nimmt nur einen Teil des Systems wahr das er verändern will, mit der Folge, dass die Veränderung unabsehbare Wechselwirkungen auslösen können, ggf. mit negativen Folgen.


Wichtiger ist aber die andere Dimension, die des Menschen der die Veränderungen anstösst. Die in solchen Momenten häufige Aussage "darin sehe ich keinen Sinn" zeigt für Chesterton eben nicht auf, dass dort keiner ist, sondern dass demjenigen der sie ausspricht ein Erkenntnis-Kurzschluss unterläuft: er geht davon aus, dass etwas das er selbst nicht wahrnimmt nicht existieren kann. Er unterliegt damit einem individualistischen Fehlschluss und baut seine weiteren Handlungen auf diesem auf.


Chesterton's Fence ist damit ein Aufruf zu mehr Selbstreflexion. Bevor man sich an die Reformierung eines komplexen Systems begibt sollte man sich immer fragen, ob die Wahrnehmung von dessen Ist-Zustand wirklich der Realität entspricht oder eher von eigenen Annahmen und gedanklichen Abkürzungen geprägt ist. Tut man das nicht besteht nicht nur das Risiko, dass ungewollte Ergebnisse eintreten, man wird auch von denen überrascht werden und ihre Entstehung nicht verstehen.

Donnerstag, 24. November 2022

Agile bureaucracy (and Hope)

Ich hätte schon früher eine Karriere als Vortragsredner anstreben sollen, die Ideen hätte ich gehabt. Vor über sechs Jahren habe ich über organisatorische Schulden geschrieben, und jetzt sind sie ein Ausgangspunkt auf den Jurriaan Kamer seinen hörenswerten Vortrag aufbaut. Zum Ansehen empfohlen.



Was man ihm hoch anrechnen muss ist, dass er es nicht beim Anprangern von Missständen belässt. Er versucht auch herauszuarbeiten was man besser machen kann, und das an konkreten Beispielen aus Firmen die ihre Arbeitsweisen bereits umgestellt haben.

Montag, 21. November 2022

Die häufigsten Fehler bei einer Kanban-Einführung (II)

Bild: Wikimedia Commons / Anick Marie - CC BY-SA 2.0

Dass es bei der Einführung von Kanban gibt es so einiges gibt, auf das man achten muss, dürfte hoffentlich klar sein, sowohl in Bezug darauf woran man auf jeden Fall denken sollte, als auch in Bezug auf das was man besser lassen sollte. In der letzten Kategorie findet sich aber auch etwas das viele überraschend finden - man sollte am Anfang besser keine Work in Progress-Limits (WIP-Limits) einführen. Wenn überhaupt ist das ein späterer Schritt, zu Beginn macht er fast nie Sinn.


Auf den Einen oder Anderen mag das verwirrend wirken. Sind WIP-Limits nicht ein zentraler Teil von Kanban? Und funktioniert die Einführung von Kanban nicht so, dass man alle Arbeit auf einem Board visualisiert und dann begrenzt wie viel davon gleichzeitig durchgeführt wird, damit das was begonnen wird dadurch schneller fertig werden kann? Die Antwort: ja und nein. Ja WIP-Limits sind zentral, und nein, man sollte sie nicht so früh einführen, selbst wenn das gut gemeint ist.


Am einfachsten zu verstehen ist das in dem Fall, in dem alle bisherigen Arbeitspakete einfach auf ein To Do-In Progress-Done-Board gepackt werden. Dann wird sich dort gleichzeitig Arbeit aus verschiedenen Be- oder Verarbeitungsphasen befinden, mit einem gemeinsames WIP-Limit für alle. Dieses würde aber einzelne Gruppen wie z.B. die UX-Designer in die Untätigkeit zwingen, wenn andere, etwa die Tester, so viel parallele Arbeiten durchführen, dass dadurch die Obergrenze erreicht ist.


Aber auch bei ausdifferenzierteren Systemen, wie z. B. Design-Umsetzung-Test-Rollout können frühe WIP-Limits kontraproduktiv sein. Es kann zwar nicht mehr der zuletzt genannte Fall vorkommen, in dem sich verschiedene Phasen gegenseitig blockieren, in einem System das seine Umstellung auf Kanban gerade erst begonnen hat wird es aber noch Abhängigkeiten nach aussen geben, z.B. zu einer Einheit die Testdaten so langsam bereitstellt, dass ein WIP-Limit auch hier Leerlauf erzwingen würde.


Man kann sich noch weitere vergleichbare Konstellationen vorstellen, die zentrale Erkenntnis ist aber klar: wenn eine Organisationseinheit ihre Rahmenbedingungen nicht selbst unter Kontrolle hat erzwingen Work in Progress-Limits im Zweifel nicht mehr Focus und schnelle Fertigstellung sondern führen zu erzwungener Untätigkeit und zu Konflikten mit anderen Einheiten, auf deren Zulieferung oder Beteiligung man angewiesen ist um die selbstgesetzte (den anderen ggf. gar nicht bekannte) Obergrenze zu halten.


Die bessere Reihenfolge im Rahmen einer Umstellung auf Kanban wäre daher, zuerst die Arbeit zu visualisieren (was schon schwieriger ist als man denken sollte), dann den Beteiligten das Wissen und die Berechtigungen geben um ihre Rahmenbedingungen zu verändern und dann erst über WIP-Limits nachzudenken. Es kann (und sollte) dann natürlich auch zu ihnen kommen, der Punkt an dem das passiert liegt dann aber nicht mehr am Anfang sondern deutlich später.


Um zuletzt ein häufiges Gegenargument gleich abzufangen: ja, man könnte es für eine Übergangszeit zulassen, dass die WIP-Limits regelmässig verletzt werden und währenddessen daran arbeiten, dass das irgendwann nicht mehr nötig ist. Das hätte aber eine (unbewusste) Erziehung zur Normverletzung zur Folge, und das ist etwas wovon man jeder Organisation nur dringend abraten kann, wenn sie nicht in ganz andere Probleme geraten will.

Donnerstag, 17. November 2022

Conway's Law

Bild: Pixabay / Succo - Lizenz

Wenn irgendwo über gute und schlechte Software-Architektur diskutiert wird, wird mit grosser Wahrscheinlichkeit früher oder später das so genannte Conway's Law erwähnt werden, und zwar entweder als Antipattern das man unbedingt vermeiden sollte oder als häufig anzutreffender Wildwuchs, der möglichst schnell zu beseitigen ist. Einigkeit besteht aber immer darüber, dass es etwas Schlechtes ist. Es lautet folgendermassen:


Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Auf Deutsch: Organisationen die IT-Systeme entwerfen neigen dazu, die System-Designs so zu gestalten, dass sie Kopien ihrer Kommunikationsstrukturen sind.


Dieses "Gesetz" verdanken wir Melvin Conway, einem amerikanischen Software-Entwickler, der die Beobachtung auf der es beruht bereits in den 60er Jahren machte. Popularisiert (und mit seinem heutigen Namen versehen) wurde Conway's Law erst ein Jahrzehnt später von Frederick Brooks in seinem bis heute häufig zitierten Buch The Mythical Man Month. Und gültig und in vielen Organisationen zu beobachten ist es bis heute.


Dass Conway's Law immer wieder auftritt erklärte Conway damit, dass in grossen Organisationen häufig eine nur eingeschränkte Sicht auf Abläufe und Strukturen vorliegt. Eine Abteilung erkennt zwar wer ihr Informationen übergibt (z.B. ein Manager) oder wer sie von ihr entgegennimmt (z.B. eine nachgelagerte Organisationseinheit), wo sie ursprünglich entstehen, wo sie letztendlich enden oder durch welche anderen Stationen sie gehen ist aber nicht nachvollziehbar.


Bedingt dadurch wird bei vielen Digitalisierungs- oder Automatisierungs-Vorhaben immer nur an den Bereichen gearbeitet die bekannt sind, also zwischen der eingehenden und ausgehenden Kommunikationsschnittstelle liegen. Da das nicht nur in einer Abteilung stattfindet, sondern tendenziell jede so vorgeht, entsteht nach und nach für jede der Abteilungen ein entsprechendes IT-System, so dass die Systemlandschaft am Ende dem Organisationsaufbau entspricht.


Dieser Effekt mag auf den ersten Blick unproblematisch erscheinen, er ist es aber nicht. Wenn z.B. zwei Abteilungen unabhängig voneinander eine Übersicht über die Firmenkunden erhalten, sie aufgrund von Conway's Law in verschiedenen Systemen ablegen und sie nur um die jeweils eigenen Informationen zu Verkäufen, Verträgen, Beschwerden, etc. erweitern, dann wird eine firmeweite Sicht auf die Kundenbeziehungen unmöglich.


Auch weitere Probleme sind leicht vorstellbar. Verschiedene Abteilungen können z.B. die selben Daten benötigen, die dadurch von Kunden oder Kollegen redundant in verschiedene Systeme eingegeben werden müssen, sie können unterschiedliche Dateiformate verwenden, die nicht in andere Systeme übertragbar sind oder sie können unterschiedliche Vorgaben für Datenmengen oder IT-Sicherheit haben, durch die die verschiedenen Systeme inkompatibel werden.


Zuletzt werden Änderungen von übergreifender Bedeutung schwierig und aufwändig. Soll etwa in alle personenbezogenen Datensätze das neue Information "Arbeitsadresse" eingeführt werden muss ermittelt werden an welchen Stellen das nötig ist und ob es überall gleich umgesetzt werden kann, dazu muss die zeitgleiche Umsetzung koordiniert werden, möglichweise einschliesslich der Auflösung von Planungs- und Priorisierungskonflikten. All das kostet Zeit und Geld.


Um diese Auswirkungen zu vermeiden sollte versucht werden die Ursachen für Conway's Law zu beseitigen, indem Digitalisierungs- oder Automatisierungs-Vorhaben immer aus einer übergreifenden Perspektive konzipert werden. Um das zu erreichen gibt es zwei grundlegend unterschiedliche Ansätze: man kann zentrale Kontroll- und Koordinationsinstanzen schaffen, oder die Code Ownership auflösen und allen Einheiten erlauben übergreifend am Gesamtsystem zu arbeiten.


Der klassische Weg in den meisten Organisationen ist der erste, also die zentrale Kontroll- und Koordinationsinstanz, die versucht den zentralen Überblick zu wahren. Aus einer "agilen Weltsicht" ist dagegen die zweite besser, die aber eine Reihe von Voraussetzungen erfordert: übergreifendes System- und Business-Verständnis der Entwicklungsteams, Clean Code, hohe Testabdeckung und eine Einigung auf gemeinsame Standards in Formatierung, Programmierung, etc.


Egal welche Variante (oder Kombination der beiden) man bevorzugt, auf Eines kann sich aber so gut wie jeder einigen: alles ist besser als Conway's Law einfach hinzunehmen - dafür sind seine negativen Auswirkungen zu offensichtlich und zu schwerwiegend.

Montag, 14. November 2022

Ein Bild sagt mehr als 1000 Worte (XXXIV)

Grafik: monkeyuser.com - License

Zugegeben, es sind zwei Bilder. Aber darüber sehen wir heute einmal hinweg. Was mir ein Entwickler-Team einmal zu diesen beiden auf den ersten Blick schlichten Zeichnungen gesagt hat: it keeps on giving, oder mit anderen Worten - man entdeckt immer weitere Details die erkennbar an Phänomene aus dem echten Leben angelehnt sind.

Freitag, 11. November 2022

Warum agil? Discovery, Delivery, Reparatur, Resilienz

Bild: Andy Mabbett / Wikimedia Commons - CC BY-SA 3.0

Sinn- und Zweck-Fragen sind immer wieder erhellend. Im Umfeld agiler Transformationen ist eine von ihnen ein grosser Klassiker: die nach dem Grund wegen dem dort überhaupt agil gearbeitet werden soll. Häufig gibt es die generische Antworten, dass mehr Flexibilität oder höhere Reaktionsgeschwindigkeit angestrebt würden. Auf die Folgefrage wofür genau die nötig sind kommt dann häufig nicht mehr viel. Dabei gibt es gleich mehrere gute Antwortvarianten, z.B. Discovery, Delivery, Reparatur und Resilienz.


Bevor wir dazu kommen aber eine schnelle Definition: als Agilität wird hier die Fähigkeit verstanden in kurzen Abständen reaktions- und lieferfähig zu sein, sonst nichts. Allen die noch mehr darunter verstehen, wie z.B. Humanismus, (Basis-)Demokratie, New Work oder Achtsamkeit, seien zuerst dieser und dieser Artikel empfohlen. Ihre Kernaussage: wie alle Begriffe sollte man auch den der Agilität nicht überfrachten, wenn er benutzbar bleiben soll. Und damit zurück zu den vier Varianten.


Discovery

Um es als Beispiel-User Story zu formulieren:1 Als Startup möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um Kundenbedürfnisse die ich neu entdecke schnell bedienen zu können. Einer der grossen Klassiker unter den Anwendungsfällen der Agilität - ein neues Produkt entsteht erst nach und nach in zu Beginn noch rudimentären Umfängen, und erst wenn mit denen validiert wird, dass es Nutzungs- und Zahlungsbedeitschaft gibt, kommt die nächste Umfangs-Erweiterung. Wenn nicht wird die Entwicklung eingestellt. Umgekehrt kann es auch sein, dass die Neuentdeckung von Nutzern oder Bedürfnissen dazu führt, dass Produktentwicklungsziele schnell dorthin ausgerichtet werden. Das klassische Framework dafür ist Lean Startup.


Delivery

Beispiel-User Story: Als Unternehmen im gesetzlich regulierten Umfeld möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um meine Produkte schnell an neue Vorschriften anpassen zu können. Zunächst weniger intuitiv verständlich, bei etwas Nachdenken macht es aber Sinn. Stark regulierte Branchen wie z.B. der Banken- und Versicherungs-Sektor müssen mitunter im Monatsrhythmus neue Vorschriften in ihren automatisierten Prozessen abbilden. Starre Planung und unflexible Umsetzung sorgen oft dafür, dass Stichtage nicht eingehalten werden können, mit Strafen durch die Aufsichtsbehörden als Folge. Ausgerechnet dort wo es starke Regulierungen gibt wird daher in immer mehr Firmen versucht agil zu arbeiten. Die Methoden-Klassiker sind dabei Scrum und SAFe.2


Reparatur

Beispiel-User Story: Als Konzern mit veralteter, fehleranfälliger Software möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um die häufig auftretenden Fehlfunktionen schnell reparieren zu können. Man mag es sich kaum vorstellen, aber in vielen Behörden und Unternehmen gibt es Anwendungen die seit dreissig oder vierzig Jahren in Betrieb sind, oder noch länger. In den meisten derartigen Fällen führen unentdeckte Bugs, übersehene Seiteneffekte oder historisch gewachsene Komplexität zu ständig auftretenden Funktionsfehlern. Wenn zentrale oder profitable Geschäftsprozesse davon betroffen sind ist es von kritischer Bedeutung, dass Ressourcen schnell umgeplant und Reparaturen zeitnah und unbürokratisch stattfinden können. Methodisch können einige DevOps-Aspekte sehr hilfreich sein.


Resilienz

Beispiel-User Story: Als von ständigen Disruptionen betroffenes Unternehmen möchte ich in kurzen Abständen reaktions- und lieferfähig sein, damit ich die Schäden durch externe Störungen begrenzen kann. Ein mit dem letzten verwandter Fall, mit dem Unterschied, dass die Probleme nicht (versehentlich) selbst erzeugt wurden sondern von aussen kommen. Das kann der neue und innovative Wettbewerber sein, aber auch Naturkatastrophen, Hackerangriffe oder Netzausfälle. Die Agilität wird hier gebraucht um diese Störungen früh zu erkennen, ihre Auswirkungen schnell zu begrenzen und möglichst schnell Kompensations- und Wiederherstellungsmassnahmen einleiten zu können. Das vermutlich am besten geeignete agile Framework ist Chaos Engineering.


Im Zweifel wird es auch noch weitere Herausforderungen geben wegen denen Agilität erstrebenswert ist, der allergrösste Teil wird sich aber einer dieser vier zuordnen lassen. Und dort wo das nicht möglich ist, ist es eine gute Idee genau zu prüfen ob nicht eine eher unsinnige Motivation der eigentliche Treiber ist (z.B. "Ich als Manager möchte überall schnell durchregieren können, wenn ich eine meiner monatlichen spontanen Eingebungen habe." oder "Wir wollen Modernität vortäuschen um Bewerber anzulocken".).


Und natürlich wird es immer wieder vorkommen, dass gleich mehrere der hier genannten Gründe für das Streben nach Agilität vorliegen, und zwar parallel. Das macht das Leben zwar nicht einfacher, es bietet aber immerhin einen kleinen Trost: mit der Einführung passender agiler Arbeitsweisen kann man in mehreren dieser Bereiche gleichzeitig für Verbesserungen sorgen.



1Die Debatte ob man User Stories aus der Perspektive eines Unternehmens formulieren sollte (eigentlich nicht) ignorieren wir heute einfach.
2Es gibt natürlich noch andere Konstellationen in denen Delivery im Focus steht, das hier ist nur ein Beispiel

Dienstag, 8. November 2022

Überstunden

Bild: Unsplash / Jonas Leupe - Lizenz

Zu den unschönsten Momenten im Leben eines Angestellten (oder eines von einem Auftraggeber abhängigen Freiberuflers) gehört es, wenn er direkt oder indirekt zu Überstunden aufgefordert wird, schlimmstenfalls verbunden mit der Drohung, bei der Nicht-Erreichung eines in normaler Arbeitszeit nicht zu erreichenden Ziels gefeuert oder nicht weiterbeauftragt zu werden. Als Betroffener ist man maximal genervt und frustriert. 


Trotzdem kommt es immer wieder dazu, die aktuelle Deadline für die an Twitters Bezahlfunktion arbeitenden Teams dürfte z.B. jetzt schon ein Klassiker unter den derartigen Fällen sein. Je nachdem wie abhängig vom Job oder wie beeinflussbar die zu Überstunden aufgeforderten Menschen sind kann es in solchen Konstellationen nicht nur zu einem späten Feierabend kommen sondern sogar zum Extrem: zum Übernachten am Arbeitsplatz, um möglichst viel Zeit dort verbringen zu können.


Quelle: Twitter


Was manchmal in solchen Fällen diskutiert wird - ist das nicht ein notwendiger Teil einer agilen Arbeitsweise? Muss man nicht immer wieder Überstunden schieben, wenn es notwendig ist (oder versprochen wurde) regelmässig Ergebnisse abzuliefern? Die Antwort darauf kann nur ein sehr verhaltenes "kommt drauf an" sein, denn selbst wenn es Fälle geben mag in denen das so ist - in den meisten erreicht man eher den gegenteiligen Effekt.


Um mit dem Grundsätzlichen zu beginnen: Agil zu arbeiten bedeutet, dass man schnell und ergebnisorientiert auf Veränderungen reagiert (responding to change over following a plan). Das bedeutet aber gerade nicht, dass Liefertermine und Lieferumfänge auch bei sich unerwartet ändernden Rahmenbedingungen eingehalten werden müssen, im Gegenteil. Da diese Termine und Umfänge Teil des initialen Plans sind wäre ein Beharren auf ihnen sogar hochgradig un-agil.


Natürlich kann es Grenzfälle geben. Die Leitmesse zu der ein Produkt fertig sein muss, wenn es dieses Jahr noch auf den Markt soll, oder den Stichtag an dem eine gesetzliche Regulierung in Kraft tritt, der eine IT-gestützte Dienstleistung entsprechen muss. Wichtig ist dann aber, dass sie nur in Ausnahmen auftreten und dass sie tatsächlich derartig harte Ursachen haben. In den meisten Fällen trifft das aber nicht zu, da ist die zentrale Motivation, dass Planänderungen einfach nicht gewünscht sind.


Diese Änderungsunwilligkeit wird dann häufig (schein-)rationalisiert, und das auch noch mit Argumenten die scheinbar zur Idee der Agilität passen: die Lead Time oder Time to Market soll kurz sein, die Verzögerungskosten (Cost of Delay) gering, das Kundenfeedback möglichst früh verfügbar. All das sind auch gute Ziele, was in einer solchen Argumentation häufig übersehen wird, ist aber der Preis der zu zahlen ist, wenn man sie mit Überstunden zu erreichen versucht.


Wie vermutlich jeder aus eigener Erfahrung bestätigen kann neigen überarbeitete, übermüdete und gestresste Menschen dazu mehr Fehler zu machen als solche die ausgeschlafen und ausgeglichen sind. Und diese Fehler führen zwangsläufig zu einem von zwei Effekten: entweder muss alles vor dem Release wieder in Ordnung gebracht werden (wodurch Zusatzaufwände entstehen, die alles verlangsamen) oder fehlerhafte Produkte gehen live, mit Fehlfunktionen und Hotfixes auf Produktion als Folge.


Vor allem dort wo regelmässig Überstunden gemacht werden häufen sich derartige Mehraufwände, und das oft in einem derartigen Ausmass, dass der scheinbare Zeitgewinn durch Überstunden ausgeglichen oder sogar in sein Gegenteil verkehrt wird. Zieht man ausserdem in Betracht, dass regelmässige Überstunden fast immer zu Abwanderung der Mitarbeiter in andere Unternehmen führen (verbunden mit Zusatzkosten für Recruiting und Onboarding) verschwindet der Business Case fast völlig.


Jedem Entscheidungsträger kann man daher nur raten es sich dreimal zu überlegen was er tut bevor er zu Überstunden aufruft. So verlockend die Aussicht auch sein mag damit irgendetwas kurzfristig zu erreichen - langfristig werden diejenigen Unternehmen erfolgreicher sein, die ihren Mitarbeitern ein ruhiges, kontinuierliches und steressfreies Arbeiten ermöglichen.

Donnerstag, 3. November 2022

Before you Scale - Descale

Mir ist gerade aufgefallen, dass es auf dieser Seite noch kein Video von mir gibt - bis jetzt. Das hier ist mein Vortrag vom Scaling Agile Summit im letzten Sommer, den ich auf dem Telekom Agilista-Barcamp wiederholt habe, wo er freundlicherweise aufgenommen wurde. Das Thema ist eines das mich schon lange begleitet und beschäftigt, die agile Skalierung.



Ich weiss nicht ob es daran liegt, dass ich zu dem Zeitpunkt Corona-positiv und dadurch etwas unkonzentriert war, aber ich höre in meinem Vortrag viel zu viele Ähs. Da muss ich noch an mir arbeiten