Ganztags lösungsorientiert

Wir investieren Vorbereitungszeit, wenn wir uns zu Besprechungen oder √§hnlichem treffen. Wir w√ľnschen uns eine produktive und positive Atmosph√§re.

Und was ist mit den anderen 80% unserer Arbeitszeit?

Hier folgt eine Liste mit zehn einfachen, l√∂sungsorientierten Dingen, die wir ohne besondere M√ľhe in einem Gespr√§ch erw√§hnen k√∂nnen, immer dann, wenn es wirklich um etwas geht.

Viel Erfolg und Spa√ü beim Ausprobieren – und lassen Sie mich bitte in den Kommentaren wissen, was davon f√ľr Sie n√ľtzlich war, was Sie √§hnlich selber schon erfolgreich eingesetzt haben – und womit man den Effekt sogar noch steigern k√∂nnte.

A. Respektvoll Kontakt aufnehmen

  • Ich br√§uchte mal Deine Hilfe. H√§ttest Du gerade kurz Zeit?
  • H√§ttest Du eine halbe Stunde f√ľr mich?
  • Ich h√§tte da einen Vorschlag ‚Äď k√∂nnten wir uns heute Nachmittag kurz zusammensetzen?

B. Nach Zukunftsbildern fragen

  • Was w√§re dann alles m√∂glich, falls sich passiert?
  • Woran w√ľrdest Du konkret bemerken, dass es noch besser l√§uft?
  • Woran genau w√ľrden auch andere das bemerken?

C. Danach fragen, was wir stattdessen wollen

  • Wohin warst Du gerade unterwegs, als das Problem Dich gestoppt hat?
  • Wovon h√§tten wir gern mehr?
  • Was w√ľrdest Du denn stattdessen lieber tun?

D. Vorfreude wecken

  • Was w√ľrde das f√ľr Deine Motivation bedeuten?
  • Wie w√ľrdest Du Dich f√ľhlen, wenn das passiert?
  • Wozu w√ľrde Dich das noch inspirieren?

E. Danach fragen, was wir alle davon hätten

  • Was w√§re daran gut?
  • Und was w√§re konkret Dein Bed√ľrfnis dabei?
  • Welche Vorteile siehst Du darin f√ľr Dich und f√ľr das Team?

F. Danach fragen, was schon funktioniert

  • Wo oder wann funktioniert das schon?
  • Was ist dort oder dann anders?
  • Wie k√∂nnen wir noch mehr von diesen „anderen“ Orten oder Momenten erm√∂glichen?

G. Menschen von Anfang an einbeziehen

  • Wie sieht die Situation aus Deiner Sicht aus?
  • Sollten wir mal zusammen √ľberlegen, wo wir hin wollen?
  • Welche Schritte in Richtung Ziel w√ľrdest Du als erstes vorschlagen?

H. Auf Erfolge und Ressourcen konzentrieren

  • Wie haben wir es bis hierher geschafft?
  • Was w√§re ein n√§chster kleiner Schritt zum Besseren?
  • Welcher kleine Schritt h√§tte den gr√∂√üten Effekt?

I. Danach fragen, was die Zuversicht weiter steigert

  • Was br√§uchten wir konkret, um noch zuversichtlicher zu sein?
  • Was w√ľrde Dich noch eine Stufe zuversichtlicher machen?
  • Wo siehst Du schon erste Anzeichen f√ľr einen Erfolg?

J. Ausdr√ľckliche Vereinbarungen freundlich treffen

  • K√∂nnen wir uns darauf einigen?
  • Wollen wir das als Experiment ausprobieren?
  • Ich w√ľrde das gern hinbekommen ‚Äď hilfst Du mir?

Bonuspunkt

Immer „Wozu…“ benutzen, wenn man urspr√ľnglich „Warum…“ sagen wollte – und sp√ľren, welchen Unterschied das macht!

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.

Positiv denken ohne Drogen

Titelfolie zu Positiv denken ohne Drogen

Letzten Freitag und Samstag hatte ich das Vergn√ľgen, am Fr√ľhjahrs-Campus der Mathema Software GmbH teilnehmen zu d√ľrfen. Wie immer war’s spannend und interessant, danke sch√∂n!

Am Samstag habe ich mich mit einer kurzen Session „Positiv denken ohne Drogen“ revanchiert:

Positiv denken ohne Drogen
Wie Sie mit Ihrer Umgebung realistisch gl√ľcklicher werden (falls Sie wollen)
Probleme gibt es gratis, in beliebiger Menge. Sehr praktisch: hat man Probleme, bekommt der Tag Struktur – ganz ohne eigenes Zutun. Bedenklich: √Ąrger, Verdruss und Dilbert werden zu unk√ľndbaren Kollegen.
Wenn Sie neugierig auf etwas Besseres sind, bekommen Sie hier ein Potpourri von Anregungen, um manche Dinge und Menschen, inklusive sich selbst, einmal souveräner zu sehen und anzupacken.

Drei kleine Aktivitäten (Fragen versenken, die Discover-Phase aus Appreciative Inquiry sowie das Wertequadrat nach Paul Helwig und Friedmann Schulz von Thun) haben den Teilnehmern offensichtlich ebenso großen Spaß gemacht wie mir.

Folien und Materialien zum Download: Positiv denken ohne Drogen (ZIP)

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?

Hier stinkt’s! Platz 10: F√ľr immer Azubi

Ja, tatsächlich: ich bin großartig. Schwierige Momente und Missionen löse ich lässig und unaufgeregt. Unfassbar sicher ist mein Auftreten.

W√§hrend das Team noch r√§tselt, w√§hrend die F√ľhrungsriege mich mit flehenden Augen ansieht, sind mir die L√∂sungen schon in der Sekunde klar, in der das erste Wort √ľber ein m√∂gliches Problem f√§llt. Sagte ich gerade „Problem“? Ich meinte nat√ľrlich: Petitesse.

Mein Dauerzustand entspannter Unterforderung weicht nur f√ľr einen fl√ľchtigen Augenblick, wenn ich die Verzweifelnden (wie √ľblich) mit einer fabelhaften, den Tag rettenden Geste aufrichte und in meinen Bann ziehe.

Und dann klingelt der Wecker. Ich wache auf, und das echte Leben beginnt.

Jammerschade – sp√§testens nach der Pubert√§t hat Hollywood wohl ausgedient und Platz gemacht f√ľr den Klassiker „√úbung macht den Meister“. Das hat man verstanden und verinnerlicht.

Oder etwa nicht?

Symptome: wie es zu m√ľffeln beginnt

Meistens zeigt die Verinnerlichung Wirkung. Gelegentlich aber durchschauen und beherrschen wir alles, was jemals erdacht und erfunden wurde, aus dem Stegreif. Gerade bei simplen Dingen wie Scrum, Extreme Programming oder Kanban ist v√∂llig offensichtlich, welch grobe Schnitzer sich die jeweiligen Erfinder geleistet haben und aus unerfindlichen Gr√ľnden zu korrigieren weigern. Selbst wenn sie dazu alles N√∂tige von uns erfahren k√∂nnten, w√ľrden sie uns auch nur einmal um geistigen Beistand bitten:

  • Mit Post-Its, Karteikarten und Stiften arbeiten? Unprofessionell! Wozu gibt’s Software?!“
  • 19 Seiten Scrum Guide einhalten? Funktioniert bei uns nicht! Jedenfalls nicht, bevor wir das tayloren und customizen (wie die anderen 500-Seiten-Methodiken vorher auch).“
  • Jeden Tag eine Viertelstunde Standup-Meeting, f√ľr alle? Nur wegen Statusreporting? Wir reden sowieso den ganzen Tag miteinander…“
  • Anderthalb Stunden retrospektive Nabelschau, therapeutisches Miteinander-Reden? Alle 2 Wochen? Wozu haben wir unser betriebliches Vorschlagswesen?!“
  • Wir machen ab sofort Scrum! Aber mit dreimonatigen Sprints, nur einmal Standup Meeting pro Woche, eindeutigen Arbeitspaketverantwortlichen und fixer Releasecontainerbeplanung 4 Monate vorab – eben einfach professionelles Scrum, mit allem, was naives Scrum bisher str√§flich vernachl√§ssigt!“

Klingt vertraut? Selber schon so etwas gedacht und gesagt? Unerkl√§rlich, weshalb „nach unserer Umstellung auf Agilit√§t“ mehr und mehr so l√§uft wie fr√ľher – nur noch schlimmer?

Ursachen f√ľr m√ľffelnde Agilit√§t, Platz 10: F√ľr immer Azubi

Wie in einem Metier die Stationen bis zum „Richtig gut“ aussehen, dazu gibt es einige Modelle. Die Br√ľder Stuart und Hubert Dreyfus beschreiben 5 Stufen (sch√∂n erl√§utert bei Werner Stangl):

  1. Anfänger (Novice)
  2. Fortgeschrittener Anfänger (Advanced Beginner)
  3. kompetent Handelnder (Competence)
  4. Erfahrener (Proficiency)
  5. Experte (Expertise)

Etwas gr√∂ber, daf√ľr noch eing√§ngiger, lauten die seit dem Mittelalter klassischen Stufen:

  1. Lehrling
  2. Geselle
  3. Meister

Wie lange braucht man zum Experten und Meister? Als Faustregel kann man mit rund 10.000 Stunden intensiver Besch√§ftigung rechnen. Beruflich gesehen sind das umgerechnet knapp 62 Arbeitsmonate, etwas √ľber 5 Jahre also. Jahre, bis man agiles Arbeiten wirklich verinnerlicht hat? Das kann man einsehen und respektieren – muss man aber nicht.

F√ľr manche kratzt es arg am beruflichen Ego, zusammen mit oder gar – Himmel! – von anderen etwas lernen zu m√ľssen. Mag sein, dass sogar Leonardo etwas laufend √ľben musste. um es zu verstehen und zu beherrschen. Aber doch nicht ich!

Shortcut Impossible

Das Bed√ľrfnis, ohne M√ľhe simple Rezepte mit klaren Erfolgsaussichten nachzukochen und daf√ľr umgehend belohnt zu werden, hat keine Chance auf Erf√ľllung. Weder durch Bienenflei√ü beim B√ľcherkonsum, noch mittels Durchdenkdelegation an Berater, noch durch munteres Mischen von Methodenmoden.

Wer seine Einsteiger-Stadien nicht liebt, lebt und letztlich hinter sich lässt, bleibt eben ewiger Azubi, unzufrieden mit jeder Methode, dabei aber von wenig Selbstzweifel geplagt. Klare und banale Ursache Рdoch von vielen so wenig beachtet wie die Fensterscheibe von der Fliege.

Wieso kommt man trotzdem derartig m√ľffelnd durch’s agile Leben?

Aus demselben Grund, aus dem auch mittelm√§√üige Handwerker,¬† mittelm√§√üige Softwareentwickler, mittelm√§√üige Unternehmen durchkommen: Weil es zum Leben reicht – und nicht das Leben kostet. Wer damit kein Problem hat, hat damit schon die L√∂sung. F√ľr alle anderen hier ein Vorschlag.

Lösungsmöglichkeit

Lerne, das Paradox zu lieben: wer nicht als ewiger Einsteiger gelten will, muss immer wieder einer werden. Je neugieriger, desto besser. Was heißt das, konkret?

Zur√ľck ins Mittelalter. Oder in den fernen Osten.

Egal, wie gut Du bist: Lehrling, Geselle und Meister bleibst Du immer. Nur das Thema und Dein Stadium wechseln. Gut, wenn Du die typischen Bed√ľrfnisse jeder Stufe immer vor Augen hast und sie bei anderen wie bei Dir selbst respektierst:

  • als agiler Lehrling hoffst Du auf einfache Regeln, Rollen und Artefakte, die den Erfolg garantieren. Du bist verunsichert, wenn Du Dich musterg√ľltig an alle Regeln gehalten, aber Deine Aufgabe trotzdem nicht erfolgreich zu ende gebracht hast. Du brauchst Ermutigung daf√ľr, dass Du immer mehr Dinge immer √∂fter richtig machst.
  • als agiler Geselle lernst Du immer besser, Deine Werkzeuge passend zur Situation zu w√§hlen, anhand von Prinzipien. Du bist verunsichert, wenn Du keine Idee hast, wie Du eine Aufgabe bew√§ltigen sollst – und wenn offenbar auch niemand sonst aus der ganzen Community eine solche Idee hat. Du brauchst Ermutigung daf√ľr, dass Du keinen offenkundigen Unsinn bis zum bitteren Ende durchexerzierst, sondern Verantwortung √ľbernimmst. Gelegentlich auch mal ohne Erfolg.
  • als agiler Meister bist Du Dir nicht mehr bewusst, nach Prinzipien zu handeln. Deine Handlungen flie√üen direkt aus Deinen Wertvorstellungen und Deiner Erfahrung.¬† Du brauchst konstruktive, harte Kritik, wenn Du langsamer Fortschritte machst als Dir m√∂glich w√§re. Du brauchst auch Lehrlinge, die in naher Zukunft einmal besser sein werden als Du je warst.

Es lohnt sich, dem eigenen Ego so lange diesen lebenslangen, auf den verschiedensten Gebieten wiederkehrenden Zyklus vor Augen zu f√ľhren, bis es zu murren aufh√∂rt und ihn genie√üen kann.

Zu altbacken f√ľr Dich?¬† Gut, dann beschreibe ich es vielleicht einmal so:

Was Du ab heute tun könntest

Fange an:

  • Wem wirst Du heute etwas weiter geben und √ľberlassen?
  • Welche Alternativen wirst Du heute n√§her betrachten?
  • Was wirst Du heute aufmerksam √ľben?

IT meets Business – Vortrag zur 4-Stunden-Woche

Der freundlichen Einladung der Organisatoren von IT meets Business konnte ich nicht widerstehen und habe mit einer Gruppe von IT-F√ľhrungskr√§ften √ľber Tim Ferriss‚ Konzept der 4-Stunden-Woche gesprochen.

Tims provokanter Ausgangspunkt: die Mehrheit der Arbeitnehmer von heute k√∂nne nicht mehr auf einen Arbeitsplatz hoffen, mit dem sie dauerhaft gl√ľcklich werde. Daher seien Angestellte gut beraten, ihr Arbeitspensum zum Geldverdienen in m√∂glichst kurzer Zeit effizient zu bew√§ltigen (daher der Titel „4-Stunden-Woche“). Die restliche Zeit k√∂nne man dann mit sinnvollen Dingen verbringen, die keinen Beitrag zum Einkommen leisten, aber kaum weniger anstrengend als die bezahlte Arbeit sein m√ľssten.

Nach dem Vortrag (die Folien finden Sie im Anhang zum Download) entspann sich eine lebhafte Diskussion: Tim Ferriss‘ Buch stammt immerhin schon aus dem Jahr 2007, aus der Zeit vor der Weltwirtschaftskrise. Eine (englische) Neuauflage ist derzeit in Vorbereitung, ich bin gespannt, was Tim am Text √§ndern wird.

Die Folien, zum Download: 2009-12-09 IT meets Business 4HWW

Pragmatic Teams

Was f√ľr Leute m√∂chte man im Team haben?

Was macht ein gutes Team aus?

Es ist pragmatisch. Es h√§lt sich an ein paar einfache, zeitlos g√ľltige Grunds√§tze:

Richtig ist, was funktioniert

Relevant ist, was in der Praxis einen sp√ľrbaren Unterschied macht. Richtig ist, was heute mit Blick auf das Ganze funktioniert. Erkenne, was bereits gut genug ist und lasse es gut sein. Es entscheidet die Teambilanz, nicht Dein Einzelerfolg.

Immer in medias res

Komm ohne Umschweife zur Sache. Denk nicht nur √ľber den ersten Schritt nach, tu ihn. Sorge daf√ľr, dass Du immer mutig die Richtung √§ndern kannst. Hole Dir von Anfang an offenes, ehrliches Feedback, von Mensch und Maschine. Erspare Dir und dem Team unn√∂tiges Drama und schlampiges Heldentum, es gibt gen√ľgend echte Bew√§hrungsproben f√ľr Deine Talente und die der anderen im Team.

Du bist nie allein

Respektiere jedes Teammitglied und respektiere das Team. Das Team ist nicht anonym, und Du bist es auch nicht. Der Kunde ist Teil des Teams, seine Erwartungen stehen aber √ľber Deinen. Nur ein intaktes Team gibt Energie.

Nur die Teambilanz entscheidet, und Du tr√§gst Verantwortung daf√ľr: was um Dich herum kaputt geht, kaputt ist oder kaputt bleibt, wird fr√ľher oder sp√§ter Dein pers√∂nliches Problem.

Liebe und lerne Dein Metier

Hab‘ Freude daran, dass Du in jeder Minute Lehrling, Geselle, und Meister in einem bist. Es ist keine Frage des Alters oder des Status‘, sondern der Neugier, der praktischen √úbung und der Erfahrung. Deinen Wert bestimmst Du jeden Tag selbst mit.

Als Lehrling √ľbe die Grundlagen sorgf√§ltig ein, lerne die Hilfsmittel kennen und befolge die Regeln. Sei klug in der Wahl Deiner Meister. Als Geselle finde L√∂sungen und Alternativen. Vergiss nicht, dass Du immer auch Lehrling bist. Sei klug in der Wahl Deiner Freiheiten. Als Meister, sei eine Quelle der Inspiration. Vergiss nicht, dass Du immer auch Geselle und Lehrling bist. Sei klug in der Wahl Deiner Grenzen.