Donnerstag, 26. Dezember 2019

Lokale Optimierung (II)

Bild: Pixabay / Carlotta Silvestrini - Lizenz
Es war eine der kurioseren Meldungen der diesjährigen Weihnachtszeit. Wie der Spiegel berichtete kursierte bei Siemens der so genannte "Keks-Erlass", eine Anweisung sich beim Konsum von Kaffee und Keksen zurückzuhalten um so Kosten zu senken. Was der spezifische Grund in diesem Fall ist kann man nur erraten, wer aber länger in Grossunternehmen gearbeitet hat wird von dieser Anekdote nicht überrascht sein, derartige Sparprogramme in eigentlich kleinen und aus Systemsicht irrelevanten Budgets gibt es immer wieder. Aber wo kommen sie her?

Wenn man den hin und wieder als Verursacher vorkommenden "Faktor Mensch" (in Form übereifriger Mittelmanager) und das gelegentlich auftretende Gesetz der Penetranz der negativen Reste ausser acht lässt bleibt vor allem ein immer wiederkehrender Auslöser für derartige Einsparversuche - ein globales Sparprogramm wird auf alle Teile des Unternehmens umgeschlagen, z.B. muss jeder 10 % weniger ausgeben. Das trifft dann auch Einheiten wie das Catering, das dann nur noch an einer Stelle einsparen kann: der Bewirtung.

Was dabei beachtet werden muss: aus einer Topmanagement-Perspektive macht dieses Vorgehen meistens Sinn. Würden derartige Optimierungen nicht einheitlich auf alles ausgerollt, würde sehr schnell fast jede Einheit beantragen, dass gerade bei ihr eine Ausnahme gemacht werden müsste. Die Begründungen dafür sind meistens so detailspezifisch, dass sie nur mit grösserem Verständnisaufwand nachvollziehbar wären, wofür schlicht die Zeit fehlt. Um dieser Situation zu entgehen fällt der Sparhammer auf alles.

Aus der operativen Perspektive ist die Sicht dagegen eine andere: ich habe schon verschiedene derartige herunterkaskadierte Detail-Sparmassnahmen erlebt, von der oben genannten Reduzierung der Bewirtung über das Verbinden der Beleuchtung mit Bewegungsmeldern bis hin zum Abzählen von Flipchart-Blättern für einzelne Meetings. Das Ergebnis in praktisch jedem einzelnen Fall - am Ende war nichts billiger und vieles sogar teurer als vorher.

Die offensichtlichste Art der Verteuerung entsteht durch Verwaltungsaufwände. Wenn ein Meeting-Organisator z.B. für jeden seiner Termine drei abgezählte Flipchart-Blätter aus einer Materialausgabe abholen muss, sind alleine die dafür nötigen Arbeitszeiten so teuer, dass man den Raum damit tapezieren könnte. Und wenn für das Abzählen und Aushändigen ein Mitarbeiter durchgehend in der Materialausgabe sitzen muss, vervielfachen sich die Kosten.

Auch das Stromspar-Beispiel hatte ähnliche Effekte. Da in allen Räumen das Licht ausgehen musste wenn die Sensoren keine Bewegung wahrnahmen sassen regelmässig Mitarbeiter in den Toiletten-Kabinen im Dunkeln. Diese waren so eng, dass selbst heftiges Winken ausserhalb des Aufzeichnungsbereichs der Bewegungssensoren stattfand. Notgedrungen wurden die "Geschäfte" jetzt in den Stockwerken verrichtet in denen die Toiletten Fenster hatten. Die täglichen Wanderungen dorthin dauerten lange und kosteten damit Arbeitszeit und Produktivität.

Am teuersten waren aber (und hier kommen wir wieder zur Siemens-Geschichte) die Einsparungen bei Kaffee, Wasser und Keksen. Das Gefühl auf einer unnötig kleinteiligen Ebene gegängelt zu werden, einschliesslich einer spürbaren Beeinträchtigung der Arbeitsbedingungen (wer einmal mit trockenem Mund vortragen musste kennt das Problem) führte zu einem heftigen und kostspieligen Absacken von Arbeitsmoral, Motivation, Eigeninitiative, Effektivität und Qualität.

In allen Fällen ergaben die lokalen Optimierungen nur bei isolierter Betrachtung Sinn, aus systemischer Sicht waren sie unsinnig und kontraproduktiv. Die Ironie der Geschichte: ausgelöst wurden sie aber durch den (fehlgeleiteten) Versuch, am Gesamtsystem zu arbeiten.

Um es gar nicht erst so weit kommen zu lassen wäre in den meisten Fällen ein anderes Vorgehen sinnvoll. Statt auf intransparente und nicht nachvollziehbare Einzelprozesse mit generischen Vorgaben für alle Einheiten zu reagieren kann man versuchen sie transparent und nachvollziehbar zu machen und dann ihre Interaktionen zu optimieren. Und an der Stelle schliesst sich der Kreis - das kann aufgrund der damit verbundenen Komplexität nur gemeinsam mit den betroffenen Mitarbeitern gelingen, die sich aber nur beteiligen werden wenn sie nicht befürchten müssen dann von Micromanagement und lokalen Pseudo-Optimierungen betroffen zu sein.

Montag, 23. Dezember 2019

Der Weihnachts-Sprint

Bild: Pixabay / destressguy - Lizenz
Die Vorweihnachtszeit ist voller Traditionen die jedes Jahr wieder aufleben. Die Städte hängen voller Leuchtdekorationen, auf Weihnachtsmärkten wird Glühwein ausgeschenkt, im Fernsehprogramm laufen Der kleine Lord und Stirb langsam und in den Scrum Teams rund um die Welt wird kontrovers diskutiert wie der nächste Sprintwechsel aussehen soll.

Der Hintergrund ist einfach: je nach Sprint-Länge und -Rhytmus wird dieser Sprintwechsel entweder in die Weihnachtsfeiertage oder in die Zeit zwischen Weihnachten und Neujahr fallen, in der fast alle Menschen sich im Urlaub befinden. Dass ein geordnetes Durchführen aller Arbeiten und Meetings damit schwer bis unmöglich wird ist klar, aber was soll stattdessen gemacht werden?

Natürlich gibt es darauf mehrere mögliche Antworten. Einige wenige Teams rechnen die Feiertage aus der Sprintlänge heraus, was zwar effektiv ist aber den Kalenderrhytmus durcheinanderbringt. Andere lassen einen Sprint ausfallen und überlassen es den wenigen Kollegen die nicht im Urlaub sind ihre Zeit selbst zu verplanen. Manche ziehen die üblichen Intervalle durch, zur Not mit reduzierter Mannstärke. Die meisten machen aber einen Weihnachts-Sprint mit angepasster Länge.

In der Anwendung sieht das so aus, dass die üblichen Wochentage des Sprintwechsels beibehalten werden, allerdings nicht in den üblichen Abständen zueinander sondern in Relation zu den Feiertagen. Bei einem Mittwochs-Sprintwechsel würde das bedeuten, dass der Weihnachtssprint am letzten Mittwoch vor dem 24.12. beginnt und am ersten Mittwoch nach dem 01.01. endet.

Je nach Jahr würde ein solcher Sondersprint unterschiedlich lang dauern, etwa 2018/19 zwei Wochen oder 2019/20 drei Wochen. Abhängig von der normalen Sprintlänge (möglich sind 1 bis 4 Wochen) kann eine solche Abweichung einen deutlich kürzeren oder längeren Sprint ergeben als üblich, und aufgrund der Gruppierung um die Feiertage auch den davorliegenden Sprint spürbar verkürzen.

Dort wo eine Velocity berechnet wird macht es Sinn diese Sprints aus der Berechnung herauszunehmen, da diese sonst ihre Aussagekraft verlieren würde. Zum einen wegen des von der Norm abweichenden Verhältnisses von Dauer und Durchsatz, zum anderen aber auch weil aufgrund der Urlaube die Crossfunktionalität nicht durchgehend gewährleistet werden kann, was natürlich Auswirkungen auf die Leistungsfähigkeit hat.

Eine Tradition der besonderen Art kommt in manchen Unternehmen noch dazu: als Entschädigung für die Mitarbeiter die im Büro den Betrieb aufrechthalten währen die Kollegen sich auf den Pisten und Stränden befinden wird ihnen ermöglicht selbst zu entscheiden woran sie in dieser Zeit arbeiten wollen. In gewisser Weise ist auch das ein Weihnachtsgeschenk.

Donnerstag, 19. Dezember 2019

Velocity

Bild: Pexels / Mike Birdy - Lizenz
Es gibt Konzepte aus dem Umfeld der agilen Frameworks, die von vielen Teams und Managern mit Begeisterung aufgenommen werden. Man verspricht sich von ihnen das was (scheinbar) durch die Agilität verloren geht: Planbarkeit und Berechenbarkeit. Unter diesen Konzepten ist die Velocity, auf deutsch Durchschnittsgeschwindigkeit, eines der beliebtesten, aber auch eines der am häufigsten falsch verstandenen. Zeit für einen näheren Blick.

Normalerweise wird unter diesem Begriff die durchschnittliche Menge an Story Points verstanden, die ein (Scrum-)Team in einem Sprint fertigstellt. Beispielsweise würde bei 12 Punkten in Sprint I, 14 in Sprint II und 10 in Sprint III eine Velocity von 12 entstehen. In vielen Firmen wird dieser Wert verwandt um die verbleibende Dauer der Produkterstellung zu planen. Dafür wird das Team aufgefordert den verbleibenden Aufwand in Story Points zu schätzen, um diese danach auf einem projizierten Zeitstrahl zu verteilen.

Dieses Vorgehen erscheint auf den ersten Blick naheliegend, enthält aber einen Denkfehler, der sich aus dem folgenden Vergleich erschliesst: bei einem Auto das mit Durchschnittsgeschwindigkeit 120 km/h unterwegs ist, bezieht sich dieser Wert auf die Strecke hinter dem Auto, nicht auf die Strecke vor ihm. Er ist lediglich ein statistischer Mittelwert der Vergangenheit, ob er in Zukunft über- oder unterschritten werden wird, hängt von vielen Faktoren ab: Strassenzustand, Wetter, Verkehrsdichte, Tankfüllung, etc.

Das gilt in gleicher Weise auch für die Produktentwicklung. Gerade im Bereich komplexer Produkte stellt diese keine berechenbare Serienfertigung dar, sondern eine Abfolge von aufeinander aufbauenden und sich unvorhersehbar beeinflussenden Prototypen oder MVPs. Diese können sich in der Zukunft grundlegend anders verhalten als in der Vergangenheit, weshalb die Projektion alter Erfahrungswerte auf die weitere Planung immer wieder auf Probleme stossen wird. Die Nutzung der Velocity zu Planungszwecken ist daher sehr unzuverlässig (und jede andere Art der Prognose wäre es auch).

Das heisst nicht, dass die Erhebung der Velocity völlig unsinnig wäre, man kann durchaus Nutzen aus ihr ziehen. Dieser besteht lediglich nicht daraus, dass man genau planen könnte, wie lange die noch verbleibenden Arbeiten dauern werden. Stattdessen ist sie ein Ausgangswert für eine vorläufige Planung, die ständig anpassbar sein muss, für den Fall, dass das durch neue Erkenntnisse nötig wird. So eingesetzt kann die Velocity ein wertvolles Hilfsmittel sein, aber eben auch nur so.

Montag, 16. Dezember 2019

Andon (II)

Der vermutlich häufigste Einwand gegen das Andon-Konzept ist der, dass es nur im Maschinenbau funktionieren würde. Dass es auch in anderen Teams funktioniert zeigt dieser Vortrag, der aber nicht nur darum interessant ist, sonden auch weil er Andon mit einer anderen grundlegenden Idee verknüpft - der psychologischen Sicherheit.

Donnerstag, 12. Dezember 2019

Ein Bild sagt mehr als 1000 Worte (XXVII)

Montag, 9. Dezember 2019

Wer von agiler Skalierung spricht meint meistens etwas anderes

Bild: Piqsels - Lizenz
Unter allen Herausforderungen, die eine agil arbeitende Organisation mit sich bringt, dürfte die Skalierung die grösste sein. Sobald es nicht mehr nur ein Team ist das nach XP, Scrum, Kanban & Co arbeiten soll, sondern mehrere, und das auch noch aufeinander abgestimmt, müssen Zusammenarbeitsmodelle entwickelt werden. Der hohe Anspruch an sie: sie sollen die auf der Teamebene mögliche Schnelligkeit und Flexibilität bewahren und auf die Gesamtorganisation übertragen, auf der anderen Seite aber auch eine gemeinsame Ausrichtung auf übergeordnete Ziele ermöglichen.

Es gibt tatsächlich auch Organisationen, in denen das gelingt, in den meisten Fällen ist das Ergebnis aber nicht das gewünschte. Entweder führt der Versuch, sich auf ein gemeinsames Ziel auszurichten, wieder zu Hierarchie und Bürokratie, oder eine nicht ausreichende Abstimmung untereinander endet in Ineffizienz und Ineffektivität. "Agil skaliert nicht" ist aufgrunddessen eine häufig zu hörende Aussage geworden. Aber ist das wirklich so? Ein anderer Erkläransatz ist der, dass das, was meistens für agile Skalierung gehalten wird, etwas ganz anderes ist.

Um das zu verstehen rufen wir uns kurz eine agile Organisationsform vor Augen. Am Anfang steht die noch zu erledigende Arbeit, meistens in Form eines Backlogs. Aus dem wird eine Teilmenge entnommen, die durch ein (Sprint-)Ziel zu einem sinnvollen Umfang gruppiert, durch ein crossfunktionales Team idealerweise ohne externe Abhängigkeiten umgesetzt und als benutzbares Increment an die Anwender geliefert wird. Übertragen auf skalierte Ansätze bleibt das Vorgehen das gleiche, nur sind es jetzt mehrere crossfunktionale Teams ohne externe Abhängigkeiten die gleichzeitig auf ein gemeinsames Ziel hinarbeiten. Visualisiert sieht das so aus:



Und jetzt die spannende Frage: entspricht das, was meistens als agile Skalierung bezeichnet wird, diesem Bild? Leider nicht. Es fehlen in praktisch jedem Fall zwei entscheidende Kriterien - die Teams sind eben nicht crossfunktional und haben eben doch zahlreiche externe Abhängigkeiten. Bedingt dadurch ist es in diesen Fällen nicht möglich, konzentriert auf das Ziel hinzuarbeiten, stattdessen sind alle gezwungen auf Zulieferungen zu warten und unfertige Arbeit an andere Einheiten weiterzugeben. Erst wenn alle dieser voneinander abhängigen Teams fertig sind, kann ein benutzbares Increment an die Anwender geliefert werden. Visualisiert (und stark vereinfacht) sieht das so aus:


Dass in einem solchen Konstrukt die Lieferzyklen deutlich länger sind, als in dem zuerst genannten, ist offensichtlich. Sowohl die zeitliche als auch die inhaltliche Koordination der Übergaben ist derartig anspruchsvoll, dass sie einen Grossteil der Arbeitszeit einnimmt. Die vorderen und hinteren Teams der Prozesskette haben keine direkten Berührungspunkte und liegen zeitlich weit auseinander, so dass umfangreiche Dokumentation nötig wird. Wenn ein zulieferndes Team mit der Arbeit fertig ist wird das abnehmende nicht immer verfügbar sein, so dass Wartezeiten im System entstehen. Etc.

Das alles heisst natürlich nicht, dass diese Abläufe nicht optimierbar wären. Aber für eine Optimierung derartiger Systeme sind die agilen Ansätze nicht die beste Lösung. Hier ist das klassische Lean Management besser geeignet, dass mit seinen Wertstromanalysen, Just in Time-Lieferungen und Work in Progress-Limits auch über passende Werkzeuge verfügt. Das wird in der Regel auch unbewusst verstanden, versehentlich aber falsch bezeichnet. Es müssen doch mehrere agile Teams koordiniert werden1, also muss auch diese Koordination agil sein. Der entscheidende Irrtum vieler Transitionsvorhaben ist also der, dass von agiler Skalierung gesprochen wird, implizit aber Lean Management gemeint ist.

Vor diesem Hintergrund wird auch verständlicher, warum die gängigen agilen Skalierungsframeworks oft nicht funktionieren. Sie sind gedacht für crossfunktionale und unabhängige Teams, werden aber angewandt auf Komponententeams mit vielen Abhängigkeiten. Das kann nicht funktionieren. Und um das allen Beteiligten klar zu machen ist das Aufzeigen des zentralen Irrtums wichtig: Wer von agiler Skalierung spricht meint meistens etwas anderes.


1Dass nicht verstanden wird, dass diese Teams ohne Crossfunktionalität und Freiheit von Abhängigkeiten kaum agil sein können, ist Teil des Missverständnisses.

Donnerstag, 5. Dezember 2019

Exvernunft

Bild: Pixabay / Ryan McGuire - Lizenz
In seiner wie immer lesenswerten Kolumne ist es Sascha Lobo gestern gelungen ein neues Wort zu prägen: die Exvernunft. Gemeint ist damit ein Verhaltensmuster das in der Vergangenheit, unter anderen Rahmenbedingungen, absolut vernünftig war, das mittlerweile aber widersinnig geworden ist. Das Entscheidende - dem sich exvernünftig Verhaltenden ist dieser Bedeutungswandel nicht bewusst.

In der Kolumne wird die Exvernunft vor allem Politikern zugeschrieben, sie findet sich aber auch an vielen anderen Stellen. Unter anderem (und hier kommt der Zusammenhang zu den sonst hier behandelten Themen) in den Fehlentscheidungen auf allen Hierarchieebenen, die in vielen Unternehmen die Ursache für Ineffizienz, Ineffektivität oder sogar schwere wirtschaftliche Schäden sind.

Vielen von ihnen ist gemeinsam, dass das was sie bewirken zwar heute schädlich ist, zu früheren Zeitpunkten aber vernachlässigbar war oder unter Umständen sogar positive Effekte hatte. Big Bang Releases, "Ambitionierte Ziele", Perfektionismus, langfristige Detailplanung und Jahresgespräche können in einer weniger komplexen Vergangenheit funktioniert haben, heute ist das nicht mehr der Fall. Das ist aber nicht für jeden ersichtlich.

Die Gründe dafür sind immer wieder ähnlich: die oft mit dem hierarchischen Aufstieg gekoppelte Entfremdung von den Veränderungen der Umsetzungsebene, eine Verklärung der Vergangenheit, Wechselmüdigkeit, Group Think oder einfach nur die trügerische Verlockung scheinbar einfacher Lösungen - letzten Endes ist es in fast jedem Fall die menschliche Fehlbarkeit.

In der menschlichen Natur liegt allerdings neben dem Problem auch die Lösung für das Phänomen der Exvernunft. Wie David Dunning und Justin Kruger in ihrer legendären aber oft missverstandenen Studie gezeigt haben: der Mensch ist nicht nur fehlbar, er ist auch lernfähig. Und selbst aus den Verstrickungen der eigenen Fehlwahrnehmungen kann man sich lösen - wenn man dabei Unterstützung erhält.

Und an dieser Stelle erklärt sich einmal mehr die Existenzberechtigung von Scrum Mastern, Agile Coaches und ähnlichen Rollen. Eine ihrer zentralen Aufgaben ist es bestehende Prozesse, eingeübte Routinen und langbewährte Handlungsmuster immer wieder aufs Neue auf ihre Tauglichkeit zu überprüfen. Mit anderen Worten: sie sollen Exvernunft aufspüren und beseitigen.

Eine wichtige und verdienstvolle Aufgabe. Und eine von Dauer.

Montag, 2. Dezember 2019

The Agile Bookshelf: The Phoenix Project

Bild: Flickr / Steward Butterfield - CC BY 2.0
Um einen Klassiker wieder hervorzuholen - einer der Gründe wegen denen es nervt Scrum Master (oder Agile Coach) zu sein ist der, dass ein immer grösser werdender Stapel Bücher darauf wartet endlich gelesen zu werden. Tatsächlich kommt derart viel auf den Markt, dass nichts anderes übrig bleibt als den eigenen Rat zu befolgen, Wichtiges zu priorisieren und Unwichtiges wegzulassen. Um so schöner ist es wenn man wieder auf ein gerade durchgelesenes Buch zurückblicken kann. Heute: The Phoenix Project von Gene Kim.1

The Phoenix Project ist einer der seltenen Fälle in denen ein Fachbuch in Form von Belletristik vorliegt. Erzählt wird die Geschichte von Bill Palmer, eines Managers der fiktiven Firma Parts Unlimited, der sich nach der unerwarteten Entlassung seines Vorgesetzten plötzlich auf dessen Position wiederfindet und als Leiter IT Operations die Verantwortung für den Abschluss des am Rand des Scheiterns stehenden Grossprojektes "Phoenix" übernimmt (der am Ende natürlich gelingt).

Um es gleich zu sagen: einen Literaturpreis wird Gene Kim wohl nicht gewinnen, dafür fehlt stilistisch doch einiges. Einige Passagen fühlen sich nach BWL-Vorlesung an, die Figuren sind z.T. holzschnittartig überzeichnet, mehrere von ihnen durchlaufen irgendwann ohne nachvollziehbare Erklärung einen radikalen Verhaltenswandel, ein Stocken der Handlung wird mehrfach nur durch den weisen Aufsichtsrat Erik Reid verhindert, der immer wieder Deus ex machina-Auftritte hat. Und doch hat dieses Buch durchaus zurecht eine grosse Fangemeinde.

Deren Anhängerschaft dürfte zunächst darauf beruhen, dass nahezu jeder der schon in grossen IT-Projekten gearbeitet hat sich in der ersten Hälfte der ca. 800 Seiten wiederfinden dürfte. Hier geht schief was schiefgehen kann und nahezu jeder mögliche Missstand findet sich. Katastrophal fehlgeschlagene Grossreleases, inkompetentes Management, sich bekriegende Organisations-Silos und Abhängigkeiten ganzer Geschäftsbereiche von einzelnen Entwicklern werden so realitätsnah erzählt, dass die Parallelen zu vergleichbaren eigenen Erlebnissen geradezu unheimlich erscheinen.

Auf andere Weise ansprechend ist die Zweite Hälfte, denn hier erkämpft sich die IT von Parts Unlimited all das was in echten Firmen oft nicht genehmigt wird. Abbau von Kopfmonopolen, Automatisierung manueller Tätigkeiten, Zurückdrängen von politischen Management-Entscheidungen, Zusammenarbeit mit anderen Organisationseinheiten, Abkehr von Big Bang Releases und vieles mehr. Dem Leser wird eine Zielwelt vermittelt die nicht nur erstrebenswert sondern erreichbar erscheint. Am Ende sind die Risiken und Probleme zwar nicht verschwunden, sie sind aber beherrschbar und behebbar geworden.

Je nach Vorwissen wird The Phoenix Project den Leser unterschiedlich berühren. Wer sich schon näher mit Agile, Lean oder DevOps beschäftigt hat wird früh erkennen wie es ausgehen wird, wer sich oberflächlich damit befasst hat wird neue Inspirationen erhalten, wer neu in diesen Themen ist wird am Ende das Gefühl haben, dass das was er auf den letzten Seiten gelesen hat zu schön ist um wahr zu sein.2 Und die Frage wird aufkommen - ginge das auch bei mir? An dieser Stelle kann dieses Buch auch seine grösste Wirkung entfalten: es macht die Vorteile der sehr technischen und abstrakten DevOps-Welt plastisch und nachvollziehbar und kann so in Unternehmen die dieses Konzept noch nicht kennen zu einem Türöffner werden.


1Höchste Zeit war es auch, die Fortsetzung The Unicorn Project ist gerade erschienen.
2Und der Vollständigkeit halber: Leser ohne Projekt- oder IT-Bezug werden verwirrt sein.