9 Fragen, die Scrum Master und Product Owner stellen sollten
Bevor ich Scrum Master wurde, arbeitete ich als technischer Leiter mit einer Vielzahl von Teams. Ein Teil dieses Jobs war es, Entscheidungen zu treffen – und ich glaube ich habe das recht gut gemacht. Entschlussfreudigkeit und Durchsetzungsvermögen gehören nun mal zu meinen Charaktereigenschaften.
Diese Eigenschaften halfen mir jedoch nicht wirklich weiter als ich Scrum Master wurde. Ich merkte, dass ich, um als Scrum Master erfolgreich sein zu können, weniger Behauptungen aufstellen und stattdessen mehr Fragen stellen musste. Weil das nicht meinem natürlichen Stil entsprach (und dies eben nicht die Eigenschaften waren, die mir bis zu diesem Punkt in meiner Karriere Erfolg gebracht hatten), fiel mir das zu Anfang schwer.
Aber mit etwas Geduld wurde ich immer besser im Fragen stellen. Einige meiner Lieblingsfragen
möchte ich gerne mit Ihnen teilen. Die meisten Fragen gelten sowohl für Scrum Master als auch für Product Owner.
2 Fragen zu Einschätzungen
Häufig benötige ich eine grobe Einschätzung von einem Team. Ich werde sie nicht darauf festnageln. (Ich frage hier nicht nach einem Commitment. Einschätzungen und Commitments sind nicht das Gleiche.) Ich möchte wirklich nur eine grobe Einschätzung. In diesem Fall ist dies eine gute Frage:
"Ich brauche keine Einschätzung. Aber wenn ich nach einer Einschätzung fragen würde, welche Einheit würde euch dann in den Sinn kommen? Stunden, Tage, Wochen, Monate oder Jahre?"
Ja ich weiß, diese Einheiten können sich überschneiden – einige Wochen können mehr als ein Monat sein. Aber eine Einschätzung wie „Oh, Wochen, ein paar Wochen.” ist häufig gut genug, um eine Entscheidung treffen zu können, was auch heißen kann, die Entscheidung zu treffen, das Team zu bitten, die Arbeit etwas genauer einzuschätzen.
In Situationen, in denen ich eine offizielle Einschätzung von einem Team habe, stelle ich häufig eine weitere Frage:
"Wie sicher seid ihr euch mit der Einschätzung?"
Hier möchte man herausfinden, wie sicher die Einschätzung ist und ob sich die Teammitglieder darüber einig sind. Eine Einschätzung bei der sich das Team zu 90% sicher ist, wird genauer sein als eine Einschätzung, bei der sich das Team insgesamt nicht sehr sicher ist und bei der die Meinungen stärker auseinander gehen.
Unstimmigkeiten innerhalb des Teams in Hinblick auf die Einschätzung können außerdem ein Indikator dafür sein, dass das Team zu voreilig diese Einschätzung abgegeben hat. Das muss nichts Schlimmes sein, aber es sollte einem bewusst sein, dass die Einschätzung dann nicht so sicher ist.
3 Fragen zu Teamentscheidungen
Als Scrum Master oder Product Owner möchte man manchmal gerne ein Gefühl dafür bekommen, wie gründlich das Team über eine Entscheidung nachgedacht hat. Hier sind drei Fragen, die ich häufig stelle:
- "Welche drei anderen Optionen habt ihr in Erwägung gezogen, bevor ihr die Entscheidung getroffen habt?"
- "Was wäre das Schlimmste, was passieren könnte, wenn wir weiter in diese Richtung gehen?"
- "Was muss gut laufen, damit dies wirklich die beste Entscheidung ist?"
Man sollte vielleicht nicht alle drei Fragen auf einmal stellen und auch nicht dieselben Fragen bei jeder einzelnen Entscheidung des Teams.
Außerdem stellen Sie als Scrum Master oder Product Owner nicht diese Fragen, weil Sie die Entscheidung des Teams revidieren können. Allerdings haben Sie das Recht, zu verstehen, wie sicher sich das Team mit der Entscheidung fühlt und ob sie sich bei der Entscheidung einig waren.
Diese Fragen sollen derartige Unstimmigkeiten aufdecken. Wenn man fragt „Was muss gut laufen, damit dies wirklich die beste Entscheidung ist?” und jemand sagt „Alles!”, bedeutet das meist, dass es ein Problem gibt.
2 Fragen zu Meetings
Ich mag Meetings nicht wirklich. Wenn ich in einem Flur stünde, an dessen einem Ende ein Haufen Schlangen wäre und am anderen Ende ein Meeting, wüsste ich nicht, in welche Richtung ich laufen würde.
Daher versuche ich möglichst, die Anzahl der Meetings sowie die Anzahl der Teilnehmer der Meetings auf ein Minimum zu reduzieren. Zu Beginn eines Meetings stelle ich häufig folgende Fragen:
- "Brauchen wir jeden, der gerade hier ist?"
- "Wer sollte noch anwesend sein?"
Die erste Frage wird gestellt, um herauszufinden, ob man auf die ein oder andere Person verzichten kann. Ich sehe oft agile Teams, die es mit dem Teamwork und der Zusammenarbeit etwas zu gut meinen. Die Teammitglieder haben dann das Gefühl, dass sie an jedem Meeting teilnehmen müssen, auch wenn es für sie völlig irrelevant ist. Das kann zum Beispiel der JavaScript-Entwickler sein, der an einem Meeting teilnimmt, in dem es darum geht, ob es sich lohnt, auf das neue Update des Datenbankanbieters umzustellen.
Wenn die Mitglieder Ihres Teams etwas übereifrig sind, was Meetings angeht, sollten Sie ihnen dafür danken, dass sie sich so für die Zusammenarbeit einsetzen, aber ihnen gleichzeitig auch vermitteln, dass sie nicht bei jedem Meeting dabei sein müssen. Erstellen Sie die Regel, dass kein Teammitglied an einem Meeting teilnehmen sollte, wenn derjenige nicht genug zu dem Meeting beitragen oder daraus nicht genug Wert schöpfen kann.
(Ja, das kann ausgenutzt werden. Unter Umständen müssen Sie einigen Leuten klar machen, dass das nicht bedeutet, dass sie an keinem Meeting mehr teilnehmen müssen. Am Ende sollte das Team als Ganzes das Recht haben, die Entscheidung einer einzelnen Person, nicht zu einem Meeting zu kommen, zu überstimmen.)
Mit der zweiten Frage will man dementsprechend herausfinden, ob jemand anwesend sein sollte, der noch nicht dabei ist. Auch wenn ich Meetings hasse (ich würde wahrscheinlich die Schlangen bevorzugen), müssen wir manchmal mehr Leute in den Meetings haben.
Entscheiden Sie sich im Zweifel für zu wenige Meetings und zu wenige Leute, aber einige Meetings sollten einfach durchgeführt werden – und diese Meetings sind noch wertvoller, wenn die richtigen Leute dabei sind.
1 Frage für’s Umherlaufen im Büro
Besonders wenn ich als Scrum Master arbeite, verbringe ich viel Zeit damit, mich an Konversationen im Büro zu beteiligen. Das ist auch bekannt als Management by Wandering Around (dt.: Management durch Umherlaufen). Wenn ich beispielsweise mitbekomme, wie ein Programmierer und ein Tester eine scheinbar wichtige Konversation haben, gehe ich manchmal zu ihnen und schaue, ob ich ihnen mit irgendetwas helfen kann.
(Das sollte man natürlich nicht jedes Mal machen und auch nicht, wenn es wie eine private Unterhaltung aussieht!)
Manchmal sind die Unterhaltungen, die ich zufällig mitbekomme, auch für andere Leute wertvoll. Vielleicht sollte der Technische Redakteur darüber Bescheid wissen, was der Tester und der Programmierer entschieden haben. Daher frage ich:
- "Sollte noch jemand darüber Bescheid wissen?"
Wenn das der Fall ist, biete ich an, diese Informationen zu teilen, wenn mir das möglich ist. Wenn nicht, biete ich an, die entsprechende Person direkt dazuzuholen.
1 Frage für Daily Standups
Im Daily Standup schaue ich mir das Burndown Chart des Teams an und frage mich dann häufig, wie das Team alle Arbeiten bis zum Ende des Sprints fertigstellen will. Wenn ich dieses Team dann aber frage, ob sie wohl alles schaffen werden, sind sie in der Regel sehr optimistisch.
Wenn ich dies für unrealistisch halte, schaue ich mir erneut das Burndown Chart an und frage:
- "Wisst ihr etwas, was ich nicht weiß?"
Vielleicht erhalte ich als Antwort, dass eines der Teammitglieder seine Stunden noch nicht im Team-Tool auf den aktuellen Stand gebracht hat. Oder jemand erklärt, dass sie zwar aktuell etwas hinterherhinken, aber einiges dazugelernt haben und sich gerade alles wieder beschleunigt. (Ich halte so etwas selten für realistisch, höre es aber oft.)
Das Team zu fragen, was sie wissen und ich nicht, bietet eine großartige Chance, Annahmen zu synchronisieren. Vielleicht nehmen sie an, dass sich jetzt wieder alles beschleunigen wird, ich denke das jedoch nicht. Daher ist es eine tolle Frage, unterschiedliche Annahmen aufzudecken.
Fazit: Fragen sind besser als Behauptungen
Als ich zum ersten Mal die Rolle des Scrum Masters übernahm, wusste ich noch nichts über die Macht der Fragen und verpasste viele Gelegenheiten, mehr über mein Team und deren Arbeit zu lernen. Erst nach einer ganzen Weile fand ich heraus, dass ich am meisten lernen kann, wenn ich Fragen stelle und den Antworten wirklich zuhöre.
Ich hoffe, dass Sie diese Fragen genauso hilfreich finden wie ich.
Dieser Beitrag stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.