Montag, 25. Juni 2018
Deine Muda: Transportation
 |
| Bild: Pixabay / Skitterphoto - Lizenz |
Kurz zum Hintergrund: solange Güter von A nach B transportiert werden, können sie nicht weitergegeben oder weiterverarbeitet werden, sie bilden also totes Kapital. Zusätzlich dazu verbraucht der Transportvorgang weitere Ressourcen, von der Arbeitszeit des Fahrers über das verbrannte Benzin bis hin zum Verschleiss des Fahrzeugs. Aus diesen Gründen gilt Transport als Muda.
Der irritierende Punkt - in vielen Firmen in denen ich gearbeitet habe sind Transporte noch ein Alltagsphänomen, und das obwohl es sich fast ausschliesslich um Branchen der IT- und Wissensarbeit handelt, in denen die Digitalisierung eigentlich dafür gesorgt haben müsste, dass alles zentral abgelegt oder per Mausklick um den Globus geschickt werden kann. Allein - oft ist dem nicht so. Überall wird noch Papier befördert.
Zwar seltener werdend aber noch immer zu finden sind die Laufmappen in denen die Hauspost Briefe und Formulare durch die Gegend fährt, häufig anzutreffen sind Lieferungen gedruckter (und schnell veraltender) Anleitungen, Anforderungen und Dokumentationen sowie Prospekte, Kataloge und Mitarbeiterzeitschriften. Einige besonders skurrile Sonderfälle bilden die Transporte digitaler Datenträger, etwa von Disketten und CDs.
Das all das auch gegenwärtig noch stattfindet lässt sich in der Regel mit zwei Ursachen erklären. Zum einen hängen gerade ältere Mitarbeiter noch an der haptischen Erfahrung von Papier und fordern diese immer wieder ein, zum anderen wird die Digitalisierung von Prozessen oft nicht mehr vorangetrieben, sei es weil man sie für abgeschlossen hält oder sei es weil gerade andere Vorhaben wichtiger sind.
Selbst wenn man es kaum glauben mag - auch heute sind in der IT- und Wissensarbeit die fehlende Digitalisierung und der damit verbundene Transportaufwand grosse Probleme. Diese anzugehen bietet noch immer ein grosses Potential für mehr Effektivität und weniger Transportation-Muda.
Donnerstag, 21. Juni 2018
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.
Montag, 18. Juni 2018
Agile Silos
 |
| Bild: Wikimedia Commons / Pline - CC BY-SA 3.0 |
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.
Freitag, 15. Juni 2018
Gemeinsame Reviews
 |
| Bild: Pxhere / Rawpixel - CC0 1.0 |
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).
Dienstag, 12. Juni 2018
Where there is no vision, the people perish
 |
| Bild: Pexels / Simon Migaj - Lizenz |
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.
Donnerstag, 7. Juni 2018
Features entsorgen
 |
| Bild: Wikimedia Commons / Hyena - CC0 1.0 |
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.
Montag, 4. Juni 2018
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:Donnerstag, 31. Mai 2018
Kommentierte Links (XXXVII)
 |
| Bild: Pixabay / Bru-nO - Lizenz |
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.
