Donnerstag, 28. Juni 2018

Kommentierte Links (XXXVIII)

FS
  • Steve Denning: Ten Agile Axioms That Make Managers Anxious

    Ein Artikel der anscheinend in der Eile des inspirierten Moments geschrieben wurde. Da die Nummer 7 zweimal vorkommt sind es 11 Axiome und nicht 10, Henrik Kniberg wird zu Henrik Nyberg und auch noch weitere Kleinigkeiten ziehen sich durch den Text. Trotz dieser kleinen Fehler ist er bemerkenswert in seinen Aussagen;

    First Law Of Agile: The Law Of The Customer
    1. Firms Make More Money By Not Focusing On Making Money
    2. There Are No Internal Customers
    3. There Are No B2B Organizations
    4. Making Better Products May Not Make More Money
    The Second Law Of Agile: The Law Of The Small Teams
    5. Forget Economies of Scale: Your Market Is One Person
    6. Don’t Scale Up: Descale Complexity Down
    7. Control Is Enhanced By Letting Go Of Control
    7. Agile Is A Mindset, Not A Process
    8. Talent Drives Strategy, Not Vice Versa
    The Third Law Of Agile: The Law Of The Network
    9. The Top-Down Organizational Pyramid Is Finished
    10. Lead Like A Gardener, Not A Commander


    Kontrovers und Kontra-Intuitiv. Das alles nachzuerzählen würde zu weit führen, daher der Ratschlag: oben auf den Link klicken und selber lesen.

  • Zeit: Deadlines halten uns von wichtigeren Aufgaben ab

  • Eine Weiterführung der Debatte um Push-Prinzip und Pull-Prinzip. Das Setzen von Deadlines ist eine der klarsten Formen von Push und wird im agilen Kontext daher nach Möglichkeit abgelehnt. Meng Zhu unterfüttert das mit wissenschaftlichen Erkenntnissen. Zeitdruck erzeugt falsche Prioritäten, senkt Produktivität, führt zu Defocussierung und zum Aufschieben wichtiger aber nicht zeitkritischer Aufgaben. Das Ganze nicht etwa im anekdotischen Einzelfall sondern im Durchschnitt einer statistisch validen Testgruppe. Das sollte eigentlich eine gute Grundlage sein um gegen "aktivierende" und "fordernde" Fristen zu argumentieren.

  • FAZ: In Kalifornien kommt der Burger vom Roboter

    Über die kalifornischen Burger-Roboter hatte ich schonmal etwas geschrieben. Mittlerweile scheint man die Probleme dort in den Griff zu bekommen, mit bemerkenswerten Folgen: das Personal wird entlastet und bekommt geldwerte Leistungen und Zeit für persönliche Entwicklung und Weiterbildung. An dieser Stelle wiederholt sich die Geschichte: bereits vor über hundert Jahren führte die Einführung des Fliessbandes zu ähnlichen Effekten. Es kommt also gerade zu einer weiteren Verschiebungswelle, weg von körperlicher Akkordarbeit, hin zu besser angesehenen und weniger aufreibenden Tätigkeiten. Mit allen Folgen die das für die gesellschaftliche Entwicklung hat.

  • Jean-Pierre Lambert: Scrum Master vs. Agile Coach - same in theory, what about practice?

    Es gibt in agilen Kreisen einen sarkastischen Witz: "Was ist der Unterschied zwischen einem Scrum Master und einem Agile Coach?" "Ein um 500 € höherer Tagessatz." Jean-Pierre Lambert geht dem näher auf den Grund. Wie er richtig schreibt sollte es zwischen den beiden Rollen eigentlich keinen Unterschied geben, weder in den Tätigkeiten noch in der Entlohnung. Und doch ist er da. Woran sich in der Berufswelt Scrum Master und Agile Coach unterscheiden zeigt er an vielen Aspekten auf. Und das nicht mit ideologischem Blick sondern einfach die Realität beschreibend.

  • Mike Cohn: Six Guidelines for Saying No to a Stakeholder

    Zu den Allgemeinplätzen in Ausbildung und Coaching von Product Ownern gehört, dass sie in der Lage sein müssen Nein zu sagen. Wie das in der Realität aussehen soll und wie dabei Verärgerung und Konflikte vermieden werden können wird dagegen zu selten erklärt. Mike Cohn macht sich die Mühe und holt das nach.

Montag, 25. Juni 2018

Deine Muda: Transportation

FS
Bild: Pixabay / Skitterphoto - CC0 1.0
Vor wenigen Tagen hatte ich die Ehre auf der Inhouse-Konferenz eines Kunden einen Vortrag halten zu dürfen. Das Thema waren die Mudas (無駄), also die nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System. Bei der Vorbereitung bin ich vor allem an einer Muda hängengeblieben, der Transportation, bzw. dem Transport.

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

FS
... 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

FS
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.

Freitag, 15. Juni 2018

Gemeinsame Reviews

FS
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).

Dienstag, 12. Juni 2018

Where there is no vision, the people perish

FS
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.

Donnerstag, 7. Juni 2018

Features entsorgen

FS
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.

Montag, 4. Juni 2018

Innovation is about collective genius

FS
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:

Powered by Blogger.