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
Powered by Blogger.