It's all about People

Ich habe Gitte vor einigen Jahren auf einem Agile Coach Camp kennengelernt und kann bestätigen: sie umarmt Menschen, auch solche die sie nicht kennt. Das dürfte im Zusammenhang damit stehen, dass sie Agilität sehr stark von der menschlichen Seite aus betrachtet. So wie in diesem Talk.

Maximum Work in Progress

Bild: Flickr / Alexander Baxevanis - CC BY 2.0

Ein häufiges Problem in Organisationen jeglicher Grösse ist das Untergehen in zu viel gleichzeitig begonnener Arbeit. Das Wechseln zwischen den verschiedenen Kontexten kostet Konzentration und begünstigt Verwechselungen und darauf folgende Fehlentscheidungen, die Menge paralleler Aufgaben sorgt dafür, das Übersichtlichkeit verloren geht und die Vielzahl wartender Stakeholder führt zu Konflikten und Meeting-Overhead. Derartige Zustände müssen verhindert werden, und zum Glück gibt es dafür auch einen Lösungsansatz.

Die Menge der übernommenen Aufgaben lässt sich in den Griff bekommen indem man sich selbst eine Obergrenze setzt (das ist sowohl für einzelne Personen als auch für ganze Teams möglich). Ist diese Grenze erreicht wird kein weiteres Arbeitspaket angenommen. Erst dann wenn eine der begonnenen Tätigkeiten abgeschlossen wird kann eine neue begonnen werden. Diese Obergrenze (das Maximum Work in Progress Limit) ist ebenso einfach wie wirksam - und fast nirgendwo gelingt es sie einzuhalten.

Angesichts des wunderbar einfach anmutenden Werkzeug des Maximum Work in Progress Limit gerät schnell in Vergessenheit, dass hinter gleichzeitigem Arbeiten an zahlreichen Aufgaben in der Regel keine Fahlrässigkeit steckt sondern Notwendigkeit. In arbeitsteilig geprägten Organisationen ist fast niemand mehr in der Lage eine Aufgabe alleine abzuschliessen, immer wieder muss auf Zulieferungen, Genehmigungen, Abnahmen oder Informationen gewartet werden. Manchmal stundenlang, manchmal wochenlang, manchmal noch länger. Um in dieser Zeit nicht untätig sein zu müssen fängt man eben mit der nächsten Tätigkeit an. Und der übernächsten. Und so weiter.

Wirksame Obergrenzen bedeuten demnach in der Regel nicht, dass man sich selber diszipliniert. Wirksame Obergrenzen bedeuten, dass man sich um vorgelagerte, nachgelagerte und parallele Prozesse kümmern muss. Erst wenn die so beschleunigt werden, dass man nicht mehr gezwungen ist auf sie zu warten kann man sich auf wenige gleichzeitige Tätigkeiten beschränken ohne dadurch immer wieder in Phasen der unfreiwilligen Untätigkeit zu geraten.

Um diese Beschleunigung umgebender Prozesse zu erreichen können je nach Kontext verschiedene Massnahmen sinnvoll sein. Die Aufstockung von Ressourcen, der Abbau von Vorschriften oder die Rücknahme lokaler Optimierungen können helfen, meistens können diese Massnahmen aber nicht selbst eingeleitet werden sondern nur von den jeweils betroffenen Einheiten. Mit Glück sind diese auch dazu bereit und in der Lage, mit Pech sind sie es nicht. Es bleibt dann nur noch ein Ausweg: selber machen.

Sowohl viele der vorgelagerten Schritte (Anforderungserhebung, Design, Abstimmung) als auch nachgelagerte Tätigkeiten (Test, Rollout) können von den meisten Entwicklungteams selber übernommen werden, wenn ihnen der nötige Freiraum und die nötigen Werkzeuge gegeben werden. Das genehmigt zu bekommen ist die eigentliche Herausforderung beim Versuch ein Maximum Work in Progress zu etablieren. Und die damit verbundenen Schwierigkeiten sind der Grund dafür, dass man wirksame Obergrenzen so selten finden kann.

Der Empfangstest

Bild: Wikimedia Commons / Deniz Gültekin - CC BY-SA 3.0

Eines der grössten Probleme in der Produktentwicklung ist zu geringes oder zu spätes Nutzer-Feedback zu den entwickelten Features. Zahllose Produkte sind am Markt vorbeientwickelt worden und haben nichts als finanzielle Verluste und Demoralisierung der Entwicklungsteams erzeugt. Um all das zu vermeiden gibt es nur einen Weg: einem potentiellen Kunden möglicht früh eine erste Version vorlegen und ihn nach seiner Meinung fragen.

Der klassische Weg das zu tun ist die Beauftragung eines internen oder externen Partners, der dann in den Fussgängerzonen der Grossstädte Passanten anspricht und in einen Befragungsraum bittet. In Bezug auf Professionalität und Reichweite noch immer der beste Ansatz, allerdings mit dem Nachteil behaftet, dass damit ein relativ hoher Zeitaufwand verbunden ist. Die Marktforscher müssen gebrieft werden, die Ergebnisse konsolidiert werden, etc.

Ein schnellerer und direkterer Weg ist eine "interne Marktforschung" im eigenen Unternehmen. Vor allem in grösseren Firmen mit hunderten oder tausenden von Mitarbeitern können sich so schon erste Feedbacks zu Verständlichkeit, Usability und Nachfrage ergeben, die man in die weitere Planung einfliessen lassen kann. Damit ist aber auch das Risiko verbunden, dass Betriebsblindheit in das Feedback einfliesst, da die eigenen Mitarbeiter keinen unbefangenen Blick mehr haben.

Eine gute Massnahme um dem entgegenzuwirken ist die Auswahl von Gesprächspartnern aus thematisch möglichst weit entfernten Unternehmensteilen. Bestenfalls mit einer so grossen Distanz, dass ihnen nicht nur die Entwicklungsabteilung fremd ist sondern auch die branchenspezifische Fachsprache, die bisherigen Altprodukte und der Markt mit seinen Konkurrenzanbietern.

Sehr gute Erfahrungen haben wir bei einem Kunden mit dem Empfangspersonal der verschiedenen Gebäude gemacht (für diese Interviews setzte sich schnell der Begriff "Empfangstest" durch). Die dort arbeitenden Damen und Herren standen in ihrem täglichen Alltag so weit ausserhalb der Arbeit der Produktentwicklung, dass sie einen unvoreingenommeneren und neutraleren Blick hatten als alle anderen Kollegen des Unternehmens.

Sich auf die Suche nach solchen Mitarbeitern zu machen ist hochgradig sinnvoll wenn um der Geschwindigkeit willen die ersten Nutzerbefragungen intern durchgeführt werden sollen. In den meisten Firmen gibt es auch mehr von ihnen als man denkt, man muss nur die Augen offenhalten - zum Beispiel beim Betreten des Gebäudes.

Untertanenkultur

Bild: Public Domain Pictures - CC0 1.0

Zu den Demonstrationen von Rechtsradikalen und "besorgten Bürgern" die in den letzten Tagen in Chemnitz stattgefunden haben ist eigentlich schon alles gesagt worden (und Politik soll auch nicht das Thema dieser Website werden). Es gibt aber einen Aspekt der gesondert herausgehoben werden kann, weil er auch über die Politik hinaus eine Bedeutung hat: die von einem Teil der Demonstranten geäussterte unspezifische Erwartung, "irgendjemand" müsste sofort "irgendetwas" tun um die Gesamtsituation zu verbessern (ein Beispiel hier).

Hinter einer solchen Erwartung stehen mehrere verschiedene Grundeinstellungen. Zum einen die, dass derjenige der sich so äussert nicht selbst aktiv werden möchte. "Jemand anders soll tätig werden, nicht ich." Paradoxerweise ist das verbunden mit einem Gefühl der Dringlichkeit. "Es muss etwas passieren, und zwar jetzt." Zuletzt ein offenes Desinteresse an einer Beteiligung an der Lösungsfindung. "Was gemacht wird interessiert mich nicht, solange dadurch alles besser wird."

Diese Grundeinstellungen sind vor allem in grossen Organisationen wie Behörden oder Konzernen immer wieder anzutreffen. Die Ursache dafür (die auch die Verbindung zu den in der DDR großgewordenen "besorgten Bürgern" bildet) ist die private und/oder berufliche Sozialisation in hierarchischen, von Befehl und Gehorsam geprägten sozialen Systemen. Man spricht in diesem Zusammenhang von einer "Untertanenkultur", einem Begriff der eine nähere Betrachtung wert ist.

Geprägt wurde er von den beiden amerikanischen Politikwissenschaftlern Gabriel Almond und Sidney Verba in ihrem Werk "The Civic Culture". Basierend auf tausenden von Interviews in mehreren von einer Untertanenkultur geprägten Ländern konnten sie aufzeigen, dass diese auf vier Annahmen beruht:

• Der einzelne Mensch ist schwach und nichts bewirken
• Das Gesamtsystem ist stark und kann alles erreichen
• Der Einfluss des Einzelnen auf die Hierarchie ist winzig
• Der Einfluss der Hierarchie auf den Einzelnen ist gewaltig

Es ist erkennbar: wer ein Weltbild hat das auf diesen vier Annahmen beruht wird fast zwangsläufig die Erwartungshaltung entwickeln, dass "die da oben" von sich aus darauf kommen müssen, wie eine als problematisch wahrgenommene Situation verbessert werden kann. passiert das nicht wird es als Systemversagen wahrgenommen, was zu Frustration und Wut führen kann.

Um die Betroffenen aus dieser Wut und Frustration in ein konstruktives Miteinander zurückzuführen ist ein Kulturwandel nötig, der in diesem Modell durch eine Widerlegung der besagten Annahmen herbeigeführt werden kann. Den Menschen muss klar werden, dass sie Gestaltungsspielraum haben, dass ihre Ideen gehört werden und dass das Gesamtsystem auf diesen Input angewiesen ist um funktionieren zu können. Das sagt sich leicht, umzusetzen ist es schwer. Aber es lohnt sich.

Wenn dieser Wandel stattfindet kann aus der Untertanenkultur (und der Erwartung "irgendjemand anders" müsste "irgendwie" alle Probleme beseitigen) eine partizipierende Kultur werden, in der jeder von sich aus dazu beiträgt, dass permanent an Verbesserungen gearbeitet wird. Dadurch wird nicht nur das Gesamtsystem leistungsfähiger, es werden auch die ihm angehörenden Menschen zufriedener. Und "besorgte Bürger" spielen dann keine Rolle mehr.

Silver bullets can hurt

Ein Vortrag über eines der grössten Risiken agiler Transitionen, die Methodengläubigkeit. Die Kernaussage, die ich auch unterschreiben würde: die gängigen Methoden und Frameworks sind gute Sammlungen von verwertbarem Wissen und Erfahrungen, aber keines von ihnen ist als Problemlösung ausreichend. Werden sie mit dieser Erwartung eingeführt richten sie eher Schaden an.

Kommentierte Links (XXXX)

• Steve Denning: For Agile, It's The Best And The Worst Of Times

  Der Auftakt zu einer ganzen Serie von Beiträgen über die Ankunft der Agilität im Mainstream. Interessant sind zwei Gedanken. Zum einen, dass die Agilität nach ihrem "offiziellen Startschuss" (dem agilen Manifest) 15 Jahre lang "in den Schatten gelebt hat" bevor sie von den Managern und Unternehmensberatern dieser Welt entdeckt wurde. Demzufolge wurde sie im Wesentlichen ohne diese beiden Gruppen entwickelt und ausdefiniert, was man ihr heute anmerkt: statt der Hierarchie und dem Börsenwert stellt sie den Mitarbeiter und den Kunden in den Mittelpunkt. Der andere Gedanke ist der, dass die Agilität durch ihre untrennbare Verbindung mit moderner Software-Entwicklung nur schwer korrumpierbar ist - wer heute Software zu einem vertretbaren Aufwand erstellen möchte kommt an echter Agilität nicht vorbei, wodurch sie immer wieder zurück auf die Füsse gestellt wird.
  

• Lars Vollmer: Denkfehler der New‑Work‑Bewegung

New Work ist ein ähnlich schwammig formulierter Begriff wie Agilität, man kann sehr, sehr viel in ihn hineininterpretieren. Eine verbreitete Deutung ist die, dass man arbeiten kann was man will, wann man will und von wo man will. Das ist lange Zeit  illusorisch gewesen, und in den meisten Berufen ist es das heute noch. Nur dort wo der Fachkräftemangel die Unternehmen beutelt lassen sie sich darauf ein. Vollmer geht davon aus, dass das zwar arbeitnehmerfreundlich ist, in der Regel aber auf Kosten der Wirtschaftlichkeit und der Kundeninteressen geht. So gesehen ist New Work auch nicht kompatibel mit Agilität, was überall dort zu Problemen führt wo man versucht beides gleichzeitig einzuführen.

• Ralph Cibis: Let's charge story points

  Die meisten agile Coaches und Practitioner betrachten es als Dogma: Story Points sind eine abstrakte, fast schon fiktive Berechnungseinheit, die weder zur Schätzung von Zeit noch zur Ermittlung von Kosten herangezogen werden darf. Wie realitätsfremd das ist zeigt sich häufig an der fehlenden Antwort darauf wofür sie dann gut sind. Ralph Cibis geht einen pragmmatischeren, wenn auch nicht unriskanten Weg - wenn den Beteiligten klar ist, dass Story Points kontextbezogen, volatil und fehlbar sind, dann sind sie als Indikator brauchbar, und zwar nicht nur für Planungen sondern auch für Preiskalkulationen. Das ist auch richtig, wird aber in der Realität meistens mit dem Customer-Vendor-Antipattern kollidieren. Funktionieren wird dieser Ansatz nur dort wo die Geschäftsbeziehungen von Ergebnisoffenheit, Respekt und Verständnis geprägt sind. Das gibt es zwar, aber ganz ehrlich - wie häufig?
  

• Willem-Jan Ageling: 5 controversial topics that were removed from Scrum

  Eine Geschichtsstunde. Wie oben von Denning beschrieben haben sich agile Ansätze wie Scrum über längere Zeit im Biotop der Software-Entwicklung ausdifferenziert, wobei viele der ursprünglichen Unstimmigkeiten oder Irrwege entfernt oder korrigiert wurden. Was das bedeutet sieht man an den von Ageling aufgeführten ehemaligen Elementen von Scrum, die grösstenteils zwischen 2010 und 2013 aus den offiziellen Regeln entfernt wurden (nur die Abschaffung der verpflichtenden drei Fragen ist neueren Datums. Sie fand erst 2017 statt). Wären sie noch in Kraft würde vieles wesentlich holperiger funktionieren als es heute der Fall ist.

• MonkeyUser: Building (a raft) with ...

  Endlich ein Ersatz für die alte Baumschaukel-Analogie, die mittlerweile schon etwas zu oft herangezogen wurde.

Deine Muda: Motion

Bild: Wikimedia Commons / Roger & Renate Rössing - CC BY-SA 3.0

Vierter Teil der Deine Muda-Serie. Die dritte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Bewegung, auf Englisch Motion. Da sie häufig mit der ersten Muda (Transportation) verwechselt wird macht eine Differenzierung Sinn: unter Transportation versteht man die Bewegung von Gütern, unter Motion die Bewegung von Personen.

Dass diese Personenbewegung als nicht gewinnbringende Tätigkeit gesehen wird liegt daran, dass eine Person während sie sich bewegt nicht in der Lage ist an wertschöpfenden Tätigkeiten teilzunehmen. Wer zu Fuss, mit dem Fahrrad, dem Motorrad, der Strassenbahn oder dem Auto unterwegs ist kann währenddessen nicht arbeiten - wenn er im Auftrag der Firma reist kostet er aber Geld (Zeit/Gehalt). Bis zu einem gewissen Grad kann das in einigen Fällen ausgeglichen werden (z.B. ist arbeiten im Zug eher möglich, zumindest am Computer), auch hier geht aber Zeit durch Planung, Umsteigen, etc. verloren.

Sogar innerhalb eines Gebäudes kann dieses Problem auftreten, besonders dann wenn es sich um Hochhäuser oder weitläufige Anlagen handelt. Ein Scrum Team bei dem die Entwickler im Erdgeschoss sitzen, der PO aber im 10. Stock wäre ein solcher Fall. Ein Team das seinen Arbeitsbereich im Flügel G hat, seinen Meetingraum aber im Flügel B ein anderer. Beides sind real existierende Beispiele aus deutschen Konzernen und in beiden Fällen werden erstaunliche Zeitmengen in Fluren, in Treppenhäusern und in Fahrstühlen verbracht.

Die Besonderheit der Motion-Muda ist, dass für ihre Beseitigung zwei Ansätze möglich sind: man kann die Mitglieder eines Teams oder einer Wertschöpfungskette in einen Raum setzen (oder zumindest auf einen Flur) oder man kann versuchen sie durch digitale Lösungen zu vernetzen, etwa durch Chatprogramme, Videotelefonie und Ticket-Tools. Aus Sicht eines Agile- oder Lean-Coaches wäre Ansatz eins zu bevorzugen, da er einfachere und direkte Kommunikation ermöglicht, in den meisten grossen Organisationen findet man eher Ansatz zwei, da er mit den ohnehin an jedem Arbeitsplatz stehenden Computern einfacher umzusetzen ist.

Dort wo ernsthaft an der Reduzierung von Personenbewegung gearbeitet wird tritt übrigens ein interessanter Seiteneffekt auf: in den meisten Fällen führen diese Bemühungen dazu, dass Teams kleiner, autarker und crossfunktionaler werden. Nur dann lässt sich die Anzahl der für die tägliche Arbeit nötigen Meetings herunterfahren. Der Grossteil aller Personenbewegungen hat nämlich das gleiche Ziel: einen Meeting-Raum.

(Nicht) wie Spotify werden

Bild: Flickr / Jon Åslund - CC BY 2.0

Ein bemerkenswerter Trend der letzten Jahre ist der, dass sich viele Unternehmen im Rahmen ihrer agilen Transition nicht mehr amerikanische Firmen als Vorbild nehmen sondern eines aus Schweden: Spotify (ein aktuelles Beispiel hier). Wie immer in solchen Fällen gibt es mehr als einen Grund dafür, z.B. den, dass Skandinavien aus europäischer Perspektive nicht so entrückt wirkt wie das Silicon Valley, oder den, dass das Produkt von Spotify (Musikstreaming) auf den ersten Blick einfach verständlich zu sein scheint. Was aber für viele Manager verlockend besonders erscheint ist etwas anderes - das mit diesem Firmennamen verbundene Skalierungsmodell.

Der durch Präsentationen und Videos bekannt gewordene Ansatz ist scheinbar einfach: gemeinsam an einem Teilprodukt arbeitende Teams bilden einen Tribe, Spezialisten innerhalb eines Tribes bilden ein teamübergreifendes Chapter und Menschen mit gleichen Interessengebieten schliessen sich unternehmensweit zu Gilden zusammen. Die Frage wie sich agile Teams koordinieren scheint damit beantwortet zu sein: durch ihre Tribes und Chapter. Beziehungsweise (und hier wird es für mittlere Manager interessant) durch ihre Tribe Leads und Chapter Leads.

Das Problem dieses Modells: niemand kann sagen ob es wirklich dauerhaft funktionieren kann, denn es es ist selbst bei Spotify nur wenige Jahre lang umgesetzt worden - und auch das nur in der IT und nur während einer explosionsartigen Wachstumsphase, die wenige Rückschlüsse auf die Umsetzung in einem stabilen Kontext zulässt. Cliff Hazell, einer der agilen Coaches und Chapter Lead bei Spotify, hat es in einem Vortrag auf den Punkt gebracht: für seine Firma ist das Tribe/Chapter/Gilden-Modell eines von gestern (ab Minute 28:10 beschreibt er wo es mittlerweile geändert wurde).

Cliff Hazell - Be best at getting better @ LKCE17 from Lean Kanban Central Europe on Vimeo.

Kurz gesagt - wer Tribes/Chapter/Gilden bei sich einführt der wird nicht so wie Spotify, sondern höchstens so wie die IT-Abteilung dieser Firma im Zeitraum 2012 - 2014 gewesen ist. In vielen Firmen führt selbst diese Erkenntnis aber nicht dazu, dass man dieses Modell nicht mehr anstrebt, im Gegenteil. Selbst das Spotify von damals erscheint vielen Betrachtern besser als der Ist-Zustand ihres eigenen Unternehmens. Ist es nicht bereits ein ausreichendes und lohnendes Ziel diesen Zustand zu erreichen? Wäre das nicht für einen ersten Schritt genug?

Die Antwort: Jein. Selbst wenn man davon absieht, dass das Tribe/Chapter/Gilden-Modell den Beweis seiner langfristigen Funktionsfähigkeit noch schuldig geblieben ist bleiben Probleme. Dass es zeitweise in Schweden funktioniert hat liegt nämlich nicht zuletzt an der mit ihm verbundenen Systemlandschaft und Software-Architektur. Erst durch die auf Microservices beruhende technische Autonomie der einzelnen Teams konnten sich die Chapter und Gilden auf fachliche Koordination und interessenbasierten Erfahrungsautausch beschränken und konnten auf die Vorgabe und Kontrolle von technischen Standards verzichten. In der klassischen Unternehmens-IT mit ihren zahllosen Abhängigkeiten würde das meistens ins Chaos führen.

Ist Spotify also kein Vorbild? Doch, ist es, nur ganz anders als erhofft. Wie oben im Video zu sehen ist das Ziel der dortigen Firmenorganisation, sich ganz im Sinn des agilen Change Managements ständig weiterzuentwickeln und nie stabil zu werden, sich ständig anzupassen, zu verändern und zu experimentieren. Das ist sehr zur Nachahmung empfohlen. Ausgerechnet für die meisten Menschen die behaupten "wie Spotify" werden zu wollen ist das aber nicht mehr das was ihnen gefällt. Ihnen fehlt darin die (scheinbare) Einfachheit.