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!

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?

Trau Dich: „Training from the BACK of the Room!“ auf dem Mathema Campus

Es gibt einige feine Unternehmen, die über den Tellerrand hinaus schauen und jedes Jahr für Kunden und Partner ein Event auf die Beine stellen, das viel mehr will als nur die eigenen Services und Produkte unters Volk zu bringen. Der Campus der Mathema Software GmbH ist so ein Event und ich habe mich auch dieses Jahr RIESIG über die Ehre gefreut, eingeladen zu werden. Danke schön! Mein Thema dieses Jahr:

Training from the BACK of the Room! Lernt Ihr schon, oder nehmt Ihr noch durch?

Kurse, Workshops, Trainings so gestalten, dass Teilnehmerinnen und Teilnehmer möglichst gut lernen und viel mitnehmen können? Das probiere ich doch gerne aus, getreu dem Motto: use the thing to teach the thing. Eine Stunde, ein Thema, ein Pulk interessierter Menschen – hier, was wir zusammen erlebt haben:

Connections: Trau Dich!

Wichtig für einen guten Einstieg in Kurse, Trainings und Workshops: von Anfang an Teilnehmer miteinander verbinden. Und Teilnehmer mit dem Thema verbinden. Und natürlich die Verbindungen zwischen dem Thema und den persönlichen Zielen der Teilnehmer kennen lernen – was ist ihnen wichtig, was eher nicht?

Leichter gesagt als getan, denn üblich sind bestenfalls Kaffeetische für allgemeine Gespräche vor Kursbeginn – was zumindest schon einmal die Menschen untereinander verbinden hilft. Wer jetzt zu „Icebreakern“ greift, also vermeintlich netten „Kennlernspielen“ könnte schon die Hälfte des Publikums verlieren, oder, noch schlimmer, aufs passive Konsumieren einstimmen. Also, mutig sein! Ich entscheide mich für ein Experiment und bereite Trau-Dich-Päckchen vor – Überraschungseier für Erwachsene, sozusagen.

Da wir einen recht kleinen Raum ohne Tische haben, werden jeweils 5-6 Stühle vorab in Vanillekipferl-Anordnung zusammengerückt, damit sich kleine Grüppchen bilden können. Ich hoffe auf die natürliche Neugier und lege die Trau-Dich-Päckchen auf den Stühlen aus. Jetzt heißt es Geduld haben und die ersten Minuten eben nicht selber die Initiative zu ergreifen. Nach ein paar Minuten schreibe ich rot und fett TRAU DICH! auf ein Flipchart, verlasse den Raum wieder und warte gespannt, was passiert.

Ganz oben im Päckchen: eine Aktivität, die ich Name the Trumps genannt habe. Die „Trümpfe“ sind sechs Lernprinzipien, die bei Training from the BACK of the Room! sehr nützlich sind. Sie hängen als überdimensionale Spielkarten an der Wand, mit einem Bild, aber noch ohne jeden Text. Die Teilnehmer finden im Päckchen ein Kärtchen mit einer grünen Haftnotiz und einer knappen Anleitung:

  • Schau die 6 Trumpfkarten an den Wänden an und denk Dir einen Namen für jede aus. Ein Beispiel wäre: „Kürzer schlägt länger“.
  • Diskutiere Deine Ideen mit jemandem & notiere sie hier unten.
  • Kleb die grüne Haftnotiz (s. Rückseite) unter Deine Lieblingskarte.

Es funktioniert: alle reden miteinander, statt abwartend auf mich zu starren. Sie gehen an den Wänden entlang und diskutieren die aufgehängten Trumpfkarten, nach und nach kleben mehr und mehr Haftnotizen an der Wand, die Stimmung ist fröhlich und gelöst. Und: ich kann vorab erkennen, was (niemanden) interessiert.

Concepts: Sechs Trümpfe

In konventionellen Trainings werden den Teilnehmern relativ viele neue Konzepte erläutert, bevor sie aktiv werden dürfen. Training from the BACK of the Room! propagiert hier das absolute Minimum. Wenn das Lernziel zum Beispiel lautet: „Die Teilnehmer bauen Neuschwanstein aus LEGO nach“, dann muss der Trainer zunächst nicht viel mehr tun als mal zwei LEGO-Steine demonstrativ zusammenzustecken. Bei vielen Kursthemen ist nicht einmal das nötig.

Kürzer schlägt länger
Kürzer schlägt länger

Also: die Lernzeit der Teilnehmer maximieren! Mich interessiert, welche Lernprinzipien sie aus den unbeschrifteten Trumpfkarten an den Wänden für sich erkannt haben. Was liegt näher, als alle in einer Shout-out-Aktivität einfach danach zu fragen? Ich halte die Trumpfkarten hoch und alle rufen Ihre notierten Ideen dazu einfach in den Raum. Ich bin baff, welches Spektrum zusammenkommt. Kaum zwei gleiche Interpretationen, und viel Heiterkeit, als ich jeweils die „offizielle“ Interpretation der sechs Trümpfe verkünde:

  1. Bewegung schlägt Stillsitzen (Movement Trumps Sitting)
  2. Mitreden schlägt Anhören (Talking Trumps Listening)
  3. Bild schlägt Wort (Images Trump Words)
  4. Notieren schlägt Mitlesen (Writing Trumps Reading)
  5. Kürzer schlägt länger (Shorter Trumps Longer)
  6. Anders schlägt Einerlei (Different Trumps Same)

[Die Karten dazu gibt es übrigens hier unten als PDF-Anhang, zum Download!]

Ich erläutere den Teilnehmern noch kurz die Phasen, die wir gerade durchlaufen (Connections; Concepts; Concrete Practice; Conclusions) und nehme mich für die nächste Phase wieder zurück – Training from the BACK of the Room! im wahrsten Sinne des Wortes.

Concrete Practice: Warum ist ein Trumpf ein Trumpf?

Die Teilnehmer finden für ihre Notizen und Skizzen zu den Trümpfen sechs leere Spielkarten in ihrem Päckchen, mit Farbstiften. Daneben noch unterschiedliche kleine Toys, denn Du lernst auch mit den Händen. Manche Hände brauchen sogar etwas zum Drehen, Ziehen, Herumspielen, damit ihre Besitzerinnen und Besitzer sich gut auf etwas ganz Anderes konzentrieren können. Wer nicht mag, lässt sein Toy eben einfach im Päckchen. Oder tauscht es gegen etwas Ansprechenderes.

Die Grüppchen ziehen jeweils verdeckt  eine beschriftete Trumpfkarte und ich bitte sie darum, innerhalb von 5 Minuten 3-5 Ideen zu sammeln, weshalb der jeweilige Lerntrumpf wohl das Lernen effektiver macht. Die Eigenverantwortung wird deutlich: kein Grüppchen bleibt still.

Anschließend fasst aus jeder Gruppe jemand die Ideen vor allen Teilnehmern zusammen. Jeder kritzelt und notiert dabei das mit, was individuell wichtig erscheint, auf den leeren Spielkarten. Manche malen Mindmaps, manche schreiben einfache Listen, manche zeichnen.

Notieren schlägt Mitlesen
Notieren schlägt Mitlesen

Technisch gesehen gehört eine solche Aktivität in die Schublade Table Teach-Back: Tischgruppen bereiten ein Teilthema für andere Tischgruppen auf – das Lernen wird so verstärkt, weil das Thema 3x durch den Kopf wandert: beim Hören, beim Durchdenken, beim Erläutern für andere.

Bohrende Fragen

Was tun dann überhaupt noch Trainerin und Trainer? ist die meist gestellte Frage. Und noch: Muss man nicht Fehler und Missverständnisse sofort korrigieren? Die Antworten sind einfach: viel; und nein, nicht sofort, sondern im Anschluss.

  • Wer seine Kurse, Workshops und Trainings nach Training from the BACK of the Room! gestaltet merkt schnell, dass die Vorbereitung genauso viel Arbeit macht wie bei konventionellen Methoden. Aber sie macht auch auch doppelt so viel Spaß!
  • Missverständnisse und Fehler gehören zum Lernen dazu. Trainerin und Trainer können nicht stellvertretend für die Teilnehmer Rad fahren lernen. Es ist Traineraufgabe, den Teilnehmern die Sicherheit zu geben, dass Fehler und  Irrtümer völlig in Ordnung sind und dass für die letzten Details und Korrekturen immer ein kompetenter Gesprächspartner mitdenkt. Der nicht als erster und laufend be-lehrt, sondern nach dem Motto mitmischt: Three before me. Oder sich wenigstens sagt: Two before you.

Die Teilnehmer bei meiner Session auf dem Mathema Campus tragen von alleine so gut wie alles zusammen, was es zu lernen gibt: ich streiche beim Zuhören gut gelaunt einen Punkt nach dem anderen von meiner Liste und muss nur wenig nach schieben, nichts korrigieren.

Beispielsweise ergänze ich noch, bei Notieren schlägt Mitlesen„:

  • Notiert wird Wissen, mitgelesen nur Information. Gleich wie gut eine Zusammenfassung von Trainerin und Trainer auch sein mag: erst mit den eigenen Worten der Teilnehmer ist  Wissen entstanden.
  • Notizen, Skizzen und Gekritzel sind individuell, physisch, visuell und an einem bestimmten Ort festgehalten. Lerner können sich oft sogar noch an die Stelle auf einem Blatt Papier erinnern, an der sie etwas Wichtiges fixiert haben – und an die Farben. Das verankert ihr Wissen viel tiefer als jede noch so unterhaltsame Präsentation.

Bei der Trumpfkarte „Bewegung schlägt Stillsitzen“ riskiere ich, weil es hier (!) genau (!) dazu passt, eine knalligere Aktivität zur Verdeutlichung: Ich verteile A4-Blätter und bitte alle, für jemand anderen ein Geschenk zu malen: „Bewegung schlägt Stillsitzen“ mit einem Smiley daneben. Wer fertig ist, möge bitte aufstehen. Ich zerknülle vor allen demonstrativ meine eigene Zeichnung: „Macht’s mir einfach nach! Sieht aus wie ein Schneeball, oder? Und was macht man … mit einem Schneeball?“ Zu den Klängen von  007 von Fanfare Ciocărlia tobt eine minutenlange Schneeballschlacht! Die Geschenke sind dann gut durchmischt…

Als Coach und Trainer habe ich mittlerweile akzeptiert, dass ich für diesen Weg oft erst Wochen nach einem Workshop Anerkennung bekomme. Viele tun sich schwer, zwischen Lernprinzipien (wie den sechs Trümpfen) und den Myriaden möglicher Aktivitäten dazu zu unterscheiden. Bei manchen ist die spontane Reaktion eher: Was macht der eigentlich noch, wir machen doch hier alles?! Oder: Das könnte man doch in der Hälfte der Zeit durchnehmen!!! Oder, verunsichert: Was soll der Kindergarten?!

Und es stimmt! Die Teilnehmer machen so viel wie möglich, denn Ihr Lernen ist das Ziel. Stimmt auch: durchnehmen könnte man doppelt soviel, in derselben Zeit – bloß verstehen und  lernen eben nicht. Und der Kindergarten? Stimmt doch: Dein Kind sollte dort lieber ordentlich durch die Mangel gedreht werden, damit es was fürs Leben lernt! Äh… Moment mal: Könnte es sein, dass man vieles dort so macht, gerade weil es eben funktioniert? Und welchem Denkverbot fügst Du Dich, wenn Du das vor Dir selbst und vor anderen lächerlich machst?

Conclusions: Auswerten, diskutieren, planen ist Trumpf

Wir diskutieren am Schluss, was die Teilnehmer aus ihrem eigenen Alltag kennen, was sie nutzen könnten, wo sie skeptisch sind. Die meisten sind nach einer Stunde immer noch hellwach und begeistert. Würden sie Training from the Back of the Room! weiterempfehlen? Falls ja, warum?

Lernerfolg viel höher. Konzept als Framework gefällt.

Weil es ganz anders als andere Vorträge in Erinnerung bleibt, und Eigeninitiative bringt Selbstwertgefühl ins Spiel.

Man kann – egal in welcher Form man trainierend tätig ist – ein paar schöne Inspirationen mitnehmen.

Aber es gibt auch kritische Stimmen: ob das wohl für alle Gelegenheiten passt? Ob das nur alter Wein in neuen Schläuchen ist? Ob es zu aufwendig wäre, ein Buch zu diesem Thema zu lesen oder einen Kurs dazu zu belegen?

Natürlich bin ich selber begeistert, schließlich bin ich ja zertifizierter Trainer für Training from the BACK of the Room! Ich schlage also einfach vor, sich die selbst erlebten (und gehaltenen!) Kurse, Workshops und Trainings noch einmal vor Augen zu führen: haben die Teilnehmerinnen und Teilnehmer das gelernt, was sie wollten? Waren sie wach im Kopf oder wie leicht narkotisiert? Haben sich Coaches und Trainer konsequent über eine hirnfreundliche Lernumgebung Gedanken gemacht, oder nur bruchstückweise, nach der Devise „Amerikanische Forscher haben herausgefunden…“?

Wer sich mit Training as usual wohl fühlt und damit seine Ziele erreicht, braucht Training from the BACK of the Room! nicht und könnte hier aufhören, zu lesen. Für wen das nicht gilt:

Lust darauf, als Trainer weiter zu wachsen?

Du kannst an einem unserer ungewöhnlichen Trainings teilnehmen und ein noch besserer Trainer werden. Der Clou: Du wirst dabei hoch motivierte, gleichgesinnte Trainer und Coaches treffen. Für Schnellentschlossene gobt es immer Frühbucher-Rabatte.

Sehen wir uns?

Die Trumpfkarten zum Download: The Six Trumps® Cards Deutsch

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 SprintplanungSprint-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)

35. Agile Monday: Appreciative Inquiry Retrospektive

Ich habe noch nie etwas von gelangweilten NASA-Teams gehört. Technische Probleme einer Marslandung werden offensichtlich als positive Herausforderung angenommen.

Sind die Aufgaben weniger technisch, dann generiert das übliche Breittreten von Problemen allerdings tendenziell noch mehr problematische Effekte als Lösungen. Bei konventionell geführten Retrospektiven  bleibt dann von dem, was bisher gut lief, zu oft nur ein schmächtiges „Weiter so!“ übrig, ohne erkennbaren Effekt. Bessere Idee: statt des ermüdenden „Problemtalk“ baut man besser auf dem Erreichten auf und überlegt gemeinsam, wie man vom erreichten Stand x auf x+1 kommen könnte. Diese Sicht verbreitet sich immer mehr.

Der 35. Agile Monday im Coworking Space Nürnberg stand diesmal unter dem Motto „Lösungsorienterte Retrospektiven“.

Über die Einladung der Agile-Monday-Organisatoren Martin Heider, Sven Winkler und René Füger  habe ich mich sehr gefreut und am ersten schönen Frühlingsabend mit zwei Dutzend Teilnehmern eine lösungsorientierte Retrospektive nach Appreciative Inquiry durchgespielt (Materialien dazu gibt’s als Anhang unter diesem Posting). Die Retrospektive drehte sich praktischer Weise um die Zukunft des Agile Monday selbst.

Vorweg: ein toller Abend!

Vorbereitung

Henne und Ei lassen grüßen: alle Formate von Appreciative Inquiry (wie Summits, Positive Change Network, oder eben auch Retrospektiven) drehen sich um ein affirmatives Thema, also ein positives, das zu Diskussionen über die angestrebte Zukunft (ver) führt und das gemeinsame Lernen stimuliert.

Agile Teams wählen ihr Retrospektiventhema dazu normaler Weise selbst, es „hält“ dann für 2-3 Retrospektiven, bis das Team für’s nächste Mal ein anderes wählt. Weil das ad hoc natürlich so nicht machbar ist, denke ich mir eine Liste von 6 möglichen affirmativen Themen aus, um den Teilnehmern etwas Auswahl zu bieten. Martin Heider gibt hilfreiches Feedback, ich streiche die Liste auf folgende zusammen:

  • Aktive Agile Monday Online Community
  • Der Agile Monday verändert
  • Der Agile Monday hilft

Zu jedem Thema entwickle ich dann drei Interviewfragen – in einem Scrum-Team wäre das zum Beispiel die Aufgabe eines Scrum Masters. Alles zusammen packe ich auf ein Arbeitsblatt. Der Abend wird, wie bei einer traditionellen Retrospektive, etwa 2 Stunden konzentrierter Arbeit bedeuten. Um die Teilnehmer nicht mit einer zusätzlichen Theorievorlesung für’s Kommen zu strafen, stelle ich auch noch ein kurzes Infoblatt mit Grafiken und Ressourcen zu Appreciative Inquiry und Lösungsorientierung zusammen, das man sich anschließend zu hause durchsehen kann (Downloads  s.u.).

Meine Erfahrung als Coach: mit etwas Routine benötigt z.B. ein Scrum Master für die Vorbereitung einer lösungsorientierten Retrospektive ungefähr ebenso viel Kreativität und Zeit wie für eine konventionelle.

Intro

Appreciative Inquiry 4D cycle

Abends nehmen es Teilnehmer wie Patrick mit Fassung, als ich eine Dauer von 2 Stunden prognostiziere. Um gleich einsteigen zu können, umreiße ich nur kurz die 4 Phasen aller Appreciative-Inquiry-Formate, den 4D-Cycle:

  1. Discover
    Finde den positiven Kern. Erinnere Dich, wann und wie schon mal etwas funktioniert hat, worauf sich aufbauen ließe.
  2. Dream
    Träume! (wie Martin Luther King – dazu später mehr)
  3. Design
    Dein Umfeld fällt nicht vom Himmel, es ist „designt“. Welche Stellschrauben gibt es hier bei uns? Welche „Stakeholder“?
  4. Deliver
    Nachdem Du Träume und Designmöglichkeiten dazu entwickelt hast: was wäre eine kleine Innovation, die Du mit ein paar Leuten anpacken willst? Wie sieht der Zeitrahmen aus?

Der Zyklus bietet eine schöne Alternative zu den klassischen Phasen einer Retrospektive (Bühne vorbereiten; Daten sammeln; Erkenntnisse gewinnen; entscheiden, was getan wird; runder Abschluss).

Ich bitte die Teilnehmer, sich selbst in Vierergruppen zu organisieren, die jeweils am selben affirmativen Thema interessiert sind.

1. Discover

In jeder Vierergruppe finden sich jeweils zwei Interviewpartner zu einem Paar zusammen. Jeder interviewt den anderen und verwendet dazu die drei Fragen auf dem Arbeitsblatt. Ich bitte die Teilnehmer, die Fragen wirklich wörtlich genau wie aufgeschrieben zu stellen – und in sich hineinzuhorchen, falls sie und warum sie die Fragen selber anders gestellt hätten.

2 Minuten für jede der drei Fragen, nach 6 Minuten also Seitenwechsel. Die nächsten 12 Minuten glaube ich, direkt neben einem Bienenstock zu stehen! Ob die Teilnehmer tagsüber, im Büro, mit den Kolleginnen und Kollegen ebenso produktiv und anregend miteinander über ihre Arbeit reden? Ich hoffe es!

Die drei Interviewfragen repräsentieren drei Fragetypen:

  1. „backward“ – frage nach wahren, konkreten Erfolgsgeschichten (nicht nach Theorien oder einstudierten Statements);
  2. „inward“ – frage, was jemand aus seiner Geschichte für sich persönlich, für das Teamwork oder gar für’s Leben gefolgert hat;
  3. „forward“ – frage, an welchen Dingen jemand eine bessere Zukunft überhaupt erkennen würde, wenn sie ohne sein Wissen, wie ein Wunder, über Nacht einträte.

Was aus den Antworten des Interviewpartners hat besonders elektrisiert, bei den „backward“ und „inward“-Fragen? Ich bitte die Teilnehmer, ihrer Vierergruppe für jeweils 3 Minuten dazu etwas zu erzählen. Jeder hört seine eigene Geschichte, aus fremdem Mund. Der Bienenstock summt wieder, für 12 Minuten.

Appreciative Inquiry ermutigt dazu, solche Geschichten, kleine Erinnerungsstücke und anderes dazu als „Positive Core Map“ zusammenzustellen: als Collagen, Interviewfilme oder in anderer Form. Ich habe eine Doku-Box mitgebracht und bitte die Teilnehmer, am Ende Ihre Interviewnotizen rein- statt wegzuwerfen. Ein paar Tage später werde ich sie scannen und für die Teilnehmer als PDF-Datei zusammenstellen. Außerdem fotografieren Martin und ich natürlich mit.

2. Dream

Dream-Kriterien

Wie träumt Martin Luther King?

Ich habe einen Traum: dass meine vier kleinen Kinder in einer Nation leben, in der man sie nicht nach ihrer Hautfarbe, sondern nach ihrem Charakter beurteilt.

Das ist ein vollständiger Satz, kein Stichwortgestammel. Es ist wünschenswertfür alle seine Zuhörer, nicht nur für ihn. Es ist formuliert, als wär’s schon Realität. Und es bringt eine echte Herausforderung für den Status Quo auf den Punkt.

Ich bitte die Teilnehmer, ihrer Vierergruppe für jeweils 3 Minuten zu erzählen, was ihr Interviewpartner auf die „Forward“-Frage geantwortet hat: an welchen Dingen würde man überhaupt erkennen, dass über Nacht ein Wunder geschehen ist? Jeder hört seine eigene Antwort, aus fremdem Mund. Der Bienenstock summt wieder, für 12 Minuten.

Die Vierergruppen bekommen dann 5 Minuten, um Ihren Traum für den Agile Monday zu formulieren, der den Kriterien auf dem abgebildeten Flipchart genügt.

Anschließend werden alle Träume zu einer Galerie aufgehängt, und jeder hat etwas Zeit, alle Träume kennen zu lernen.

3. Design

Design Possibility Map

Wir lösen die Vierergruppen auf – jeder arbeitet mit und an dem Traum weiter, der ihn am meisten anspricht. Die Flipcharts mit den Träumen werden zu „Design Possibility Maps“:

  • im Zentrum der Traum;
  • im ersten Kreis darum genug Platz, um per Brainstorming auf kleinen Klebezetteln mögliche Designelemente zu sammeln: welche Skills, Orte, Strukturen, Gelder, Absprachen, … können genutzt / eingerichtet / definiert / gestaltet werden, um dem Traum näher zu kommen?
  • im zweiten Kreis darum genug Platz für ein weiteres Brainstorming: wer sind die Stakeholder des Traums? Wer muss mit ins Boot? Wen wird unser Traum etwas angehen (und dabei hoffentlich auch anstecken)?

Nach 10 Minuten hängen 5 umfangreiche Design Possibility Maps als Galerie an den Wänden.

Jeder bekommt 10 grüne Klebepunkte und 10 weitere Minuten, um auf einem Rundgang Feedback zu geben: welche Designelemente hätten Deiner Meinung nach den größten Effekt? Hier zählt nur die Rückmeldung – es wird nichts dazu entschieden, was später getan wird. Oder ob überhaupt.

4. Deliver

Innovationenparade

Von Geschichten über Träume sind die Teilnehmer jetzt also bei konkreten Designmöglichkeiten für den Agile Monday angekommen.

Zeit, dass etwas daraus wird! Welche kleine Innovation fällt Dir zu Deinem Lieblingstraum ein? Wechsle ruhig zu einem anderen Traum, wenn Du beim Rundgang einen für Dich attraktiveren gefunden hast!

Ich verteile Zettel an die Teilnehmer und bitte sie, je nach Lust allein oder mit anderen zusammen eine kleine Innovation zu formulieren:

  • was ist die Kernidee?
  • welchem Zeitrahmen stellst Du Dir dafür vor?

Nach 5 Minuten stehen 11 Leute Schlange, um ihre Innovationsidee vorzustellen und Mitstreiter zu suchen.

Jeder Zettel hat am unteren Ende eine noch leere Liste für die Mitstreiter, die sich in den kommenden Minuten mit Namen und Emailadressen füllt. Überall im Raum stehen kleine Grüppchen herum und diskutieren schon engagiert (und LAUT!) über erste Schritte.

Schlussrunde

Das Fazit der Teilnehmer fällt sehr positiv aus – manche freuen sich besonders darüber, dass man Appreciative Inquiry ganz offensichtlich auch noch mit zwei Dutzend Leuten sehr effizient nutzen kann (für den einzelnen Facilitator ist bei 30-40 Leuten Schluss; die Methode skaliert auf bis zu 1.000 Teilnehmer – da sind dann Vorbereitungsgruppen und ein Team von Facilitators gefragt).

Ein Teilnehmer befürchtet, dass seine Kollegen 2 Stunden auch schon bei herkömmlichen Retrospektiven als viel zu lang empfinden. Meine Antwort: das einzig relevante Erfolgskriterium für eine Retrospektive ist, ob eine Gruppe dabei Ihre Fähigkeit zur Selbstorganisation (zum Selbstmanagement?) beweist: erarbeitet sie relevante Verbesserungsaktivitäten? Und vor allem: wird aus denen zeitnah auch etwas? Falls dazu 10 Minuten Retrospektive genügen – macht das ruhig so. Falls die Anwesenden aber nur nach 10 Minuten einnicken und sich aus dem Raum ganz weit weg wünschen, deutet das vermutlich auf etwas Anderes hin als auf ein Problem mit der Dauer.

Probleme fallen übrigens keinem Tabu oder Schweigegelübde zum Opfer. Wie Insoo Kim Berg, eine Begründerin der Solution-Focused Brief Therapy (SFBT) es formuliert hat:

Just because I am solution focused does not mean that I am problem phobic.

Probleme zu besprechen ist kein Problem. Aber wenn Du Probleme als Endstation betrachtest, dann hältst Du den Stein und Deinen daran verstauchten Zeh für wichtiger als das Ziel, zu dem Du auf dem Weg bist. Reinen Problem-Talk halte ich weder für professionell noch für zielführend. Er füllt nur bequem die Agenda, ohne dass man auch nur eine Sekunde über den Zweck hinter der Agenda nachdenken müsste.

Frag Dich also immer: wo will ich denn eigentlich hin?

Ein toller Abend – danke an alle Teilnehmer, die Organisatoren Martin, Sven und René und den Coworking Space Nürnberg für den Denk-Raum!

Materialien zum Download: Dossier Appreciative Inquiry und Solutions Focus, AI Retrospektive Agile Monday

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?

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