Donnerstag, 26. Juli 2018

Deine Muda: Inventory

Bild: Flickr/GOVBA - CC-BY-2.0
Dritter Teil der Deine Muda-Serie. Die zweite Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Lagerhaltung, auf Englisch Inventory. Auf den ersten Blick ein Problem das vor allem in Hardware-produzierenden Branchen auftritt, auf den zweiten Blick aber auch eines der Software-Industrie.

Zunächst zum Grundsätzlichen: warum ist Lagerhaltung ein Problem? Weil Güter die gerade gelagert werden gebundenes und nicht nutzbares Geld darstellen. In ihren Einkauf oder ihre Herstellung musste bereits investiert werden, so lange sie irgendwo gestapelt liegen kann mit ihnen aber kein Gewinn erwirtschaftet werden. Man spricht in diesem Zusammenhang auch von totem Kapital. Lagerhaltung zu vermeiden erhöht demnach die Liquidität und spart nebenbei noch die Kosten für die Anlagen in denen die Lagerung stattfindet.

Auch in der Softwareentwicklung gibt es das Phänomen, dass "auf Halde" produziert und dadurch totes Kapital angehäuft wird. Es tritt da auf wo Deployment- und Rollout-Prozesse so schwerfällig, bürokratisch und arbeitsaufwändig sind, dass ein Go Live neuer Features nur alle paar Monate möglich ist, im schlimmsten Fall nur ein- oder zweimal pro Jahr. Auch hier liegt zwischen dem Ausgeben von Geld für Lizenzen und Gehälter und dem Erwirtschaften der ersten Gewinne des neuen Produkts ein langer Zeitraum. Wirtschaftlich vernünftig ist das nicht.

Was spezifisch in der Software-Industrie dazukommt ist das Risiko, dass mit veraltenden Anwendungsteilen einhergeht - und veraltet ist Software mitunter schon nach mehreren Monaten "Lagerzeit". Wenn über längere Zeit hinweg Features zwar produziert aber nicht integriert werden (oder nicht mit echten Produktionsdaten laufen, oder keine echte Schnittstellenanbindung haben, etc.), dann steigt die Wahrscheinlichkeit, dass der Go Live Ausfälle, Hotfixes und übereilte Anpassungen nach sich zieht. Das kostet dann wieder Zeit und Geld.

Um eine derartige Folgen von Lagerhaltung fertiger Features zu vermeiden ist es nötig, dass die für einen Go Live nötigen Prozesse und Arbeitsschritte verschlankt, beschleunigt, digitalisiert und automatisiert werden. Erst wenn es möglich ist mindestens monatlich auf Produktion zu deployen können totes Kapital und ausufernde Integrations- und Bugfixing-Phasen vermieden werden. Das ist zwar nicht einfach, es ist aber machbar. Und es ist ein Business-Case.

Montag, 23. Juli 2018

Dev/Non-Dev Ratio

Bild: Pixabay / Louise Hoffmann - Lizenz
Grundsätzlich ist es zwar so, dass die Situation jeder Organisation irgendwie einzigartig ist, trotzdem gibt es bestimmte Rahmenbedingungen, die durchgehend Einfluss auf das jeweilige "Agilitätspotential" haben. Eine davon (zumindest in Software entwickelnden Firmen) ist das Verhältnis von Software-Entwicklern zu Nicht-Entwicklern. Je höher der Anteil an Nicht-Entwicklern an der Belegschaft ist, desto schwerer wird sich die Firma mit Agilität tun.

Um Missverständnissen vorzubeugen: in kaum einem Unternehmen nennenswerter Grösse werden die Software-Entwickler hundert Prozent des Personals ausmachen. Es wird so gut wie immer den Bedarf nach Buchhaltung, Einkauf, etc. geben. Zu einem Problem kann das aber werden, sobald die Anzahl dieser Leute an die der Software-Entwickler heranreicht oder sie übersteigt. Dann sind nämlich meistens einige (oder alle) der folgenden Konstellationen gegeben:

Es existieren organisatorische Silos

Wenn Teams und Abteilungen nicht crossfunktional aufgestellt sind enstehen permanent Koordinations- und Eskalationsaufwände. Im besten Fall müssen die verschiedenen Silos (Fachabteilung, Anwendungsentwicklung, Betrieb, etc.) ihr Vorgehen ständig miteinander abstimmen, gegebenenfalls gibt es sogar abweichende und gegenläufige Planungen, die regelmässig in Konflikten münden. Im schlimmsten Fall stellen sich die Silos ihre Leistungen gegenseitig in Rechnung, mit allem was das an Verhandlungen und Spar-Lösungen zur Folge hat.

Es existieren Wasserfall-artige Prozessketten

Ein ähnliches Phänomen, allerdings innerhalb der Anwendungsentwicklung. Wenn verschiedene Teams für Anforderung, Konzeption, Entwicklung, Test und Rollout tätig sind, dann führt das zu den gleichen Problemen wie im Fall der organisatorischen Silos. Zusätzlich dazu kommt das Phänomen, dass frühere Prozesschritte (Anforderung und Konzeption) in der Regel einen höheren Output haben als spätere (Entwicklung, Test und Rollout), wodurch es zu Stau, Multitasking und Priorisierungskonflikten kommt.

Es existieren vielstufige Hierarchien

Zum Teil eine Folge des letzten Punktes. Bei Konflikten greift noch zu häufig der Reflex, diese durch eine übergeordnete Eintscheidungsinstanz (das Management) lösen zu lassen statt durch die Beteiligten selbst. Das Weiterleiten vieler Entscheidungen nach oben kann aber nur zu zwei Ergebnissen führen: entweder entsteht dort ein weiterer Flaschenhals durch den alles verlangsamt wird, oder es werden immer mehr Entscheider/Manager eingestellt, die zwangsläufig einen immer grösseren Anteil ihrer Zeit dafür verwenden müssen, sich untereinander zu koordinieren.

Es existieren viele nicht automatisierte oder digitalisierte Arbeitsschritte

Ein etwas anderer Fall als bei den letzten Punkten - hier geht es um die eigentliche Produktion. Je geringer der Automatisierungs- und Digitalisierungsgrad beim Testen, Dokumentieren, Berechtigungsmanagement, etc. ist, desto mehr Zeit geht an diesen Stellen verloren. Die Anzahl an Nicht-Entwicklern wie z.B. manuellen Testern und Business Analysten ist an diesen Stellen ein Indikator für langsame und schwerfällige Prozesse.


Dass derartige Konstellationen existieren hat seine Ursache fast immer in einem falsch verstandenen Effizienzdenken. Die zuvor genannten Phänomene gehen oft auf die Annahme zurück, dass Software-Entwickler produktiver sind wenn sie nur Code schreiben und nichts anderes tun. Die Auslagerung von allem anderen in eigene Silos, Prozesschritte, Hierarchie-Ebenen und (Hilfs-)Teams ist die Folge davon. Dass stattdessen die Effizienz sinkt ist dann eine unangenehme Überraschung.

Donnerstag, 19. Juli 2018

Sommer, Sonne, Schlendrian

Bild: Wikimedia Commons / Duncan Galbraith - CC BY 3.0
Ferien! Es ist Sommer, die Sonne scheint und die Büros werden leer. Ein Grossteil der Mitarbeiter fährt in den Urlaub und es bleiben nur wenige zurück, die eher einen Notbetrieb aufrecht halten als geregelt zu arbeiten. Mitunter kommen die Zurückgebliebenen dann auf die Idee, für die Ferienzeit das eigene Vorgehen "pragmatisch anzupassen". Und damit beginnen die Probleme.

Sowohl in der Produktion als auch in der Methodik sind die Möglichkeiten für den kleinen und grossen Murks unbegrenzt. Die Backend-Entwickler sind in Spanien? Kein Problem, die Frontendler produzieren schonmal "auf Halde". Es sind keine Tester verfügbar? Nicht schlimm, dann gibt es nach den Ferien eine Bugfixing-Phase. Der Product Owner ist auf Kreuzfahrt? Dann wird eben der Scrum Master zeitweise zum Scroduct Ownster. Alles nicht so wild, was soll schon passieren?

Was passieren kann (und sehr häufig auch passiert) ist, dass durch derartige Konstellationen in den Ferien technische und organisatorische Schulden angehäuft werden. Nicht integrierte Komponenten, ungetestete Features oder "verschlankte" Prozesse können langfristige Folgen von erstaunlichem Ausmass haben - vom unkorrigierbar erratischen Verhalten einer Anwendung bis zum kryptisch fragmentierten Backlog ist alles möglich und alles bereits vorgekommen.

Die folgerichtige Frage ist: wie können auch mit reduzierter Besatzung genug Strukturen und Standards aufrechterhalten werden? Verschiedene Maßnahmen machen Sinn. Am Einfachsten ist es natürlich wenn nur Teile des Teams zur selben Zeit in den Urlaub fahren (oder aber alle gleichzeitig). Und für alle Tätigkeiten können Stellvertreter ausgesucht und trainiert werden, mit dem Ziel, dass bestimmte Dinge nicht vermischt werden (z.B. Anforderer ≠ Entwickler und PO ≠ Scrum Master).

Auch das Backlog kann so priorisiert sein, dass die Anforderungen nur die Teile der Arbeit betreffen, die von der Ferienbesatzung beherrscht werden können (z.B. ein Refactoring der automatisierten Testfälle, wenn alle Entwickler im Urlaub sind, oder ein Proof of Concept, wenn nur Entwickler übrig geblieben sind).

In allen Fällen sollte ein Ziel im Vordergrund stehen: auch während der Ferien sollte in möglichst kurzen Zyklen der Zustand des "potentially shippable" erreicht sein. Das ist aber nur gegeben wenn es eben nicht zur Anhäufung technischer und organisatorischer Schulden kommt.

Montag, 16. Juli 2018

Agile Compliance

Bild: Wikimedia Commons / Creig Pat - CC BY-SA 4.0
Wenn die Vorteile von agilen Vorgehensweisen genannt werden liegt in der überwiegenden Mehrzahl der Fälle der Schwerpunkt auf der IT, die so zu bedarfsgerechteren Produkten und schnelleren Releases kommt. Auch Betrieb (Stichwort DevOps) und andere Organisationseinheiten entdecken diese Welt mittlerweile für sich und sehen in Agilität ein anzustrebendes Zielbild. Es gibt aber auch einen weiteren Berech in dem dieser Ansatz Sinn macht, selbst wenn man ihn dort zunächst nicht vermuten würde - Compliance.

Zum besseren Verständnis muss man sich vor Augen halten was dieser Begriff bedeutet. Compliance ist in der Theorie eine Umschreibung für die Einhaltung von Gesetzen und Richtlinien während der Berufsausübung. In der Realität haben sich Compliance-Tätigkeiten allerdings in Teilen von dieser Bedeutung gelöst und auf die damit verbundene Bürokratie ausgedehnt - in fast allen auch nur halbwegs grossen Organisationen bedeutet Compliance heute, dass die eigene Arbeit möglichst lückenlos dokumentiert wird, um bei Bedarf nachzuweisen zu können, dass man sich wirklich an alle Vorschriften gehalten hat1.

Im klassischen wasserfall-artigen Vorgehen führt das am Ende eines Geschäftsjahres oder einer Projektphase zu hektischen Aktivitäten. Nicht nur muss rückwirkend dokumentiert werden, gegebenenfalls muss zuerst durch Reverse Engineering ermittelt werden was überhaupt der zu dokumentierende aktuelle Stand ist. Und im schlimmsten Fall weicht der Ist-Stand so stark von den Vorschriften ab, dass er überarbeitet werden muss. So kann klassische Compliance dazu beitragen, dass sich "fast fertige" Projekte noch erstaunlich lange ziehen.

Ein agiler Ansatz würde dieses Risiko minimieren indem die notwendigen Dokumentationen parallel zur Produktentwicklung fertiggestellt werden, idealerweise im Team selbst, möglicherweise aber auch durch unterstützende Spezialistenteams. Das bedeutet zwar, dass Juristen, Datenschutz-Beauftragte, Penetrationstester und Security-Spezialisten durchgehend verfügbar sein müssen, im Gegenzug ist der Zustand des "potentially shippable" damit durchgehend gewährleistet und nicht nur punktuell. Und die Nacharbeits-Aufwände am Ende fallen weg.

Ein in diesem Kontext sinnvolles Vorgehen wäre übrigens ein Aufbrechen von Wissensmonopolen, z.B. durch den Transfer von Security- oder Datenschutz-Know-How in die Umsetzungsteams. Auch das trägt bei zu schneller Reaktionszeit, da nicht mehr auf den Experten gewartet werden muss.


1Das einfach wegzulassen ist zwar naheliegend, wegen der Überprüfung durch Regulierungs- und Aufsichtsbehörden aber oft nicht machbar.

Donnerstag, 12. Juli 2018

Customer-Vendor Antipattern

Vielleicht hat Jeff Patton Pech mit seinen Bekanntschaften aus dem agilen Umfeld. Vielleicht ist seine Aussage, dass die ausschliesslich auf die Velocity fixiert wären, nur ein rhetorischer Trick um sich als Schwimmer gegen den Strom zu inszenieren. So oder so - sein Vortrag geht auf einige wichtige Punkte ein, und sein Illustrations-Stil ist etwas Besonderes.

Jeff Patton at MTP Engage Hamburg 2018 from Mind the Product on Vimeo.

Montag, 9. Juli 2018

Jenga-getriebene Retrospektiven

Bild: Flickr / RJP - CC BY 2.0
Wenn Teams sich entscheiden nach Kanban1 zu arbeiten statt nach Scrum fällt vieles weg, was von manchen Menschen als einengend empfunden werden kann, unter anderem die Fixierung auf Sprints von ein bis vier Wochen. Was damit allerdings auch verloren geht ist der automatisch stattfindende Feedback- und Verbesserungszyklus, der durch die am Ende jedes Sprints stattfindende Retrospektive angetrieben und am Laufen gehalten wird.

Nun ist es nicht so, dass es in Kanban keine Retrospektiven gäbe. Sie heissen zum Teil anders (z.B. Kaizen Session, Schulterblick oder KVP-Meeting), aber sie sind da, ohne sie wäre das "manage the flow" nicht möglich. Anders als in Scrum bleibt aber die Frage wann sie stattfinden sollen. "Immer wenn es nötig ist" ist zwar grundsätzlich ein guter Ansatz, bei ihm drohen sie aber vom Alltagsbetrieb verdrängt zu werden. Und feste Intervalle gehen wieder in Richtung Scrum, was oft nicht (mehr) gewünscht ist.

Ein interessanter Ansatz kommt von einem kölner Gamification-Guru und basiert auf einem Jenga-Spiel. Die Grundidee: wie beim normalen Jenga werden nach und nach die Steine aus dem Turm herausgezogen, und sobald er umfällt ist eine Retrospektive fällig. Das Team muss jetzt nur noch vereinbaren wann jeweils ein Stein gezogen wird. Mögliche Anlässe sind:
  • Ein Stein für jeden Tag seit der letzten Retrospektive
  • Ein Stein für jede Aufgabe die in die Expedite-Lane geschoben wird
  • Ein Stein für jede Überschreitung der WIP-Limits
  • Ein Stein sobald ein vereinbartes WIP-Age überschritten wird
  • etc.
Bei diesem Vorgehen würde es spätestens ca alle sechs Wochen zu einer Retro kommen, alleine wegen der Regel, dass ein Stein pro Tag gezogen wird. Je nach vereinbarten weiteren Regeln kann es aber auch deutlich schneller so weit sein, das Vorgehen ist also stark anlassgetrieben. Und zuletzt können Retrospektiven auch spontan angesetzt werden - man muss dafür nur den Turm umwerfen.


1Steht in diesem Fall stellvertretend für nicht-iteratives, durchflussorientiertes Arbeiten, zu weiteren Varianten siehe hier.

Donnerstag, 5. Juli 2018

Nicht-Newtonsche Organisationsformen

Bild: Pixabay / Moho01 - Lizenz
Wie würde eine ideale Organisationsform eines agilen Unternehmens aussehen? Eine Frage die noch schwieriger zu beantworten ist als es zunächst den Anschein hat. Selbst wenn es klar ist, dass das Erscheinungsbild anders sein muss als in den starren, bürokratischen Strukturen der Gegenwart - fast alle Scrum Master, Agile Coaches und Unternehmensberater bleiben die Antwort auf die sich darauf anschliessende Frage schuldig: Wie dann?

Die naheliegendste Erwiederung ist die klassische, unbefriedigende Beraterantwort: es kommt immer darauf an. Grundsätzlich ist das auch richtig, nur durch die Orientierung an den im Einzelfall gegebenen Herausforderungen kann eine Organisation reaktionsfähig und somit agil bleiben. Das Problem ist die damit einhergehende Gefahr der Beliebigkeit und Planlosigkeit, die dazu führen kann, dass dauerhaft oder zeitweise in die falsche Richtung gelaufen wird. Ähnlich wie im Fall der Produktentwicklung gilt auch in der Organisationsentwicklung, dass es ein Zielbild oder eine Vision geben sollte der man folgen kann. Die wird durch ein "Kommt darauf an" nicht geliefert.

Auch die nächsthäufige Idee ist nicht ganz befriedigend: die "fluide Organisation". Dabei ist auch dieser Ansatz gut. Genau wie eine Flüssigkeit bewegt sich eine solche fluide Organisation nicht auf dem direktesten Weg Richtung Ziel (→ Zielbild/Vision) sondern auf dem Weg des geringsten Wiederstandes. Hindernisse werden nicht bekämpft sondern umflossen, und bei einer Verlagerung des Widerstandes verlagert sich auch der Fluss. Das Problem an dieser Stelle: manchmal muss man auch im agilen Kontext standhaft sein, etwa um zu Überregulierung oder Überspezifikation Nein zu sagen. Dafür sind fluide Organisation nicht gemacht.

Letztendlich bräuchte es eine Kombination der drei Typen: fluide wenn es möglich ist, mit stabileren, wiederstandsfähigeren Strukturen wenn es nötig ist und das Ganze ständig wechselnd, je nachdem was gerade Sinn macht. Eine Inspiration dafür wie das aussehen könnte liefert ein physikalisches Phänomen: die nicht-newtonschen Flüssigkeiten. Grundsätzlich verhalten diese sich wie jede andere Flüssigkeit auch und fliessen entlang des geringsten Widerstandes. Aber: wenn sie unter Druck gesetzt werden verfestigen sie sich, und zwar um so stärker je heftiger der Druck ist. Erst wenn der nachlässt verflüssigen sie sich wieder. Ein konkretes und verblüffend bekanntes Beispiel dafür kann man sich hier ansehen.

In die Realität umsetzbar ist eine derartige nicht-newtonsche Organisationsform allerdings nur wenn ihre Mitglieder erhebliches Commitment und einen hohen Reflektionsgrad haben. Sobald angefangen wird auf die Organisation Druck auszuüben müssen sie das erkennen und sich zum Widerstand zusammenschliessen, sobald der Druck nachlässt müssen sie die dafür erschaffenen Regeln und Strukturen zurückbauen und auflösen. Das immer wieder zu tun ohne irgendwann zu sehr in eine Richtung zu kippen ist eine Herausforderung.

Der Punkt ist aber auch, dass man eine nicht-newtonsche Organisation eher als ein anzustrebendes Fernziel sehen muss und nicht als den nächsten umzusetzenden Schritt. Wie oben gesagt: als Zielbild oder Vision. Selbst wenn diese vermutlich nie zu hundert Prozent erreichbar ist - sie gibt der Organisationsentwicklung die Möglichkeit zu überprüfen ob der eingeschlagene Weg noch der richtige ist oder ob er korrigiert werden sollte. Allein das ist schon viel wert.

Montag, 2. Juli 2018

Agile is not a mindset

Bild: Pexels / Rawpixel - Lizenz
Eigentlich ist es nach dieser Überschrift bereits vorbei. Wie kann er es wagen? Häresie, Frevel, Proselytismus. Er hat Jehova gesagt! In der agilen Community ist es mittlerweile ein Allgemeinplatz, dass Agilität ein Mindset ist, eine Geisteshaltung und eben kein Regelwerk und keine Methode. Basta! Naja. Dem zweiten Teil dieser Aussage würde ich sogar zustimmen, Agilität ist tatsächlich keine durch Regeln definierte Methodik. Dem ersten Teil widerspreche ich aber, ein Mindset ist es auch nicht. Eine bestimmte Geisteshaltung ist zwar eine Voraussetzung, alleine für sich genommen bewirkt diese aber noch gar nichts.

Schauen wir uns das Ganze näher an. Das Wort "agil" hat eine Bedeutung: beweglich oder reaktionsschnell. Ohne Kontext ist das noch sehr unspezifisch. Bin ich bereits agil wenn ich in der Lage bin bei Bedarf meine Meinung schnell zu ändern? Wohl kaum. Es braucht also Zusatzparameter. Für den Kontext von XP, Scrum & Co wurden diese im legendären Manifesto for Agile Software Development geliefert, und zwar anders als man bei erstmaligem Lesen denken könnte nicht nur mit Schwerpunkt auf geistiger Haltung sondern auch mit einem klaren Fokus auf zu erzielenden Ergebnissen.

Vor den berühmten vier Gegensatzpaaren steht auf seiner ersten Seite der Satz: "We are uncovering better ways of developing software by doing it and helping others do it." und genau das ist der Punkt - im Sinn seiner Urheber definiert sich Agilität durch das Liefern von Ergebnissen (Software) und durch das ständige Verbessern dieses Lieferungsprozesses. Auf der zweiten Seite wird das sogar noch genauer ausgeführt: ... early and continuous delivery ..., ... changing requirements, even late in development ..., ... working software is the primary measure of progress ..., und so weiter. Wer mag kann es dort nachlesen.

Warum diese Betonung des Delivery-Aspekts wichtig ist erkennt man an einem in vielen Organisationen zu hörenden Spruch: "Wir sind ja agil, sind offen für geänderte Anforderungen, machen Retros, hinterfragen Regeln, etc - aber wegen der gesetzlichen Vorschriften / wegen unserer Vorgesetzten / wegen unserer veralteten Anwendungen releasen wir nur zweimal pro Jahr." Das Mindset wird an dieser Stelle zu einem Teil einer Selbsttäuschung, die man so formulieren könnte: "Dass wir nur alle paar Monate neue Funktionen zum Anwender bringen ist zwar schade, es hindert uns aber nicht daran Agil zu sein, denn wir haben ja die richtige Geisteshaltung."

Um dieser Selbsttäuschung vorzubeugen rate ich mittlerweile dazu, den Satz Agile is a mindset nicht mehr zu verwenden. In meiner Sicht der Dinge ist Agilität die Fähigkeit sich schnell und unbürokratisch an sich ändernde Rahmenbedingungen anzupassen um kontinuierlich Mehrwert liefern zu können. Wie oben gesagt, ein bestimmtes Mindset ist dafür eine von mehreren Voraussetzungen. Nicht weniger, aber auch nicht mehr. Und wenn die genannte Anpassungs- und Lieferfähigkeit nicht da ist, dann ist man nicht agil, egal wie offen und flexibel die Geisteshaltung ist.

Darum: Agile is not a mindset.