Hinderniswörter

Picture of a rock on a road

Sam Laing und Karen Greaves von Growing Agile haben vor kurzem ein paar praktische Tipps zu Impediments, also Hindernissen, auf Youtube zusammengestellt: Wie erkennt man sie? Wie kann das Team sie zusammen anpacken?

Schöner Tipp daraus: macht Euch eine Liste von Hinderniswörtern und fragt genauer nach, wenn Ihr sie öfters oder von mehreren hört. Nicht nur der Scrum Master ist dabei gefordert Рjeder hat seinen blinden Fleck, oder besser: sein taubes Ohr.

Hier Sams und Karens Liste, mit den deutschen Entsprechungen:

ENDE
guessIch glaube / Wir glauben, ...
waitingIch warte / Wir warten ...
wishIch w√ľnschte, ...
hopefullyHoffentlich...
tryIch versuche / Wir versuchen, ...
not available... nicht verf√ľgbar / erreichbar.
busy... beschäftigt / ausgelastet damit, ...
still... (immer) noch ...
expectedIch hatte erwartet / Wir hatten erwartet, ...
thoughtIch dachte / Wir dachten, ...

Denkt man √ľber die W√∂rter nach, dann erkennt man Alarmsignale f√ľr viele klassische, blockierende Fehlentwicklungen:

  • Multitasking;
  • vers√§umte Kommunikation;
  • fehlende Hilfsmittel;
  • PAL-Felder;
  • Selbstgef√§lligkeit.

Mir fallen noch weitere Hinderniswörter ein:

ENDE
not reallyeigentlich nicht / kein
who?wer?
should havehätte ... sollen
had promisedhatte versprochen, ...
stabilize... stabilisieren
officiallyoffiziell
pro formapro forma
finally / at lastendlich
temporaryvor√ľbergehend
workaroundZwischenlösung

Das reicht schon fast f√ľr ein veritables Impediment Bingo.
Welche Hinderniswörter kennt Ihr noch?

Der Scrum Guide 2013 – was gibt es Neues?

Der neue Scrum Guide 2013 ist seit einer Woche herunterladbar, momentan noch ausschließlich auf Englisch. Es lohnt sich, genauer hinzusehen, was Ken Schwaber und Jeff Sutherland geändert haben.

(Alle Hervorhebungen in Zitaten von mir).

Praxisnäher oder schon ScrumBut?

Viele kleine, unscheinbare Einf√ľgungen (best, usually, …) und √Ąnderungen im Text sorgen f√ľr neue Ausnahmen und Relativierungen. Was fr√ľher noch zumindest als fragw√ľrdig galt, taucht nun als dezentes Zugest√§ndnis auf:

  • Die Sprintl√§nge darf jetzt offiziell variieren, sollte es aber am besten nicht („Sprints best have consistent durations throughout a development effort.“).
  • Das Sprintziel darf jetzt im Sprint nicht mehr gef√§hrdet werden, bisher war bereits die Beeintr√§chtigung verboten („endangered“ ersetzt das alte „affected“). √úber die Grenze dazwischen darf spekuliert und viel diskutiert werden. Bei der Arbeit.
  • Die Zusammensetzung des Entwicklungsteams muss √ľber einen Sprint nicht mehr konstant bleiben. Niemand muss sich also mehr verstecken mit Modellen wie einer Teilzeit-Mitgliedschaft (z.B.: Frank ist nur jeden Mittwoch da) oder auch der Austauschbarkeit von Human Resources (z.B.: es muss immer „ein Entwickler“ im Team sein, egal ob das Michael oder Frank ist).
  • Bisher galt: wurde die Sprintl√§nge gek√ľrzt, mussten auch die Ereignisse Sprintplanung,¬†Sprint-Review und Sprintretrospektive proportional gek√ľrzt werden. Jetzt werden sie in diesem Fall nur als „usually shorter“ bezeichnet. 2015 dann vermutlich als „sometimes shorter“.
  • Tasks haben nicht mehr einen Tag als strikte Obergrenze f√ľr ihre Bearbeitungsdauer. Hier halten Ken und Jeff gar nicht erst bei „usually“ inne, sondern zerlegen die Eintr√§ge des Product Backlogs often to units of one day or less“.

H√∂flich zusammengefasst: es wird ab sofort gebilligt, die Arbeit gem√§√ü Scrum dem Arbeiten in vor-agiler Zeit deutlich anzugleichen. Man k√∂nnte es auch weniger h√∂flich eine Lizenz zum Bullshit nennen: Ken und Jeff haben hier in der Diskussion zu ScrumButs deutlich Stellung bezogen – f√ľr meine Begriffe im sumpfigen Gel√§nde.

Sprintplanung ab sofort ganz neu? Nein.

Die Sprintplanung hat keine zwei gleich langen Teile mehr. Statt dessen werden die beiden Teile zu Themen umdeklariert, ihre √úberschriften bleiben aber gleich:

  1. What can be done this Sprint? und
  2. How will the chosen work get done?

Praktisch bedeutet das nur, dass beide Themen unterschiedlich lange diskutiert werden k√∂nnen. Thema 1 muss trotzdem vor Thema 2 abgehandelt werden. Implizit scheint es jetzt auch eine Anwesenheitspflicht f√ľr den Product Owner bei Thema 2 zu geben, zumindest wurde die Formel „The Product Owner may be present“ ersatzlos gestrichen.

Heisse Kartoffel Sprintziel: essen will sie jeder

Wozu ein Sprintziel? Als Sinn wird „Koh√§renz“ in Bezug auf irgend etwas genannt,¬† was das Entwicklungsteam zur Zusammenarbeit bringt, statt zur isolierten Arbeit von Einzelnen. Leider spielt laut Scrum Guide keine Rolle, ob das Sprintziel fachlich, technisch oder mit Blick auf das Firmensommerfest koh√§rent ist:¬† „The Sprint Goal can be any other coherence“, Hauptsache Teamwork.

Die Fragen während des Daily Scrum werden ab sofort als Erinnerung an das Sprintziel und den teamorientierten persönlichen Beitrag dazu ausgerichtet. Beispielsweise heißt es nicht mehr

  • „What has been accomplished since the last meeting?“ (2011), sondern
  • „What did I do yesterday that helped the Development Team meet the Sprint Goal?“ (2013).

Das finde ich gut, wenn auch etwas angestrengt erzieherisch. Die Verantwortung f√ľr das Formulieren des Sprintziels wird allerdings wie eine hei√üe Kartoffel so schnell im Kreis herumgereicht, dass einem schwindlig wird:

  • „The Product Owner discusses the objective that the Sprint should achieve…“
    Sagte man fr√ľher einfach „mitteilen“, „verk√ľnden“ oder „anordnen“, so nutzt man heute „discuss“ (oder das uns√§gliche „communicate“) – als h√§tten die Zuh√∂rer etwas mitzureden.
  • After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.“
    „Ein“¬† Sprintziel wird nachtr√§glich, passend zur Vorhersage des Entwicklerteams ausgearbeitet? Sicher?
  • Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how…“
    Moment: die Entwickler haben das festgesetzt? Wirklich? Oder ist das einfach nur schlampig formuliert?

Zusammengefasst: der Product Owner teilt allen die objective des Sprints mit, das Scrum Team arbeitet ein Sprint Goal aus, und gesetzt hat es am Ende angeblich das Development Team.

So sehr mir insgesamt die neue starke Betonung des Sprintziels gef√§llt: ich f√ľrchte, als Guide wird hier eher der agile gesunde Menschenverstand n√ľtzlich sein als ein Papier mit solch halbgaren Formulierungen. Eine verpasste Chance!

Raider heißt jetzt Twix

…sonst √§ndert sich nix:

  • Eintr√§ge im Product Backlog, die fertig zur √úbernahme in einen Sprint sind, wurden die letzten beiden Jahre „ready“ oder „actionable“ genannt. Ab sofort hei√üt das „Ready“. Mit gro√üem R. Eine kleiner Schritt f√ľr die Orthographie, ein gro√üer Sprung vorw√§rts f√ľr die Scrum-Community.
  • Die Definition of „Done“ ist noch nicht done und pendelt absatzweise hektisch zwischen „Done“ und „done“.
  • Die laufende Pflege und √úberarbeitung des Product Backlogs wurde die letzten beiden Jahre in der Community meist „grooming“ genannt. Ab sofort hei√üt das „refinement“.

Feiges Geschwurbel

Manches Buzzword soll offensichtlich unangenehmen Klartext √ľberdecken. Sch√∂nstes Beispiel: „Artifact transparency“

Ein als besondere Neuerung angepriesener Abschnitt: Transparenz bei Artefakten sei gut. Und selbstredend ist der Scrum Master verpflichtet, jedem auch bei der Herstellung von noch mehr Transparenz zu helfen. Mehr konnte ich dem Text zunächst nicht entnehmen. Ich habe es redlich und wiederholt versucht.

Einige Gl√§ser (Frapp√©) sp√§ter fiel mir dann ein, dass Scrum-Werte wie Offenheit und Mut nicht mehr Teil des Scrum Guides sind (s.u.). Mir d√§mmerte bei der Lekt√ľre, dass mit „Transparenz“ hier letztlich Wahrheit gemeint ist. Das industrielle Scrum von 2013 hat anscheinend die Kraft verloren, diesen Begriff „Wahrheit“ offen und mutig zu benutzen, um nach mehr davon zu verlangen. Was f√ľr eine Ironie.

Rollen: Harder, better, faster, stronger

Es gibt angeblich mehr zu tun, in einigen Rollen:

Der PO…

…konnte sich bisher damit begn√ľgen, die Wertsch√∂pfung des Entwicklerteams sicherzustellen. Aber das altbackene und prozessverd√§chtige „ensuring“ musste jetzt dem wesentlich dynamischeren „optimizing“ weichen. Wer braucht da noch Kanban!

F√ľr den Scrum Master…

…reicht „Understanding long-term product planning in an empirical environment“ ab sofort nicht mehr, das W√∂rtchen „long-term“ wurde einfach gestrichen. Eine heimt√ľckische √Ąnderung, finde ich, denn sie ersetzt schlagartig das, was nie existierte, durch das, was jemand anderes als der Scrum Master l√§ngst h√§tte tun m√ľssen.

Auch wichtig: die neue Aufgabe „Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value“. Ich freue mich auf viele heitere Szenen, wenn der in anderthalb Tagen zum CSM geschulte Scrum Master vorschriftsm√§√üig sicherstellt, dass der ebenfalls in anderthalb Tagen zum CSPO geschulte Product Owner seine Kernaufgabe auch wirklich beherrscht.

Und eine besonders sportliche neue Idee zur Hirnakrobatik in der Sprintretrospektive: „The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.“ Je √∂fter und l√§nger ich √ľber diese Formel und ihre praktischen Konsequenzen f√ľr den Scrum Master nachdenke, desto [Schimpfw√∂rter gel√∂scht, bitte bleiben Sie sachlich! – die Red.].

Weg damit!

Ist Produktentwicklung zu komplex f√ľr Scrum?

Zwei Jahre lang galt: „Scrum is a framework structured to support complex product development.“ Diese Struktur m√∂chten Ken und Jeff jetzt offenbar lieber durch (ihr?) zus√§tzliches Consulting schaffen und streichen den Passus ersatzlos. Erhalten geblieben ist an anderer Stelle nur das nebul√∂se „Scrum is a process framework that has been used to manage complex product development.“

Vision? Endlich Geschichte.

Aufatmen beim Scrum Master: „Clearly communicating vision“ steht nicht mehr auf seiner To-Do-Liste. Diese Unterst√ľtzungsleistung f√ľr den PO entf√§llt ersatzlos, vielleicht, weil eine Vision, die klar vermittelt werden soll, ja zuerst einmal existieren m√ľsste. Das ist im industrialisierten Scrum immer unwahrscheinlicher geworden, also weg damit – das Wort „vision“ taucht jetzt im Scrum Guide nirgendwo mehr auf.

Was nur konsequent ist und dem Schicksal der „values“ folgt. Die Scrum-Werte (Respekt, Mut, Offenheit, Fokus und Commitment – wie es in den Sagen und Mythen vergangener Zeiten lautet, falls ich mich recht entsinne) wurden ja bereits getilgt: hie√ü es im Scrum Guide 2009 noch, der Scrum Master habe daf√ľr zu sorgen, dass sich das Team an „Scrum values, practices, and rules“ halte, lautet die Formel seit 2011 „Scrum theory, practices, and rules“.

Da scheint mir bizarr, wie Ken Schwaber k√ľrzlich kritisierte, andere h√§tten wohl das agile Prinzip „Individuals and Interactions over Processes and Tools“ aus den Augen verloren. Er empfiehlt: „Keep the values, keep the principles, think for yourself.“ Eat your own dog food, Ken.

Du musst es nicht tun, sondern nur verstehen!

Und nochmals Aufatmen beim Scrum Master: das naive „Teaching the Development Team to create clear and concise Product Backlog items“ (2011) geh√∂rt nicht mehr zu seinen Aufgaben, es weicht endlich einem professionellen „Helping the Scrum Team understand the need for clear and concise Product Backlog items“ (2013).

Ich finde, das spart Arbeit. Denn man darf getrost voraussetzen, dass dieser Bedarf jedem l√§ngst schmerzlich bewusst ist. Somit f√§llt f√ľr den Scrum Master auch hier keine wirkliche Mehrarbeit an. Trotzdem – es w√§re sicher mehr drin gewesen. F√ľr die kommende Version des Scrum Guides schlage ich etwas vor wie: Nurturing the Scrum Team’s appreciation of the need for transparent Product Backlog items.

In der Gosse gelandet: vom festen Event zur formellen Gelegenheit

Welcher Satz stammt aus dem Scrum Guide 2011 und welcher aus dem Scrum Guide 2013?

„Although improvements may be implemented at any time, the Sprint Retrospective provides…

  • „… a dedicated event focused on inspection and adaptation.“
  • „… a formal opportunity to focus on inspection and adaptation.“

Muss ich aufl√∂sen? Allenfalls f√ľr Menschen, die Geburtstagspartys als formelle Gelegenheiten betrachten, um sich ihren Freunden zu widmen. Oder auch nicht.

Easter eggs – Lachen mit Scrum

Ken und Jeff haben durchaus Sinn f√ľr Humor, wie ein paar Fundst√ľcke zeigen:

  • 2011 hielten sie Scrum noch f√ľr „Extremely difficult to master“, jetzt haben sie das „extremely“ entsorgt.
  • Der Product Owner muss nur noch optional l√ľgen, also im Sprint Review nicht mehr unbedingt „completion dates based on progress to date“ extrapolieren – in Klammern folgt jetzt ein neckisches „(if needed)“.
  • Abweichlern, die Scrum nicht als Framework bezeichnen wollen, werden die Instrumente gezeigt: die zugeh√∂rige √úberschrift „Scrum Overview“ wird zu „Definition of Scrum“ umgetitelt. Nehmt das, Ihr Ketzer! Auch sonst werden die Z√ľgel der Orthodoxie straffer angezogen – 2011 schienen noch „Specific strategies for using the Scrum framework“ denkbar, jetzt sind es nur noch „Specific tactics.

Mein subjektives Fazit

Der neue Scrum Guide 2013 ist ein konsequenter Schritt in Richtung industriell betriebenes Scrum. Werte waren bereits 2011 ausgemerzt, die Produktvision wird es jetzt. Aus dem Sammelsurium von vermeintlichen Kleinständerungen stechen bei genauerem Hinsehen viele ScrumButs ins Auge, die den Segen der Scrum-Erfinder bekommen. Um nur ein zwei zu nennen: Tasks, die länger als einen Tag dauern; oder Teammitglieder, die bei laufendem Sprint aus dem Team abgezogen oder in das Team entsandt werden können.

Die Verbesserungen sind demgegen√ľber marginal, wenn auch einige √ľberf√§llige darunter sind, etwa das Einfordern eines Sprintziels.

Wer im Vergleich dazu lesen m√∂chte, was gut gelebtes Scrum wirklich sein kann, dem empfehle ich als Erholung nach dem Scrum Guide das neue Buch von Tobias Mayer zu lesen, seine Essaysammlung The People’s Scrum.

Heute kauf ich mir ein Zertifikat

A stack of certificates

Formulierungen wie „zertifizierter Scrum Master“, und „Certified Scrum Master (CSM), alternativ Professional Scrum Master (PSM) I“ tauchen immer √∂fter in Projekt- oder Stellenbeschreibungen auf, manchmal sogar unter der Rubrik must have. Das ist einerseits verst√§ndlich, weil jede/r sich einfach „Scrum Master“ nennen kann. Andererseits scheint wenig bekannt, was man sich unter „zertifiziert“ konkret vorstellen darf.

Um es einfach auszudr√ľcken und es im entsprechenden Selbstversuch zu demonstrieren:

Ein zertifizierter Scrum Master ist jemand, der einen Multiple-Choice-Test bestanden hat. Je nach Geschmacksrichtung (Scrum Alliance: CSM; Scrum.org: PSM) ist ein vorheriger Anderthalb-Tages-Einf√ľhrungskurs in Scrum zur Zeit dabei optional (Scrum.org) oder zwingend (Scrum Alliance).

CSM versus PSM I

Die beiden Varianten der Multiple-Choice-Tests schenken sich wenig, veranschlagte Zeit (60 Minuten), Testgeb√ľhr (100$, aber s.u.) und geistiger Anspruch (s.u.) sind bei beiden Unternehmen, pardon: Organisationen, deckungsgleich. Allerdings unterscheidet sich der Umfang sp√ľrbar:¬† 35 Fragen f√ľr den CSM-Titel, 80 f√ľr den PSM I. Ebenso die f√ľrs Bestehen n√∂tige Quote richtiger Antworten: 69% f√ľr den CSM-Titel, 85% f√ľr den PSM I.

Zeitdruck und Quotendruck sind f√ľr den PSM in spe also merklich h√∂her – man darf w√§hlen: billiger und stressiger oder teurer und lockerer. Den CSM-Test kenne ich bereits, da ich einigen angehenden CSMs dabei √ľber die Schulter geschaut habe (nein, ich habe nicht beim Schummeln geholfen, sondern blieb ganz still). In eine kleine Auswahl der PSM-I-Testfragen kann man gratis hineinschnuppern, was sich dann Scrum Open Assessment nennt.

Ihr k√∂nnt es mir hoffentlich nachsehen, dass ich f√ľr dieses Posting keinen „Certified Scrum Trainer“ (CST) der Scrum Alliance mit rund 1.400 ‚ā¨ Kursgeb√ľhr begl√ľcken m√∂chte, nur um anschlie√üend 35 Fragen f√ľr das CSM-Zertifikat beantworten zu d√ľrfen. Das erste mal „Scrum Master“ war ich vor gut einem Dutzend Jahren, einen obligatorischen Einf√ľhrungskurs vor einem Test ist mir dieses Posting daher nicht wert. Ich spare mir also den CSM-Kurs und w√§hle den PSM-I-Testparcour.

Pl√§diere ich etwa gegen CSM- oder PSM-Einf√ľhrungskurse generell? Ganz und gar nicht, in fokussierter Atmosph√§re mit einem guten Trainer die Grundlagen von Scrum kennen zu lernen ist eine gute Idee.

Die Multiple-Choice-Tests

N√ľchtern und illusionslos gesprochen, pr√ľfen die Multiple-Choice-Tests bei beiden Organisationen im Wesentlichen folgende Dinge:

  1. ob man den offiziellen Scrum Guide (bei der Scrum Alliance bereits subtil relativiert durch Core Scrum) im Kopf präsent hat, inklusive feiner Details
    (wie etwa das „potentially“ in „potentially releasable“)
  2. ob man vor dem Klicken konzentriert die Fragen und alle Antworten bis zum Ende liest und dabei auch Verneinungen nicht √ľbersieht
    (etwa in „Which two (2) things does the Development Team not do during the first Sprint?“)

Beide Tests sind auf braves Auswendiglernen und minimales Transferwissen angelegt, oder, um es anders auszudr√ľcken: sie sind Tests auf der Shu-Ebene, mit einer Prise Ha. Wo ein Scrum Master mit etwas echter Erfahrung agil antworten und sagen w√ľrde „Lass uns das Team fragen“ sollte man im Test lieber nicht ins Gr√ľbeln geraten, sondern brav die Lehrbuch-Antwort herleiten und geben.

Maximal 3-4 Fragen erfordern echtes √úbertragen von Wissen auf hypothetische Situationen. Daher w√§re es leider f√ľr die MissionZertifizierung“ riskant, die eher simplen Fragen gedanklich mit (s)einer schwierigen Unternehmensrealit√§t verkn√ľpfen und entsprechend beantworten zu wollen. Merke: mit den Radiobuttons eines Multiple-Choice-Tests kannst Du nachtr√§glich nicht diskutieren. Was nicht bedeutet, dass sich hinter den Kulissen nach Kritik nichts √§ndert. Vergleiche zum Beispiel folgende zwei Fassungen einer Frage (von Scrum.org).

Fr√ľher:

Scrum Master is a management position?
A) True
B) False

Aktuell:

Scrum Master is a „management“ position?
A) True
B) False

Unterschied bemerkt? Wie hätte er Deine Antwort jeweils beeinflusst?

„Richtig“ ist √ľbrigens A). Zur Erinnerung: mit den Radiobuttons eines Multiple-Choice-Tests kannst Du nachtr√§glich nicht diskutieren.

„Und? Wie war’s?“

Scrum.org sagt:

Results for: Rolf F. Katzenberger
Title: PSM I
Score: 75 out of 80 points
Percentage: 94%
Duration: 00:30:59
Date started: Fri 5th Apr 2013 6:18am
Date finished: Fri 5th Apr 2013 6:49am

Feedback:
Congratulations! You have demonstrated a fundamental understanding of the roles, rules, artifacts, and time-boxes that bind together the Scrum framework. This qualifies for certification as a Professional Scrum Master I.

Passabel. Leider liefert Scrum.org unter Feedback nichts zu den aus seiner Sicht falschen Antworten; ich kann Euch also nicht berichten, wo ich geschlampt habe oder den Scrum Guide nochmal hätte durchlesen sollen. Apropos durchlesen: der Unterschied zwischen fundamental und profound ist klar?

Nach einer Investition von einer halben Stunde und umgerechnet 77 ‚ā¨ darf ich mich jetzt also „Professional Scrum Master I“ nennen und ein h√ľbsches Logo auf meiner Webseite zeigen.

Mindestens haltbar bis…

F√ľr den CSM-Titel gilt:

There is not currently a continuing education requirement for the CSM certification.
In order to renew your certification and membership, you can use the green „Renew Membership“ button on your dashboard. It is $100 for two years.

Bei mittlerweile gesch√§tzten 60.000 CSMs weltweit generiert dieser kleine gr√ľne Button also potentiell 3 Millionen $ Einnahmen pro Jahr. Ich gestehe unumwunden, dass ich die Scrum Alliance um dieses Gesch√§ftsmodell beneide und tr√∂ste mich damit, dass ich wenigstens kein Tropfen in seinem revenue stream bin.

Der PSM-I-Titel h√§lt momentan lebensl√§nglich, ohne weitere Kosten. Sobald diese Geschmacksvariante dank Preisvorteil und MHD zahlenm√§√üig mit dem CSM etwa gleich gezogen hat, rechne ich allerdings mit einer spontanen Erleuchtung seitens Scrum.org, dass nur ein obligatorischer Einf√ľhrungskurs mit einer j√§hrlichen geb√ľhrenpflichtigen Auffrischung auf Dauer den hohen Qualit√§tsstandard beim PSM I garantieren k√∂nne. Derzeit existieren bereits an die 7.500 PSM-I-Titeltr√§ger weltweit, das Verh√§ltnis zu CSMs liegt also noch bei rund 1:8.

Mein Fazit

Wissen ist nicht gleich Können.

Liebe Personaler, CSM und PSM geh√∂ren nicht in Projekt- und Stellenausschreibungen. Achtet statt dessen genau darauf, welche Skills und Erfahrungen durch Entwicklungsarbeit und Berufserfahrung belegt sind. Wer eine Zertifizierung als must have in einer Ausschreibung f√ľr Scrum Master auflistet, aber keine nachgewiesene Erfahrung verlangt, wird gerade von den erfahrenen Scrum Mastern nicht ernst genommen, die er gerne an Bord holen m√∂chte.

Liebe angehende Scrum Master, ich kenne einige deutsche CSTs persönlich und empfehle deren CSM-Kurse oft und gerne. Aber nicht wegen des Zertifikats.

Liebe Scrum Alliance und Scrum.org, nie h√§tte ich mir vor 12 Jahren tr√§umen lassen, k√ľnftig so etwas erfrischend offen Gesch√§ftst√ľchtiges zu lesen wie heute Morgen von Sabine Canditt (CSM, CSP, CSC, CST), zum Thema Scrum Guide (Scrum.org) versus Core Scrum (Scrum Alliance):

scrum.org und die Scrum Alliance sind zwei unterschiedliche Organisationen mit unterschiedlichen Zertifizierungsprogrammen. Um voneinander unabhängig sein zu können, brauchen beide Organisationen eine Referenz, die der Zertifizierung zu Grunde liegt, und die sie selbst beeinflussen können.

Das trifft es wohl recht genau: Man benötigt zwei Definitionen von Scrum, damit zwei Organisationen zwei Arten von Zertifikaten verkaufen können.

Update 2014-09-24: Scrum Alliance, scrum.org und Scrum Inc. haben heute bekannt gegeben, dass sie sich wieder auf den Scrum Guide als gemeinsame Definition von Scrum geeinigt haben. Der Scrum Guide wird ab sofort unter scrumguides.org verf√ľgbar sein.

Wissenstransfer mit Shu-Ha-Ri-Sprints

Agile Teams leben in der Grauzone: Skills und Aufgaben sind keine Frage von Schwarz oder Weiß, ich oder Du.

Wenn die Testerin zum „Bottleneck“ wird, weil Entwickler nicht wissen (wollen), wie man ein Testskript anwirft: schlecht f√ľrs Ziel. Wenn der Product Owner (PO) keinen Sinn darin sieht, von Anfang an mit der Testerin an brauchbaren Akzeptanzkriterien zu feilen: schlecht f√ľrs Ziel. Wenn die Testerin zwar programmieren k√∂nnte, aber sich str√§ubt, auch mal Unittests zu erweitern: schlecht f√ľrs Ziel.

Der Scrum Guide sagt:

Unabh√§ngig von der verrichteten Arbeit werden die Mitglieder des Entwicklungs-Teams als Entwickler bezeichnet. Scrum sieht keine anderen Titel f√ľr die Mitglieder eines Entwicklungs-Teams vor; es gibt keine Ausnahme von dieser Regel

Das bedeutet f√ľr das interdisziplin√§re Team eben nicht, dass jeder wirklich alles und noch dazu gleich gut k√∂nnen muss. Es bedeutet, dass jeder zu jedem Zeitpunkt Meister, Geselle und Azubi zugleich ist, nur eben auf unterschiedlichen Gebieten – und immer wieder von neuem.

Agiles Teamwork lebt von dieser Grauzone. Davon, dass nicht danach gefragt wird, wer f√ľr das Erreichen des Ziels verantwortlich ist, weil die Antwort ohnehin klar ist: das gesamte Team.

Wann immer das Schwarz-oder-Wei√ü-Spiel („Was soll ich denn noch alles k√∂nnen?“, „Das ist nicht mein Job!“, …) gespielt wird, um letztlich gar nichts au√üerhalb der eigenen Expertise kennen lernen zu m√ľssen: schlecht f√ľrs Ziel. Eine meiner wichtigsten Fragen an jedes Team ist deshalb: wie spielt Ihr denn statt dessen das Meister-Geselle-Azubi-Spiel, so dass es funktioniert?

Shu-Ha-Ri-Sprints: lernen, verstehen, vermitteln

Ein interessanter Weg neben z.B. Workshops, Schulungen und Communities of Practice (CoPs): das Team erklärt jeden Sprint zu einem Shu-, Ha- oder Ri-Sprint, rotierend.

  • W√§hrend eines Shu-Sprints (von Śģą shu, befolgen) betrachtet sich jedes Teammitglied als „Azubi“ und w√§hlt ein Wissensgebiet, zu dem es einen im Team allseits anerkannten Meister um die Zusammenarbeit bei einem entsprechenden Task bittet. Bist Du selbst der einzige Meister, dann befolgst Du Deine eigenen Lessons Learned oder die Literatur, die Du f√ľr ma√ügeblich h√§ltst, f√ľr diesen Sprint √ľbergenau und achtest darauf, wo Du vielleicht schlampig oder √ľberheblich geworden bist.
    (Wieder) lernen durch Achtsamkeit ist das Ziel.
  • In einem Ha-Sprint (von Á†ī ha, sich l√∂sen) betrachtet sich jedes Teammitglied als „Geselle“, reflektiert und notiert bei jedem Task, welche Praktiken, Techniken und Konventionen des Teams den Prinzipien des agilen Manifests gerecht werden und welche nicht.
    Die Zusammenarbeit besser verstehen durch Achtsamkeit ist das Ziel.
  • In einem Ri-Sprint (von ťõĘ ri, transzendieren) betrachtet sich jedes Teammitglied als „Meister“ und √ľberl√§sst gezielt die Hauptarbeit an einem Task, f√ľr den es selbst am besten geeignet w√§re, einem „Azubi“. Es gelten keine kurzfristigen Kosten-, Geschwindigkeits- oder Fehlertr√§chtigkeits-Ausreden.
    Respekt, Mut und Offenheit durch aufmerksames Coachen zu leben ist das Ziel.

In jeder Sprint-Retrospektive sammelt das Team die Erfahrungen des Einzelnen damit. Und es wird nach meiner Erfahrung einiges zusammengetragen, was zu wichtigen Erkenntnissen f√ľhrt. Ein Wissenstransfer findet ganz nebenbei statt, beim Arbeiten (Tasks), nicht statt dessen (Workshop, Schulung).

Warum wird der gesamte Sprint unter ein entsprechendes Motto gestellt? Warum darf sich nicht jeder in jedem Sprint frei zwischen Shu, Ha und Ri entscheiden?

Die strikte Regel bietet mehrere Vorteile:

  • die Rotation des gesamten Teams zwischen den dreien verringert Statusgehabe und macht klar, dass a) jeder ein respektabler Fachmensch auf seinem Gebiet ist und b) es zum Status des „Meisters“ geh√∂rt, zu coachen;
  • die Retrospektiven zerfasern nicht und fokussieren, in Rotation, jeweils auf Shu, Ha oder Ri;
  • kein Teammitglied kann ewig Azubi bleiben;
  • da es keinen Meister ohne Azubi (und umgekehrt) gibt, findet in Shu- und Ri-Sprints laufend ein intensiver Rollenwechsel statt; und
  • da sich niemand in einem Ha-Sprint als Meister oder Azubi definieren (lassen) muss, sch√§rft jeder dritte Sprint den gleichberechtigten Blick aller darauf, ob wirklich schon, noch oder wieder agil gearbeitet wird.

Welche Wege habt Ihr gefunden, Euer Meister-Geselle-Azubi-Spiel zu spielen?

enprovia Scrum Day 2012

This week, I had the pleasure to discuss Caveats and traps to avoid in agile development and Success factors for medium to large size Scrum projects at the enprovia Scrum Day 2012 in Bratislava, Slovakia (please find my presentations attached at the end of this post).

A great opportunity to chat with practitioners from all sectors (legal, financial, software shops, and many more). Agile clearly has a substantial market share here, so we were able to focus on detailed, tricky questions.

In preparation of my talks, I took the chance to flip through my oldest agile-related notebooks again, reviewing my personal lessons learned from 12 years of work in that field. The Top 10 of traps I had encountered proved to be almost exclusively related to organizational and psychological issues, but even the „techies“ in the audience didn’t resent that. During an afternoon talk, I summarized three central success factors for large Scrum projects.

Lots of interesting discussions at a superbly staged event Рthanks again to enprovia for starting this in Slovakia!

The slides, for downloading: Caveats and traps to avoid in agile development, Success factors for medium to large size scrum projects