Donnerstag, 29. September 2016

Kommentierte Links (XVII)

Grafik: Pixabay / Geralt - Lizenz
  • Ron Jeffries: Dark Scrum

  • Ab einem gewissen Bekanntheitsgrad kann man einfach mal neue Begriffe einführen und Ron Jeffries ist bekannt genug um es zu versuchen. Seine Wortschöpfung "Dark Scrum" bezeichnet eine Umsetzung dieser Methode bei der das Management die gegebene Transparenz missbraucht. Statt Vertrauen und Selbstorganisation gibt es Mircomanagement, Command & Control, Blaming und Rechtfertigungszwänge. Nachvollziehbarerweise sind die Ergebnisse eines solchen Vorgehens verheerend. Sollte es gelingen den Begriff Dark Scrum zu etablieren und zu popularisieren würde es vielen Scrum Mastern ein Werkzeug geben um dagegen zu argumentieren. Ob das von Erfolg gekrönt wird steht auf einem anderen Blatt, aber zumindest weiss man dann woran man ist und kann ggf. mit den Füssen abstimmen.

  • Jobspotting.com: Warum ein Kicker noch keine Unternehmenskultur macht (Edit: Link ist mittlerweile tot)

    Wenn wir schon bei neuen Begrifflichkeiten sind - ich würde hier von potemkinscher Agilität sprechen. Offene Räume, Teamevents, Kickertische und Lounge-Bereiche machen das Arbeiten vielleicht bequemer, sorgen aber nicht von sich aus für Selbstorganisation und effektives Arbeiten. Ich kann mich an lichtdurchflutete Großraumbüros erinnern in denen übles Dark Scrum gelebt wurde (siehe oben) und an Abteilungen mit Loft-Atmosphäre in denen die (Pseudo)Scrumteams nur die Detailvorgaben der Anforderungsmanager und Architekten abarbeiten durften. Eine agile Transition ohne Kulturwandel funktioniert eben nicht.

  • Rob Lambert: A Blazingly Simple Guide To Turning Around a Team

    Ob ich diesen Weg als "berauschend einfach" bezeichnen würde weiß ich nicht, schließlich sind auch hier sechs Monate Arbeit notwendig um ein dysfunktionales Team "umzudrehen". Grundsätzlich macht das Vorgehen allerdings Sinn - ein Monat zur Einarbeitung, ein Monat für die Erarbeitung von Metriken und Benchmarks, ein Monat für das Anstoßen größerer Veränderungen, zwei Monate für die Umsetzung, einen Monat für Retrospektiven und Stabilisierungen. Mein empfohlenes Vorgehen dauert ähnlich lang. Interessant ist in solchen Fällen die Reaktion des Managements wenn ab dem zweiten Monat die Leistung des Team (vorübergehend) sinkt. Das ist der klassische Zeitpunkt an dem irgendjemand die Nerven verlieren und alles abbrechen kann.

  • Victor Savkin: Is Taking Small Steps Always a Good Idea?

    In vielen Teams ist es eine wiederkehrende Diskussion, die in fast jedem Planning II geführt wird: wie granular müssen Tasks geschnitten werden? Dieser Artikel versucht die Diskussion auf wissenschaftliche Füße zu stellen indem er den Bekanntheitsgrad der Aufgabe mit den Verarbeitungskapazitäten des Gehirns in Verbindung setzt. Verkürzt gesagt entsteht dabei folgende Faustregel: hoher Bekanntheitsgrad = große Tasks, geringer Bekanntheitsgrad = kleine Tasks. Voraussetzung ist aber, dass auch diese größeren Tasks noch innerhalb eines Tages zu bewältigen sein müssen. Vor allem die Visualisierungen finde ich sehr ansprechend, sie sollten sich gut in Workshops integrieren lassen.

  • Scott Belsky: Avoiding Organizational Debt

  • Das ist eine interessante Definition von Organisatorischer Schuld. Ich habe bisher darunter verstanden, dass versäumt wird die Organisation so aufzustellen, dass sie gegenwärtige und/oder zukünftige Herausforderungen bewältigen kann. Hier ist die Definition grundlegender: Organisatorische Schuld liegt vor wenn die Entscheidungsträger nicht bereit oder in der Lage sind Entscheidungen zu treffen. Der Effekt ist in beiden Fällen der Gleiche - die Herausforderungen der Gegenwart überfordern die Organisation, mit allen denkbaren Folgen die sich daraus ergeben. Bei dem Entscheidungszentrierten Ansatz ist aber die Lösung naheliegender und offensichtlicher: früh entscheiden, früh überprüfen, früh korrigieren.

Montag, 26. September 2016

Ein Bild sagt mehr als 1000 Worte (XIII)

Ein Kalauer für die Oktoberfest-Zeit.

Donnerstag, 22. September 2016

Dunning-Kruger-Effekt (II)

Grafik: Pixabay / CreativeMagic - Lizenz
Um den Dunning-Kruger-Effekt ging es hier ja im letzten Jahr schon einmal. Verkürzt gesagt: Wer inkompetent ist, ist im Normalfall auch nicht kompetent genug um das zu erkennen, weshalb er keine Notwendigkeit sieht etwas an sich zu verändern. David Dunning und Justin Kruger haben es bereits im Titel ihrer Arbeit treffend zusammengefasst – David Dunning, Justin Kruger: Unskilled and unaware of it. How difficulties in recognizing one‘s own incompetence lead to inflated self asessments. Ein deprimierender Befund, und einer der in der Realität immer wieder zu falschen Verhaltensweisen führt. Allerdings – diese werden nicht notwendigerweise von den Betroffenen an den Tag gelegt.

Ich musste bereits mehrfach miterleben, dass Scrum Master das agile Coaching von Entwicklern oder Managern mit dem Verweis auf Dunning und Kruger nicht weitergeführt haben. „Der lernt es nicht mehr“, „Der hat ein zu dickes Brett vor dem Kopf“, „Der ist Change-resistent“. Solche Aussagen. Die Betroffenen wurden einfach aufgegeben, häufig mit einem Karriereknick als Folge. Nun will ich nicht abstreiten, dass es pathologische Persönlichkeiten gibt, bei denen alle Hoffnung vergebens ist. Die sind aber sehr selten. Im Normalfall sind die bockigen Problemfälle sehr wohl durch Coaching erreichbar. Und: das steht nicht etwa im Gegensatz zu den Erkenntnissen von Dunning und Kruger, sondern wird von denen genau so beschrieben.

Wenn die beiden belegen, dass die Mehrheit der „erkenntnisresistenten“ Personen nicht zur Verbesserung ihres Verhaltens in der Lage ist, dann meinen sie damit nicht ohne externe Unterstützung. Mit Unterstützung sind sie es jedoch sehr wohl. In der letzten ihrer vier Versuchsreihen erhielten die Teilnehmer „Nachhilfe“. Ihnen wurde freundlich und nachvollziehbar erklärt wo sie von Fehlannahmen oder Missverständnissen beeinflusst waren und was stattdessen die richtigen Schlüsse und Verhaltensweisen gewesen wären. Und siehe da – das Kompetenzlevel stieg und die Fähigkeit zur realistischen Selbsteinschätzung stieg auch.

Dass der Dunning-Kruger-Effekt mittlerweile als ein „doof bleibt doof“-Totschlagargument benutzt wird ist nicht im Sinne seiner Urheber. Die Studie sagt klar aus, dass Menschen durch Coaching besser und kompetenter werden können. Und wer das bestreitet sollte vielleicht überprüfen ob er nicht selbst von dem Effekt betroffen ist.

Montag, 19. September 2016

Die Wasa

Zumindest im englischsprachigen Raum ist die Geschichte der Wasa ein legendäres Beispiel für schlechtes Projektmanagement: geplant als größtes Schiff der schwedischen Flotte wurde sie sie während der Bauzeit durch permanente Änderungsanforderungen so stark verändert, dass sie fahruntüchtig wurde und während ihrer Jungfernfahrt sank. In diesem Video ist das alles anschaulich visualisiert.



Interessant ist, welche unterschiedlichen Schlüsse aus dieser Geschichte gezogen werden. Klassische Projektmanager sehen in ihr eine Bestätigung für die Grundhaltung, dass Change Requests wann immer möglich abzulehnen sind. Agile Projektmanager leiten daraus eher die Sinnhaftigkeit von Prototyping, Datengetriebenheit, iterativem Vorgehen und hoher Testabsicherung ab.

Donnerstag, 15. September 2016

Scrumkoch-Zertifikat

Meine Zertifikats-Liste ist um einen imposanten Eintrag reicher: mit einer leichten Verspätung von nur neun Monaten hat Chefkoch.de mit der Verteilung der Scrumkoch-Zertifikate begonnen. Wenn das nicht ein unschlagbares Zeugnis meiner umfassenden Qualifikationen ist - was dann?


Montag, 12. September 2016

Abstimmung mit den Füssen

Bild: Unsplash / David Lee - Lizenz
Über die Jahre habe ich einige Scrum-Projekte miterlebt: große, kleine, langlebige, kurzfristige, solche an denen ich beteiligt war, solche die ich auditieren durfte und solche die ich von aussen betrachten konnte. In weit über der Hälfte von ihnen ist das Vorgehen irgendwann nicht mehr agil gewesen. Nach einer kurzen Euphoriephase wurde den Verantwortlichen der Kontrollverlust unheimlich und das Management artete immer stärker in Detailsteuerung und Detailkontrolle aus. Die vorhersehbaren Folgen - die Auslieferungszyklen wurden länger, Flaschenhälse und Silos entstanden, die Kultur wandelte sich kontinuierlich in Richtung Blaming und Cover your Ass. R.I.P. Agilität.

Sollte mir das Sorgen machen? Ja das tut es. Es zeigt, dass agile Transitionen schwer sind und häufig scheitern. Es zeigt, dass das Management häufig noch nicht bereit ist für einen Rollen- und Verhaltenswechsel. Es zeigt, dass Cargo Cult und Dark Scrum verbreitet sind und sich weiter ausbreiten. Eine ganz bestimmte Sorge habe ich allerdings nicht: die Sorge, dass Scrum grundsätzlich scheitern könnte. Selbst wenn die Mehrheit der Führungskräfte diese Methode bewusst oder unbewusst untergräbt (und ich fürchte, dass das so ist) - letztendlich sitzen sie am kürzeren Hebel. Und der Grund dafür ist der Fachkräftemangel.

Selbst wenn Scrum eigentlich ein Framework ist, dass im Wesentlichen auf Unternehmensinteressen wie kurzen Entwicklungszyklen, wenig Verschwendung und hoher Produktqualität beruht - für die meisten Entwickler ist es etwas ganz anderes. Zu ihrem Glück ist es so, dass der beste Weg zur Erreichung der gerade genannten Ziele die Selbstorganisation ist. Viel Selbstbestimmung, wenig Befehle, keine unrealistischen Deadlines und konstruktive Zusammenarbeit gehören einfach dazu wenn man Mitglied in einem Scrum-Team ist. Wer das einmal erlebt hat will in der Regel nie mehr anders arbeiten, und wenn man das alles im aktuellen Job nicht mehr haben kann, dann wartet bereits der nächste.

Bedingt durch den IT-Fachkräftemangel sind die Unternehmen gezwungen ihren potentiellen Mitarbeitern etwas zu bieten, und Scrum ist etwas womit man sich von anderen Unternehmen abheben kann. Wer den Wettbewerb um die besten Köpfe nicht verlieren will kommt gar nicht darum herum. Auf der anderen Seite vertreibt jeder Anfall von Command and Control die Mitarbeiter zunächst in die innere und dann in die äussere Emigration. Ich habe miterlebt, dass ein Unternehmen nach der Abschaffung von Scrum über die Hälfte seiner IT-Abteilung verloren hat. Und das ist kein Einzelfall.

In vielen Unternehmen ist diese Realität gedanklich noch nicht angekommen. Hier wird noch geglaubt, man könne agile Methoden per Dekret für gescheitert erklären. Ich fürchte, dass hier ein Lernen durch Schmerzen stattfinden muss bevor sich etwas ändert. Andererseits - auch das ist ja Inspect & Adapt, oder?

Donnerstag, 8. September 2016

Hardware-Scrum mit 3D-Druckern

Bild: Wikimedia Commons/Urfin7 - CC BY-SA 4.0
Zum ersten mal habe ich vor ca. einem Dreivierteljahr davon gehört, dass Airbus agile Methoden in der Hardware-Fertigung einsetzt, und zwar bei der Master of Future Administration-Veranstaltung in Berlin. Zu den Referenten dort gehörte ein Airbus-Manager, der erzählte, dass die Firma 3D-Drucker einsetzt um neue Typen von Kabinenhalterungen herzustellen. Für die Herstellung müsste nur das Design in den Drucker geladen werden, unmittelbar darauf könnte der Druck starten und nach einem Tag hätte man bereits die ersten Belastungstest-Ergebnisse auf deren Basis das Design wieder verbessert werden könnte. Ich wollte eigentlich schon damals darüber schreiben, allerdings ist mir das Thema immer wieder entfallen - bis jetzt.

Zufällig bin ich diese Woche auf einen Artikel aus dem letzten Juni gestossen, aus dem hervorgeht, dass Airbus mittlerweile ganze Flugzeuge im 3D-Druck erstellt. Konkret geht es um den "Thor" (Testing High-Tech Objectives in Reality), eine Drohne bei der bis auf den Antrieb, Fahrwerk und die Fernsteuerung bereits alles aus dem Drucker stammt. Im Grunde findet bei diesem Gerät nichts anderes statt als ein Integrationstest: nachdem die Einzelteile in der oben erwähnten Art und Weise hergestellt wurden werden sie zusammengesetzt und der Thor kann abheben. Wenn er fliegen und landen kann ohne beschädigt zu werden war der Test erfolgreich und die Bauteile können auch in kommerziellen Flugzeugen eingesetzt werden. Wenn er in der Luft auseinanderfällt entstehen selbst bei einem Totalschaden lediglich Materialkosten in Höhe von 20.000 €.

Zusammengenommen dürfte zwischen Designanpassungen und Jungfernflug bei dieser Art der Herstellung nur ein Zeitraum von wenigen Wochen liegen (bei herkömmlicher Fertigung können das Monate oder sogar Jahre sein, wie ich letztes Jahr in Berlin gelernt habe). In derartig kurzen Zeiträumen wäre es sogar möglich in Sprints zu arbeiten - Scrum in der Hardware-Fertigung also. Dadurch, dass es der Flugzeugbau ist der eine Vorreiterrolle bei der agilen Fertigung einnimmt schließt sich übrigens ein Kreis, schließlich wurde in dieser Branche bereits in den 50ern iterativ-inkremental development (IID) eingesetzt, einer der frühesten Vorläufer agiler Methoden. Um es mit einem meiner Liebliengslieder zu sagen: It's all just a little bit of history repeating.

Montag, 5. September 2016

Neurowissenschaften und Agilität

Beta-Blocker, Spiegelneuronen, Melatonin, Cortisol und Herzratenvariabilität - zunächst sollte man nicht denken, dass diese Themen mit der Agilität in Unternehmen zu tun haben. Dass dem doch so ist wird in diesem Vortrag herausgearbeitet, der dadurch einige völlig neue Blickwinkel öffnet. Sehenswert.