Samstag, 30. Januar 2016

Kommentierte Links (IX)

FS
  • Harvard Business Review: The New New Product Development Game

  • Bis heute kommt es immer wieder vor, dass ich auf meinen Projekten Manager treffe, die der Meinung sind, dass Scrum und ähnliche Methoden "neumodische Erscheinungen" wären, die sich "erstmal bewähren müssen". Ich weise diese Leute dann in der Regel auf diesen Artikel von Hirotaka Takeuchi und Ikujiro Nonaka hin, den die beiden vor ziemlich genau 30 Jahren im Harvard Business Review veröffentlicht haben (Ausgabe Januar 1986). In ihm wurde der Begriff Scrum zum ersten mal für die Beschreibung von Arbeitsprozessen benutzt und in ihm finden sich bereits die grundlegenden Ideen, auf denen agile Methoden heute beruhen: Built-in instability (heute würde man sagen Agilität), Self-organizing project teams, Overlapping development phases, “Multilearning”, Subtle control, Organizational transfer of learning. Eine erstaunlich lange Geschichte für eine neumodische Erscheinung.

  • DZone: 38 Scrum Master Interview Questions To Avoid Imposters

  • Ich habe es selber schon mehrfach schmerzlich erleben müssen - gute Scrum Master zu finden ist schwer, und immer wieder werden Stellen an völlig ungeeignete Personen vergeben (nicht zuletzt aufgrund von vom Thema überforderten Recruitern und Personalern). Dieser Interview-Leitfaden hier hätte einigen Projekten die ich kenne einen Großteil ihrer Probleme von vornherein erspart, da er die falschen Kandidaten sicher ausgesiebt hätte. Natürlich gibt es aber auch einen Haken: Stefan Wolpers, der Verfasser der 38 Fragen, liefert nämlich die Antworten nicht mit. Ohne Kenntnis und Verständnis der Methode kann der Interviewer also nur bedingt etwas mit ihnen anfangen. Nochmal umgekehrt betrachtet ist das aber wieder gut, den wer keine Ahnung von Scrum hat sollte auch keine Einstellungsinterviews mit Scrum Mastern führen.

  • Dave Smith: A developer’s guide to interviewing

  • Das Ganze von der anderen Seite betrachtet. In einem Job-Interview sollten nicht nur die Vertreter der einstellenden Firma Fragen stellen, sondern auch derjenige der sich für den Job interessiert - und die Fragen von Dave Smith würden einige Firmen die ich kenne nicht gut dastehen lassen. Was mir besonders gefällt: er fragt nicht nach der eingesetzten Methode (behaupten, dass man Scrum macht kann jeder) sondern versucht aus Informationen über Arbeitsabläufe und Standards Rückschlüsse zu ziehen. Woher wissen die Angestellten woran sie arbeiten müssen? Wie halten sie es mit Unit Tests? Gibt es Continuous Integration? Wie ist der Bugfixing-Prozess? Und so weiter. Ein paar dieser Fragen nehme ich sicher in mein nächstes Interview mit.

  • Joshua Partogi: Scrum does not work here in Asia

  • Geschichten wie die von Joshua Partogi habe ich bereits von einigen Scrum Mastern und Coaches gehört, die in Süd- oder Ostasien unterwegs waren. Scrum wird als reine Softwareentwicklungs-Methodik gesehen, die notwendigen Änderungen im restlichen Unternehmen werden dagegen ignoriert oder verleugnet. Dazu kommen Hierarchie-Gläubigkeit, die Unfähigkeit Konflikte sachlich (oder überhaupt) auszutragen, zwanghafter Konformismus und die Verwechselung von billiger Personalbeschaffung mit billiger Softwareentwicklung. Das Ergebnis ist Cargo Cult, also etwas das irgendwie nach Scrum aussieht aber nichtmal in Ansätzen so funktioniert. Der aus meiner Sicht bemerkenswerteste Aspekt ist Partogi aber gar nicht bewusst: In vielen deutschen (und generell westlichen) Großunternehmen findet man praktisch alles was er sagt genauso wieder, weshalb die Scrum-Einführungen auch dort regelmässig kläglich scheitern. Manche Verhaltensmuster sind eben universeller als man denkt.

  • Grant Amons: Ditching Scrum for Kanban — The best decision we’ve made as a team

  • Die Überschrift sagt eigentlich bereits alles: ein Team wechselt von Scrum zu Kanban und wird glücklich. Obwohl die Scrum-Einführung vieles verbessert hatte brachte sie nämlich auch Unzufriedenheit mit sich, da regelmässig Sprint-Ziele verfehlt wurden und Aufwandsschätzungen sich als falsch herausstellten. Nach dem Wechsel gab es diese Probleme nicht mehr und alle lebten happily ever after. Spontan würden mir dazu zwei Gedanken in den Sinn kommen: Erstens - hat dieses unzufriedene Team wirklich vorher Scrum gemacht, oder war bereits die Umsetzung falsch? (Besser ausformuliert findet sich diese Frage bei Hannah Kane). Und zweitens - ist das was dort jetzt gemacht wird wirklich Kanban? Beschrieben wird es als Scrum ohne feste Sprints und ohne Retrospektive - müsste es da nicht mehr geben, etwa ein Work in Progress-Limit, einen Eliminate Waste-Grundsatz oder einen Kaizen-Prozess? Unabhängig davon kann es aber durchaus sein, dass Kanban für manche Teams besser funktioniert als Scrum, allerdings nennt Amons auch eine sehr wichtige Voraussetzung für den Wechsel: bevor man sich entscheidet Scrum wieder abzuschaffen sollte man es zuerst verstanden haben, sonst weiss man nicht was man tut (siehe dazu auch: Shuhari und Harikiri).

Dienstag, 26. Januar 2016

Jira/Confluence als Grund für Monokultur in Retrospektiven

FS
Ironie der Geschichte: Nachdem Michael Küsters erst letzten Monat geschrieben hat, dass Retrospektiven nicht "fancy" sein müssen, war ich gestern Teil einer von ihm moderierten Retro, die einige spielerische Elemente beinhaltete, die ich so noch nicht kannte. Eine meiner Erkenntnisse: ein großer Maler/Zeichner werde ich nicht mehr. Aber unabhängig vom konkreten Einzelfall - ich bewege mich in letzter Zeit wieder zu der Ansicht hin, dass Retrospektiven zumindest ab und zu neue Elemente haben sollten um nicht zu sehr in Routinen abzurutschen. Selbst wenn eine neue Form nicht zwingend neue Erkenntnisse bringt, zumindest ist es weniger wahrscheinlich, dass eine irgendwann in Ablehnung umschlagende Langeweile entsteht.

Im Rahmen dieser Überlegung habe ich später auch mit einigen Kollegen diskutiert wie es wohl zu der häufig anzutreffenden "Monokultur" kommen kann. Einen Grund dafür hatte ich bis vor kurzem gar nicht auf dem Schirm - es ist dieser hier:


Bei etwas Überlegung ist es klar: wenn das beliebteste agile Projektmanagement-Tool (Jira/Confluence) nur ein einziges Retro-Template enthält, das dann auch noch automatisch aufpoppt sobald der Sprint geschlossen wird und das sich auch nicht mit vertretbarem Aufwand modifizieren lässt, dann ist die Versuchung sehr groß es auch genau so zu verwenden. Vor allem bei Teams die nur digital und nicht mit physischen Boards arbeiten ist die Wahrscheinlichkeit eines "machen wir immer so" sehr hoch.

Aktuell benutze ich Jira und Confluence zwar auch, das Retrospektiven-Template setze ich aber bewusst nicht ein. Während der Veranstaltung selbst benutze ich eine beschreibbare Wand, die Dokumentation erfolgt dann über hochgeladene Fotos. Das ist zwar keine Garantie für Abwechselung, aber zumindest ein vereinheitlichender Faktor fällt damit weg.

Mittwoch, 20. Januar 2016

Ein Bild sagt mehr als 1000 Worte (X)

FS
Zum 10. Jubiläum von "Ein Bild sagt mehr als 1000 Worte" gibt es sogar Bewegtbild. Mit einem Insider-Witz für Software-Entwickler.


via GIPHY

Montag, 18. Januar 2016

Ist das noch Scrum oder kann das weg?

FS
Bild: Flickr/Enrique Fernandez - CC BY 2.0
Ein immer wiederkehrendes Phänomen in Scrum ist es, dass Teams sich darüber beschweren, dass die Methode ihnen zu restriktiv und zu einengend ist. Der Zwang die User Stories immer gleich zu formulieren (Als [Rolle] möchte ich [Aktion] um [Mehrwert]), die Vorschrift, dass man nicht mehrere von ihnen gleichzeitig bearbeiten darf (Sequenzielle Abarbeitung), das Verbot digitale statt physischer Boards zu benutzen (haptische Erfahrung), die Begrenzung von Sprints auf zwei Wochen (kurze Auslieferungszeit) und viele weitere Vorgaben werden als nicht immer zielführend emfunden. Mitunter wird aufgrund solcher Regeln sogar in Frage gestellt, ob Scrum wirklich eine agile Methode ist, da sie eine Anpassung an aktuelle Aufgaben und Probleme erschweren und verhindern können. Diese Einwände sind zwar in gewisser Weise richtig, dennoch steckt ein Denkfehler in ihnen: keine der genannten Regeln ist wirklich ein Teil von Scrum, genauso wenig wie viele andere von denen das häufig behauptet wird.

Das tatsächliche Scrum-Regelwerk ist eher schlank. Der offizielle Scrum Guide ist je nach Formatierung lediglich zwischen 15 und 20 Seiten lang, regelt nur die wichtigsten Bereiche (drei Rollen, fünf Events, drei Artefakte und wenige grundlegende Definitionen) und lässt sonst sehr viel Freiraum. Selbst scheinbar selbstverständliche Bestandteile der Methode erwähnt er nicht einmal - z.B. findet man in ihm weder die Taskboards noch die Backlog Refinements oder das Minimum Viable Product (MVP). Das alles (genau wie die weiter oben genannten Punkte) sind optionale Erweiterungen, die sich irgendwann mal eingebürgert haben ohne verpflichtend zu sein. Wenn man es wollte könnte man sie alle weglassen ohne damit gegen die Regeln zu verstoßen, das Ergebnis würde sich immer noch mit vollem Recht Scrum nennen können. Allerdings: Nur weil man es könnte heißt es nicht, dass man es auch sollte.

Praktisch alle gängigen Erweiterungen sind nicht durch Willkür entstanden sondern das Ergebnis jahrzehntelanger Best Practices. Egal ob sie aus anderen Methoden wie Kanban, Extreme Programming und Lean Startup übernommen oder extra für Scrum entwickelt wurden, hinter ihnen steckt immer die Motivation, die Ideen von Scrum und Agile möglichst optimal in die operative Arbeit umzusetzen. An dieser Stelle setze ich nach Möglichkeit auch immer an wenn sich eines meiner Teams gegen die scheinbar restriktiven und dogmatischen Regeln auflehnt: ich biete an, in einer Diskussionsrunde darüber zu sprechen wo diese Best Practices herkommen, warum man sie übernommen hat, was sie bewirken und welche Risiken man eingeht wenn man sie fallen lässt.

In fast allen Fällen haben sich die Teams danach entschieden, ihre Vorgehensweisen doch nicht zu ändern oder sie nur minimal zu modifizieren. Ihr Problem waren in diesen Fällen nicht die Regeln selbst, sondern deren fehlende Begründung und Erklärung. Sobald diese nachgereicht wurden stieg die Akzeptanz deutlich an. Und in den wenigen Fällen in denen doch Änderungen vorgenommen wurden gab es einen wirklich guten Grund dafür.

Donnerstag, 14. Januar 2016

Charisma als Scrum Master-Eigenschaft

FS
Bild: Wikimedia Commons/Alberto Corda - Public Domain
Ein Ergebnis vieler Diskussionen der letzten Zeit: ein Scrum Master sollte eine charismatische Person sein. Dort wo Scrum richtig implementiert ist, ist er nicht der disziplinarische Vorgesetzte des Teams, dieses sollte ihm aber trotzdem (bis zu einem gewissen Grad) freiwillig folgen. Eine Grundlage dieser Gefolgschaft - zumindest so wie wir es verstanden haben - ist das Charisma, das er in die Waagschale werfen kann um seine Teammitglieder zu begeistern und vom richtigen Vorgehen (adaptiv, iterativ, etc.) zu überzeugen. Wenn er es hat kann er seinen Job machen, denn dann werden seine Ratschläge auch angehört, angenommen und umgesetzt werden wenn man nicht völlig sicher ist was ihre Umsetzung bewirken wird. Wenn nicht wird er es schwer haben, denn Vieles im agilen Vorgehen (z. B. keine Detailplanung, keine Zeit-/Aufwandsschätzung, keine Kontrolle) erscheint zunächst widersinnig wenn man anderes gewohnt ist. Und ein zweifelndes, von seiner Ansprache nicht überzeugtes Team wird sich meistens nicht trauen neue Wege zu gehen. So weit, so einfach. Es bleibt allerdings die Frage: Charisma - was soll das sein? Als alter Geisteswissenschaftler würde ich zur Bestimmung auf denjenigen zurückgehen, der den Begriff in seiner heutigen Form festgelegt hat, auf Max Weber. Er definierte es folgendermassen:
Charisma soll eine als außeralltäglich [...] geltende Qualität einer Persönlichkeit heißen, um derentwillen sie [...] als Führer gewertet wird. Wie die betreffende Qualität von irgendeinem ethischen, ästhetischen oder sonstigen Standpunkt aus "objektiv" richtig zu bewerten sein würde, ist natürlich dabei begrifflich völlig gleichgültig: darauf allein, wie sie tatsächlich von den charismatisch Beherrschten, den Anhängern, bewertet wird, kommt es an.
Mit anderen Worten: es kommt nicht darauf an wie überzeugend und bewundernswert exzellent in seinem Tun ein Scrum Master ist (selbst wenn das häufig fälschlicherweise für Charisma gehalten wird). Er ist nur dann charismatisch, wenn sein Team ihn dafür hält. Das passiert übrigens schneller als man denken sollte - in der Soziologie geht man davon aus, dass in der westlich/europäischen Welt Charisma nicht nur bestimmten Personen, sondern auch bestimmten Ämtern zugeschrieben wird. Das gilt z.B. für religiöse Führer, aber auch und gerade für die Wirtschaft. Noch einmal Max Weber:
Beziehung zur Wirtschaft: Die Veralltäglichung des Charisma ist in sehr wesentlicher Hinsicht identisch mit Anpassung an die Bedingungen der Wirtschaft als der kontinuierlich wirkenden Alltagsmacht. [...] In weitestgehendem Maße dient hierbei die erb- oder amtscharismatische Umbildung als Mittel der Legitimierung bestehender oder erworbener Verfügungsgewalten.
Stark vereinfacht gesagt und auf das konkrete Beispiel bezogen: die Teammitglieder nehmen zunächst ganz selbstverständlich an, dass der Scrum Master überzeugend und exzellent ist - warum sonst sollte man ihm diesen Job gegeben haben? Aber - was passiert, wenn sie mit dieser Annahme falsch liegen, wenn der Scrum Master diese Erwartungen nicht erfüllt? Auch darauf gibt die Theorie eine Antwort. Ein letztes mal Weber:
Über die Geltung des Charisma entscheidet die durch Bewährung [...] gesicherte freie [...] Anerkennung durch die Beherrschten. Bleibt die Bewährung dauernd aus, [...] vor allem: bringt seine Führung kein Wohlergehen für die Beherrschten, so hat seine charismatische Autorität die Chance, zu schwinden.
Anders formuliert: der Scrum Master hat zwar zunächst einen Vertrauensvorschuss, er wird aber permanent an den ihm entgegengebrachten Vorschusslorbeeren gemessen. Zeigt sich jetzt, dass er auch nicht überzeugender und besser ist als alle anderen, dann war es das mit der freiwilligen Gefolgschaft.

Um zur Aussage und Frage vom Beginn zurückzukommen: ein Scrum Master wird nur dann als charismatisch wahrgenommen (und nur dann folgt man ihm) wenn er die Erwartungen die die Teammitglieder in ihn setzen durchgehend erfüllt. Eine Herausforderung. Um das zu können und nicht daran zu scheitern sollte er in der Lage sein Expactation Management zu betreiben. Erst indem er seinem Team vermittelt wo es hohe Erwartungen haben kann und wo nicht macht er diese erfüllbar. Zu seinem Glück ist er dafür sogar zuständig und (wenn er denn fähig ist) auch in der Lage, denn das Vermitteln von Methodenkenntnis und Rollenverständnis ist zentraler Teil seines Jobs. Letztendlich ein Zirkelschluss - durch sein (Amts)charisma kann er die Erwartungshaltung beeinflussen und diese danach auch erfüllen, woraus wieder neues Charisma entsteht. Anders als man denken könnte ist charismatisches Auftreten also keine Göttergabe sondern ein anspruchsvolles Handwerk, das man beherrschen muss wenn man in der Lage sein will das Team indirekt zu leiten.

Dienstag, 12. Januar 2016

Telefonkonferenzen

FS
Einer von vielen Gründen gegen geografisch verteilte Teams.

Donnerstag, 7. Januar 2016

Zeitdruck und Innehalten (und Lego)

FS
Bild: Wikimedia Commons/Powerhauer - CC BY-SA 3.0
Zum Scrum Master-Job gehören unter Umständen Scrum-Workshops, in denen die Methode mit Hilfe von Legosteinen erklärt wird: Anstelle von Software werden damit Gebäude erstellt, das "Projekt" ist auf ein bis zwei Stunden begrenzt und die einzelnen Zyklen und Meetings sind entsprechend verkürzt, sonst wird versucht so nah wie möglich am Original-Vorgehen zu bleiben (eine genauere Erläuterung gibt es hier). Das Ziel ist eine eher spielerische Vermittlung, die auch für Menschen zugänglich ist die keine vertieften IT-Kenntnisse haben. Vor diesem Hintergrund kann dieses Vorgehen sehr sinnvoll sein, allerdings würde ich bei seinem Einsatz raten mit Vorsicht vorzugehen.

Beim Lego-Scrum (und auch bei anderen Simulationsmethoden wie z.B. dem Scrum-Kochen) sollte man meiner Meinung nach zwei Risiken bedenken: Zum Einen das Problem der fehlenden "Ernsthaftigkeit" (darüber hatte ich bereits etwas geschrieben), zum Anderen sollte man sich bewusst sein, dass Scrum auf diese Weise unter einem hohen Zeitdruck stattfindet. Bei einer 90-minütigen Simulation mit drei Sprints zu je einer halben Stunde bleiben für Refinement, Planning, Daily Standup, Review und Retrospektive jeweils nur wenige Minuten. Gerade bei unerfahrenen Teams kann das dazu führen, dass so viel wie möglich davon weggelassen wird um mehr Zeit für die "richtige Arbeit" zu haben. Wird das nicht diskutiert oder korrigiert gehen die Teilnehmer möglicherweise mit dem "Erkenntnisgewinn" nach Hause, dass diese Meetings etwas sind was man streichen oder stark verkürzen sollte wenn man schneller vorankommen will. Wenn sich das einmal in den Köpfen festgesetzt hat ist es mitunter nur schwer wieder dort herauszubekommen. Und das ist nicht der einzige "Kollateralschaden" der auftreten kann.

Zu den Kernelementen von Scrum gehört nach meinem Verständnis, dass in regelmässigen Abständen der Zeitdruck von den Teams weggenommen wird. Egal wie dringend und wichtig neue Features gerade sind (und sie sind fast immer dringend und wichtig) - in festen Zyklen muss innegehalten und Abstand genommen werden. Nur wenn man aus dem Hamsterrad heraussteigt und zurücktritt kann man sich die richtigen und zielführenden Fragen stellen:
  • Ist das was wir vorhaben überhaupt technisch umsetzbar? (Refinement)
  • Ist das was wir vorhaben in der gegebenen Zeit überhaupt zu bewältigen? (Planning)
  • Sind wir noch im Zeitplan, und wenn nicht - wie gehen wir damit um? (Daily Standup)
  • Ist das was wir produziert haben wirklich das was die Benutzer wollen? (Review)
  • Ist das methodische Vorgehen das wir gewählt haben tatsächlich das richtige? (Retrospektive)
Was passiert aber wenn man sich die Zeit für dieses Innehalten nicht nimmt sondern schnellstmöglich durch die Meetings hetzt um schnell wieder an die Arbeit zu kommen? In den meisten Fällen wird man Murks als Ergebnis haben. Probleme werden nicht durchdrungen, Gedanken nicht zu Ende gedacht, Beschlüsse vorschnell gefasst und Diskussionen abgewürgt. Am Ende stehen Ergebnisse die nicht wirklich brauchbar sind.

Zurück zur Lego-Simulation. In ihrem Fall besteht ein hohes Risiko, dass die enge Zeitbegrenzung die Meetings so staucht, dass sie in der gerade erwähnten Form dysfunktional sind. Wenn dadurch aber der "Erkenntnisgewinn" geprägt ist, den die Teilnehmer mitnehmen, dann ist das sogar wesentlich schwerwiegender als im oben genannten ersten Fall. Dann entsteht nämlich der Eindruck, dass die Scrum-Regelmeetings im Zweifel nicht nur verzichtbar sondern sogar eher schädlich sind, weil ja "offensichtlich" nur halbgare und kaum brauchbare Ergebnisse in ihnen entstehen. Und wenn sich dieser Eindruck erstmal verfestigt hat, dann wird es wirklich schwer ihn zu korrigieren.

Das alles heisst nicht, dass man Lego-Scrum und ähnliche Methoden gar nicht einsetzen sollte. Es heisst aber, dass in ihnen explizit darauf geachtet werden sollte, dass die beschriebenen Fehlentwicklungen nicht eintreten. Möglich ist etwa eine Mindestdauer für Meetings, so dass es für die Teams nicht mehr möglich ist Arbeitszeit zu gewinnen indem man die Meetingzeit zusammenstreicht. Auch die Frage ob ein bis zwei Stunden wirklich für eine Simulation ausreichen kann man diskutieren (ich z.B. glaube das nicht). Und zuletzt sollten die Veranstalter in eigenen Retrospektiven regelmässig auch ihr eigenes Vorgehen überprüfen, ganz so wie sie es vermutlich selbst irgendwann mal in einer Scrum-Simulation gelernt haben.

Montag, 4. Januar 2016

Website under Construction

FS
Der Vorsatz für das neue Jahr war: Weg mit dem alten Standard-Template, her mit etwas Zeitgemäßerem. Es kann sein, dass es deswegen noch hier und da etwas schräg aussieht und dass einzelne Inhalte nicht erreichbar sind, das gibt sich in den nächsten Tagen. Grundsätzlich wandert alles was vorher am rechten Rand angezeigt wurde in die horizontalen Navigationsbereiche oben oder ganz unten.


Bild: Wikimedia Commons/John Curtis, CC0 1.0
Powered by Blogger.