Global Scrum Gathering London 2018

Global Scrum Gathering London 2018: Teil 1 – Teams, ScrumMaster und Product Owner

Nach meiner Premiere im letzten Jahr, habe ich dieses Jahr wieder das europäische „Global Scrum Gathering“ besucht. Wieder war es unglaublich inspirierend, auch wenn keiner der Beiträge auch nur annähernd an Abschlussrede von Lyssa Adkins herangereicht hat. Nichtsdestotrotz möchte ich die Highlights der Sessions, an denen ich dieses Mal teilgenommen haben, mit Euch teilen. Wie schon bei meinem letzten „Global Scrum Gathering“-Erfahrungsbericht gibt es weiterführende  Informationen und Links zum Thema.

Dieser Blogpost behandelt hauptsächlich die Teams, ScrumMaster and Product Owner Kategorie, während der zweite Post (Global Scrum Gathering London 2018 Teil 2) sich auf Kultur, Werte, Führung und Skalierung konzentrieren wird.

Ich fange damit an, die Angst vor Zurückweisung zu überwinden, während man Fragen stellt. Eine Sache derer ich mir gerne schon in Jahr 2 meiner ScrumMaster-Karriere bewusst gewesen wäre. Interkulturelle Aspekte von Teams habe ich sehr früh kennen gelernt. Trotzdem wächst ihre Bedeutung rasant, insbesondere in unseren modernen, meist internationalen Arbeitsumgebungen. Der dritte Beitrag war unheimlich wertvoll für mich, da ich häufig Meetings und Workshops moderiere, oder auf andere Weise Zusammenarbeit fördere: Von den Core Protokollen zu erfahren und direkt damit einzusteigen war großartig!

Zu guter Letzt schreibe ich noch über den Höhepunkt der Konferenz für Product Owner: Jeff Pattons Workshop hilft mir sehr dabei, Product Owners in ihrer Arbeit zu unterstützen.


Was ich in 100 Tagen Zurückweisung gelernt habe – Jia Jiang

Bessere ScrumMaster ausbilden

Wir starten mit einer der zwei Grundsatzreden von Tag 2: Zurückweisungs-Therapie mit Jia Jiang. Sein Einstieg war eine nette (aber unheimlich traurige) Anekdote über Zurückweisung in der Schulzeit. Über Inspiration durch Bill Gates kamen wir auf Jias Wunsch, selbst Unternehmer zu werden. (Ganz nebenbei: Meldet Euch für Bill Gates‘ newsletter an! Hier! Jetzt!) Jia musste die gesamte Zeit mit Zurückweisung zurecht kommen. Um selbst besser damit umzugehen, hat er mit einer „Therapie“ angefangen, die er selbst „Zurückweisungs-Therapie“ genannt hat: 100 Tage, 1 Herausforderung pro Tag von kleinen Gefallen bis zu richtig verrückten Bitten. Alles ist auf Youtube; klickt Euch durch, klickt auf das Video und dann sucht einfach nach einer anderen Nummer.

Hauptaspekt der Rede war, dass wir oft nicht berücksichtigen, was der Gefragte möchte, während wir selbst eine Frage stellen. Ein weiterer Rat war, nach einer Zurückweisung um einen zweiten Gefallen zu bitten. Die meisten Menschen stehen dem sehr aufgeschlossen gegenüber, weil sie sich nach der ersten Ablehnung verpflichtet fühlen, Eure Bitte zu erfüllen.

Das beste Zitat:

Fragt einfach! Wenn ihr nicht fragt, weist ihr Euch schon selbst zurück! Seid furchtlos*!

*nicht schamlos

SGLON18 sketch notes - Power of Rejection

Als ScrumMaster ist das ein überaus wichtiger Aspekt der Arbeit mit Teams. Wir wollen Dinge verbessern. Oft werden unsere Vorschläge abgelehnt. Sollten wir deshalb aufhören, zu fragen? Natürlich nicht! ScrumMaster sollten kontinuierlich nach Verbesserung streben:

  • an sich selbst (schwierig, aber immerhin wenig Zurückweisung)
  • Teams (schwieriger, da die Kollegen einige unserer Ideen zurückweisen könnten)
  • Unternehmen (am schwierigsten, weil wir hier auf erbitterten Widerstand treffen)

Fragt einfach!


Der kulturelle Faktor in Scrum Teams – Fabian Schwartz

Bessere ScrumMaster ausbilden

Der Titel von Fabian Schwartz‘ Session war ein wenig irreführend: Es ging weniger um Teamkultur, wie ich erwartet hätte, sondern eher über (inter!)kulturelle Faktoren von Teams. Wir haben Hofstedes Kulturdimensionen kennen gelernt

Niedrige Machtdistanz PDI Hohe Machtdistanz
Kollektivismus IDV Individualismus
Feminität MAS Maskulinität
Niedrige Ungewissheitsvermeidung
UAI Hohe Ungewissheitsvermeidung
Langfristige Ausrichtung LTO Kurzfristige Ausrichtung
Beherrschung IVR Nachgiebigkeit

und insbesondere wie (hohe) Machtdistanz Produktivität verringert während (hoher) Individualismus Produktivität erhöht. Auf einer Glockenkurve sind multikulturelle Teams sowohl die effektivsten als auch die ineffektivsten. Am wenigsten effektiv sind sie, wenn kulturelle Unterschiede Zusammenarbeit behindern. Sobald diese Unterschiede akzeptiert (und sogar genutzt!) werden, was eine der Aufgaben eines ScrumMasters ist, werden diese Teams die effektivsten.

Es folgte ein schneller Übergang zu Arbeitsethos, nicht als interkultureller Faktor, sondern schlicht als wichtiger Faktor guter Teams. Mit einem einfachen Beispiel hat Fabian Schwartz gezeigt, wie wichtig es ist Trittbrettfahrer-Probleme (free rider) zu adressieren:

∅ Performance Trittbrettfahrer Durchschnitts-Performer Leistungsträger
3 1 3 5
2.7 1 3 4
2.2 1 2.7 3

Nach und nach, wenn das Problem nicht angegangen wird, werden Trittbrettfahrer die Gesamtleistung eines Teams verringern. Zuerst leidet die Performance der Leistungsträger, dann verringert sich die Durchschnitts-performance und damit auch die Leistung des (bis dahin zufriedenstellenden) Durchschnittsmitarbeiters.

Ich habe früher schon (eine) ähnliche Erfahrung gemacht. Wir sind als Team und Firma das Thema angegangen und haben es gelöst: Am Ende waren alle zufrieden (inklusive des Trittbrettfahrers, der sich in Folge selbständig gemacht hat). Die Leistung des Teams war ohne ihn sogar gestiegen!

Ich halt nach wie vor nicht viel von den Lösungsansätzen großer Beratungsfirmen, sich regelmäßig von den „ineffektivsten“ 20% der Belegschaft zu trennen. Aber innerhalb von Teams muss man diese Probleme lösen. Insgesamt war dieser Beitrag echt gut: Ich konnte vieles nachempfinden, habe etwas gelernt und wir alle haben eine Buchempfehlung bekommen →

SGLON18 sketch notes - Cultural Factor in Scrum Teams


Hochperformante Teams: Core Protokolle für Psychologische Sicherheit und Emotionale Intelligenz – Richard Kasperowski

Bessere Teams formen

Richard Kasperowski hat seine Session mit einer Frage ans Publikum begonnen: Beschreibt mit einem Wort das beste Team mit dem ihr je gearbeitet habt. Mit großer Mehrheit war dieses Wort: Vertrauen.

In Folge führte er uns durch die meines Erachtens beste Session dieses Scrum Gatherings, denn

  • es war inspirierend (ja, andere waren auch inspirierend)
  • erkenntnisreich (ja, in anderen Sessions habe ich auch etwas gelernt)
  • sofort umsetzbar (Die Core Protokolle konnte ich direkt in einem Offsite 2 Wochen nach der Konferenz einsetzen!)

In aller Kürze: Die Core Protokolle sind ein einfaches Regelwerk bzw. Sammlung einfacher Methoden, um in einem Team/einer Gruppe eine „Aufwärtsspirale“ besserer Zusammenarbeit zu erzeugen:

Positive Voreingenommenheit → Freiheit → Check in → Personal Ausrichtung → Nachforschen → wiederholen

Mit positiver Voreingenommenheit eine Aufgabe zu delegieren führt bei demjenigen, der die Aufgabe ausführt zu einem Gefühl der Freiheit. Dann einen Check in zu machen: Wie geht’s? Welche Hindernisse gibt es und welche Gefühle erzeugen diese, erleichtert die gemeinsame Ausrichtung. Dann bei Hindernissen die Ursachen zu ergründen und die Lösung wiederum zu delegieren startet den Zyklus erneut. So sieht moderne Führung aus.

SGLON18 sketch notes - Core Protocols for Psychological Safety and Emotional Intelligence

Wer mehr darüber lesen möchte: Kasperowski hat ein Buch über die Core Protokolle geschrieben, welches ich auf meine Leseliste gesetzt habe (die nicht-öffentliche „zu lesen“ Liste). Für Anfänger wie mich, sind schon die Originalquellen von den McCarthy’s eine große Hilfe! Edit: Der Link funktioniert mittlerweile nicht mehr. Hier ist eine neue gute Quelle.


Sei ein ausgeglichener Produkt-Anführer, kein Featurevermittler oder Produkt-Diktator – Roman Pichler

Bessere Product Owner ausbilden

Nach SGDUB17 war dies die zweite Session, die ich von Roman Pichler gesehen habe. Anders als die erste hat mich diese nicht sehr beeindruckt. Das lag vermutlich daran, dass

  1. ich allem, was Roman gesagt hat uneingeschränkt zustimme und
  2. nichts davon neu war für mich.

Roman Pichler ist ein starker Verfechter von guter Product Ownership. Sein Beitrag hier drehte sich um die Zerrissenheit von POs zwischen dem Dasein als Feature Vermittler (weiterleiten von Anfragen der wirklich entscheidenden Leute, ohne selbst Wert zu stiften) oder dem eines Product-Diktators (der jedes kleinste Detail selbst entscheidet). Beide Extreme führen nicht zu den besten Ergebnissen. Ausgewogene Product Ownership ist der Schlüssel zum Erfolg:

  • Feature Vermittler müssen sich selbst ermächtigen
  • Product-Diktatoren müssen andere ermächtigen

Hier sind meine sketch notes:

SGLON18 sketch notes - Balanced Product Ownership


Experimentieren – Jeff Patton

Bessere Product Owner ausbilden

Jeff Patton eine Legende. User Story Mapping hat sich zur weit verbreiteten und vor allem anerkannten agile Praktik gemausert und Jeffs gleichnamiges Buch wird sogar in Product Owner Training empfohlen.

Auf diesem Scrum Gathering hielt er eine Session deren Agenda einfach nur „Experimentieren“ lautete. Nichts mehr. Nur ein Wort. Trotzdem (und völlig zu Recht) hat er ein so großes Publikum angezogen, dass der Raum schon sehr gefüllt war. Sein Rundumschlag über Produktentwicklung fing mit einem Zitat von Kent Beck an, der von der ersten User Story erzählte, der er begegnet war:

“Ich tippe die Postleitzahl ein und es füllt automatisch Stadt und Bundesland aus, ohne, dass ich noch etwas machen muss!”

Was diesen Beitrag so unheimlich wertvoll gemacht hat, war die großartige Mischung aus Lehre und Einarbeitung während das Publikum die Teilnehmer aktiv teilnahmen und in den Übungen mitgearbeitet haben.

Nicht nur der Inhalt (Product Ownership von Anfang bis Ende, das Wichtigste über User Stories), sondern auch wie er präsentiert hat, waren beeindruckend. Jeff hat gezeichnet während er erzählt hat, so dass die Teilnehmer dem Gesagten bildlich folgen konnten und zwar jeden einzelnen Schritt des Weges.

Die praktischen Übungen waren das Ausfüllen von

  1. Opportunity Canvas
  2. und dem Lernplan für diese Geschäftsmöglichkeit

Um noch einmal zu unterstreichen, wie wichtig es ist, zu lernen, was Nutzer wollen und zu lernen, wie wir Produkte bauen, für die Nutzer bereit sind etwas zu bezahlen, sagte er:

Je schneller ihr Mist baut, desto mehr Mist baut ihr. — Jeff Patton

Also lasst uns endlich aufhören, (nur!) Velocity zu messen. Lasst uns anfangen, unsere Lerngeschwindigkeit zu messen! Hier endlich mal tolle sketch notes von Jeffs Beitrag:

Weil uns am Ende die Zeit ausging (bzw. wir nicht den gesamten Umfang behandeln konnten), empfahl er uns zum Abschluss zwei Bücher zum Thema (sein eigenes Buch hat er natürlich nicht empfohlen, aber ich habe das hier hinzugefügt, der Vollständigkeit halber):


Hier ist mein gesamter „Stundenplan“ – was dieser Post nicht zusammengefasst hat, wird teil des nächsten Beitrags, also bleibt dran! Folgt mir auf Social Media oder hier.

Montag Dienstag Mittwoch
😉 What I learned from 100 Days of Rejection – Jia Jiang
Creating better ScrumMasters
Keynote: The Psychology of Creating a High Performing Culture – Damian Hughes
Creating better ScrumMasters
The Cultural Factor in Scrum Teams – Fabian Schwartz
Creating better ScrumMasters
ING’s leaders, what were they willing to give up? – Leonoor Koomen
Creating better Leaders
Be a Balanced Product Leader, Not a Feature Broker or Product Dictator – Roman Pichler
Creating better Product Owners
High-performance Teams: Core Protocols Psychological Safety and EI – Richard Kasperowski
Creating better Teams
Agile Culture: The Number One Leadership Challenge – Sabine Canditt, Rickard Jones
Creating better Leaders
Experimentation – Jeff Patton
Creating better Product Owners
Delivering a High-Performance Agile Organization – Michael Sahota
Creating better Leaders
Teal, is it time to reinvent organizations? – Tobias Mayer, Antoinette Coetzee, Simon Powers
Fishbowl
Scaling Scrum – Jeff Sutherland, John McFadyen, …
Fishbowl

Fragen? Anmerkungen, Kommentare? Lasst uns diskutieren, gerne unter diesem Post!

Facebook Kommentare

Schreib einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.