Schlagwort-Archive: retrospective

Feedback-Methoden – 4 Augen bis 360 Grad

Je nach Anlass und Konstellation kann man Feedback auf unterschiedliche Arten einholen. Als Fortsetzung unserer Feedback-Reihe seien hier einige Methoden vorgestellt:

4-Augen-Feedback

Das 4-Augen-Feedback eignet sich, wenn man jemandem persönliches Feedback zu einem konkreten Verhalten geben möchte. Das sollte möglichst zeitnah passieren. Je länger man wartet und je mehr Beobachtungen sich aufstauen, umso schwerer wird es konstruktiv Feedback zu geben.

Wenn man selbst wissen möchte, wie man in einer Situation gewirkt hat, kann man natürlich aktiv nach Feedback fragen. Auch dafür sollte man möglichst konkrete Fragen stellen. Studien haben ergeben, dass Menschen es vorziehen sich zurückzuhalten oder gar Notlügen zu erzählen, nur um kein unangenehmes Feedback geben zu müssen (2). Zudem sollte man Speichellecker oder ewige Nörgler vermeiden, sondern Personen wählen, die ein ernsthaftes Interesse an konstruktiver Kritik haben.

Spontan 4-Augen Feedback zu geben oder zu bekommen kostet am meisten Überwindung. Deswegen führen viele Teams und Organisationen regelmäßig Feedback-Sessions durch. Die Regelmäßigkeit macht es dann auch einfacher ad hoc Feedback zu geben.

Um sein Feedback strukturiert vorzubereiten kann man z.B. den Feedback-Planner von Jerome (3) verwenden: LINK.

360-Grad-Feedback

Beim 360-Grad-Feedback bekommt eine Person Rückmeldungen aus verschiedensten Richtungen, also bei einer Führungskraft z.B. von Mitarbeitern, Kollegen auf der gleichen Führungsebene und vom Vorgesetzten. Dies kann anonym passieren, z.B. über ein HR-Tool oder offen z.B. nach dem Prinzip des heißen Stuhls: Ein Meeting von maximal 30 Minuten wird einberufen, in dem ein Teilnehmer Feedback (Empfänger) von den anderen Teilnehmern (Geber) erhält. Zur Vorbereitung füllt jeder Feedback-Geber einen Feedback-Bogen aus.  (z.B. was der Empfänger Starten, Stoppen und Weitermachen soll). Auf dem Meeting liest dann jeder Feedback-Geber dem Empfänger seinen ausgefüllten Bogen vor. Der Empfänger erhält den Bogen um später darüber reflektieren zu können. Er darf Verständnisfragen stellen, aber er darf sich nicht rechtfertigen. Zudem hat der Empfänger am Ende die Möglichkeit eine offene lösungsorientierte Diskussion zu starten.

Für 360°-Feedback verwende ich meinen eigenen Feedback-Bogen, den man hier herunterladen kann: Start Stop Continue 360 Grad Feedback.

Kollegiale Beratung

Eine Variante ist die sogenannte Kollegiale Fall-Beratung. Auch hier sitzt eine Person (Fall-Erzähler) auf dem heißen Stuhl und kriegt Feedback von den anderen Teilnehmern (Berater). Der Unterschied liegt jedoch im Ablauf:

Nach der Verteilung der Rollen und der Darstellung der Situation dürfen die Berater Verständnisfragen stellen. Dann ziehen sie sich zur Identifikation zurück. Der Fall-Erzähler geht aus der Runde und darf nur zuhören und sich Notizen machen, während sich die Berater in seine Lage versetzen und ihre Wünsche und ihr Erleben schildern. Dann fangen die Berater an sich über Hypothesen und Vermutungen auszutauschen. Der Fall-Erzähler hört weiterhin zu und macht sich Notizen. In der Stellungnahme bekommt er dann Gelegenheit Ergänzungen und Korrekturen zu dem gehörten zu machen. Die Berater korrigieren evt. Ihre Hypothesen. Für die Lösungssuche geht der Fall-Erzähler wieder aus der Runde, hört zu und notiert sich wichtige Punkte. Jeder Berater sagt nun, was er in der Situation tun würde, ohne zu diskutieren. Schließlich kommen wieder alle zusammen und der Fall-Erzähler teilt mit welche Ideen er umsetzen will. Im Abschluss gibt es noch eine Feedback-Runde. Alle Einheiten sind mit 5 bis max. 15 Minuten absichtlich knapp getaktet, so dass man ins 60-90 Minuten auf den Punkt kommen muss.

Weiterführende Informationen zur kollegialen Beratung findet man z.B. bei Tietze/Thun* (5).

Retrospektiven

Auf Teamebene seien hier natürlich noch Retrospektiven genannt, in denen z.B. nach Scrum mindestens 1 Mal pro Monat reflektiert wird, wie die Zusammenarbeit im Team war. Die Retrospektiven können bei Bedarf z.B. für 360-Grad-Feedback genutzt werden, sollten sich aber nicht darauf beschränken. Für agile Retrospektiven gibt es eine etablierte Phasen-Struktur, die zum Beispiel im gleichnamigen Buch (1) beschrieben wird. Eine große Auswahl von Methoden findet man im Retromaten.

Im nächsten Beitrag beleuchte ich die Themen Selbst-Reflexion, Selbst-Erkenntnis und Achtsamkeit: LINK.

Links/Literatur

(1) Derby, Esther 2006: Agile Retrospectives*: Making Good Teams Great (Pragmatic Programmers)

(2) Eurich, Tasha 2017: Insight*: The Surprising Truth About How Others See Us, How We See Ourselves, and Why the Answers Matter More Than We Think (English Edition): Currency

(3) Jerome, Paul J. 1999: Coaching Through Effective Feedback*: Pfeiffer

(4) Rosenberg, Marshall B. 2016: Gewaltfreie Kommunikation*: Eine Sprache des Lebens: Junfermann

(5) Tietze, Kim-Oliver 2003: Kollegiale Beratung*: Problemlösungen gemeinsam entwickeln (Miteinander reden Praxis): Rowohlt Taschenbuch

(*) Affiliate-Links.

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Satisfaction Histogram

Das Bauchgefühl des Entwicklungsteams kann ein wichtiger Indikator für Engpässe im Entwicklungsprozess sein.

Esther Derby und Diana Larsen beschreiben in ihrem Buch Agile Retrospectives: Making Good Teams Great* die Methode des Satisfaction Histograms. Bei CoreMedia habe ich die Methode über einige Sprints als Teil der Retrospektive genutzt und möchte hier darüber berichten. Auch die anderen ScrumMaster haben die Methode in ihren Teams übernommen.

Je nach Team wurden verschiedene Aspekte bewertet:

  • Teamwork
  • Sprint Deliverable Quality
  • Product Quality
  • Product Vision

Bei der Benotung habe ich mich an den im Buch vorgegebenen Beispiel für Teamwork orientiert. Hier z.B. meine Formulierungen für Product Vision und Product Quality:

Product Vision
1 = The vision is brilliant and directs to amazing success.
2 = I believe following the vision will lead to success. It motivates me.
3 = The vision is clear and understandable, but it doesn’t help much.
4 = To me the vision is not plausible. It doesn’t encourage me at all.
5 = I don’t know the product vision or I think following it is a complete waste of time.

Product Quality
1 = I think we have a perfect product! It is absolutely flawless.
2 = I am fully satisfied with the quality of our product.
3 = I’m fairly satisfied. Overall the quality is nothing to be ashamed of.
4 = We didn’t ignore quality, but it was not enough.
5 = I’m unhappy and dissatisfied. I lie awake at night because of our poor product quality.

Das Team hat anonym abgestimmt, den Durchschnitt berechnet und in ein Diagramm eingetragen, in dem man den bisherigen Verlauf sehen konnte. Anschließend wurde darüber reflektiert, insbesondere bei großen Ausschlägen oder wenn das Ergebnis überraschend ausfiel. Der Product Owner durfte mit abstimmen. Ich als ScrumMaster habe nicht mitgestimmt.

Mit der Zeit entstanden Verlaufskurven wie die folgende:

Die Abstimmung und das Diagramm dienten in vielen Fällen als Katalysator für Diskussionen: Schlechte Werte oder Tendenzen nach unten bildeten einen guten Ausgangspunkt für die Frage nach dem Warum. Oft hat die Diskussion Gründe aufgezeigt, die nicht offensichtlich waren. So hatte zum Beispiel ein starkes Absinken der Product Quality und Sprint Deliverable Quality (Sprint F) keine Ursache in technischen Veränderungen, sondern in verstärkter Analyse. Weniger überraschend war, dass die Qualität des Sprint-Deliverables stärker schwankt als die Qualität des Produkts insgesamt. Zum Teil waren die Tendenzen dort sogar gegenläufig (Sprint C), wenn z.B. nicht alle für den Sprint geplanten Stories umgesetzt werden konnten, aber ein unangenehmer Performance-Bug entfernt werden konnte. Die Messung der Product Vision zeigte, wann diese wieder aufgefrischt werden muss, wenn das Team sie im Tagesgeschäft mit der Zeit aus dem Blick verloren hat. Wichtig ist aber auch die Ergebnisse nicht überzuinterpretieren. Je nachdem wer gerade anwesend ist und je nach Tagesstimmung schwanken die Ergebnisse.

Insgesamt halte ich das Histogram für ein nützliches Mittel um ein objektiviertes Gefühl für verschiedene Aspekte des Entwicklungsprozesses zu bekommen. Mehr als vier Bereiche würde ich dabei nicht gleichzeitig betrachten, damit die Methode leichtgewichtig bleibt.

Im Buch wird empfohlen die Messungen nur alle paar Iterationen durchzuführen. Es ist richtig, dass sich mit der Zeit ein gewisser Ermüdungseffekt einstellt. Ich fand es allerdings wertvoll jeden Sprint einen Messwert zu haben, um Trendwenden zeitnah mitzubekommen.Wenn man feststellt, dass die Werte konvergieren bzw. kaum noch neue Erkenntnisse produzieren, sollte man die betrachteten Bereiche variieren.