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.

Mittwoch, 31. August 2016

Kommentierte Links (XVI)

Grafik: Pixabay / Geralt - Lizenz

Ethan Bernstein, John Bunch, Niko Canner, Michael Lee: Beyond the Holocracy Hype

Mal wieder ein Longread. Man lernt hier viel über Holocracy, eine Management-Methode die dort ansetzt wo Scrum aufhört: in den höheren Ebenen mittlerer und größerer Unternehmen. Statt fester Manager-Positionen gibt es hier flexible Rollen, die je nach Bedarf von unterschiedlichen Personen wahrgenommen werden können, wodurch eine Entkoppelung von Entscheidungs- und Umsetzungsebene verhindert wird. Über die bloße Erklärung der Rollen und Prozesse werden aber auch Grenzen aufgezeigt, bis zu dem Punkt an dem Mitarbeiter kündigen weil sie sich in den neuen Strukturen nicht mehr wiederfinden.

Lars Jensen: Ein Blatt wendet sich

Die Washington Post dürfte zur Zeit wohl eines der weltweit spannendsten Medien-Experimente sein. Seit der Übernahme durch den Amazon-Gründer Jeff Bezos wird dort in einer Art gearbeitet die sich in vieler Hinsicht an die agilen Frameworks anlehnt: datengetrieben, mit A/B-Tests, kurzen Feedback-Zyklen und IT-gestützten Prozessen. Von der Realität in den deutschen Redaktionen ist das noch Lichtjahre entfernt, bietet aber einen Blick auf eine Zukunft wie sie auch hier irgendwann eintreten könnte.

Jason Little: Why Agile Breaks Your Organization (Edit: Link ist mittlerweile tot)

Die zentrale These von Jason Little beruht darauf, dass es in großen Unternehmen zwei Organisationsstrukturen gibt: eine offizielle, die in der Theorie besser funktioniert als in der Praxis, und eine inoffizielle, die den Laden am Laufen hält (die brauchbare Illegalität, zu der ich bereits etwas geschrieben habe). Im Rahmen von agilen Transitionen werden meistens aus den bisher informellen Prozessen offizielle, da in ihnen Entscheidungen immer dorthin verlagert werden wo sie in der Praxis Sinn machen. Für das Gesamtunternehmen ist das aus wirtschaftlicher Sicht gut, aus organisatorischer Sicht aber kritisch, da die Dysfunktionalität der offiziellen Prozesse jetzt offensichtlich wird.

Patrik Höglund: Hackable Projects (Code Health)

Unter "Hackable" versteht man bei Google nicht etwa, dass ein Projekt Sicherheitslücken hat, sondern dass es jederzeit leicht modifizierbar und umplanbar ist. Konkreter definiert gilt es aus technischer Sicht als hackable sobald die folgenden Kriterien erfüllt sind:
  • Developing is easy
  • Fast build
  • Good, fast tests
  • Clean code
  • Easy running + debugging
  • One-click rollbacks
Aus diesen Kriterien werden die drei Pfeiler Code Health, Debuggability und Infrastructure abgeleitet, deren Google-Definition in einer Serie von Einträgen erläutert wird. Dieser hier ist der erste und dreht sich folgerichtig um Code Health.

Red Herring: How Zalando Tech Became Berlin’s Hottest Workplace

"Radical Agility" klingt erstmal vielversprechend. Was sich anscheinend bei Zalando dahinter verbirgt ist eine Abschaffung der klassischen Abteilungs-, Bereichs- und Teamleiter mitsamt vieler dahinterstehender Kompetenzen: Teamzusammenstellung und Auswahl der Themen an denen gearbeitet wiird erfolgen jetzt beispielsweise selbstorganisiert auf der untersten Ebene. Ich habe ähnliche Konstellationen bereits erlebt, mitsamt der damit verbundenen Herausforderungen. Sich so aufzustellen ist in vieler Hinsicht schwer, aber auch in vieler Hinsicht lohnenswert.

Montag, 29. August 2016

Scaled Agile: Scrum of Scrums und Communities of Practice

Bild: Wikimedia Commons/Caroline Léna Becker - CC BY 3.0
Zu den häufigsten Problemen auf größeren Scrum-Projekten gehört die übergreifende Koordination zwischen den Entwicklungsteams. Es muss sichergestellt werden, dass Abhängigkeiten berücksichtigt werden, dass redundante Arbeit vermieden wird und dass Erkenntnisse und Erfahrungen ausgetauscht werden. Da die Koordination durch einen oder mehrere Manager zu Hierarchie, Zeitverlust und Ineffizienz führen würde (siehe hier) tauschen die Teams sich direkt aus, in Meetings die meistens unter den Namen "Scrum of Scrums" (SoS) oder "Communitiy of Practice" (CoP) stattfinden.

Scrum of Scrums

Das Scrum of Scrums dient der Identifitierung und Auflösung von Problemen und Abhängigkeiten zwischen den Teams, bzw. zwischen mehreren Teams und Kunden, Stakeholdern oder dem umgebenden Unternehmen. Beispiele wären unklar definierte Schnittstellen oder Architektur-Standards. Ein SoS sollte regelmässig, z.B. einmal pro Woche als 15-minütiges Standup-Meeting stattfinden, teilnehmen sollte ein Vertreter jedes Teams (im Idealfall weder der PO noch der Scrum Master, es kann aber ein Scrum Master als Moderator anwesend sein).1 Um die Arbeit strukturiert und transparent zu halten kann ein Scrum of Scrum ein eigenes Backlog haben, in dem die Aufgaben gesammelt, priorisiert und sequentiell abgearbeitet werden. In diesem Rahmen kann auch mit Sprints und "Aufgaben-Ownern" gearbeitet werden, wenn das für die Beteiligten sinnvoll erscheint.

Community of Practice

Eine Community of Practice hat den gegenseitigen Austausch von Erfahrungen und Best Practices zum Ziel. Da diese sich im Einzelfall sehr stark unterscheiden können sind Format, Dauer und Teilnehmerkreis nicht vorgegeben. Für eine CoP die sich mit Erfahrungswerten zu Meeting-Moderation befasst bietet sich beispielsweise ein Lean Coffee an, für eine die sich mit Programmier-Techniken befasst ein Coding-Dojo, für wieder andere ein Expertenvortrag. Teilnehmen kann jeder der Interesse hat, die hier gelernten Techniken können in die anderen Teams übernommen werden, müssen aber nicht. In vielen Unternehmen werden Communities of Practice auch als Gilden bezeichnet.

Der Expertentipp: SoS und CoP getrennt halten

Ein häufiges Antipattern ist es, diese beiden Koordinations-Meetings zu einem zusammenzulegen um dadurch Zeit zu sparen. Wer das tut hat meistens nicht verstanden, dass Scrum of Scrums und Community of Practice grundlegend verschiedene Konzepte sind, die unterschiedliche Teilnehmer und unterschiedliche Meetingformate erfordern und unterschiedliche Ergebnisse hervorbringen. Derartige Hybrid-Meetings haben ein sehr hohes Dysfunktionalitäts-Risiko, weshalb sie nach Möglichkeit vermieden werden sollten.


1Im den Skalierungsframeworks Scrum@Scale und SAFe ist die Teilnahme am Scrum of Scrums den Scrum Mastern vorbehalten, was ein häufiger Kritikpunkt an ihnen ist