Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Sich zu verstehen ist auch Teamarbeit – ein Warm-up für das Sprint Planning

Mit einer anderen Person zu sprechen, dieser etwas mitzuteilen, sich mit ihr zu unterhalten, sich argumentativ auszutauschen, hat häufig zum Ergebnis, dass die beiden Gesprächspartner auseinandergehen und genauso klaffen ihre Bilder der Situation vollkommen auseinander. Bereits im Kindergarten machen wir beim Spielen erste Erfahrungen mit dieser Kommunikationsprämisse. Jedes Kind kennt „Stille Post“. Ein Kind flüstert einem zweiten eine Botschaft ins Ohr. Das zweite Kind gibt das, was es gehört bzw. verstanden hat, an ein drittes Kind weiter. Die Nachricht wird bis zum letzten Empfänger weitergegeben. Was am Ende der Kommunikationskette rauskommt, lässt die Spieler meistens in schallendes Gelächter ausbrechen. Denn es ist inhaltlich etwas vollkommen anderes als das, was kurz zuvor auf die Reise geschickt wurde. In der Kinderwelt ist es einfach ein lustiges Spiel. In der Kundenwelt und im Management von Wünschen und Anforderungen ist es ein Graus und trägt oftmals zu Missverständnissen und Fehlschlägen bei.

Der Anspruch zu „verstehen, was der Kunde haben möchte“ und die sich daraus ableitende Forderung „sicherzustellen, dass er genau das auch bekommt“ (Colin Hood, Experte Systems Engineering) sind hoch – insbesondere dann, wenn wir uns vor Augen führen, was es bedeutet, einen Anderen (in diesem Fall den Kunden) zu verstehen.

„Verstehen hat seinen eigentlichen Ort in menschlichen Gesprächen. Sofern wir eine Sprache zu sprechen gelernt haben, wissen wir (…) zu unterscheiden, ob wir jemanden verstanden zu haben glauben, oder ob wir, was jemand gesagt hat, verstanden haben, wenn er oder sie uns etwas mitteilt (das ist die Grammatik des Ausdrucks mitteilen: jemand teilt jemandem etwas unter Verwendung von Mitteln mit). Und wir sagen dann, wir  hätten ihn oder sie verstanden, wenn wir nicht nur das Gesagte (den ‚Inhalt’, die Proposition), sondern auch die bestimmte Art und Weise, in der uns jemand etwas mitteilt, richtig aufgefasst haben, und das heißt zunächst: Wenn unsere Auffassung unwidersprochen bleibt. In metaphorischer Annäherung: Wir haben verstanden, wenn wir sagen können, dass wir das, was uns jemand mitgeteilt hat, miteinander teilen. Wir beurteilen unser Miteinander-Sprechen  dann unter Verwendung des Ausdrucks ‚verstehen’, wenn wir, was und wie mitgeteilt wurde, gemeinsam haben.“  (Jan Müller, 2008)

Richtig verstehen und richtig weitergeben

Ein Product Owner ist bei der Erstellung seines Product Backlogs für das Erfassen der Kundenbedürfnisse und die Beschreibung der damit verbundenen Anforderungen verantwortlich. Um dies im Sinne des Kunden angemessen leisten zu können, gehört es zu seinen Aufgaben, die Bedürfnisse der Kunden, Enduser und anderer Interessenvertreter richtig zu verstehen und kontinuierlich zu bearbeiten. Verstehen zu wollen, was ein Kunde haben möchte, ist allerdings alles andere als einfach (und das nicht nur aufgrund des oben beschriebenen Verständnisses von „Verstehen“). Oft spricht man mit den falschen Personen, nicht selten weiß der Auftraggeber gar nicht, was er wirklich will oder der Kunde teilt uns bereits Lösungen mit, anstatt Anforderungen zu beschreiben. In jedem dieser genannten Fälle erhöht sich das Risiko, dass die Entwicklung eines Produktes in die falsche Richtung läuft und so eine „falsche“ Lösung gebaut wird. Der Product Owner besitzt hoffentlich die Kraft der Unterscheidung und lässt es in die Anforderungen einfließen, die er schließlich an sein Entwicklungsteam kommuniziert.

Ist euch was aufgefallen? Wer genau gelesen hat, wird feststellen, dass das Aufgabenspektrum des Product Owners eine große Ähnlichkeit mit dem Stille-Post-Spiel hat. Der Kunde sagt dem Product Owner, was er will. Der PO überführt diese Wünsche in sein Product Backlog. Den wichtigsten und am höchsten priorisierten Ausschnitt des Backlogs bringt der Product Owner zum Entwicklungsteam ins Sprint Planning und dort wird dann geplant, was und wie die Anforderungen (übersetzt in User Stories) umgesetzt werden sollen. Wohl dem, der jetzt weiß, wie man richtig versteht. 

Ich habe eine gute und eine weniger gute Nachricht. Die weniger gute Nachricht ist, dass das mit dem Richtig-Verstehen nicht leicht ist. Das kann ich euch mit diesem Beitrag lediglich bewusst machen (Erkenntnis als erster Schritt der Verbesserung). Die gute Nachricht allerdings ist, dass es etablierte Mittel und Methoden gibt, das Richtig-Verstehen zu üben und besser darin zu werden.

Sprach-Übungsfeld Baustelle

Eine spielerische Methode möchte ich euch vorstellen. Oft scheitert Kommunikation, weil zu viel Information auf einmal weitergegeben wird und/oder nicht die gleiche Sprache gesprochen wird. Sprache ist ein nicht genormtes Ausdrucksmedium! Jeder Mensch ist in der Verwendung von Sprache von seiner (Alltags-)Umwelt, seinem fachlichen Hintergrund, seinen sonstigen Kenntnissen und seinen persönlichen (Lebens-)Erfahrungen geprägt. Sprache bringt das alles individuell zum Ausdruck. Missverständnisse in der Kommunikation sind quasi vorprogrammiert und nahezu unvermeidlich. Ein Widerspruch in sich: Es geht (scheinbar) nicht mit, aber (wohl auch nicht) ohne Kommunikation! Um sich dieses Dilemma vor Augen zu führen und am eigenen Leib zu erleben, empfehle ich, das Planspiel „Auf der Baustelle“ vor einem Sprint Planning Meeting auszuprobieren. Es wird euch Augen und Ohren öffnen – versprochen!

Auf der Baustelle – die Aufgabe und die fünf Rollen

Die Aufgabe ist es, mit verteilten und klar definierten Rollen ein Lego-Modell nachzubauen. Die fünf Rollen sind

  • der Informant,
  • der Baumeister,
  • der Rückmelder,
  • der Bote und
  • der Materialverwalter.

Der Informant

Der Informant sieht das Modell und beschreibt es dem Boten. Er hat Kontakt zum Boten und zum Rückmelder.

Der Bote

Der Bote gibt die Informationen, die er vom Informanten erhält, an den Baumeister weiter. Er sieht weder das Modell noch den Nachbau des Baumeisters. Er hat Kontakt zum Informanten, zum Baumeister und zum Rückmelder.

Der Baumeister

Der Baumeister (Product Owner) baut nach den Informationen des Boten das Modell nach. Die dazu benötigten Teile besorgt er sich beim Materialverwalter. Er hat Kontakt zum Boten, zum Materialverwalter und zum Rückmelder.

Der Materialverwalter

Der Materialverwalter gibt dem Baumeister die Steine, die er anfordert. Er sieht weder das Modell noch den Nachbau des Baumeisters. Er hat Kontakt zum Baumeister und zum Rückmelder.

Der Rückmelder

Der Rückmelder darf sowohl das Modell wie auch den Nachbau sehen. Er hat Kontakt zu allen anderen. Seine Kommunikation beschränkt sich jedoch darauf, dass Fragen, die ihm gestellt werden, nur mit JA oder NEIN beantworten darf. Jede weitere Äußerung ist ihm untersagt.

Die Planung

Die Planungsphase dauert vom Zeichen „Start“ an 15 Minuten. Entscheidet ein Team, vor Ablauf der Zeit mit der Planung fertig zu sein, kann es früher mit dem Bau beginnen. Folgende Anweisungen sind in der Planungsphase vom Team umzusetzen:

  • Entscheidet gemeinsam, wer welche Rolle in der Gruppe übernimmt.
  • Überlegt, wie ihr bei der Lösung der Aufgabe vorgehen wollt und worauf besonders zu achten ist.
  • Zeigt dem Spielleiter (z.B. ScrumMaster) an, wenn eure Planung abgeschlossen ist.
  • Ihr habt 30 Minuten Zeit, das Modell nachzubauen.

Die Zutaten

  • Teilnehmerzahl:   5
  • Beobachter: beliebig viele
  • Zwei Lego Modelle (ein fertig gebautes und eines in seine Einzelteile zerlegt)
  • mindestens zwei Räume
  • Rollenschilder (Bote, Informant, Materialverwalter, Baumeister, Rückmelder)

Tipps zur Durchführung

  • Händigt dem Materialverwalter das Lego Material aus (Tisch als Auflage). Ermöglicht dem Informanten und dem Rückmelder Zugang zum fertigen Modell.
  • Auf Nachfrage wird allen Team-Mitgliedern – außer dem Rückmelder – erlaubt, sich Notizen und/oder Skizzen zu machen. Diese dürfen gezeigt, aber nicht weitergegeben werden.
  • Wenn ihr mehr als fünf Teilnehmer habt, dann könnt ihr Beobachter einteilen, die als „Schatten“ mit den jeweiligen Spielern mitlaufen und Feedback geben sollen.
  • Gebt alle 5 Minuten die Zeit an.

Nach dem Spiel ist vor dem Spiel – Fragen für ein After Action Review

  • Was wurde in der Planungsphase besprochen?
  • Wie hat sich die Teamkonstellation in der Planungsphase ergeben?
  • Wie habe ich mich in meiner Rolle gefühlt?
  • Wie gut konnte ich die Anfragen meiner Gesprächspartner umsetzen?
  • Wie leicht/schwer war es, Informationen weiterzugeben bzw. aufzunehmen?
  • Wie stark wurde der Rückmelder eingebunden? Was hat sich im Verlaufe des Spiels dabei verändert?
  • Was lief gut?
  • Warum wurden wir fertig/nicht fertig?
  • Was würde ich JETZT anders machen?
  • Welche Erkenntnisse habe ich für das Schreiben meiner Userstories gewonnen?
  • Welche Erkenntnisse habe ich für die Sprint Plannings gewonnen?

 

Viel Erfolg beim besseren Verstehen! 

Literatur

Peter Dürrschmidt et. al. Methodensammlung für Trainerinnen und Trainer. 2009. managerSeminare.