Das Ergebnis von 60 Jahren kontinuierlicher Optimierung

... kann man hier sehen. Von mehr als einer Minute verkürzt sich der Vorgang des Reifenwechselns in der Formel 1 auf nur noch wenige Sekunden:



Hinter dieser Verbesserung stecken verschiedene Faktoren: geänderte Teamzusammensetzung, geänderte Abläufe und neue Technologie, angetrieben von einem hochgradig kompetitiven Umfeld. Die Parallelen zur IT sind offensichtlich.

Agile Silos

Bild: Wikimedia Commons / Pline - CC BY-SA 3.0

Agile ist im Augenblick ein Hype. Die Kritiker sind zwar nicht verstummt, werden aber kaum noch wahrgenommen und eine Branche nach der anderen, ein Unternehmen nach dem anderen beschliesst mitzumachen. Anders als noch vor einigen Jahren beschränken sich die Agilisierungs-Bemühungen auch nicht mehr auf die Softwareentwicklung. Auch HR, Marketing, Operations, Strategie und praktisch jedes andere Ressort will zukünftig agil sein. Das ist zunächst einmal eine gute Entwicklung - oder?

Die Antwort: im Prinzip ja, im Rahmen der Umsetzung gibt es aber immer wieder Probleme. Agile HR, Agiles Marketing, Agiler Vertrieb, etc. klingen zwar erstmal gut, in der Realität führt diese Umettikettierung aber meistens nicht dazu, dass hier wirklich effektiver gearbeitet wird. Der Grund dafür, dass viele Unternehmen schwerfällig, bürokratisch und ineffektiv sind ist nämlich nicht fehlende Agilität in den organisatorischen Silos, die blosse Existenz der Silos ist der Grund dafür.

Die Phänomene sind allgemein bekannt: der Vertrieb der schneller Aufträge akquiriert als die Produktentwicklung sie abarbeiten kann, die Personalabteilung die unsinnige Weiterbildungen organisiert weil sie zu weil weg von den Bedürfnissen in der Fertigung ist, die Strategieabteilung die Kooperationspartner heranholt deren Systeme mit der eigenen IT inkompatibel sind, all das wird nicht besser dadurch, dass es jetzt noch schneller, wendiger und effektiver stattfindet.

Wenn ein Unternehmen agil werden möchte ist die Agilisierung von Silos nicht der richtige Weg. Der bessere Ansatz wäre es die Silos aufzulösen oder aufzuweichen und stattdessen crossfunktionale Einheiten einzurichten. DevOps als Kombination von Entwicklung und Betrieb greift ja schon um sich, aber warum nicht auch Entwicklung und Vertrieb? Oder warum können Marketing und Einkauf ihre Fortbildungen nicht selbst organisieren, ohne Beantragungs- und Genehmigungsbürokratie?

Natürlich ist das in der Konsequenz viel gravierender als das blosse Einführen einer neuen Methode. Vielleicht steht am Ende eine Struktur in der manche Ressorts aufgelöst werden und andere weitreichende Kompetenzen abgeben. Und natürlich kann das unbequem sein, Egos verletzen und alte Karrierepfade verbauen. Auf der anderen Seite bringt es aber auch viel mehr als das Anbringen eines "Agilen Labels" auf einem Silo in dem die Leute genauso im eigenen Saft schmoren wie vorher.

Gemeinsame Reviews

Bild: Pxhere / Rawpixel - CC0 1.0

Ob in Scrum nach jedem Sprint oder in Kanban oder anderen Frameworks je nach Bedarf - Review Meetings in denen der neueste Produktfortschritt den Auftraggeben und Nutzern vorgestellt und mit ihnen diskutiert wird sind ein zentraler Bestandteil agiler Vorgehensweisen. In der Regel hat dabei jedes Team ein eigenes Review-Meeting, allerdings kann es Konstellationen geben in denen gemeinsame Veranstaltungen Sinn machen.

Am naheliegendsten in das im Rahmen agiler Skalierung. Wenn mehrere Teams an einem gemeinsamen Produkt oder in einem gemeinsamen Projekt arbeiten sind mit grosser Wahrscheinlichkeit die Themen aller Teams miteinander verwandt, vor allem dann wenn sie in Release Trains oder anderen gemeinsamen Taktungen arbeiten. Da auf diese Art ein gemeinsames Increment entsteht (oder zusammen passende Incremente entstehen) macht auch eine gemeinsame Präsentation und Diskussion Sinn.

Ein weiterer Anwendungsfall für gemeinsame Reviews ist gegeben wenn mehrere Teams an einer gemeinsamen Codebasis arbeiten in der es keine teambasierte Code Ownership gibt. Das Review kann in dem Fall der passende Ort sein um sich einen Überblick darüber zu verschaffen welches Team an welcher Stelle Änderungen vornimmt. Das Risiko bei einem solchen Vorgehen ist, dass die Veranstaltung zu technisch wird und dadurch andere Zielgruppen abschreckt. Gegebenenfalls macht daher ein gemeinsames technisches Review separat vom fachlichen Review Sinn.

Im Rahmen geografisch verteilter Firmen können gemeinsame Reviews Teil von Events sein mit denen der standortübergreifende Zusammenhalt gefördert wird. Im Rahmen von Präsentationen und Diskussionen können die Mitglieder der jeweiligen Teams direkt miteinander interagieren, was erfahrungsgemäss deutlich intensiver ist als gemeinsame Videokonferenzen. In diesem Kontext haben die Meetings damit eine zusätzliche soziale Funktion.

Zuletzt kann in Firmen mit vielen Teams ein gemeinsames Review eine Notwendigkeit sein um die Kalender der Stakeholder zu entlasten. Man kann sich das einfach vorstellen: wenn 15 Teams gemeinsam an einem Webshop bauen und jedes Ein- oder Zweiwochensprints hat, dann kämen bei separaten Sprint Reviews bis zu 60 Stunden pro Monat zusammen die man alleine in diesen Meetings verbringen könnte, Anlauf- und Abklingzeiten nicht mitgerechnet. Ein Zusammenlegen kann hier für Erleichterung sorgen (wobei aber immer noch gewährleistet sein muss, dass Austausch stattfinden kann).

Where there is no vision, the people perish

Bild: Pexels / Simon Migaj - CC0 1.0

Aller Anfang ist hart, aber wenn es eine Organisation einmal geschafft hat agile Strukturen bei sich einzuführen ist sie zu Erstaunlichem in der Lage. In kurzen Abständen kann sie ihren Kurs anpassen, neue Wege in Technik und Fachlichkeit gehen, neue Kunden ansprechen und mit neuen Partnern kooperieren. Das alles vermag sie nicht nur einmal zu tun sondern beliebig oft, immer wieder und wieder. Und wenn sie Pech hat wird es dann genau so kommen.

So schön die mit Agilität einhergehende Reaktionsgeschwindigkeit auch ist, sie kommt mit einem Preis. Fertige Features wieder auszubauen oder bereits beschlossene Pläne zu verwerfen wird immer dazu führen, dass gewisse Aufwände umsonst gewesen sind und ggf. sogar mit Zusatzaufwänden rückgängig gemacht werden müssen. Wo das regelmässig passiert (und das ist an mehr Stellen als man denken sollte) führt es zu hohem Ressourcenverbrauch und zu zurückgehender Motivation der Mitarbeiter, die das Gefühl bekommen umsonst zu arbeiten. Ein solcher Zickzack-Kurs sollte also möglichst vermieden werden.

Eine gute Möglichkeit dem entgegenzuwirken ist die Schaffung einer übergreifenden Produktvision für die beteiligten Teams, z.B. "Wir wollen für unsere Kunden alle Bankdienstleistungen auf dem Handy verfügbar machen". Die hilft zum einem dabei unnötige Features zu identifizieren und gar nicht erst zu bauen (etwa eine nur auf dem Desktop verfügbare Anwendung), zum anderen kann dadurch erkennbar werden wo noch zu füllende Lücken in der Anwendungslandschaft sind die die Teams noch unter sich aufteilen müssen (z.B. wenn auf dem Handy noch keine Kontoauszüge einsehbar sind).

Um die Teams nicht zu sehr einzuengen (was Agilität und Reaktionsgeschwindigkeit reduzieren würde) sollte eine Produktvision nicht zu stark ausformuliert sein. Zwar sind unter dem einen, plakativen Satz häufig noch einige erklärende Zeilen zu finden, sobald diese aber mehrere Absätze (oder noch schlimmer: Seiten oder Kapitel) umfassen ist das ein klares Zeichen für einen zu hohen Detaillierungsgrad. Wenn sie es wollen können Teams sich aus der grossen Vision kleinere Teilvsionen ableiten, aber wenn das geschieht sollten sie es selbst tun, nicht ein Manager oder Koordinator. Das würde die Selbstorganisation untergraben.

Wer die übergreifende Produktvision formuliert kann übrigens von Produkt zu Produkt und von Firma zu Firma unterschiedlich sein, vom Firmeninhaber bis zu einer PO-Community ist alles denkbar. Demjenigen oder denjenigen sollte nur klar sein, dass es ein Balanceakt ist. Wie oben erwähnt: ohne klare Vision droht Beliebigkeit, bei zu viel Details erstarren die Strukturen. Der anzustrebende Punkt liegt irgendwo in der Mitte dazwischen.

Features entsorgen

Bild: Wikimedia Commons / Hyena - CC0 1.0

Eine der besten Definitionen von Agilität ist die, dass eine agile Organisation in der Lage ist in kurzen Abständen nutzbare Funktionen zum Kunden oder Benutzer zu bringen, unmittelbar dessen Feedback einzuholen und dieses sofort in die Entwicklung der nächsten Funktionalität einfliessen zu lassen. Deliver, inspect, adapt, deliver, inspect, adapt, etc., etc., etc. Ein immerwährender Strom neuer, immer besser werdender Produktincremente.

So richtig und wichtig dieses Vorgehen auch ist, wird es genau so durchgeführt verursacht es aber auch Probleme. Die Codebasis wird immer grösser, die Seitenauswirkungen der Weiterentwicklung werden unvorhersehbarer, die Regressionstests umfangreicher, die Zielgruppen diverser und die die Kundenfeedbacks zahlreicher und uneinheitlicher. Infolge dessen muss ein immer grösserer Teil der Entwicklungszeit für Instandhaltung, Qualitätssicherung und Abstimmungen verwandt werden. Die Durchlaufzeiten werden höher, die Incremente kleiner, die Agilität sinkt.

Die beste Möglichkeit dem entgegenzuwirken ist eine regelmässige Reduzierung des Funktionsumfangs. Den zuvor genannten Entwicklungen wird damit entgegengewirkt, die Produkte werden schlanker und beweglicher und mit ihnen die gesamte Organisation. Die spannende Frage ist jetzt: welche Features sollte man entsorgen? Die leidige Antwort: es kommt drauf an. Naheliegend ist es, die am wenigsten genutzten zuerst auszubauen, aber auch andere sind möglich - die am wenigsten gewinnbringenden, die wartungsaufwändigsten, die am wenigsten zur Firmenidentität passenden und gegebenenfalls noch viele mehr. Egal welche es letztendlich sind - einige müssen daran glauben. Müssten. Eigentlich.

Das alles findet leider nur sehr selten statt, in der Regel deshalb weil ein solches Vorgehen nicht zu den Grundsätzen passt nach denen in vielen Firmen Produktentwicklung stattfindet. Ressourcen und Kapazitäten werden dorthin geleitet wo es Kunden und Umsätze zu gewinnen gibt, nicht dorthin wo Komplexität reduziert wird. Und wenn sogar eine kleine aber treue Benutzergruppe verloren gehen würde werden Diskussionen oft vom jeweils zuständigen Management-Team abgeblockt. An diesen Stellen braucht es Gesamtverantwortung und systemisches Denken. Nur wer die hat erkennt, dass die globale Verbesserung die lokale Verschlechterung aufwiegt.

Wie in vielen anderen Aspekten sind auch hier die kalifornischen IT-Unternehmen vorbildlich. Mit iGoogle, dem Google Reader, Facebook Paper, Instagram Maps, Twitter Vine und vielen mehr gibt es mittlerweile eine erstaunliche Menge entfernter Features und sogar ganzer Produkte, darunter auch solche mit treuen Usern und andere die früher sogar als strategische Zukunftsprojekte galten. Sucht man also nach Beispielen und Argumentationshilfen in dieser Sache - hier findet man sie reichlich. Du willst sein wie Google und Facebook? Dann fang an indem Du die Axt an die eigenen Features legst.

Innovation is about collective genius

Wenn es um die Themen Innovation und Kreativität geht glauben viele Menschen, dass diese in erster Linie in den Köpfen einzelner Menschen entstehen. Dass es sich stattdessen um eine Teamarbeit handelt (und wie man diese befördert) wird hier von Linda Hill beschrieben:

Kommentierte Links (XXXVII)

• Martin Aziz: Business Agility has little to do with Scaling Agile

  Etwas merkwürdig an diesem Artikel ist, dass agile Skalierung in ihm nicht vorkommt, die Überschrift ist also irreführend. Was hingegen sehr gut beschrieben wird sind die für Business-Agilität notwendigen Strukturen auf den verschiedenen Organisationsebenen: auf der obersten Ebene wird eine sich ständig anpassende Strategie verfolgt um mit dem bestehenden Leistungsvermögen den grösstmöglichen Ertrag in einem Marktsegment zu erwirtschaften, in der Mitte werden die einzelnen Produkte und Dienstleistungen immer weiter entwickelt und an die Kundenbedürfnisse angepasst, auf der untersten Ebene sorgen die Teams für transparente Abläufe und hohe Durchlaufzeiten im eigentlichen Produktionsprozess. Klingt ganz einfach. Eigentlich.

• Luís Gonçalves: How to Calculate Cost of Delay So You Know Where You’re Losing Money

Ein Argument das immer wieder vorgebracht wird wenn es um den Mehrwert von agilen und lean-Vorgehensweisen geht ist die Cost of Delay, bzw. deren Reduzierung. Da Kosten sich beziffern lassen sollten stellt sich die Frage, wie das im Fall der Cost of Delay aussehen soll. Diese Aufschlüsselung von Luís Gonçalves ist sehr hilfreich, sie bietet sowohl mehrere Möglichkeiten der Berechnung als auch verschiedene Erscheinungsformen mitsamt des damit verbundenen Dringlichkeitsgrades.

• Fagner Brack: Not Every Company Is a Software Company

  Wer hätte es gedacht, nicht jede Firma ist eine Software-Firma. Aber: ab einer bestimmten Grösse aufwärts (grösserer Mittelstand) stellt jede Firma Software her, und wenn auch nur durch das Customizing eingekaufter Standard-Produkte. Das Problem: in den meisten Unternehmen ist das dem Management nicht bewusst, und wenn doch kann es die damit verbundenen Implikationen nicht erkennen und bewerten. In der Konsequenz wird ein Software-Entwicklungsprozess von Leuten gesteuert denen die Auswirkungen ihres Tuns nicht in Gänze klar sind. Was das bedeutet und was das für Folgen nach sich ziehen kann wird hier detailliert erläutert.
  

• Ben Mancini: Fixing the certification problem

  Ich gestehe, ich bin zertifiziert. Mehrfach. Trotzdem kann ich der damit verbundenen Industrie immer weniger abgewinnen, zu offensichtlich ist es mittlerweile, dass es sich hier im Wesentlichen um ein Tauschgeschäft von Geld gegen Titel handelt. Ben Mancini macht sich sehr kluge Gedanken darüber wie ein besseres Zertifizierungs-System aussehen müsste und was dafür an den bestehenden Zuständen zu ändern wäre. Das Problem das ich sehe - so lange es ein solches Millionengeschäft ist werden die aktuell beteiligten Firmen nicht auf das Geld verzichten wollen. Und wie er selber schreibt: für die Erstellung eines besseren Systems bekäme man zwar Dank, der Aufwand würde aber nicht bezahlt werden. So spricht vieles dafür, dass es bleibt wie es ist.

• Ron Jeffries: Developers Should Abandon Agile

  Irgendwann habe ich mal geschrieben, dass Konzerne nicht versuchen sollten agil zu werden sondern sich stattdessen auf die notwendigen Verbesserungen konzentrieren sollten: kurze Time to Market, hohe Reaktionsgeschwindigkeit und Vermeidung sinnloser Arbeit. Ron Jeffries überträgt das auf die Software-Entwickler - statt sich auf agile Frameworks zu konzentrieren sollten sie an inkrementeller Fertigstellung, kurzen Lieferzeiten, Clean Code und intensiver Kommunikation mit Fachabteilungen und Management arbeiten. Die Pointe ist in beiden Fällen die gleiche: wenn man das macht ist Agilität die Folge, egal ob beabsichtigt oder nicht.

Datengetriebene Retrospektiven

Bild: Pexels / Lukas - CC0 1.0

Nachdem ich in der letzten Woche von Klaus Leopold in dessen unverwechselbarer Art mit Zahlen bombardiert wurde möchte ich dieses Thema auch hier aufgreifen. Agile Vorgehensweisen nehmen für sich in Anspruch, dass sie empirisch basiert und datengetrieben sind, und die naheliegendste Verwendung der erhobenen Zahlen ist ihre Nutzung als Teil des ständigen Verbesserungsprozesses. Ein guter Moment dafür sind die Retrospektiven, in denen die Metriken gemeinsam analysiert werden können. Erfahrungsgemäss bieten sich dann je nach Art der Metrik unterschiedliche Massnahmen an.

Cycle Time

Die Zeit zwischen dem Beginn einer Umsetzung und deren Ende, wobei am Ende ein Produktinkrement stehen sollte das jederzeit live gehen könnte. Im Sinn der Agilität sollte diese Zeit möglichst kurz sein, sollte das Team sie als zu lang empfinden können Massnahmen beschlossen werden um das zu beschleunigen. Dazu gehören z.B. das Kleinerschneiden von Anforderungen oder das Automatisieren von Tests.

Lead Time

Entspricht der Zeit zwischen dem ersten Aufkommen einer Anforderung und dem Ende der Umsetzung (also Cycle Time plus vorgelagerte Prozesse), was bedeutet, dass häufig andere Teams oder Abteilungen beteiligt sind. Auch diese Zeitspanne sollte so kurz wie möglich sein, zu den möglichen Verbesserungsmassnahmen gehören die Harmonisierung von Übergaben zwischen den Phasen oder die Verbesserung der Kommunikation zwischen den Teams und Abteilungen.

Throughput

Eine der häufigsten und einfachsten Metriken: erfasst wird die Zahl der vervollständigten Arbeitspakete pro Zeiteinheit (z.B. pro Monat). Da diese Zahl durch eine Vielzahl von Faktoren beeinflusst werden kann gibt es keine Verbesserungsmassnahmen die naheliegender sind als andere, hier kommt es auf den Einzelfall an.

Velocity

Im agilen Kontext wird dieser Begriff vor allem von Scrum Teams benutzt (obwohl er kein offizieller Teil von Scrum ist). Unter ihm wird die Summe der Story Points aus allen im letzten Sprint fertiggestellten User Stories verstanden. Da Story Points keine exakte Schätzung sind und ggf. nicht alle Items im Sprint so geschätzt werden ist diese Zahl mit Vorsicht zu behandeln, sie kann aber die Ausgangsbasis für eine Problemanalyse sein.

Work in Progress

Die Menge verschiedener Aufgaben an denen ein Team gleichzeitig arbeitet. Das mit zu viel paralleler Arbeit verbundene Multitasking führt in der Regel zu Konzentrationsverlust und höherer Cylcle Time, umgekehrt kann bei Arbeitsprozessen die sich über mehrere Phasen erstrecken zu wenig Arbeit in einer Phase dazu führen, dass die nachgelagerten Phasen leerlaufen. Die Gegenmassnahmen sind Ober- oder Untergrenzen, die so genannten Work in Progress-Limits oder WIP-Limits.

WIP-Age

Eine Ableitung der Lead Time. Konkret geht es darum, wie hoch die bisherige Lead Time der Aufgaben ist, die im aktuellen Moment, bzw. im aktuellen Sprint bearbeitet werden. Ist diese Wert zu hoch, die Cycle Time innerhalb der Umsetzungsphase aber niedrig, kann das bedeuten, dass in den vorgelagerten Prozessschritten Staus bestehen weil dort zu viel vorgearbeitet wird. Um das zu beheben kann es Sinn machen WIP-Limits einzuführen die über alle Phasen harmonisiert sind und dabei auch die jeweiligen unterschiedlichen Cycle Times berücksichtigen.

Blocked Days/Hours

Sowohl hohe Lead Times und Cycle Times als auch hohes WIP-Age können darauf zurückgehen, dass Arbeiten unterbrochen werden müssen um auf Zulieferungen oder Abnahmen zu warten, die von Personen ausserhalb des Teams vorgenommen werden. Ist die Anzahl der dadurch entstehenden Verzögerungstage oder -stunden zu hoch kann das dadurch ausgeglichen werden, dass das Team diese Arbeiten selbst erledigt (und das ggf. erlernt).

Bug Rate/Incident Rate

Eher unschöne Metriken, da sie die Folge von früher gemachten Fehlern und Versäumnissen sind. Dementsprechend sollten Verbesserungen am besten auf die Qualitätsaspekte der Produktentwicklung abzielen, etwa auf Testabdeckung und Code Reviews.

Bugfix Time

Auch das ist klar, je länger es dauert Bugs zu beheben desto mehr Probleme treten auf, und das sowohl bei der Systemstabilität als auch bei der Nutzerzufriedenheit. Die Bugfix Time als Sonderfall der Lead Time oder Cycle Time ist daher von besonderer Bedeutung. Die beste Gegenmassnahme ist eine Zero Bug-Policy.

---

Voraussetzung für all das ist natürlich, dass die jeweiligen Metriken permanent erhoben werden, entweder digital durch die jeweiligen Tools oder von Hand. Das ist zwar ein gewisser Aufwand, allerdings einer der sich definitiv lohnt.