Montag, 27. Juli 2015

Die Geschichte des Post-its

Wer schon einmal auf einem Scrum- oder Kanban-Projekt gearbeitet hat wird sofort wissen was dieser Comic mit diesem Blog zu tun hat. Das größte Projekt auf dem ich bisher war ( > 300 Entwickler ) hat pro Jahr mehrere Tonnen (!) Post-its verbraucht und in der Scrum-Szene gibt es den Running Gag, dass die Methode in Wahrheit von 3M erfunden wurde um deren Absatz anzukurbeln.

How a Solution Without a Problem Became the Post-it Note
Zum Lesen bitte auf den Schriftzug im eingebundenen Vorschaubild klicken.

Donnerstag, 23. Juli 2015

Der Scrum Master als Impediment

Bild: Wikimedia Commons/Twice25 - CC BY-SA 2.5

Selbst wenn er vielleicht nicht ausdrücklich so gemeint ist, der Dilbert-Comic von gestern wird von vielen Leuten die ich kenne als Anspielung auf inkompetente Scrum Master verstanden, die ihrem Team mehr schaden als nutzen. In der Theorie mögen die Scrum Master nämlich die Rolle der Change Agents, Team Coaches und agilen Evangelisten einnehmen, in der Realität sind es aber leider zu häufig Fehlbesetzungen. In den letzten Jahren sind mir einige derartig fehlbesetzte Personen begegnet und aufbauend darauf möchte ich eine kleine Typologie erstellen.

  1. Die bockige Zwangsverpflichtung
    2. Der erste und vermutlich der tragischste Fall. Niemand hat ihn gefragt ob er den Job wollte, und wenn doch dann wollte er nicht und musste trotzdem. Er kommt nicht klar mit Verantwortung und/oder Menschen, empfindet seine Arbeit als Zumutung und fährt sie so weit wie möglich herunter. Als Folge dieser Verweigerungshaltung stellt er irgendwann nur noch Termine ein, blockt alles andere ab mit der Begründung, dass das Team schließlich selbstverwaltet ist und macht sonst nichts.
  2. Der Cargo Cult-Scrum Master
    3. Schließt an die Artikel zu vermurkstem Scrum, zu  Shuhari und zum Dunning-Kruger-Effekt an. Ohne zu wissen was er tut fügt dieser Typus dem Team schweren Schaden zu: Retrospektiven fallen aus oder finden nur Alibi-mäßig statt ("Jeder sagt kurz einen Satz zum letzten Sprint"), aus Groomings werden Product Owner oder Entwickler ausgeladen ("Die sollen lieber arbeiten") und in Reviews werden unfertige Stories vorgeführt ("Wir müssen doch zeigen was wir gemacht haben"). Das Verheerende daran ist, dass das alles aus gutem Willen entsteht und aus dem Glauben, eigentlich das Richtige zu tun um das Team "besser" zu machen. Deshalb vielleicht der gefährlichste Typ.

  3. Der Chef/Abteilungsleiter
    4. Bedarf im Grunde keiner Erklärung. Die Teammitglieder sind ihm disziplinarisch untergeordnet, und das bleibt auch so. Scrum steht nur auf dem Papier, in Wirklichkeit gibt er die Befehle.

  4. Der Projektmanager
    5. Ein Grenzfall mit fließendem Übergang zum manchmal notwendigen bestimmenden Schrum Master. Er "zwingt das Team zu seinem Glück" und opfert dabei mitunter bewusst "kleinere" Elemente von Scrum dem Erreichen des Release/Quartalsziel/Projekterfolg. Fängt vielleicht ganz harmlos an, führt das Team aber langfristig in den Wasserfall zurück. Anders als dem Cargo Cult-Scrum Master ist ihm bewusst was er tut.

  5. Die Sekretärin
    6. Vielleicht der skurrilste Fall. Entsteht aufgrund eines völlig falsch verstandenen Stellenprofils. ("Scrum ... was? Was macht der?" ... "Ah, Termine einstellen. Was noch?" ... "Impediments? Was soll das sein?" ... "Ah, wenn zum Beispiel keine Rechner da sind. Ist also demnach eine Projektassistenz, dieser Scrum Master. Das macht am besten die Frau Jäger aus dem Vorzimmer vom Chef.").

Jeden dieser Typen habe ich schon einmal erlebt und so unterschiedlich sie auch sein mögen, eines haben sie alle gemeinsam: Wenn sie einmal da sind wird man sie nur schwer wieder los. Selbst wenn ein ganzes Team gegen einen fehlbesetzten Scrum Master rebelliert führt das nicht notwendigerweise zur Besserung sondern nur zu noch mehr Ärger, da das Aufbegehren gegen einen "Vorgesetzten" in fast keiner Organisation gerne gesehen wird. Der erbauliche Schluß fehlt daher leider, vielleicht trage ich ihn irgendwann mal nach.

Montag, 20. Juli 2015

Shuhari (und Harikiri)

Grafik: Wikimedia Commons/Jossi - CC0 1.0

Ich weiß nicht ob es an Hirotaka Takeuchi und Ikujiro Nonaka liegt, aber in Teilen der agilen Szene sind japanische Begriffe beliebt geworden. Kanban, Kaizen und Kata gehören dazu, aber auch ein anderer, den ich in letzter Zeit in vielen Diskussionen wiedergefunden habe: Shuhari (auch Shu-Ha-Ri, 守破離). Vereinfacht gesagt verbirgt sich dahinter ein aus dem Aikido stammendes Lernkonzept, das dem Vernehmen nach von Alistair Cockburn in die IT übernommen wurde und aus drei namensgebenden Stufen besteht:
  1. Shu (守): Das Erlernen der Regeln
    2. Auch beschrieben als die Phase des Lernenden. Hier werden die bereits bestehenden Regeln befolgt und verinnerlicht - und zwar nicht "weil der Chef das befohlen hat" oder "weil man das immer so macht" sondern um zu erfahren, zu verstehen und den Sinn darin zu erkennen.
  2. Ha (破): Der Bruch mit den Regeln
    3. Auch beschrieben als die Phase des Meisters. Im Bewußtsein der Folgen und Konsequenzen kann man versuchen die Regeln zu variieren und dadurch zu verbessern, so dass sie ihren Sinn noch besser erfüllen.
  3. Ri (離): Das Überwinden der Regeln
    4. Auch beschrieben als die Phase des Großmeisters. Wichtig ist nur noch der Sinn der hinter allem steht. Da er umfassend verstanden und durchdrungen wurde, sind Regeln nicht mehr notwendig, weil ohnehin nur noch so gehandelt wird wie er es erfordert.
Von Cockburn war Shuhari ursprünglich angedacht um das Erlernen von Programmiertechniken zu optimieren, mittlerweile empfehlen viele Coaches dieses Vorgehen aber auch beim Erlernen agiler Methodiken. Gerade im Fall von Scrum, das eine Vielzahl von Regeln aufweisen kann, deren Sinn sich nicht immer sofort erschließt, ist es sehr naheliegend. Im Normalfall folgt hier nämlich auf die Einführung eine Phase der Unsicherheit, in der Vieles nur halbherzig oder noch nicht richtig umgesetzt wird und der Nutzen deshalb noch nicht erkennbar ist. Das führt zum Hinterfragen der unverstandenen und als sinnlos empfundenen Prozesse und Artefakte, und oft zum Wunsch sie "an die Bedüfnisse anzupassen" oder gleich abzuschaffen.

Wird nach die Methoden-Einführung eine Shu-Phase gelegt, kann diese dazu beitragen das Team von derartigen gut gemeinten, in der Konsequenz aber verheerenden Fehlern abzuhalten. Die optimale Länge dieser Phase ist zwar nicht definiert, es dürfte aber unstrittig sein, dass sie mehrere Sprints andauern sollte1. Wenn auf der anderen Seite Teams kurz nach dem Einführungsworkshop alleine gelassen werden, neigen sie erfahrungsgemäß zu einem Verhalten, dass ich gerne als "Harikiri" bezeichne (zusammengesetzt aus den Phasen Ha und Ri und dem Harakiri). Gemeint ist damit ein versehentlicher "Selbstmord" der Scrum Methodik durch den Versuch, gleich zu Projektbeginn Verbesserungen vorzunehmen. Wenn dabei zentrale Elemente wie z.B. der Sprint, die Retrospektive oder die Rolle des Product Owners abgeschafft oder verschlimmbessert werden, dann können Blockaden, Ineffizienz oder permanente Konflikte die Folge sein.

Immerhin eines ist dabei aber positiv hervorzuheben - anders als der echte Harakiri hat der Harikiri nicht das dauerhafte Ableben zur Folge. Die gemachten Fehler lassen sich durchaus korrigieren, sei es durch eine (späte) Selbsterkenntnis des Teams oder durch externes Coaching. Da diese Kurskorrektur aber mit dem Eingeständnis verbunden ist Fehler gemacht zu haben, kann sie für manche Teams eine schmerzliche Prozedur sein, die man sich durch eine vorgelagerte Shu-Phase hätte ersparen können.


1Ich kenne Scrum Master die in dieser Zeit mehere aufeinanderfolgende einwöchige Sprints ansetzen, um die Frequenz und damit den Lerneffekt zu erhöhen. Ich sehe das eher kritisch, weil so kurze Abschnitte sehr hohe Meeting-Anteile haben, was erfahrungsgemäß zu Abwehrreaktionen der Teammitglieder führt.

Samstag, 18. Juli 2015

Ian Sense, Scrum Master

In gewisser Weise dürfte Ian Sense das Gegenstück zu Chet Rong sein. Und wer wäre besser für den Job eines Scrum Masters geeignet sein als ein Rugby-Spieler?

Dienstag, 14. Juli 2015

Die Entfremdung des Programmierers von seiner Arbeit

Bild: Flickr/Vinoth Chandar - CC BY 2.0

Der Gegenstand, den die Arbeit produziert, ihr Produkt, tritt ihn als ein fremdes Wesen, als eine von dem Produzenten unabhängige Macht gegenüber. [...] Ja, die Arbeit selbst wird zu einem Gegenstand, dessen er nur mit der größten Anstrengung und mit den unregelmäßigsten Unterbrechungen sich bemächtigen kann.
Manchmal höre ich von Abteilungsleitern und Managern, dass sie bei ihren Besuchen auf den Scrum-Projekten ihrer Firmen nicht mehr das Gefühl haben, dass dort noch mit Computern gearbeitet wird.1 Statt am Rechner zu sitzen stehen die Programmierer an Flipcharts, bewegen Zettel an riesigen, wandbedeckenden Boards, halten Pokerkarten hoch, werfen sich Bälle zu und beschriften Moderationskarten. Der Wunsch doch mehr die digitalen Projektmanagement-Werkzeuge zu benutzen, die eigene Arbeit über Ticket-Tools nachvollziehbar zu machen und es generell "etwas mehr nach IT aussehen zu lassen" wird häufig vehement abgelehnt, mit den Begründungen "nicht immer sitzen zu können", "die haptische Erfahrung zu brauchen", "Dinge physisch bewegen zu wollen" oder einfach "mal was anderes in der Hand haben zu wollen als die Tastatur".

Beides, das Bedürfnis nach körperlicher Bewegung und den Wusch nach der haptischen Erfahrung habe ich mittlerweile derartig häufig in verschiedenen Teams miterlebt und auf Scrum Master-Selbsthilfegruppen Agile Meetups erzählt bekommen, dass ich kaum umhin kann, darin ein verbreitetes, über Einzefälle deutlich hinausgehendes Phänomen zu sehen. Hier rächt sich vermutlich der geisteswissenschaftliche Hintergrund, denn irgendwie drängt sich mir eine bestimmte Deutung auf. Meine steile These: die Ursache dürfte jene sein, die der oben erwähnte Karl Marx vor langer Zeit als die Entfremdung, Entäusserung oder Entwirklichung der Arbeit beschrieben hat.2 Selbst wenn Marx es seinerzeit eher auf die Industriearbeiter bezogen hat kann man es gut auf die gegenwärtige IT-Branche anwenden: Datenbankmigrationen, Code-Refactorings, Content-Verteilungen und ähnliche Tätigkeiten finden auf einer derartig abstrakten Ebene statt, dass sie selbst demjenigen surreal erscheinen, der täglich mit ihnen zu tun hat. Weder sind die Ergebnisse dieser Tätigkeiten geeignet im eigenen Alltag eingesetzt zu werden noch sind sie fassbar oder vorzeigbar; der letztendliche Nutzer bleibt (wenn er denn überhaupt existiert) unsichtbar und unidentifizierbar. Noch einmal mit den Worten von Marx:

Die Entfremdung drückt sich so aus, [...] daß immer mehr die sinnliche Außenwelt aufhört, ein seiner Arbeit angehöriger Gegenstand, ein Lebensmittel seiner Arbeit zu sein; zweitens, daß sie immer mehr aufhört, Lebensmittel im unmittelbaren Sinn, Mittel für die physische Subsistenz des Arbeiters zu sein.
Etwas weniger verschwurbelt könnte das durchaus der Gefühlsausbruch einer zeitgenössischen Fachkraft sein, den er da von sich gibt. Ironie der Geschichte: erst in der postindustriellen Computerwelt bewahrheitet sich damit das, was Marx eigentlich als zwangsläufige Folge industrieller Fertigungsmethoden sehen wollte. Ausgerechnet der Programmierer, der vermutlich am wenigsten ausgebeutete und in seinem Tun freieste Arbeiter der jüngeren Wirtschaftsgeschichte, fühlt sich dem Produkt seines Schaffens in einer Form nicht verbunden, die der Kommunismus eigentlich dem Malocher an Fließband oder Hochofen unterstellt hat. Noch weiter gedacht: Wenn die Entfremdung des Menschen von seiner Arbeit Teil jener bedrückenden Erfahrung ist, die den Arbeiter gegen das Joch der Bourgeoisie aufbegehen lässt, was dann in der kommunistischen Herrschaftsübernahme mündet; und wenn andererseits die haptischen und spielerischen Elemente, die inhärenter Teil von Scrum sind, diese Entfremdung zu lindern vermögen - dann würde das in Konsequenz bedeuten, dass diese bescheidene Projektmanagement-Methodik durch Placebo-Effekte der Bewusstwerdung des Entwicklers als revolutionäres Subjekt entgegenwirkt. Demnach wäre Scrum (ein letztes Marx-Zitat) einsetzbar als eine weitere Variation von Opium für das Volk.

Ein berauschender Gedanke. Oder ein bekloppter. Oder beides.3

1Was natürlich auch daran liegen kann, dass sie vor allem zu Meetings erscheinen.
2Nicht dass ich Marxist wäre. Seine Theorien sind eher wirr, enthalten aber manchmal interessante Denkansätze.
3Und vielleicht war ich auch bei Verfassen dieser Zeilen selber berauscht. Man weiss es nicht.

Donnerstag, 9. Juli 2015

Squad Health Check

Grafik: Pixabay / Blink of an Eye - Lizenz
Diese Woche durfte ich zum ersten mal den berühmten Squad Health Check mitmachen, der bei Spotify entwickelt wurde. Ziel ist es, anhand verschiedener Indikatoren zu erkennen, wo im Team die Dinge gut, bzw. verbesserungswürdig laufen. Scrumtypisch findet das Ganze an einer Wand statt, wo auch im Anschluss das Ergebnis visualisiert wird. Im Detail nachlesen kann man das Modell bei Spotify selbst, hier nur das Wichtigste in Kürze:

Als erstes kann jedes Entwicklungsteam bestimmen wie gut es seiner Meinung nach um die einzelnen Indikatoren steht. Vorgeschlagen werden vier Kategorien (Gut, Mittel, Schlecht, Tendenz) und 10 Indikatoren (Easy to release, Suitable process, Code base health, Delivering value, Speed, Mission, Fun, Learning, Support, Pawns or players). Ermittelt wird der Stand entweder über eine Abstimmung mit dem Planning Poker Set oder dem Daumen, oder alternativ durch Ankreuzen auf dem Board:
Das so ermittelte Ergebnis kann im Folgenden konsolidiert werden und lässt sich auf einem weiteren Board projektübergreifend darstellen, indem man die Einschätzungen der Teams nebeneinander auflistet, z.B. in Form von Ampeln:
Wie immer bei derartigen Bestandsaufnahmen sollte die eigentliche Arbeit an dieser Stelle erst beginnen. Welche konkreten Maßnahmen aus dem Healthcheck abgeleitet und ergriffen werden hängt dabei ganz vom Ergebnis und verschiedenen äusseren Faktoren ab.


BTW: Spotify war so freundlich, dieses Modell und Vorlagen für die Karten unter einer CC-SA-Lizenz zur allgemeinen Verfügung zu stellen.

Dienstag, 7. Juli 2015

Ein Bild sagt mehr als 1000 Worte (IV)

Mittwoch, 1. Juli 2015

Lean und Agile im Laloux-Kulturmodell

Als studierter Geisteswissenschaftler mag ich sowas ja: die Einordnung agiler Praktiken in gesellschaftliche Funktionsmodelle, in diesem Fall das Kulturmodell von Fredric Laloux. Sehr schön auch die grafische Umsetzung.


Lean and Agile Adoption with the Laloux Culture Model from Agile For All on Vimeo.

Um darüber hinaus noch eine pseudointellektuelle Anmerkung zu machen: mir kommt es so vor, als habe sich Laloux von dem Charismabegriff von Max Weber inspirieren lassen. Müsste man ergründen. An einem weniger sonnigen Tag.