In meinen Beobachtungen des Daily Business von Scrum-Teams stoße ich in regelmäßigen Abständen auf ein interessantes, aber auch bedenkenswertes und manchmal ärgerliches Phänomen. Viele ScrumMaster kommen beim Sprint Review ihrer essentiellen Verantwortung als Meeting Facilitator, Change Agent und Servant Leader nur bedingt nach. Immer wieder erlebe ich, dass das Sprint Review vom ScrumMaster als eine Art Auszeit genutzt wird. Während der Product Owner u.a. allen Anwesenden das Sprint Goal vorstellt, in diesem Kontext die ausgewählten Backlog Items erläutert, einen Ausblick auf die nächsten Userstories in der Roadmap gibt und das Entwicklungsteam die Ergebnisse des Sprints vorstellt, sollte der ScrumMaster die vornehmliche Aufgabe verfolgen, das Sprint Review zu moderieren. Moderation ist jedoch vielschichtig und wird von so manchem ScrumMaster nur eingeschränkt oder gar nicht umgesetzt.

Bevor ich allerdings hier tiefer erkläre, was mir bei der Umsetzung durch die ScrumMaster fehlt, möchte ich noch einen Schritt zurück gehen und beleuchten, warum das Sprint Review ein so wichtiges Meeting ist.

 

Warum das Sprint Review so wichtig ist

Glaubt man Boris Gloger und seiner Meinung in Scrum – Produkte zuverlässig und schnell entwickeln zur Sprint Review, kann die „Bedeutung dieses Meetings nicht genug betont werden“ (Gloger, 2011, S. 176). Das Sprint Review dient der Statuserhebung im laufenden Projekt und soll im Wesentlichen eine Antwort auf die Frage geben, ob „das Team geliefert (hat), was es versprach“ (a.a.O.). In noch unerfahrenen Scrum-Teams und Unternehmen, die noch am Anfang ihrer agilen Organisationsentwicklung stehen, wird das Meeting häufig als Präsentation durchgeführt. Das Sprint Review ist jedoch mitnichten eine Veranstaltung, in der den anderen (z.B. Management, Customer, Anwender, Fachabteilungen, Lieferanten, etc.) lediglich via Power Point das Produkt gezeigt wird. Vielmehr dient die Review (engl. Bewertung) als Einladung, „die Funktionalität auszuprobieren“ (Gloger, 2011, S. 178). Auf diesem Weg erhofft sich das Team, Feedback zu bekommen, „neue Ideen zu generieren und neue Möglichkeiten nutzen zu können“ (a.a.O.).

 

Feedback(un)kultur

Ein Feedback zu geben, ist jedoch eine hohe Kunst. Dieser sind leider nur wenige wirklich gewachsen, was dazu führt, dass das, was an Feedback bei jenen (Entwicklungsteam) ankommt, die damit ursprünglich den Wunsch und die Hoffnung verbunden hatten, Anerkennung für die getane Arbeit im vergangenen Sprint zu erhalten und/oder ungenutzte Perspektiven aufgezeigt zu bekommen, oftmals ernüchternd, manchmal sogar erschütternd und vor allem demotivierend ist. Den Klassiker der Feedback(un)kultur vertritt in diesem Zusammenhang die Gruppe der Ja-aber-Sager. Die Ja-aber-Sager sind während einer Sprint Review leicht zu erkennen. Haltet Ausschau nach Kopfschütteln und übermotivierten Meldeversuchen (z.B. Handmeldung, die durch Fingerschnipsen verstärkt wird), die von paraverbalen Ungedulsäußerungen (z.B. Seufzen) begleitet werden und schließlich in einem Wortbeitrag münden, die mit der Einleitung „Ja, aber“ ein (aus Sendersicht) plausibles und unumstößliches Gegenargument (z.B. Befürchtung, unüberwindbares Problem, etc.) liefern. Die Reaktion auf ein „Ja, aber“ ist fast immer die gleiche: Man (das Entwicklungsteam) rechtfertigt sich und es entbrennt ein fieberhafter Wettstreit darüber, wer Recht hat. Schließlich und letztendlich ist es die abgelaufene Timebox, die Schlimmeres verhindert. Zurück bleibt ein kritisiertes und verunsichertes Entwicklungsteam.

 

Möglicherweise habe ich das Szenario ein wenig überspitzt dargestellt und es geht keineswegs darum zu sagen, dass Ja-Aber-Sager unrecht haben. Nichtsdestotrotz erlebe ich regelmäßig solche Beispiele in ähnlicher Ausprägung. Und weil ein „Ja, aber“ zu keiner Zeit ein konstruktiver oder gewinnbringender Einstieg in einen ernsthaften Fachdiskurs ist, sondern „ein erbitterter Kampf um die Unanfechtbarkeit der eigenen Meinung“ (http://www.gedankenzirkus.de/wordpress/die-ja-aber-dummschwatzer), muss es eine aktive Instanz geben, die Regeln aufstellt und Ja-Aber-Argumente nicht einfach zur Kenntnis nimmt und so ein Entwicklungsteam mit der Kritik – im wahrsten Sinne des Wortes –  im Regen stehen lässt. Dieser Jemand ist und kann nur einer sein: der ScrumMaster.

 

Der ScrumMaster muss wie in jedem anderen Scrum Meeting auch in einem Sprint Review seiner Verantwortung in dreifacher Weise nachkommen:

  • Als Meeting Facilitator gibt der ScrumMaster für das Sprint Review Kommunikationsregeln vor und macht diese für alle Besucher transparent. Eine Regel könnte beispielsweise lauten: “Eine Wortmeldung beginnt nicht mit „Ja, aber“.” Er tritt als Moderator des Meetings auf und sorgt unter anderem dafür, dass sich die Beteiligten ausreden lassen und verschiebt (zeitintensive) Diskussionen auf einen späteren Zeitpunkt.
  • Als Servant Leader stellt sich der ScrumMaster schützend vor sein Team. Er bestärkt es, kritisches Feedback ebenso offen und dankbar wie positives anzunehmen, ohne es zu kommentieren oder sich zu rechtfertigen: don`t feed the feedback!
  • Als Change Agent setzt er sich im Rahmen des Sprint Reviews konsequent für die Einhaltung der vorgegebenen Kommunikations- und Feedbackregeln ein, um auf diese Weise Werte wie Wertschätzung oder Respekt zu stärken und sie über die Teamgrenze hinaus zu transportieren und unternehmensweit zu etablieren.

Rezept gegen Ja-Aber-Sager

Man mag es kaum glauben. Es sind nur zwei Worte und sie können trotzdem eine vernichtende Wirkung haben. Es scheint nahezu unmöglich, noch an positive Kommunikation zu denken, wenn die Kommunikation des Gegenübers alles andere als wertschätzend ist. So schwierig muss der konstruktive Umgang mit Ja-Aber-Sagern allerdings gar nicht sein, wenn es gelingt, den eigenen Ärger über den gerade geäußerten Widerstand zu reframen (umzudrehen) und dem Gegenüber mit Verständnis für seinen Einwand zu begegnen.

 

Also: Beginnt eure Reaktionen auf das Ja-Aber-Argument mit „Das verstehe ich…“, „Da hast du recht…“ oder „Das ist ein interessanter Punkt …“ und fügt dann das magische Wort „und“ ein, bringt euer nächstes Argument oder verstärkt das vorangegangene Argument durch mehr Detailtiefe!

 

Ein einfaches “Dankeschön” ist ein weiteres, sehr erfolgreiches Rezept gegen Ja-Sager. Ja, ihr habt richtig gelesen. Gerade wurde eure Arbeit des letzten Sprints nicht besonders wertschätzend beurteilt und ihr sollt euch bedanken, z. B. mit den Worten: “Vielen Dank für dein Feedback. Wir nehmen dein Argument mal mit ins Team und diskutieren es aus. Was hältst du davon, wenn du dann einfach dazukommst und wir schauen, was das für das Ergebnis unseres Sprints bedeutet. Wann hast du Zeit für uns?“


Literatur

B. Gloger (2011). Scrum – Produkte zuverlässig und schnell entwickeln. Hanser Verlag

Avatar of David Holzer
Er kann keine Ikea-Schränke zusammenbauen. Wenn er ein Bild aufhängt, endet das in einem loriotschen Chaos. Aber wenn er Menschen durch neue Situationen führen muss, ist David gelassen und fokussiert. Dort wo andere an die Grenzen ihrer Belastbarkeit stoßen, vermittelt er Ruhe und Orientierung, kann aber als guter „Leser“ von Stimmungen genauso spontan motivieren.