10 Gründe warum ein ScrumMaster Mimik lesen können sollte

Es gibt viele Gründe warum das Erkennen von Mimik äußerst wertvoll ist. Zum einen weil sich jeder über Jahre sein eigenes Alphabet zurechtlegt, unabhängig davon ob die Buchstaben auch richtig zugeordnet sind. Zum anderen führt ein ScrumMaster durch viele Meetings mit hoher Intensität wie Reviews, Retrospektiven oder Dailies, hierbei die Signale richtig zuordnen zu können ist sehr wertvoll.

  1. Weil wir Mimik oft falsch interpretieren und niemand der traurig ist hören möchte, dass er sich ärgert.
  2. Weil wir unausgesprochene Einwände erkennen und damit erst behandeln können.
  3. Weil wir Emotionen wie Angst rechtzeitig erkennen und damit situativ schnell eingreifen können.
  4. Weil wir das Stress-Level unserer Team-Mitglieder durch Erkennen und Umleiten der Kommunikation senken können.
  5. Weil wir Widerstand erkennen noch bevor er ausgesprochen wird.
  6. Weil ScrumMaster gute Beobachter sein sollten.
  7. Weil wir auf der Tonebene nicht immer Antworten auf unsere Fragen bekommen.
  8. Weil Interaktion zwischen Team-Mitgliedern häufig non-verbal abläuft.
  9. Weil wir destruktive Signale schon wahrnehmen können bevor Aktionen geschehen.
  10. Weil wir Begeisterung (echte Freude) von sozial erwünschtem Verhalten (soziales Lächeln) unterscheiden können.

Erfahrung aus der Praxis

Punkt 10, Situation Review: Das Review endet, der Kunde lächelt, aber ist das Lächeln echt? Der ScrumMaster interpretiert, dass der Kunde höchst zufrieden war. Mit einem prüfenden Blick hätte man erkannt, dass der Kunde zwar gelächelt hat, allerdings nur sozial. D. h. er hat sich an die Erwartungshaltung der Situation angepasst. Es fehlte das "Blitzen um die Augen". Der Kunde war nicht begeistert, er hat sich nur sozial verhalten. Es macht einen Unterschied, ob ein "weiter so" verfolgt wird oder ob eine Intervention und ein offenes Folgegespräch notwendig sind.

Soziale vs. echte Freude

Auf dem unteren Bild kann man leicht den Unterschied sehen, da das echte Lächeln schon fast in ein Lachen übergeht. Der starke Kontrast soll verdeutlichen, dass sich an den Augen der wesentliche Teil abspielt. Wirklich erkennen kann man es allerdings nur, wenn man die Baseline zu den Bilder kennt, d. h. das Gesicht in Normalzustand, ohne Muskelkontraktion.

Das schöne ist, Mimik erkennen kann man lernen: http://jedev.org/mimikresonanz/

Soziales Lächeln. Der Mund lächelt, jedoch die Augen nicht.

Echtes Lächeln, hier sogar ein stark ausgeprägtes. Die Augen lachen mit.

Mimikresonanz®-Basic-Training

Kleiner Informationsblock:

Am 29. und 30. Juli 2016 halte ich ein Basic-Training für Mimikresonanz®.

Hier lernt ihr "zwischen den Zeilen" zu lesen und erkennt, dass es viele Signale gibt, die die Mimik verrät. Manchmal sagt einem die Mimik weit mehr als die Worte des Gegenübers. Ab und zu erkennt man Signale, die gar nicht zu der Aussage passen. Spannend wenn man neben dem korrekten Beobachten auch damit interagieren kann. Das und mehr lernt ihr in dem Training :-)

Aus eigener Erfahrung kann ich sagen: für die Produkt- und Organisationsentwicklung kann das Gold wert sein :-)

Wer Interesse hat schaut hier hin: http://jedev.org/mimikresonanz/

Schmankerl

Anbei ein, wie ich finde, spannendes Video. Alex Rodriguez, ein überführter Doping-Sünder, im Interview über Doping, bevor er überführt wurde. Spannend ist Mimik und Körpersprache in den Sekunden 5 bis 20. Was beobachtet ihr? Wie interpretiert ihr eure Beobachtungen?

Question Formulation Technique – Sven‘s Selbstversuch

Vor einigen Wochen erarbeiteten Sven und ich uns gemeinsam ein Thema, indem wir die Question Formulation Technique (QFT) anwendeten. Die Technik setze ich seit über einem halben Jahr sowohl beruflich als auchprivat ein, während für Sven die Technik und Vorgehensweise neu war. Das Ergebnis dieser Zweier-Session möchte ich Euch hier vorstellen. Zuvor kurz zur Klärung was QFT ist und wo es herkommt.

Überblick und Hintergrund zu QFT

Die Question Formulation Technique (QFT) ist eine Fragetechnik aus der Pädagogik, die vom Right Question Institute erarbeitet wurde und insbesondere an Schulen und Universitäten in USA verbreitet wird. Die Technik war ursprünglich dazu gedacht, das kreative Fragenpotential von Kindern und jungen Erwachsenen zu aktivieren sowie ihre Beteiligung am Unterricht und Interesse für Themengebiete zu steigern. Eigenschaften, die wir in der agilen Software-Entwicklung an unterschiedlichen Stellen gut gebrauchen können, wie ich finde.

Die Technik selbst besteht aus 7 einfachen Schritten:

  1. Fragenfokus formulieren
  2. Regeln klären
  3. Fragen stellen
  4. Fragen kategorisieren
  5. Fragen priorisieren
  6. Erste Schritte definieren
  7. Reflektieren

Und genau das habe ich mit Sven auch gemacht.

Schritt 1: Fragenfokus formulieren

Als Fragenfokus (= ein Thema / eine Situation / ein Problem, das selbst keine Frage ist). Sven wählte:

  • „Ich arbeite im besten Projekt aller Zeiten“. 

Damit schloss Sven den ersten Schritt ab, in dem er einen Fokus definierte, auf den sich alle nachfolgenden Fragen beziehen werden.

Schritt 2: Regeln klären

Im zweiten Schritt gilt es vier Regeln zu beachten, nämlich:

  1. Stelle so viele Fragen wie nur möglich
  2. Keine Antworten, Diskussionen, Bewertungen
  3. Schreibe jede Frage genauso auf wie sie gestellt wurde
  4. Verändere jede Aussage in eine Frage

Der Sinn dieser Regeln besteht darin, für alle nachfolgenden Schritte eine freie Arbeitsweise zu ermöglichen, die nicht durch Kritik oder Bewertungen unterbrochen wird.

Schritt 3: Fragen stellen

Der dritte Schritt „Fragen stellen“ ist ein reines Brainstorming, bei dem so viele Fragen generiert werden sollen, wie es nur geht. Dabei soll man nicht darauf achten ob eine Frage bereits gestellt wurde oder die vorhergehende Frage einfach umformuliert wurde. Alles ist erlaubt, solange es eine Frage ist.

Dieser Schritt, kann je nach Bedarf 5-10 Minuten dauern. Sven hatte 10 Minuten Zeit seine Fragen aufzuschreiben. Parallel habe ich ebenfalls meine Fragen zu dem gleichen Fragenfokus erarbeitet, so dass wir unsere Ergebnisse nach dieser Runde vergleichen konnten. Sven kam auf 25 Fragen, ich auf 27 Fragen. Neben der Anzahl ist uns aufgefallen, dass wir das gleiche Thema aus ganz unterschiedlichen Blickwinkeln betrachtet haben, was uns viel über unseren aktuellen Kontext verraten hat.

Sven hatte eher auf seine Person bezogene Fragen gestellt, z. B. „Was habe ich dazu beigetragen?, Wo wurde ich überrascht? Was habe ich übersehen?“, während ich projektbezogene Fragen gestellt habe wie „Welche Skills haben die Personen in diesem Projekt? Gibt es einen Kunden für dieses Projekt? Ist das ein agiles Projekt?“. Darüber hinaus hatten wir Fragen, die den gleichen Tenor hatten wie „Was haben wir aus dem vergangenen Projekt übernommen, das uns erfolgreich gemacht hat?“ und „Was können wir aus diesem Projekt ins nächste übertragen?“. Beide Fragen beschäftigen sich mit „Learnings“ jedoch aus unterschiedlichen zeitlichen Perspektiven.

Hier komme ich zu der Idee, dass man Fragen nach ihrer zeitlichen Abfolge ordnen könnte, wenn man einen Bedarf dafür hätte. Eine schöne Anmerkung von Sven war, dass es ihn überrascht hat, dass ich ihn nicht nach den ersten zehn Fragen gebremst habe, sondern, dass er die gesamten 10 Minuten nutzen konnte. Nun darin liegt der Sinn der Übung, sich Zeit zu nehmen, damit das Gehirn auch die Chance hat sich mit Fragen warm zu laufen, neue Ansätze auszuprobieren, neue Aspekte in einer bereits gestellten Frage zu finden, die Richtung zu wechseln und wieder zu einer Formulierung zurück zu kommen. Zeit, die man sich sonst nicht dafür nimmt.

Schritt 4: Fragen kategorisieren

Beim vierten Schritt „Fragen kategorisieren“ geht es darum, die erarbeitete Fragenliste durchzugehen und bei jeder Frage entweder „G“ für eine geschlossene Frage oder ein „O“ für eine offene Frage zu vermerken. Das hat den Effekt, dass man anhand der Häufigkeit direkt sehen kann welchen Fragentyp (geschlossen, offen) man grundsätzlich bevorzugt. Das ist nicht wertend gemeint, beide Möglichkeiten sind gleich gut, was häufig jedoch anders gesehen wird. Deshalb ist es auch gut sich ins Gedächtnis zu rufen, welche Vor- und Nachteile sowohl offene als auch geschlossene Fragen haben, was QFT an dieser Stelle auch fordert.

Als Ergebnis kam bei Sven wie bei mir raus, dass wir fast nur offene Fragen stellten. Damit war der vierte Schritt allerdings noch nicht abgeschlossen, denn hier soll man alle gestellten Fragen umwandeln und die Fragenliste ergänzen. Sprich, man soll alle offenen Fragen in geschlossene Fragen verwandeln und alle geschlossene Fragen in offene Fragen umformulieren. Das braucht ein klein wenig Übung, denn das macht man eher selten. Hier sollte man sich nicht allzu sehr am genauen Wortlaut festklammern, das schränkt unnötig ein. Der Sinn soll bei der Umformulierung erhalten bleiben, aber es muss nicht Wort für Wort wiedergegeben werden. Was passiert jedoch an dieser Stelle mit einer Person? Man reflektiert über die Fragen, die man gestellt hat, in dem man eine sinnvolle Übersetzung zu finden sucht. Man entdeckt ggf. auch Fragen, die eine Voraussetzung für vorhergehende Fragen bilden oder nachfolgend beantwortet werden können.

Am Ende dieser Übung wuchs die Fragenliste von Sven um mehr als das Doppelte, wobei er im Zuge der Umformulierung weitere Fragen ergänzte, die er zusätzlich wieder umformulierte, sodass er am Ende auf 55 Fragen kam. An der Stelle führte ich meine Liste nicht mehr weiter. Der Hintergrund für diesen Schritt ist, dass jede gestellte Frage einen neuen Fokus für eine Antwort eröffnet. Die Antwort richtet sich nämlich nach der Fragenformulierung aus, zumindest wünscht man sich das . Was macht man aber mit 55 Fragen? Das klärt sich im nächsten Schritt.

Schritt 5: Fragen priorisieren

Bei „Fragen priorisieren“ geht man durch die Gesamtliste durch und wählt drei Fragen aus, die am wichtigsten / interessantesten / relevantesten für den Fragenfokus zu beantworten wären. Hierbei sollte man darauf achten an welcher Stelle sich diese Fragen befinden. Zu Beginn der Liste, am Ende des ersten Abschnitts oder vielleicht eher bei den umformulierten Fragen. Das verrät einem welche Wege das Gehirn einschlagen musste, bis die Fragen aufgekommen sind, die es wirklich Wert sind beantwortet zu werden.

Neben der Priorisierung fragt QFT nach dem Grund weshalb explizit diese drei Fragen ausgewählt wurden, sodass man wieder einen Reflektionspunkt hat, an dem man mit der Argumentation nochmals prüfen kann, ob die Wahl richtig getroffen wurde.

Sven wählte 3 Fragen aus:

  • #09 Was lässt es mich übersehen?
  • #12 Wie kann ich es loslassen?
  • #17 Wo bin ich überrascht worden?

mit „Was lässt es mich übersehen?“ als erste Priorität.

Exkurs - QFT und dieser Blog

Kleines Nebenbeispiel: Ich habe QFT verwendet, um festzulegen welche Fragen ich in diesem Artikel beantwortet haben möchte. Alles waren gute Fragen (angedeutet im Bild) aber die eine, an Stelle 34 war ausschlaggebend für diesen Artikel, nämlich „Darf ich Beispiele aus dem Versuch mit Sven schreiben?“ Das war eine Umformulierung der offenen Frage „Welche Beispiele kann ich schon aufzeigen?“, die an 14er Stelle aufkam. Insgesamt habe ich 40 Fragen generiert, von denen ein Großteil sich in diesem Artikel wiederfinden. 

Schritt 6: Erste Schritte definieren

Erste Schritte definieren“ ist der Punkt an dem das Gehirn sich bei jedem kurz verweigern wird, denn hier gehen wir wirklich ins Eingemachte. Anhand dieser vier zusätzlichen Fragen plant man die Beantwortungsschritte und das Ziel, das man mit den priorisierten Fragen verfolgt:

  1. Was ist das Ziel?
  2. Was ist der erste Schritt?
  3. Kommt noch ein Schritt davor?
  4. Wie sieht es aus, wenn man das Ziel erreicht hat?

Beispielsweise hatte Sven als Ziel seine Perspektive zu weiten um hinter den Goldrausch zu sehen, um von innen und außen das "beste Projekt allerzeiten" zu betrachten. Sein erster Schritt wäre gewesen sich eine Liste von Ideen zu machen, wie er etwas übersehen könnte. Um das zu realisieren müsste er davor sich einen Termin für das Bearbeitungsfenster setzen und davor noch entscheiden ob es ihm überhaupt wichtig ist es weiter zu verfolgen. Sein Ziel erreicht hätte er, wenn er etwas findet, was er übersehen hat. Das mit jemanden besprochen, kategorisiert und bewertet hat.

Wenn man mit den ausgewählten Fragen an dieser Stelle Schwierigkeiten bekommt, d. h. wenn sich diese vier Fragen nicht sinnvoll beantworten lassen, dann sollte man seine Gesamtliste nochmal prüfen, ob eine andere Frage sich nicht doch besser eignet.

Schritt 7: Reflektion

Mit dem letzten Schritt „Reflektion“ endet die Technik. Man reflektiert nochmal über den gesamten Prozess, was zu diesem Zeitpunkt leicht fallen sollte, denn man reflektiert ja die gesamte Zeit über. Beim ersten Mal lohnt es sich diese vier Fragen zu beantworten:

  1. Was habe ich mit dieser Technik gelernt?
  2. Was hat mich überrascht?
  3. Was hat mir gefallen?
  4. In welcher Situation könnte ich QFT verwenden?

Zur letzten Frage habe ich hier einige Bereiche zusammengetragen, in der ich QFT schon benutzt habe:

Schlusswort

Im Grunde ist QFT eine Kreativitätstechnik, die einen über Fragen den Weg weist ein besseres Ergebnis zu erzielen. Wie die Anwendung auf ein bestimmtes Gebiet in der agilen Software-Entwicklung aussehen kann, versuche ich in einem separaten Artikel zusammen zu fassen.

Nadja

Agile Computerspiele

Spiele eignen sich außerordentlich gut um Ideen, Techniken und Praktiken leicht verständlich zu vermitteln. Als ScrumMaster greift man deshalb häufig und gerne auf Rollenspiele, Ballspiele, Kartenspiele, Legospiele, Brettspiele und selbst ausgedachte Spiele zurück, um agiles Gedankengut  zu transportieren. Auf Webseiten wie Tastycupcakes findet man unterschiedliche Variationen dieser Spiele, die zudem nach Themenbereichen unterteilt sind. Was diese Spiele gemeinsam haben ist, dass Software-Entwickler ihre Aufmerksamkeit auf etwas lenken müssen, das nicht ihrem "natürlichen Lebensraum" entspricht und sie oftmals aus ihrer Komfortzone herausreißt. Dagegen ist nichts einzuwenden, ganz im Gegenteil, denn "Lernen" und "Wachstum" passieren immer außerhalb unserer Wohlfühlzonen, was Jan-Hendrik Heuing sehr schön in seinem Blog "Scrum and comfort zones" beschreibt.

Dennoch finde ich, dass man "Komfortzonen" als ScrumMaster unterschiedlich ansprechen kann. Bei Rollenspielen habe ich häufig den Eindruck gewonnen, dass sich Kollegen mehr darauf konzentrieren sich dem Spielrahmen anzupassen, d. h. sich eine neue Rolle auszudenken, sich anders zu verhalten oder mehr dem zu verweigern als Erkenntnisse zu gewinnen, die sie auf ihre Arbeit übertragen können. Deshalb stelle ich mir die Frage, ob der Fokus in der Übung nicht durch die Inszenierung verloren geht. Sehr viel Aufmerksamkeit wird darauf verschwendet, dass man sich über das Spiel ärgert oder sich der Situation entziehen will und damit wenig partizipiert.

Was wäre jedoch, wenn man den Entwicklern ihre Komfortzone lassen und ein Computerspiel als didaktisches Medium nutzen würde? Warum holen wir die Menschen nicht dort ab, wo sie sich wohl fühlen und verlieren dadurch keine Energie auf persönliche Konflikte mit dem Setup der Übung? 

Zocken kann jeder

Zocken ist etwas ganz natürliches für einen Software-Entwickler. Auch wenn sich viele privat nur für Ego-Shooter, Adventure, Taktikspiele oder andere Genres interessieren, haben sich vermutlich die meisten auch an andere Spielarten herangetraut. Damit steigt die Wahrscheinlichkeit, dass sich Entwickler sehr schnell in die Gegebenheiten eines neuen Computerspiels einleben können. 

Sicherlich eignet sich nicht jedes Computerspiel, um agile Konzepte zu vermitteln aber einige gibt es, die es Wert sind gezielt gespielt zu werden. Aus meiner Sicht gehören Besiege und Factorio dazu.

Besiege

Besiege ist ein physikbasiertes Spiel, das von Spiderling Studios entwickelt wurde und seit 2015 am Markt ist. Ziel des Spiels ist es durch eigens zusammengebaute Maschinen - Gebäude, Armeen, Burgen oder Türme - zu zerstören. Mit jedem Level muss eine andere Maschine gebaut werden, die der Mission gerecht wird, z.B. „Zerstöre die Windmühle“ oder „Vernichte 100 Soldaten“. Das bedeutet, dass mit jedem Level sich ein oder mehrere Spieler aufs neue Gedanken machen müssen wie die Maschine beschaffen sein muss, welche Komponenten benötigt werden, was von der bisherigen Bauweise weiterverwendet werden kann und was gänzlich gelöscht werden muss. In jedem Level steigt man in ein neues Experiment ein, das man mehrmals hintereinander auf die Probe stellen kann, um zu sehen ob das ausgearbeitete Design den Anforderungen stand hält und die Maschine das verhalten aufweist, das man sich davon verspricht. Somit testet man unentwegt sein Produkt auf Schwachstellen und verbessert solange bis die Maschine das Ziel zerstört hat.  

Gespielt hat mein Team Besiege in einer Retrospektive zu Beginn 2016. Dafür hat sich das Team in zweier Gruppen aufgeteilt, um die gleichen Missionen durchzuspielen. Drei Fokusthemen der Retrospektive hatten wir zuvor miteinander vereinbart:

  • Sprint Planning 2
  • Pair Programming
  • Refactoring oder Innovation

Die zweier Teams hatten nur wenige Vorgaben:

  • zeichnet die Maschine als Entwurf auf, bevor die Maschine gebaut wird
  • nach je 10 Minuten Spielzeit machen wir eine 5-minütige Retrospektive 
  • nach drei Durchläufen = 30 Minuten Spielzeit übertragen wir die Erkenntnisse aus dem Spiel auf die drei Themenbereiche

Briefing zu Besiege dauerte 3 Minuten (anstatt der geplanten 15 Minuten), denn jeder wusste sofort was zu tun war. Besiege bietet ein kleines Tutorial zum Spiel an, das wir uns zu Beginn gemeinsam angesehen haben. 

Als Scrum Master kann man sehr viele Beobachtungen aus dem Spiel ziehen und einige dieser Fragen schon in den 5-minütigen Zwischenretrospektiven abfragen und auf Post-Its festhalten: 

  • Wie harmonisch arbeiten die zweier Gruppen miteinander?
  • Wie entscheiden sich die Gruppen auf das initiale Design?
  • Wie lange haben die Gruppen benötigt um das initiale Design zu erarbeiten?
  • Wie schwer ist es ihnen gefallen eine Entscheidung zu treffen?
  • Wie schnell haben sie die erste Vorgabe "zeichnet die Maschine als Entwurf auf, bevor die Maschine gebaut wird" verworfen und warum?
  • Wie ist das Verhältnis von Sprechen und Bauen in den zweier Gruppen?
  • Wessen Meinung überwiegt in der Gruppe?
  • Wie häufig verändern die Gruppen die Maschine?
  • Wer neigt zum Over-Engineering?
  • Wer setzt auf ein einfaches Design?
  • Fragen sich die Gruppen gegenseitig um Rat, wenn sie nicht weiter kommen?  

In der anschließenden Gesamtretrospektive habe wir nur einige dieser Fragen gezielt nochmal beleuchtet und unsere üblichen Vorgehensweisen im Sprint Planning 2, beim Pair Programming und hinsichtlich Refactoring dagegen aufgewogen. 

Sprint Planning 2

Für Sprint Planning 2 kamen mehr Erkenntnisse als Folgeschritte heraus:

  • Visualisierung ist notwendig, um Ideen zu übermitteln  
  • Design muss anpassbar sein
  • Entscheidungen waren einfach zu treffen weil das Ziel klar war
  • Realität ist komplizierter als das Spiel

Pair-Programming

Beim Pair-Programming hat das Team sich vorgenommen im nächsten Daily gemeinsam zu entscheiden welche UserStory im Pair-Programming von wem durchgeführt wird. Die darauf folgende Retrospektive soll das Thema nochmal aufnehmen. 

Refactoring oder Innovation

Zu Refactoring oder Innovation gab es die Erkenntnis, dass wir im Team einen Mittelweg finden müssen, um Over-Engineering und Refactoring- bzw. Innovationsgedanken zu kombinieren, da offensichtlich wurde, dass unterschiedliche Vorgehensweisen im Team vorherrschen.

Mein Ziel alle drei Themen zu beleuchten haben wir damit erreicht und einen konkreten nächsten Schritt beim Pair-Programming identifiziert. Die weiteren Themen sind gute Kandidaten für weitere Retrospektiven geworden. 

Die Beteiligung war die gesamte Zeit über sehr hoch und es hat Spaß gemacht über den Vergleich der gebauten Maschinen, den Einfallsreichtum und Denkrichtungen im Team, Visuell darzustellen.

Factorio

Das nächste Spiel, das sich förmlich aufdrängt ist Factorio, das seit 2016 verfügbar ist.

In diesem Strategiespiel baut und pflegt man Fertigungsanlagen, die man fortwährend automatisiert, bis sie sich selbständig versorgen.

Welches Ziel man wohl damit im agilen Umfeld verfolgen könnte ;)

Nadja

Team-Burnout: Risikofaktor Führung

Fengler beschreibt insgesamt 6 Risikofaktoren für Team-Burnout: Führung, Institution, Team, Person, Privatleben und Zielgruppe. In diesem Artikel gehe ich auf Aspekte der Führung ein, die Teams in den Burnout führen können.

Führung

Führung und Vorgesetzte haben einen großen Anteil an dem Burnout von Personen und Teams, da sie maßgeblich Einfluss auf die Rahmenbedingungen von Teams haben.

Als wesentliche Merkmale einer Führungskraft, die Teams und deren Mitglieder in die Verzweiflung treibt, nennt Fengler: Uninformiertheit und DurchsetzungsschwächeKonfliktscheue, Unberechenbarkeit, übermäßige Kontrolle, Grenzüberschreitungen, ÜberforderungUnterdrückung von Mitarbeiter-Initiativen, Menschenverachtung sowie Klüngel und Seilschaften.

Wer gibt Gas, sodass Teams Gummi lassen? - Bild "Burnout" von driver Photographer, Creative Commons 2.0, Flickr

Schwache Führung

Zaudern und zögern hat bei Führungskräften starke Auswirkungen auf Teams. Für ein Team bedeutet es, dass das Warten auf Verbesserungen und Entscheidungen unerträglich wird. Beispielsweise kann Arbeit nicht beendet oder gestartet werden, da selbst getroffene Beschlüsse revidiert und wieder aufgeschoben werden. Oft fehlt die Unterstützung für Themen des Teams bei Problemen. Teams fühlen sich nicht vertreten, da niemand für sie einsteht. Durch Beschwichtigungen fühlen sich Menschen manipuliert und nicht ernst genommen. Letztlich kann man das auf einen Mangel an Durchsetzungskraft zurückführen, der Teams demotiviert und das Vorankommen des Teams bei den Aufgaben und der Entwicklung nahezu unmöglich macht.

Dazu kommt, dass manche Führungskräfte sich nicht trauen unpopuläre Themen durchzusetzen, da sie Konflikte scheuen. Somit verweilen Teams und Organisation in der Mittelmäßigkeit, unfähig Verbesserung und Mitarbeiter-Initiativen voran zu treiben. Als Folge degeneriert der Arbeitsethos von Teams weiter. 

Überforderte Selbstorganisation

"Das soll das Team entscheiden" - egal ob die Kompetenz dafür vorhanden ist, oder ob das Team überhaupt Interesse hat die Entscheidung zu fällen. Auch egal, ob das Team über die Entscheidung in Konflikte gerät und sich dabei zerfleischt. Ist man als Führungskraft selbst nicht konfliktfähig und mangelt es an Entscheidungswille, dann belastet manche Führungskraft ihr Team damit, dass sie eigene Entscheidungen treffen sollen und kaschiert das mit dem Trojanischen Pferd Selbstorganisation.

Gerade beim Einsatz von agilen Methoden und überforderten Managern delegiert Management Entscheidungen zurück ins Team. Dabei führt eine Delegation von Leitungs- und Konfliktentscheidungen ins Team oft zu Chaos im Team. Es wird übersehen, dass solche Entscheidungen für Teams zum "Dauerstressor" werden können.

Neben der Kompetenzfrage, die Teams in die Überforderung treibt, muss man zudem berücksichtigen, dass Mehrheiten und Interessen innerhalb des Teams wechseln. Zudem bewähren sich manche Entscheidungen nicht und es fehlt die rechtzeitige Intervention, die Entscheidung zu revidieren. Im schlechtesten Fall trifft ein Team eine Entscheidung, die dann von Führung widerrufen oder von Ausnahmen durchlöchert wird.

Teams können jedoch auch lernen mit Fehlentscheidungen umzugehen und diese zu revidieren. Hierbei helfen regelmäßige Reflexion und Retrospektiven. Allerdings benötigt ein solches Team eine Reife und die Konsequenz Entscheidungen nachzuverfolgen und sich neu auszurichten.

SVNWNK

Literatur: Fengler 2015: Jörg Fengler, Klett-Cotta Verlag, Ausgebrannte Teams

Der Normativ ist dem Innovativ sein Tod

In Unternehmen herrscht Konformitätsdruck: Die Mehrheit bestimmt durch soziale Beeinflussung die Verhaltensweisen und Überzeugungen Einzelner. Individuen passen sich an die Mehrheit an, auch gegen die eigenen Überzeugungen.

Möchte man Veränderung in eine Organisation tragen, steht man mit dem Neuen, der Innovation, gegen die Norm. Dieser normative Einfluss beruht auf

  1. Zugehörigkeit, 
  2. sozialer Anerkennung
  3. sowie auf Sanktionen bei normabweichendem Verhalten.

Betrachtet man die drei Punkte auf Organisationsebene, dann ist klar, dass Innovation einen starken Widersacher hat, sofern nicht an Dreh- und Angelpunkten klar Stellung bezogen wird.

Definition: Konformität
"Unter Konformität wird die Veränderung individueller Verhaltensweisen, Überzeugungen, Einstellungen etc. infolge sozialer Beeinflussung durch eine numerische Majorität (Mehrheit) der Gruppenmitglieder verstanden. Die individuellen Positionen werden infolge dieses Einflusses an die Majoritärtsposition angepasst." - (Stürmer & Siem, 2013)

"Forward march" von showbizsuperstar, Creative Commons 2.0, Flickr

Wer etwas verändern möchte, sollte sich daher mit Einfluss und Strafe an Schlüsselpositionen beschäftigen und ein System schaffen, was dahingehend die Veränderung begünstigt. Das kann heißen, dass zum einen klar kommuniziert wird was das "neue Ziel" ist und wie sich deswegen Spielregeln verändern. Zum anderen sollte man untersuchen, welche Gegenbewegungen existieren, die zurück in das alte System ziehen. Hier ist insbesondere der Blick auf Personen zu lenken, die das neue, gewünschte Verhalten bestrafen. Sind diese Personen nur zu Lippenbekenntnissen zu bewegen, dann sollte man auch über eine Neubesetzung der Postionen nachdenken.

Definition: Normativer Einfluss
"Sozialer Einfluss, der darauf beruht, dass man die Erwartungen der Majorität erfüllen und negative Sanktionen bei normabweichenden Verhalten vermeiden möchte." - (Stürmer & Siem, 2013)

Der normative Einfluss ist wie ein Magnet, der das System in der Konstellation hält. Ändert man innerhalb der Konstellation nur die Variablen, die keinen Einfluss auf die Ausrichtung haben, dann stabilisiert sich das System wieder im ursprünglichen Bild. Alles steht wieder an seinem Platz und in Reih und Glied.

Nicht jeder beugt sich unter den Konformitätsdruck. Es gibt auch Widerstand und Abweichler, die sich nicht der Mehrheit anschließen, wenn es gegen ihre eigenen Überzeugungen geht. Solche Personen können dem System eine Weile widerstehen und im System Zellen aufrechterhalten, indem sie die Zellen vor der Konformität abschirmen und eine eigene Norm ausprägen. Verliert die Zelle den Kern des Widerstands, verfällt sie meist in Kürze in die alten Muster der Organisation zurück.

Beispiel 1: Zögerliche Implementierung

Unklare Kommunikation und fehlende Rückendeckung in der breiten Öffentlichkeit (Bekenntnis) führt dazu, dass gar nicht klar ist, dass ein neuer Kurs verfolgt werden soll. Eine Auseinandersetzung mit Barrieren für das Neue und dem eigenen System findet nicht statt. Der Kurs ist "auf geringe Sicht fahren" und immer eine Hand am Beckenrand, sodass ein zurück jederzeit möglich ist. 

Hier prägt man weder ein Bewusstsein für das "Neue" in der Organisation aus, noch unterstützt man die Personen, die das "Neue" vertreten sollen, ausreichend. Mit Problemen und Stellschrauben setzt man sich nicht auseinander, sodass das "Alte" die Initiative wieder in den alten Rahmen presst.

Beispiel 2: Wegfall von Widerstand und Abweichlern

Innerhalb einer klassischen Organisation hat sich ein agiler Ableger aufgebaut. Auf den Ableger wirkt der Druck des Systems angepasst an die Norm zu arbeiten, bspw. mit viel Multitasking, Störungen, unklaren Anforderungen für die Entwicklung, etc. An der Grenze der Zelle wird dem Ganzen widerstanden. Es werden bspw. nur klare Anforderungen (Definition of Ready) in die Entwicklung gegeben und kein Multitasking auf Tagesbasis zugelassen (Portfolio-Planung). 

Bricht der Widerstand weg, kann das Erreichte nicht konserviert werden. Die Organisation fällt zurück in alte Muster und der Druck der Norm sorgt für Anpassung. Die erreichte Innovation verblasst.

Der Ausweg

Gibt es ihn und wenn ja für wen? Zum einen für den Einzelnen zum anderen für die Organisation.

"Ob es besser wird, wenn es anders wird, weiß ich nicht. Dass es aber anders werden muss, wenn es besser werden soll, weiß ich!" - Georg Christoph Lichtenberg

Der Einzelne passt sich meist der Norm an. Die auferlegte Pflicht wird übernommen. Stimmt sie nicht mit den eigenen Überzeugungen überein, kränkt es den Einzelnen. Die eigenen Überzeugungen werden entwertet und spiegeln sich nicht in der Arbeit wider. Das kuriose daran ist, dass die Pflicht der Norm eigentlich gar nicht existiert, sondern es obliegt der Wahl des Einzelnen sich ihr anzuschließen oder zu widersetzen. Fällt die Entscheidung gegen die Pflicht und dafür für Selbstrespekt, Selbstbestimmung und Freiheit einzustehen, so kann sich etwas verändern. Hat man seine Stimme gefunden, so kann man anderen dabei helfen die ihre zu finden.

Die Organisation hat jederzeit die Wahl etwas anders zu machen. Verliert sie Schlüsselpositionen, so können diese neu besetzt werden. Auch eine Auseinandersetzung in Retrospektive mit dem Scheitern ist sinnvoll, um daraus Schritte für die Zukunft abzuleiten. Kritisch sollte man sich mit der eigenen Rolle auseinander setzen und wie ein System geschaffen werden kann, dass alte Fäden durchschneidet und wie man kraftvolle neue Fäden spinnt. Für die Kommunikation einer neuen Strategie ist es selten zu spät. Trifft man im Rampenlicht klare Entscheidungen für die neue Strategie, so kann die Wahrhaftigkeit der Absicht in die Organisation einsickern.

SVNWNK

Literatur:

READY TO PLAY: Definition of Ready (DoR)

Um Blockaden während der Entwicklung zu minimieren, treffen Teams immer wieder gerne eine Vereinbarung bzgl. dem Stand von bearbeitungsfähigen Items - kurz Definition of Ready (DoR).

Die Definition of Ready umfasst alle Punkte, die abgeklärt sein müssen, damit die Entwicklung beginnen und durchgeführt werden kann. Hier geht es um Zulieferungen an das Team und Vorbereitungsmaßnahmen vom Team selbst. Optimalerweise nimmt man die Punkte auf, die Blockaden verursachen und die Entwicklung (deutlich) verlangsamen. Obwohl das zumeist kontextabhängig ist, gibt es einige Punkte, die Teams immer wieder stolpern lassen.

Deswegen ein Beispiel für eine Definition of Ready:

Pflicht:

  1. Das Item ist dem Team bekannt und es ist geschätzt
  2. Das Item ist klein genug, damit es in einem Sprint umgesetzt werden kann
    1. max. ein Fünftel der Velocity oder 1-5 Story Points
  3. Das Item ist frei von Blockaden
  4. Das Item ist frei von externen Abhängigkeiten
  5. Das Item ist testbar
    1. anhand der Kriterien und mit akzeptablen Aufwand
    2. in einer verfügbaren Umgebung != Dev-Rechner (z. B. bei Fremdsystem-Integration)
  6. Es liegen alle Dokumente, die zur Umsetzung benötigt werden vor (Designs, Bilder, mehrsprachige Texte, Schnittstellendokumentation) oder ist ein Ergebnis des Sprints und das Team ist befähigt das Ergebnis zu erbringen

Optional:

  1. Das Item ist verständlich beschrieben anhand von Akzeptanzkriterien
  2. Der Business-Wert für das Item ist klar artikuliert und messbar
  3. Technisches Restriktionen (Constraints) sind beschrieben, sofern vorhanden
  4. Relevanz für Stakeholder z. B. Datenschutz oder Security wurde geprüft und daraus resultierende Ansprüche sind aufgenommen (als eigene Stories oder Akzeptanzkriterien)

Thomas Hawk, "Ready", Creative Commons 2.0, Flickr

Die Definition of Ready sollte nicht als starres Dokument angesehen werden. Vielmehr können mit der Reife und zunehmender Cross-Funktionalität des Teams sich Punkte in den Aufgabenbereich des Teams verschieben. Dadurch wird das Team autonomer und bündelt mehr Arbeit im Team. Ob es dadurch langsamer oder schneller wird hängt von der Effektivität der vorigen und neuen Organisation ab. Skaliert eine solche Verschiebung nicht, kann es auch sein, dass weitere Punkte in die Definition of Ready aufgenommen werden müssen. Dabei erhöht man die Abhängigkeiten des Teams von externen Quellen.

Persönlich tendiere ich dazu die Autonomie eines Teams zu stärken. Das liegt daran, dass ich die Erfahrung gemacht habe, dass die Anzahl der Blockaden und Wartezeiten deutlich sinkt und mit mehr umspannenden Aufgaben ein Team ein besseres Verständnis für die Fachdomäne entwickelt. Nicht zuletzt schätzen viele Teams es, eine ganzheitliche Lösung zu liefern. Zusätzlich nimmt das Konfliktpotential zwischen Teams und Organisation an den Schnittstellen ab.

Auch wenn in Ausnahmefällen auf einzelne Punkte verzichtet werden könnte, so sollte man den Prozess nicht aufweichen. Wenn man das macht, dann degeneriert man leicht den Entwicklungsprozess und landet im öden Mittelmaß der eigenen Leistungsfähigkeit bzw. öffnet der Disziplinlosigkeit Tür und Tor (broken window principle).

Letztlich muss das Team entscheiden, ob ein Item sinnvoll bearbeitungsfähig ist. Ist ein Item das nicht und besteht wer auch immer auf die Bearbeitung, so trägt diese Person die Verantwortung für die unwirtschaftlichen Konsequenzen in Zeit, Budget und Anwenderzufriedenheit.

SVNWNK

Rezept eines Sprint Plannings (SP 1)

Sprint Plannings (SP) kann man auf viele verschiedene Arten durchführen. Ich persönlich bevorzuge ein Sprint Planning 1 und 2, aufgetrennt mit Fokus auf das WAS (SP 1) und das WIE (SP 2).

Das Planning 1 nutzen wir um den Ablauf der zu besprechenden Items zu diskutieren. Hier gehe ich davon aus, dass das Refinement stattgefunden hat, der grobe Plan für den nächsten Sprint bereits bekannt ist und die Items trotzdem noch nicht bis ins letzte Detail besprochen sind (um Verschwendung vorab zu minimieren).

Bild von Stuart, "Checklists that matter" (Creative Commons 2.0), Flickr

Bild von Stuart, "Checklists that matter" (Creative Commons 2.0), Flickr

Ziel und Zweck ist für mich somit das Festhalten des Umfangs für den nächsten Sprint. Das gilt für die Summe der Items als auch für den Umfang eines jeden Items. Zudem planen wir gemeinsam die Reihenfolge. Es ist sowohl ein kooperativer Prozess, das Beste aus den nächsten Wochen herauszubekommen, als auch das Briefing des Teams.

Zu einem guten Sprint Planning gehört für mich eine Vorbereitung, die keine Zeit der Teilnehmer verschwendet, und ein klarer, wiederkehrender Ablaufplan für das Planning selbst.

Ich beschränke mich in diesem Artikel auf die Vorbereitung und den Ablauf eines Sprint Planning 1.

Vorbereitung

  • Abschließen des Vorgänger-Sprints, evtl. Übertrag liegt priorisiert vor
  • Alle Items sind "ready", nach Definition of Ready: Items sind frei von Blockaden und Schlüsselfragen, geschätzt, klein, bekannt, etc.
  • Items liegen in priorisierter Liste vor
  • Verschicken der Einladungen für die Teilnehmer
  • Buchen der Räume inkl. Rüstzeiten
  • Einholen der Abwesenheiten (Team-Kalender + evtl. Stakeholder)
  • Vorbereiten der Besprechung (technische Vorbereitung beginnt circa. 20 Minuten vorher)

Materialien

Flipchart(s), Whiteboard(s), Beamer, Rechner, Post-Its (alle Items auf Post-Its vorbereitet), Stifte, Kamera

Optional: Remote-Ausstattung wie Video-Kamera(s), Mikrofon, WebEx oder ähnliches

Ablauf

Set und Setting (5min)

Ziel: Ermitteln der Kapazität des Sprints.

Lead: ScrumMaster

  • Checken der Anwesentheit
  • Aufnehmen der Verbesserungen der Retrospektive
  • Ermitteln/Abgleichen des Forecasts mittels Velocity Chart mit Kapazität

Setting the Stage (10min)

Ziel: Erzeugen des Gesamtbildes für alle Beteiligten und setzen des Fokus für den Sprint.

Lead: Product Owner

  • Sprintziel vorstellen
  • Übersicht über alle geplanten Themen geben

Vorstellen der Items (90 min)

Ziel: Verstehen der einzelnen Items und festlegen des Umfangs pro Item (ggf. Vereinfachen von Items).

Lead: Product Owner

  • Durchsprechen/-arbeiten eines jeden Items
  • Festhalten der Akzeptanzkritieren pro Item
  • Abgleichen mit Definition of Done

... solange bis die Zeit ausläuft oder ein Veto des Teams auftritt. Das Veto bzw. nächste Go kann mit einer Fist-of-Five oder einer Konsent-Abstimmung ermittelt werden.

Optional: Festhalten der Akzeptanzkriterien pro Item auf einem Flipchart.

Commitment und Negotiation (15 min)

Ziele: Überprüfen ob das Commitment sinnvoll und möglich ist und Strukturieren des logischen Aufbaus.

Lead: ScrumMaster

  • Absprache über Umfang inkl. Austausch von Items
  • Festlegen der Abarbeitungsfolge der Items
  • Checken der offenen Items zum Start (WIP-Limit für den Sprint setzen)

Ein Sprint Planning ist kein Dogma. Es sollte jedoch klar strukturiert und vorbereitet sein. Wenige Teams mögen es mit unbekannten Items konfrontiert zu werden. Noch unbeliebter sind Items, die nicht ausreichend vorbereitet und unvollständig sind. Hier verschwendet man Zeit, was wiederum mangelnden Respekt gegenüber dem Team ausdrückt.

Während eines Sprint Planning 1 nutze ich Forecast und Commitment. Der Forecast hilft dem Team den Umfang und die eigene Kapazität besser einzuschätzen. Das Commitment wird genutzt um den Pull-Effekt zu erzielen und Hoheit über die eigene Arbeitslast sicherzustellen.

SVNWNK

Wenn Teams ausbrennen

Gibt es ihn, den Burnout ganzer Teams? Wenn man Veröffentlichungen der Psychologie verfolgt, dann: ja. Der Burnout im Team charakterisiert sich über die Dimensionen des individuellen Burnouts (Erschöpfung, Leistungsminderung und Entfremdung), dazu kommt im Team die Dimension des Kohäsionsverlusts.

Im Folgenden möchte ich auf einige Merkmale eingehen, die charakteristisch für die Dimensionen sind (angelehnt an Fengler 2015). Es handelt sich um:

  1. Entschlusslosigkeit
  2. Konsens ohne Folgen
  3. Freude über Misserfolge
  4. Reizbarkeit im Binnenkontakt
  5. Feindseeligkeit gegenüber anderen Subsystemen
  6. Reflexionsverweigerung

Diese Merkmale sind ein Auszug und damit nicht vollständig. Auch ergeben einzelne Merkmale per se noch keinen Team-Burnout, allerdings ist bei Auftreten der Merkmale das Risiko für den Team-Burnout deutlich erhöht (sensibel auf diese Merkmale zu achten und reagieren ist meines Erachtens ein Kennzeichen für verantwortungsvolle Führung).

Gerade bei einer Umstellung der Arbeitsweise (agile Transition) bin ich häufig auf solche Merkmale gestoßen. Zum einen lagen die Merkmale bereits ausgeprägt vor, zum anderen wurden sie bei der Umstellung verstärkt oder abgeschwächt. 

Da hier gerade die Rolle des ScrumMasters zur Schlüsselfigur werden kann, beziehe ich mich in der Ausarbeitung der Beispiele auf Scrum.

Bild von Dave Wild ("Burnout 1"/Lizenz Creative Commons 2.0)

Entschlusslosigkeit

Dienstag, 11:27 Uhr, Retrospektive: Es wird ein Thema diskutiert, das dem Team eindeutig ein großes Leiden zufügt. Trotz des Schmerzes ist das Team nicht fähig gemeinsame hilfreiche Konsequenzen daraus zu ziehen. Es findet keine Einigung statt welcher Vorschlag nachverfolgt werden soll oder es bilden sich Gruppen, die nur für ihre eigenen Vorschläge einstehen und anderen Vorschlägen nicht folgen können.

Das Thema versandet und wird nicht fertig bearbeitet.

Konsens ohne Folgen

Mitten im Sprint: Das Team strauchelt bei einem altbekannten und benannten Problem, welches es bereits mehrfach lösen wollte. Das Thema und die Maßnahmen dazu wurden gemeinsam in der letzten Retrospektive im Konsens erneut beschlossen. Nur bei der Umsetzung ist keiner mehr dabei. Wie aus der eigenen Realität entfernt, entfremdet vom eigenen Ziel die Leistungsfähigkeit zu erhöhen oder aufrecht zu erhalten, tritt das Team auf.

Es entsteht eine Diskrepanz zwischen der gemeinsamen Entscheidung und den herbeigesehnten Korrekturhandlungen. Korrekturhandlungen werden nicht durchgeführt, vergessen oder gleichgültig.

Freude über Misserfolge

Mitten im Sprint: Server-Ausfall, Einbruch von Buchungszahlen, wichtige Zulieferungen bleiben aus - und das Team freut sich. Sarkasmus breitet sich aus. Es entsteht ein "da hat sich wieder gezeigt wie kompetent XY seine Arbeit erledigt hat" oder "wenn es offline ist, kann sich immerhin keiner über die Usability beschweren, das nenne ich Fortschritt!".

Ist das Arbeitsklima durchtränkt von solchen giftigen Aussagen, dann steht ein wichtiger Arbeitsauftrag für die Unternehmensführung an. Es gibt Organisationen bei denen die Gespräche auf den Fluren häufig aus solchen vergifteten Nachrichten bestehen, was die verantwortliche Führung entweder nicht mitbekommt oder schlimmer: ignoriert.

Reizbarkeit im Binnenkontakt

Mitten im Sprint: Dünnhäutigkeit, Spannungen und Empfindlichkeiten im Verlauf des Tages und die Team-Mitglieder gehen wegen vermeintlichen Kleinigkeiten an die Decke. Die Beziehungen, die die Team-Mitglieder zusammenhalten sind aufgerieben und das Zugehörigkeitsgefühl ist verletzt. Außerhalb des Teams wird der Feind in jedem anderen Zimmer erwartet, insbesondere bei Komponenten-Teams, die auf Zusammenarbeit angewiesen sind, gegenüber Führung oder dem Qualitätsmanagement.

Der persönliche Kontakt wird heruntergefahren. Stille oder gereizte Stimmung greift um sich. Es entsteht die Angst Personen anzusprechen. Die Kooperationsfähigkeit sinkt drastisch. Aufgaben werden teilweise nicht oder verspätet erledigt, da die Zusammenarbeit gestört ist.

Feindseeligkeit gegenüber anderen Subsystemen

Freitag, 10:28 Uhr, Daily Scrum: Ein Team-Mitglied beschwert sich über die mangelnde Kooperationsbereitschaft der Nachbarabteilung, die für den Betrieb der Anwendung zuständig ist. Trotz mehrerer Rückfragen kommt keine Antwort und die übrigen Team-Mitglieder stimmen in den Frust des einen mit ein. Überraschend heftige und pauschale Kritik wird feindseelig geäußert. Das Wir-Gefühl, was eine gesunde Organisation ausmacht, fehlt.

Diese wechselseitigen Ablehnungen zwischen Abteilungen treten häufig auf. Ein weiterer Klassiker ist der zwischen Entwicklung und Vertrieb ("denn sie wissen nicht was sie verkaufen" vs. "sie können Nichts in Budget entwickeln, das funktioniert"). 

Reflexionsverweigerung

Mittwoch, 13:43 Uhr, Retrospektive: Es wird ein Thema angesprochen, dass dem Team Probleme verursacht. Hierbei handelt es sich um irgendetwas, das im Handlungsrahmen der Organisation steckt und das Team beeinflusst. Dem ScrumMaster (Beobachterrolle) fällt leicht auf was das Problem mit sich bringt. Das Team selbst nimmt den Sachverhalt hingegen als normal an und der Elefant im Raum wird großflächig umschifft, wobei das Umschiffen als Teil der Tätigkeit angesehen wird.

Es kommt einem so vor als würden alle Team-Mitglieder mit einer Hand auf dem Rücken gebunden arbeiten und keiner sich daran stören. Die Bindungskraft zur eigenen Arbeit und Organisation ist dahingehend verringert, dass ein Einlassen auf das Problem nicht mehr gegeben ist.

Abschluss

Wenn Entfremdung die Bindung zur eigenen Arbeit, zur Organisation und zu den Kollegen stört und sich Menschen immer weiter emotional von ihrer Arbeit zurück ziehen, ja in Distanz gehen, dann bleibt die Gesundheit bei der Arbeit immer öfter auf der Strecke. Überwiegt Ärger, Frust, Angst, Verachtung oder gar Ekel die Freude an der Arbeit, dann sind Erschöpfung und Leistungseinbußen oft Auslöser und Folge. Oft sind Teams in ihrer Verbundenheit der einzige Kleber, der die Personen in der Organisation hält. Geht dieser Kleber (Kohäsion) zusätzlich verloren, dann zerstreut sich das Team in einzeln nebeneinander arbeitende Personen. Das Risiko für den Burnout eines ganzen Teams erhöht sich drastisch.

Über Retrospektiven kann man sehr gut an den Punkten Konsens ohne Folgen, Entschlusslosigkeit oder Reflexionsverweigerung arbeiten. Hierfür unterstützt man bspw. das Team dabei daran festzuhalten die eigenen Maßnahmen durchzuführen. Ein Aufzeigen von Verbesserung oder von ausgebliebener Aktion sollte in jeder Retrospektive aufgenommen werden bspw. durch den Einsatz einer Skalenabfrage im Starfish-Format.

Fragen, die sich anbieten sind:

  • Wie sarkastisch sprechen wir über unsere Arbeit? (selten, häufig)
  • Im Team werden kleinere Aufgaben als Überlastung wahrgenommen? (selten, häufig)
  • Im Team herrscht ein gereiztes Klima? (selten, häufig)
  • Beschlossenes setzen wir nicht in die Tat um? (selten, häufig)
  • Mit anderen Teams/Abteilung oder der Organisation haben wir Auseinandersetzungen? (selten häufig)

SVNWNK

Literatur: Fengler 2015: Jörg Fengler, Klett-Cotta Verlag, Ausgebrannte Teams

Source: https://www.flickr.com/photos/publicenergy...

Problemlösen

Im Artikel "Der Lösungszoo" habe ich beschrieben, dass m. E. die Lösungsorientierung/-fokussierung häufig darauf reduziert wird das Problem (Impediment) zu umschiffen und unmittelbar mit Lösungen ins Haus zu fallen.

Gerecht wird man damit eher sich selbst als dem Problem. Daher gehe ich hier auf Schlüsselpunkte beim "Problemlösen" ein:

Verstehen und Wissensgrenze

Um ein Problem zu lösen, muss man es als eines erkennen. Daher ist die Analyse ein wesentlicher Teil des Problemlösens. Meist überschätzen wir unsere Kenntnis zum Problem. Durch eine Analyse erkennen wir nicht nur die Details, sondern uns wird klar was wir dazu noch nicht wussten. Wir erreichen damit die Wissensgrenze, die nötig ist um das Problem und die Lösung zu verstehen. Dadurch vermeidet man bspw. das Behandeln von Symptomen und kann leichter an der Wurzel ansetzen. Eine gute Methode ist bspw. eine Root Cause Analyse oder die Fragetechnik 5 Whys.

Optionsraum öffnen

Ist das Problem an der Wurzel erkannt, so kann man sich in den Lösungsraum begeben. Hier hilft besonders schöpferisches, kreatives und produktives Denken - denn gerade die schwierigen Probleme müssen systemgerecht und damit mit neuen Wegen, neuem Denken beschritten werden. Optimalerweise findet man mehrere Optionen, die zur Lösung des Problems beitragen und als Pfade im Experiment ausgewählt werden können (Build-Measure-Learn). Hier ist es sinnvoll sich Maßeinheiten zu definieren, die innerhalb eines Zeitraums erreicht werden sollen. Dokumentieren lässt sich das bspw. im Firmen-Wiki als A3 Problem Solving Template.

Diskussion und Experiment

Die dokumentierten Probleme lassen sich bspw. in einer wiederkehrenden Session mit Führung und wichtigen anderen Stakeholdern durchsprechen. Man vergewissert sich gemeinsam welcher nächster Schritt der Wichtigste ist, wo Unterstützung notwendig ist und was das letzte Experiment an Ergebnissen gebracht hat. Zudem kann man gemeinsam festlegen welche Probleme am stärksten auf die Ziele der Organisation einzahlen.

Hier möchte ich besonders ans Herz legen auf die Unregelmäßigkeiten und Überraschungen von Experimenten ein Auge zu werfen. Hier liegt die Chance etwas Besonderes zu finden, was sich nachzuverfolgen lohnt. In jedem Fall ist es die Chance etwas zu lernen.

SVNWNK

 

Die Hand am Ball

10:30, Daily Scrum

"Oh ja, danke! Den Ball brauche ich, ohne den Ball kann ich nicht." war der Ausspruch eines Team-Mitglieds bei uns im Daily. Wir nutzen einen kleinen Ball als Gesprächstoken zum Regulieren des Gesprächsflusses bei uns im Daily Scrum. Keine Frage hatte Christian einen Scherz gemacht, wobei auch in diesem Scherz mehr als ein Funken Wahrheit steckt. Denn es hat mir verdeutlicht was so ein Gesprächstoken im Daily noch ist: eine Beruhigungsgeste.

Beruhigungsgesten

Wenn Stress bei uns hoch kommt, dann fangen wir an Signale zu senden. Das kann eine gesteigerte Blinzelfrequenz sein oder die Zunahme von Beruhigungsgesten, auch Adaptoren oder Manipulatoren genannt. Im Zentrum steht hier, dass Berührung uns beruhigt. So fällt es uns leichter mit Stress oder unangenehmen Situationen umzugehen.

Ein Ball zur Moderation eines Daily Scrums. Das Bild "Ball" ist von Beth Haugth  (flickr.com/Creative Commons 2.0)

Man unterscheidet drei Arten von Beruhigungsgesten (Adaptoren):

  1. Selbst-Adaptoren: man berührt sich selbst, z. B. durch Lippenlecken oder kratzen am Kinn
  2. Fremd-Adaptoren: man berührt jemanden Anderen, z. B. durch den Griff an die Hand des Nachbarn im Kino bei einer spannenden Szene
  3. Objekt-Adaptoren: man berührt ein Objekt, z. B. spielt man mit einem Stift oder nimmt ein Gesprächstoken in die Hand, in unserem Beispiel: ein Ball

Objekt-Adaptor

Ein Objekt-Adaptor reduziert Stress. Menschen haben, wenn sie vor anderen Menschen sprechen, Stress. Gerade in neuen und ungewohnten Situationen besteht Stress, insbesondere wenn man z. B. ein Daily in einem Team hat in dem das Vertrautsein noch nicht sehr ausgeprägt ist.

Mit einem kleinen Gesprächstoken, welches ihr weitergebt, steuert ihr nicht nur den Gesprächssfluß, ihr reguliert auch den Stress des Sprechenden. Probiert es bei euch selbst aus und beobachtet wie sich eure Team-Mitglieder in ihrem Verhalten verändern und wie stark sie mit dem Token interagieren. Ihr werdet auf interessante Beobachtungen und Erkenntnisse stoßen. 

SVNWNK

Mehr zu Thema

  1. Wenn das Gesicht mit der Schulter zuckt - der "Facial Shrug"
  2. 10 Gründe warum ein ScrumMaster Mimik lesen können sollte
  3. Mimikresonanz®-Basic-Training
  4. Anmeldung zum Mimikresonanz®-Training

Der Lösungs-Zoo

Hereinspaziert, hereinspaziert, geben Sie ihr Problem direkt bei uns an der Kasse ab. Wir präsentieren den Lösungs-Zoo. Egal welches Problem Sie haben, wir haben attraktive Lösungen am laufenden Band. Wir müssen weder ihr Problem kennen, noch inspizieren wir es und bitte reden Sie nicht mit uns darüber. Mit jeder unserer Lösungen bestehen Sie im Löwenkäfig wie am Trapez!

Ständig Lösungsorientierung, nein danke

Mit dem Hut der Lösungsorientierung formuliert man positive Ziele, teilweise auch ohne sich der Probleme bekannt zu sein, weil sie z. B. wie bei menschlichen Beziehungen versteckt in Wahrnehmung und Aussagen sind. Mittels wertschätzender Kommunikation, positiven Verstärkens und dem Bewusstmachen der verfügbaren Ressourcen umschifft man dabei Beschuldigung und Anklagen. Man richtet seinen Fokus auf die Zukunft.

Sich einer Methode zu  verschreiben ist das eine, das andere ist eine Methode über alles andere zu stellen: Heute ist es teilweise verpönt Probleme ohne Lösung anzusprechen. Das wäre nicht konstruktiv sagt man. Man könne kein Problem diskutieren ohne Lösung, am besten mehr als eine Option. Management könnte man nicht damit aufhalten keine Lösung zu präsentieren, denn die hätten ihre eigenen Probleme.

Ich frage mich an dieser Stelle: Schämt man sich dafür, dass es ein Problem zu lösen gilt und noch nicht direkt eine Lösung präsentieren kann? Oder wirkt man inkompetent, gar dumm, wenn man nicht eine Lösung an der Hand hat? Oder vergisst man, dass es mehr als einen Hut gibt, den man tragen kann?

Es geht soweit, dass manche meinen, man ist ohne Lösungsorientierung nicht mehr positiv. Das ist die eine Art der Interpretation und man verkennt den Zweck der Methode Anschuldigungen hinter sich zu lassen. Der Fehler passiert allerdings früher: Ein Problem ist erstmal eine Beobachtung. Darauf folgt eine Interpretation. Beides zu trennen und zu erkennen, dass die eigene Interpretation fehlerhaft sein kann, erfordert Demut. Betreten wir den Lösungsraum zu früh und validieren wir unsere Beobachtungen nicht, dann wird unsere Lösung dem Problem nicht gerecht und wir jonglieren mit leeren Händen.

Zu ihrem Problem...

...sagen sie jetzt nichts, wir kennen die Lösung!

In der Software-Entwicklung kennen wir es: wir hören unseren Kunden nicht richtig zu und haben die Lösungen schon im Kopf. Wir nehmen durch vorauseilenden Gehorsam und der Überschätzung unserer eigenen Fertigkeiten die Lösung vorweg.

Nur noch adapt, kein inspect mehr

Genauso ereilt es immer wieder ScrumMaster, Consultants und dergleichen. Sie springen sofort auf die Lösungen, ohne sich dem Problem zu widmen. Sie adaptieren, ohne zu inspizieren. Schritt zwei vor Schritt eins. "Habe ich schon mal gehört, so ähnlich gehabt oder klingt wie" heißt es dann und schneller als man bis drei zählt ist eine Lösung parat. Wer Hammer und Schrauben hat nagelt gerne.

Tell me my future von twogypsyhearts (Flickr/CC 2.0)

Dabei gibt es bei Problemen so viel zu holen. Betrachtet man ein Problem gemeinsam aus mehreren Blickwinkeln, kann man tief schürfen: 

  1. Der Blick auf das Sozialverhalten bei dem Problem ist eine Facette.
  2. Gemeinsame bereits erfolgte Beobachtungen zu diskutieren ist großartig. 
  3. Wem ist etwas anderes, vielleicht gegenteiliges aufgefallen? 
  4. Abzusprechen wie man das Problem untersuchen möchte birgt Möglichkeiten. Spanned wird welche Beobachtungen noch zu machen sind.
  5. Welche Anreizsysteme verbergen sich hinter dem Problem, wo sind die Ursachen?
  6. Was bedeutet das Problem lokal, was global?
  7. Mit welchen Problemen steht es in Verbindung?
  8. Was sind Katalysatoren, was Hemmer? 
  9. Was wäre der Lackmus-Test für die Lösung?

 

 

Was übrig bleibt

Neben Lösungsorientierung gibt es noch Problem- und Potentialorientierung. Hier liegen lohnende Perspektiven. Warum nicht den Hut wechseln und ein Problem aus allen drei Perspektiven beleuchten?

Vielleicht es einmal wieder so machen wie früher Toyota in den USA: Ein Manager wird von seinem Vorgesetzten gebeten über die Probleme zu reden, damit sie diese gemeinsam lösen können. Das Selbstverständnis war dort, dass sie dafür da waren Probleme zu kennen und zu lösen. 

Vielleicht ist es auch nur eine Einstellungssache, ob ein Problem etwas ist, was man meiden sollte.

SVNWNK

Ohne Commitment kein Team

Ohne Commitment ist ein Team nur eine Gruppe von Menschen: Ohne Einsatz, Verbindlichkeit, Verlässlichkeit oder gar Hingabe entsteht selten etwas Gemeinsames. Die Bereitschaft ein gemeinsames Ziel zu verfolgen eint eine Gruppe zu einem echten Team.

Weswegen mangelt es immer wieder an Verlässlichkeit, Verbindlichkeit, Einsatz oder Hingabe?

Ein oftmals unterschätzter Punkt ist das Fehlen des Stolzes auf die eigene Arbeit. Gerade auf diesen Punkt kann man aus vielen Perspektiven blicken.

Eine Perspektive ist es wenn die übertragene Verantwortung sich nicht mit den eigenen Mitteln deckt. Das kann sein, wenn die Fähigkeit fehlt eine Aufgabe dem Anspruch gerecht auszuführen. Wenn aus Herausforderung eine Überforderung wird. Eine gerade so oder schlecht ausgeführte Arbeit macht niemanden stolz. Unrealistische Fristen stellen auch eine Art der Überforderung und des "damit ungenügend Seins" dar. Wer so etwas aufstellt, nimmt den Team oft das Commitment am Start - obwohl ironischer Weise bei unrealistischen Fristen das höchste Commitment überhaupt notwendig wäre.

Ein sehr dynamischer Zug. Ohne Commitment nicht zu machen, nicht zu halten.

Foto "Dyno" von Marian Schütz (Flickr/ Creative Commons)

Ein weiterer Punkt, der hoffentlich bald ad acta gelegt wird, ist es dem Team vorzuschreiben schlechte Arbeit zu machen. Gibt's nicht? Leider doch. Es gibt immer noch Organisationen, die ihren Teams die Grundlage nehmen tadellose Produkte zu liefern. Darunter fallen in der Software-Entwicklung TDD-Verbot oder miese Coding-Guidelines. Insbesondere die Unternehmen, die keinen Verbesserungsprozess aus dem Team heraus gestatten oder fördern, untergraben die tägliche Arbeit und damit das tägliche Commitment. 

Brutal ist das nicht nur am eigenen Leib zu erfahren, sondern auch im Gespräch mit anderen. Ich kann mich noch zu gut an eine Interview-Reihe erinnern, die ich durchgeführt hatte: "Ich möchte gute Arbeit leisten, aber mir wird gesagt, ich soll schlechte Arbeit machen! Das ist ausreichend, nur nicht mehr rein stecken. Ich verzweifle hier."

Ob sich in diesem Unternehmen etwas geändert hat, ich hoffe schon, denn schon ein schlauer Mann hat mal gesagt:

Eliminate barriers that rob people of their right to pride in workmanship.
— W. E. Deming

Erste Schritte

Wie kann man einem Team seinen Stolz geben? Hier ein paar Punkte zum ausprobieren:

  • Applaudiert ihnen im Review
  • Lasst sie nur das in den Sprint ziehen, was sie schaffen
  • Belastet Teams nicht mit künstlichen, unrealistischen Fristen
  • Lasst sie ihre Arbeit verbessern und ihre Qualität erhöhen
  • Bringt sie mit Endnutzern in Kontakt
  • Released häufiger
  • Gebt euren Team-Mitgliedern den Auftrag zuhause oder bei ihren Freunden ihr Produkt vorzustellen

SVNWNK

ScrumMasters Advice: Fragilität vs. Risiko

Eine oft gestellte Frage ist: "Wie bringe ich Risiken in der Agilität unter?". Ich empfehle den folgenden Perspektivenwechsel:

Wir haben das Problem, dass wir uns auf schwer planbaren, ungewissen Terrain bewegen. Auf diesen Terrain setzen wir uns mit bekannten und unbekannten, potentiell gefährdenden Ereignissen bzw. Risiken auseinander. Bei näherer Betrachtung stößt man immer wieder auf die Punkte:

  1. Ob ein Ereignis eintritt lässt sich schwer vorhersagen.
  2. Spricht man bei seltenen Ereignissen davon, dass es unmöglich ist die Auswirkungen zu kalkulieren.
  3. Vermutet man nur die Eintrittswahrscheinlichkeit bekannter Ereignisse (Prognose eines Risikos), unbekannte erschließen sich erst bei oder nach ihrem Eintreten.

Fragile hearts by clumsy_jim, licensed under Creative Commons, taken from Flickr.com

Nimmt man die 3 Punkte ernst, dann führt das dazu, dass die meisten Prognosen nur indirekt hilfreich sind, indem sie unser Vorstellungsvermögen reizen uns aber beim Problem alleine lassen.

Was uns leichter fällt

Blicken wir stattdessen auf das System, auf das sich das Ereignis auswirkt, dann können wir benennen wie fragil das System sich bezüglich des Ereignisses verhält. Es kann davon profitieren oder geschädigt werden. Die Einschätzung, ob etwas fragil ist, fällt uns leichter als das Eintreten von Ereignissen zu bestimmen.

Empfehlung

Einem ScrumMaster empfehle ich daher die fragilen Systeme zu suchen und sie durch Systeme zu ersetzen, die im besten Fall vom Eintreten, von unvorhersagbaren Ereignissen profitieren. So mildern wir das Eintreten von Ereignissen nicht nur ab, sondern profitieren auch davon.

Ein Beispiel für ein fragiles System ist die hierarchische Planung, das Aussteuern von Personen und die oft damit verbundene Arbeitsteilung. Wir ersetzen in agilen Organisationen das durch gemeinsame Planung (responsibility-based planning), selbstinformierende Arbeitsplätze (self-directing workspace) und Team-Arbeit.

SVNWNK

Was haben Sekretärinnen und ScrumMaster gemeinsam?

Ich erinnere mich an eine Diskussion zwischen Boris und Fabian zurück. Es geht darum ob Slack ein fester Bestandteil von Scrum sein sollte. Fest im Sinne von "explizit erwähnt in den Guidelines". Das Gespräch drehte sich um Innovationsfähigkeit und ob es nicht schlichtweg die Aufgabe eines ScrumMaster ist den Rahmen für Slack aufzubauen.

Wenn man Slack genauer betrachtet, gibt es verschiedene Ausprägungen von Slack. Die bekannteste ist der Time-Slack: z. B. 20% der Arbeitszeit für eigene Projekte. Daneben steht der Control-Slack: z. B. die Entscheidung über den eigenen Entwicklungsprozess an die Mitarbeiter zu geben. Beides zusammen hilft Organisationen sich weiterzuentwickeln.

A just a slackline. It bends and gives slack for innovative tricks. The pictures is called "Walking over Sarajevo", taken by by Nicolò Paternoster, published by CC-BY-SA-3.0, via  Flickr.

Unternehmen sind auf Veränderung angewiesen. In dem was sie tun und wie sie es tun. Laste ich Mitarbeiter zu 100% aus, so fehlt ihnen der Spielraum sich weiterzuentwickeln. Es können keine neuen Techniken, Tools, Methoden und Werkzeuge erlernt werden. Zum anderen verfolgen zu wenige neue Ideen. Innovation wird zu einem Rinnsal.

Veränderung umzusetzen ist Aufgabe von allen im Unternehmen, nicht von einzelnen. Hierzu benötigt man Freiräume zum Lernen, Scheitern, Ausprobieren. Ohne Freiräume keine Veränderung von innen heraus und keine Chance stetig auf Veränderung von außen reagieren zu können.

In beiden Fällen fällt es schwer sich zu verbessern. Man stolpert lieber mit schlechten Schuhen, statt sich andere anzuziehen. Oder anders gesagt: 

"Wenn ich stetig mit dem Kopf unter Wasser schwimme geht mir nicht nur die Puste aus, ich bekomme auch nicht mit was über der Wasseroberfläche alles passiert."

Von Sekretärinnen und ScrumMastern

Was haben die beiden nun gemeinsam? Es ist der Slack. Ein großer Wert bei einer Sekretärin ist, dass sie Freiräume hat, sprich Slack. Sie ist nicht zu 100% ausgelastet weil verplant, sondern kann auf Ereignisse und Anfragen reagieren. Sie kann helfen, wenn andere keine Zeit haben und das hilft der gesamten Organisation. Gleiches gilt für den ScrumMaster. Er hat per se Slack für ungeplante Aufgaben und Hindernisse. Dinge die passieren, die niemand plant. Er kann die Fäden aufheben, die herunterfallen, zudem den Rahmen schaffen, damit Innovation und Veränderung stattfindet.

SVNWNK

PS: wer wissen möchte, was Manager und Immobilienmakler gemeinsam haben liest hier weiter

PPS: Ein guter Stolperer fällt nicht. Ob wir alle gute Stolperer sind und damit trotzdem schnell genug sind ist eine andere Frage. Ich für mich verzichte gerne auf Schreckmomente und unnötige Adrenalinstöße.

Wie viel Zwang verdient ein Team?

Auf einem Open Space war ich in der Session: "Wie viel Zwang ist gegenüber einem Team in Ordnung?". Für mich war die Session bizarr, bedrückend, belustigend, beängstigend - und unglaublich widersprüchlich.

Das Szenario war ein "gut funktionierendes Testteam", laut dem Erzähler: ein Team von Freunden. Auf dem Weg zu Agile, so meinte er, war es notwendig die Auflösung zu erzwingen und eine Umverteilung zu anderen Teams anzuordnen. Feature Teams war der geplante Schlüssel zum Erfolg und nach einiger Zeit stellte sich auch eine positive Wirkung ein, trotz anfänglichem Widerstand, Ärger und Unstimmigkeiten. Lokale Optimierung wäre ein furchtbares Übel, und die Notwendigkeit für globale Optimierung sei sein großes Anliegen.

Auf meine Frage hin "habt ihr das Team vorher gefragt, sie mit den Informationen konfrontiert, die euch zum Handeln veranlasst haben?", antwortete er: "Nein, sie hätten sich sicher nur gesträubt, da sie ein eingespieltes Team wären und das große Ganze nicht sehen würden."

Ein Widerspruch?

Kommen wir zu den Punkten, die mir nicht besserwisserisch und doch schwer im Magen liegen. Agile ist bedeutungsschwer mit dem Stichwort Selbstorganisation  verknüpft. Vereinfacht bedeutet Selbstorganisation ein Ausgleich an Mitteln und Verantwortung sowie dezentrale Entscheidungen an der erstmöglichen Stelle, die die Frage beantworten kann. Oder klassisch ausgedrückt: eine Verschiebung von Entscheidungen aus dem Management in die unteren Hierarchieebenen. Damit das funktioniert ist der Ausgleich von Information zur Verantwortung notwendig.

"Camp Delta in Guantanamo" by Christian Seebauer (Own work) CC-BY-SA-3.0, via Wikimedia Commons

Wie passt das nun zum obigen Beispiel? Ganz einfach: Hier schickt man mit Agile Leute in die Selbstorganisation und traut ihnen gleichzeitig nicht zu richtige oder wichtige Entscheidungen für das Unternehmen zu treffen. Die Entscheidung wie man sich ggf. besser organisieren könnte. Man traut ihnen nicht zu, dass, wenn sie die Informationen bekommen, sie sich für das Wohl der Organisation entscheiden und es ggf. über die eigene Schwerfälligkeit stellen. Daher fragt man sie vorher gar nicht und verschwendet das Potential eines gemeinsamen konstruktiven Wegs. Ein Solcher birgt die Möglichkeit sich schrittweise auf etwas hinzubewegen, was das Problem auch adressiert. Es gibt mehr als eine Option Zusammenarbeit zu verbessern, vielleicht fände man etwas, an das ein paar Wenige gar nicht gedacht haben und besser funktionieren würde als ein Pauschalrezept.

Stattdessen fällt es nur zu leicht zu sagen: "Ich kenne die Antwort, andere werden nur falsch entscheiden". Unterstellt wird dann oft, es geht nicht anders, denn außerhalb meines Kopfes herrscht Unwissenheit, mangelnder Intellekt, Bequemlichkeit oder gar Boshaftigkeit. Ironischerweise tragen im nächsten Schritt die Teammitglieder die Entscheidung und Konsequenzen, sollen ihr Bestes geben und ohne Murren Entscheidungen hinnehmen. Hier fordert man dann die erwachsene und professionelle Reife ein, die vorher nicht zugetraut wurde. Vielleicht redet man sich noch ein, etwas Gutes getan zu haben, denn man hat sie dann "zum Glück gezwungen" und "nicht mit einer Entscheidung belastet".

Fazit

Dass eine Veränderung in diesem Beispiel etwas Positives bewirken kann, zweifle ich nicht an. Was mir fehlt ist der Respekt gegenüber den Menschen. Wie viel von dem mangelnden Respekt Selbstüberschätzung, fehlende Courage, Kommunikationsfertigkeit oder Konfliktfähigkeit ist, kann jeder selbst entscheiden. Egal wie man es sieht, für mich persönlich ist das ein Weg ganz weit weg von Agile, denn wenn ich ernst nehme, was hinter dem Gedankengut steht, dann gehören die Entscheidungen über die Organisation der eigenen Arbeit zu den Menschen, die sie ausführen:

The best architectures, requirements, and designs
emerge from self-organizing teams.
— http://agilemanifesto.org/principles.html
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
— http://agilemanifesto.org/principles.html
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
— http://agilemanifesto.org/principles.html

Debriefing - Das Schließen einer Welt

Zielsetzung und Rahmen

Persönlich hilft ein Debriefing beim Reflektieren, Lernen sowie Transferieren und Weitergeben von Erfahrung, Gruppen ziehen Schlüsse, treffen Entscheidungen und planen etwas umzusetzen. Nach einer Übung kann man es den Teilnehmern überlasse selbst zu reflektieren, oder man unterstützt sie, indem man die Übung nachbespricht und zusammenfasst was wesentlich für die Teilnehmer war. Dazu gehört was sie weitergeben bzw. teilen möchten und welche Schritte sie als nächstes planen.

Ein Debriefing benötigt etwas Zeit am Ende der Übung, daher plane zwischen 5 und 15 Minuten dafür ein. Wie lange genau hängt von der eingesetzten Methode, der Nummer der Fragen und der Anzahl der Teilnehmer ab.

Fragen

Was genau nachbesprochen bestimmst Du anhand der gestellten Fragen. Daher solltest Du, bevor Du die Übung startest, die paar Fragen vorbereiten, die dich deinem gewünschten Ziel näher bringen. Ziele lassen sich inhaltlich gliedern oder bspw. nach Emotion, Beobachtung oder den gezogenen Schlüssen der Teilnehmern. Hier sind einige meiner favorisierten Fragen:

  1. Was war interessant?
  2. Was war faszinierend? 
  3. Was war überraschend? 
  4. Wann hast Du dich unwohl gefühlt? 
  5. Was hast Du gelernt?
  6. Was von dem Gelernten wirst du wie auf der Arbeit einsetzen? 
  7. Was wirst Du in den nächsten 48 Stunden anders machen? 
  8. Was passierte als...? 
  9. Wie hast Du dich gefühlt als...?
  10. Was wäre passiert, wenn...?

Ich empfehle 3-5 Fragen mit der Tendenz zur Untergrenze. Die Fragen wählst Du im Kontext deiner Übung aus, überlege dir dein Ziel bzw. unterstütze das Ziel deiner Übung. Nimm eine Mixtur von Fragen, die Emotion, Beobachtung und Lernen mit einschließen. Menschen reagieren auf gleiche Fragen unterschiedlich. Die gemachten Erfahrungen unterscheiden sich in Beobachtung, Emotion und den gezogenen Schlüssen, was zu weiteren Einsichten und Konfusion führen kann - beides ist ein guter Boden um zu lernen.

Methoden

Wie Du nachbesprichst liegt an der Methode, die Du auswählst. Für gewöhnlich gewährt man den Teilnehmern einen kurzen Moment zum Durchatmen und für die persönliche Reflektion. Ich bevorzuge es danach mit einer persönliche Übung zu starten, bevor die Einsichten mit der Gruppe geteilt werden. Hier sind meine favorisierten Methoden für ein Debriefing:

a) Offene Stichwortabfrage: frage die Teilnehmer die Fragen und dokumentiere ihre Antworten auf einem Flipchart. Für gewöhnlich möchten die meisten Teilnehmer ihre Erfahrung teilen. Daher achte darauf, dass die Redeanteile fair verteilt werden. Die, die viel reden müssen evtl. gebremst werden. Diejenigen, die ruhiger sind kannst Du aufmuntern teilzunehmen, indem Du sie direkt ansprichst. Sei aufmerksam wer welche Zeichen sendet (Körpersprache/Mimik).

By U.S. Navy photo by Mass Communication Specialist 1st Class Monica Nelson [Public domain], via Wikimedia Commons

b) Verdeckte Kartenabfrage: bereite ein Starfish-Retrospektive auf Flipchart vor und benutze deine Fragen anstelle der Starfish-Fragen. Starte damit, dass die Teilnehmer ihre Erfahrungen auf Post-its aufschreiben. Gib ihnen dafür eine Timebox von 1-2 Minuten, evtl. möchtest Du auch die Anzahl der Post-its pro Frage auf 1-3 einschränken. Sobald die Zeit um ist, startet die erste Person, steht auf und hängt ihre Erfahrungen auf das Flipchart. Ein, zwei kurze Sätze sollten einen jeden Post-it begleiten.

Closed keyword format: pepare a starfish retrospective flip chart and use your debriefing questions instead of the starfish questions. Let people write down their experience on notes. Give them 1-2 minutes to write it down, maybe you want to limit the number of notes per question to 1 or 2. As soon as finished the first person stands up, sticks the notes to the flip chart and says one sentence about it.

c) Lighting talk: jede Person bekommt eine Timebox von 1-2 Minuten und kann über ihre Erfahrungen reden. Stell deine Fragen bevor sie starten und gib den Teilnehmern eine kurze Pause bevor es an das Teilen der Erfahrung geht.

Noch ein paar Worte

Es kommt oft vor, dass Menschen enttäuscht sind, wenn sie ihre Erfahrungen nicht teilen konnten. Deshalb ist es ratsam die Themen, die geöffnet wurden auch zu schließen. Bei einem Debriefing steht das Lernen im Mittelpunkt, daher solltest Du es ernst nehmen.

SVNWNK

 this article in English: click