Warum wir lieber feiern als loben

Teams in der Challenge Zone sind motivierter, engagieren sich stärker für das Ziel und bringen eine deutlich höhere Performance. Doch welche Faktoren führen dazu, dass sich ein Team traut, in die Challenge Zone zu gehen? Es ist nicht das Lob des Chefs, sondern die Möglichkeit, eigene Erfolge zu erleben und zu feiern.

Eigentlich wollen wir alle dasselbe: das Projekt soll ein echter Erfolg werden, alle Beteiligten wollen sich motiviert über den üblichen Beitrag engagieren, Besonderes leisten, Neues ausprobieren, Risiken eingehen und meistern. Am Schluss sollen der Erfolg und die Begeisterung für das Team, den Kunden und alle Beteiligten stehen – und somit die klassisch win-win-win Situation herstellen.

Damit dies so passieren kann, muss sich das Team jedoch von seiner sicheren Arbeitsweise lösen und von der „Comfort Zone“ in die Herausforderung, die sogenannte „Challenge Zone“ wagen. Diese ist nicht nur anstrengender als die gewohnten Muster, sondern birgt auch das Risiko eines Misserfolgs – das Team muss darauf gefasst sein, unterwegs zu stolpern oder temporär vom Weg abzukommen.

Einigen Teammitgliedern trauen sich die „Challenge Zone“ eher zu als andere. Neben der individuellen Veranlagung, sich Dinge zuzutrauen, kann man auch innerhalb des Projekt Voraussetzungen schaffen, die den Mitgliedern oder dem Team das Vertrauen gibt, die Herausforderungen aktiv anzunehmen.

Wenn ein Mitarbeiter eine positive Erfahrung macht und merkt, dass es sich lohnt, sich anzustrengen, wird er sich häufiger in die „Challenge Zone“ wagen. Wenn ich aus der Deckung gehe und es schaffe, komme ich in den Flow. Außerdem gibt es eine Weiterentwicklung, die eine Performancesteigerung nach sich zieht. Diese positiven Erfahrungen wiederum stärken das Selbstbewusstsein und Vertrauen.

Normalerweise hört man oft: „dann muss der Chef eben mehr loben!“ Doch dieser Vorschlag birgt mehrere Fallstricke: Der Chef weiß selten, was wirklich gut lief, er lobt oft aus Berechnung, und mit dem Lob stellt er sich über die Gelobten. Besser ist es, wenn wir uns für Erfolge feiern. Doch woher wissen wir, was Erfolge sind?

Grundvoraussetzung ist, dass wir wissen, was im Projekt vor sich geht. Dazu gehört nicht nur der regelmäßige Kontakt mit allen Beteiligten, sondern auch das Wissen, wie es um das Projekt steht, welche Ziele im Sprint geplant wurden. Erfolge sind schließlich das, was wir als Erfolg sehen. Die Ziele sollten daher herausfordernd, aber nicht unmöglich sein. Fehler sind dazu da, dass wir daraus lernen.

Reviews sind eine hervorragende Möglichkeit, die erreichten Erfolge zu sehen und anzuerkennen. Das Feedback sollte am besten vom Kunden oder vom Product Owner kommen, hilfsweise kann das Team auch selbst dies hervorheben. Eine sogenannte „Positiv-Retro“ kann mit der Frage beginnen: „Was hat seit der letzten Retro GUT funktioniert“. Das hilft den Fokus von der defizit-orientierten Denke weg zu nehmen. Das Feedback kann von allen Teilnehmern kommen, also vom Product Owner, vom Scrum Master, vom Kunden, von den Stake Holdern, den Chefs etc. Es sollte auf jeden Fall authentisch und nicht berechnend passieren.

Wenn dann tatsächlich Features oder gar ein Sprint erfolgreich abgenommen wurde, sollte dies gefeiert werden! Am besten sofort im Review selbst oder zeitnah, z.B. gleich abends zusammen weggehen. Vor allem der Scrum Master sollte dies im Blick behalten; gefordert ist jedoch jeder im Team, dies anzustoßen.

Auch jenseits des Reviews nach einem Sprintende kann man die Zufriedenheit der Beteiligten ermitteln – sei es durch einfach Methoden wie Daumenanzeige im Daily Standup, über einen NikoNiko Kalender, einem Stimmungsbarometer oder anderen Techniken. Erfolge anerkennen sollte spontan pasieren und nicht strategisch geplant werden – einfache, aber effektive Methoden hierfür sind z.B. eine Kudo-Board, ein karma++ im Chat setzen, ein kurzer Blogeintrag im internen Wiki, Bagdes verleihen, ein Gong im Büro – der Fantasie sind keine Grenzen gesetzt.

Mit dem Bewusstsein der eigenen Erfolge steigt auch die Bereitschaft, neue Methoden zu adaptieren, aus Fehlern zu lernen und Wagnisse einzugehen – und somit zum Erfolg des Projekts deutlich beizutragen.

(Die Inhalte dieses Blogposts entstanden in einer Diskussion der CoP „SAM“ (Share Agile Methods) im Rahmen eines Slackdays von Mayflower. Mehr zu den Slackdays bei Mayflower gibts in 3 Tagen unter dieser URL.)