Wenn das Gesicht mit der Schulter zuckt

Gesehen habt ihr diese Mimik alle schon: Die Mundwinkel zieht es nach unten und der Kinnbuckel kommt hoch. Diesen Gesichtsausdruck nennt man den "Facial Shrug", er steht für Dreierlei:

  1. das mimische Schulterzucken, um Unwissenheit oder Unsicherheit auszudrücken
  2. um Respekt zu zollen ("das war ja gar nicht übel" oft in Kombination mit Kopfnicken)
  3. ein Einwandsignal, hindeutet auf Unsicherheit oder Verneinung

Anna Ingordino mit einem Facial Shrug :-)

Ein Gesichtsausdruck und drei mögliche Interpretationen. Was auch heißt, wir liegen zwar vielleicht mit unserer Beobachtung richtig, die Interpretation ist jedoch unsicheres Terrain. Sehen wir uns ein Beispiel dazu an.

Fallbeispiel

Szenario: Wir planen die nächsten Schritte. Gerade schließen wir einen Schritt ab und fragen: "Ist jedem klar, was hier zu tun ist?"

Beobachtung: Ihr seht bei zwei Personen einen "Facial Shrug" über das Gesicht huschen. Person A nimmt sehr aktiv an der Planung teil und beantwortet viele Fragen. Person B war sich bisher immer wieder unsicher und hatte Fragen.

Interpretationen: Ausgehend von dem Kontext, den wir kennen, lassen sich mehrere Interpretationen spinnen:

  1. Starten wir mit Person B. Sie könnte zu dem Zeitpunkt unsicher sein, ob sie alles verstanden hat. Es könnten auch noch nicht formulierte Einwände existieren, die später zu Blockaden führen.
  2. Bei Person A kann das anderes aussehen. Es könnte sein, dass die Klärung für sie so effektiv war, dass sie mimisch Respekt zollt. Vielleicht reagiert die Person auch nur gedanklich auf die Frage mit: "Ich habe keine Ahnung ob die anderen es verstanden haben".

Ungeachtet der Qualität der Frage und der Interpretation, die man wählt: Wie macht man weiter?

  1. Es ist legitim das Thema nochmals zu öffnen, indem man die Beobachtung anspricht und für Klarheit sorgt.
  2. Auch kann man über die Beobachtungen hinweg gehen und die nächsten Schritte vorantreiben.

Ich empfehle hier aber mindestens weiter zu beobachten wie sich die beiden Personen bei dem Thema verhalten. Daraus lassen sich interessante Rückschlüsse ziehen. Lag wirklich ein Einwand vor? Wäre es besser gewesen das direkt zu klären?

Wer möchte, der spricht das Beobachtete gleich an, oder öffnet nochmals den Raum für eine kurze Klärung. Auch ein Nachfragen später unter 4 Augen kann zur Klärung führen. Hierbei sollte man jedoch beachten, dass Menschen oft nicht bewusst ist, was sie mit ihrem Gesicht ausdrücken. Zusätzlich kann der Moment schon wieder vergessen sein.

Abschließend ist es gut zu wissen, dass Mimik sehr schnell sein kann. Ist die Bewegung schneller als 500 ms, dann spricht man von einer Mikroexpression. Das ungeschulte Auge übersieht somit oft die Bewegung, selbst wenn es die Bedeutung des Ausdrucks kennt.

SVNWNK

Zeit zu üben ;-)

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

Das Humpty Dumpty Syndrom

"Humpty Dumpty saß auf dem Eck, Humpty Dumpty fiel in den Dreck und auch der König mit seinem Heer, rettete Humpty Dumpty nicht mehr."

Quelle: https://de.wikipedia.org/wiki/Humpty_Dumpty

Der moderne Humpty Dumpty

924px-Denslow's_Humpty_Dumpty_1904.jpg

Kennt ihr das? Ihr merkt früh, dass in eurer Entwicklung etwas in Schieflage gerät und eigentlich muss man jetzt etwas verändern. Ihr sprecht es an und bekommt die Rückmeldung: "Keine Panik, das wird nicht passieren und wenn es passiert, dann hau' ich euch mit Manpower raus!" Eventuell setzt man noch eins drauf: "Bitte behalte deine Gedanken bzgl. dieses Problems für dich, sonst machen sich die Leute nur sorgen."

So in der Art geht es dem guten Humpty Dumpty von Alice im Wunderland auch. Er weiß zwar, dass er auf einer dünnen Mauer sitzt und für ihn als Ei das mehr als gefährlich ist, aber er verdrängt es. Zudem ist er der Meinung: Mein König haut mich da schon wieder raus.

Jetzt sitzt ihr also sprichwörtlich auf einem schmalen Grat mit der Hoffnung, dass euch euer König raushaut, wie Humpty Dumpty. Auch wenn das manchmal gut gehen kann, wird doch viel zu oft der Grat auf dem ihr sitzt schmaler und schmaler.

Der Sturz

Wer spät in der Entwicklung reagiert, der verursacht meist mehr Schaden als Nutzen (vgl. B. Brooks Law). Das Problem mit dem man oft konfrontiert ist, ist laut Gerald M. Weinberg und Brooks:

"Managers are often foolishly optimistic about things going well. Moreover, when thing do go poorly, manager imagine that they will get better by themeselves."

Das Problem wird nicht erkannt und selbst wenn es erkannt wird, dann fehlt das Wissen damit umzugehen. Sie verfallen in das Humpty Dumpty Syndrome. Abwarten, verzögern und auf Wunschdenken spielen.

Wenn dann letztlich anerkannt wird, dass ein Problem existiert, dann wird massiv gerudert. Was das System durch nicht-lineare Effekte aus den Fugen brechen lässt. Weinberg dazu:

"Instead of merely making the project late, a sufficiently foolish manager can make the project collapse."

Das Problem wird mitunter dadurch verstärkt, dass die erzeugten Änderungen sowohl die Arbeitslast erhöhen als auch die Effektivität der Arbeitenden verringern. Zudem führt ein zu langes Abwarten dazu, dass Änderungen kaum mehr Effekt haben, außer man macht sie groß, was dazu führt, dass jede Menge nicht-lineare Seiteneffekte auftreten.

Früh mit kleinen Schritten

Arbeitet man früh mit dem Feedback aus dem System, indem man die Signale der Menschen wahrnimmt, so lässt sich schnell und leicht entgegen arbeiten und man hat sogar noch Zeit zum Experimentieren. Mit frühen Änderungen lassen sich insbesondere positive Feedback-Zyklen durchbrechen, sodass diese keinen größeren Schaden anrichten können.

Ein Beispiel

Zwei Abteilungen arbeiten zusammen: Frontend und Backend. Das Frontend-Team muss das Backend stetig integrieren und ist stark vom Wissen über deren Schnittstelle abhängig. Die Integration läuft schleppend bis gar nicht, ein echter Test kann nicht stattfinden. Ein kleiner Schritt wäre jetzt das Komponenten-Team Frontend zu einem echten Feature-Team zu machen, indem man eine Person aus dem Backend-Team hinzufügt. Integration, Done und die Lieferfähigkeit wären gestärkt durch eine kleine Änderung des Team-Setups hin zu Cross-Funktionalität.

Unterlässt man das und verschleppt sich die Integration weiter und damit die fertiggestellten Features (partially done == waste), so steigt die Tendenz eine große Änderung vor Schluss zu tätigen. Beispielsweise erkennt man die Not der Integration und setzt weitere Teams (z. B. Integration, Test) auf. Oft explodieren an der Stelle dann nicht nur die Kosten, sondern das gesamte System. 

SVNWNK

Literatur

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:

Schläfst Du schon oder grübelst Du noch?

Wer grübelt oder sich sorgt, schläft nicht gut. Kurzum, wer unter emotionaler Anspannung steht, sucht nachts öfter mal erfolglos den Schlaf. Man ist zwar körperlich anwesend, bleibt aber gedanklich und emotional im Alltag verhaftet. Oft sind es Alltagsprobleme, die mit zu Bett gehen. Meist fehlt die Distanz und die betroffenen Personen schaffen es nicht, sich aus der Pflicht zu nehmen. Es fehlt die Entspannung und "wer zum Schlafen ins Bett geht, bleibt wach" (Weeß).

"Darkness into light" von jasleen_kaur (Creative Commons 2.0 - adapted to bw), Flickr

Als Ursachen für Schlafprobleme gelten überwiegend persönliche Probleme und Belastungen am Arbeitsplatz. Über beides sorgt und grübelt man dann abends im Bett.

Grübeln ist das wiederkehrende Nachhängen, Nachdenken über etwas Vergangenes. Beginnend mit Reflexion hin zu einem Teufelskreis an Gedanken wie etwas anders hätte laufen sollen, was man besser machen oder unterlassen hätte können sowie die Gedanken darüber wie ein Problem am besten gelöst wird - meist kritisch wertend mit hohem Selbstbezug. Die beteiligten Emotionen sind vorrangig Trauer, Scham und Ärger. Grübeln ist mitunter auch gefährlich, da es im Zusammenhang mit Depression stehen kann.

Sorgen ist auf Ereignisse in die Zukunft ausgerichtet. Man fürchtet sich vor möglichen auftretenden Problemen, Ereignissen sowie Ergebnissen und sucht gedanklich nach Möglichkeiten zur Veränderung oder Vermeidung. Die vorrangige Emotion ist Angst.

Die am stärksten von Schlaflosigkeit betroffenen bzw. von Schlafproblemen gepeinigten Berufsgruppen sind Politiker und Führungskräfte. Hier fallen auch ScrumMaster und Product Owner darunter, die mit ihrer Verbundenheit zum Team und Produkt die eine oder andere schlaflose Nacht verbringen. Im Schnitt schlafen die meisten von uns zu wenig. Etwas mehr als 8 Stunden pro Tag sollten wir durchschnittlich schlafen. Zudem zeigte eine Studie über 24 Länder hinweg, der Trend geht zu noch weniger Schlaf (1). Laut Dr. phil. Dipl.-Psych. Hans-Günter Weeß leben wir in einer unausgeschlafenen Gesellschaft, die unter der Woche Schlafschulden aufbaut und am Wochenende wieder abbaut. 

Die Konsequenzen von fehlendem Schlaf sind vielseitig: Die Übermüdung während der Woche führt, neben Produktivitätseinbußen durch z. B. Konzentrationsstörungen, auch zu einem Emphatie- und Werteverlust. Verschiedene Dinge werden gleichgültig, wenn das Ziel "beenden, gehen und schlafen" ist.

Lösungsansätze

Neben professioneller ärztlicher Behandlung lohnt ein Blick in die Literatur (siehe unten). Die nachfolgenden Punkte sollen beides nicht ersetzen. 

Entscheidungen treffen

Manchmal geht es schlichtweg darum eine Entscheidung zu treffen, hier können Gespräche, Beratung oder Coaching helfen. In jedem Fall muss man zur Entscheidung kommen, damit man die Schleife darum herum wegbekommt.

Grübeln

Weniger Grübeln kann zu mehr Schlaf führen.

Da Personen beim Grübeln einen Kontrollverlust erleben und nicht mehr aus der Schleife heraus kommen, kann es helfen es unter die Lupe zu nehmen und die Aufmerksamkeit zu schulen, um eine flexible Kontrolle über die eigenen Gedanken zu erlangen. Das geht z. B. mit auditiven Übungen mit wiederkehrenden gleichen und unterschiedlichen Geräuschen. Zunächst konzentriert man sich auf ein Geräusch, später dann auf die Wechsel von Geräuschen (siehe dazu Tobias Teismann). Diese einfache Übung stärkt die Kontrollerfahrung.

Auch ein Aufschieben und bewusstes Konsumieren von Grübeln und Sorgen kann Abhilfe schaffen. Hierzu notiert man sich die Themen, die einen ins Grübeln bringen, und schiebt die Auseinandersetzung auf ein eigenes dafür eingerichtetes Zeitfenster. Das kann zu bis zu 30 % weniger Grübeln führen.

Weitere probate Mittel um Aufmerksamkeit zu binden und Kontrolle und Pausen zu bekommen sind: Ablenkung, Aktivität und Wahrnehmen des Moments mit den eigenen Sinnen.

SVNWNK

(1) - 36 % der Befragten gaben an, dass sie weniger als vor 5 Jahren schliefen, 49 % gleich viel, 14 % mehr als vorher.

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

 

Kompetenz als Einbahnstraße - was passiert wenn die Latte zu hoch liegt?

Was passiert, wenn Sie als Hochspringer die Latte über das Maß Ihrer Fähigkeiten legen? Sie reißen die Latte und nach weiteren Kontrollsprüngen stapeln Sie wieder tiefer.

ISTAF Berlin 2010: Siegerin Hochsprung Ariane Friedrich. 
Bild von André Zehetbauer (CC BY-SA 2.0) gefunden auf Flickr

In der Arbeitswelt klafft zwischen Anspruch und Wirklichkeit oft eine Lücke und gerade Führung wird häufig dahingehend gestresst, dass die Kompetenz für die Rolle/Positon fehlt.

Einen Erklärungsversuch hierfür hat der kanadische Pädagoge Laurence J. Peter:

Das Peter-Prinzip

Das Peter-Prinzip besagt, dass der Aufstieg bei Berufstätigen sie dort hin führt, wo sie dem Anspruchsniveau nicht mehr gewachsen sind. Es wird der Punkt erreicht an dem die Fähigkeiten nicht mehr ausreichen und die Latte zu hoch hängt. Da eine Zurückstufung einer Degradierung gleich kommt, verweilen die Personen in der Lage und stecken zumindest einen Teil ihrer Anstrengung ins Kaschieren der eigenen Unfähigkeit.

Hierarchien begünstigen den Aufstieg, sind sie doch die Wege nach oben in die eigene Unfähigkeit. Klassischerweise sind die Wege nach oben in den meisten Organisationen Wege in die Führungsriege. 

Glücklicherweise sind in den Organisationen nicht alle Positionen mit Unfähigen besetzt. Somit kann Arbeit noch von denen erledigt werden, die noch nicht ihre Stufe der Unfähigkeit erreicht haben.

Ein Blick auf die Kulissen

Was hier helfen kann ist ein Blick auf und hinter die Kulissen:

  1. Welche Rollen und Positionen werden in der Organisation als Anreiz, Belohnung und Statussymbol vergeben?
  2. Sind die Ansprüche an die Rollen/Positionen benannt, dokumentiert, bekannt und prüfbar?
  3. Wie und wie oft evaluiere ich die erfolgreiche Besetzung der Rollen?
  4. Wie gehe ich als Führungskraft mit Sachzielen um?
    1. Vertrete ich Konfliktfall die Ziele der Organisation?
    2. Ordne ich als Führungskraft Sachziele der persönlichen Beziehung unter?
  5. Welche Schritte gibt es, wenn die Latte zu hoch hängt?

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

Selbst-Management mit der Pomodoro-Technik

Alles Tomate...

Die Pomodoro-Technik ist eine Technik um den eigenen Fokus zu erhöhen, indem man den Tag in kleine Häppchen von 25 Minuten unterteilt (Iterationen). Innerhalb der Zeit arbeitet man dann störungsfrei an den ausgesuchten Aufgaben. Denn 25 Minuten kann jeder fokussiert arbeiten und bei Störungen kann man jeden auf 1-25 Minuten später vertrösten.

Nach der Iteration kommt eine Pause für den Spannungsabfall, sodass konzentriert der nächste Pomodoro gestartet werden kann. Mit ein wenig Übung schafft man mit Pomodoros deutlich mehr, als man sonst erreichen würde.

Mehr zur der Technik findet ihr unter: http://pomodorotechnique.com/

Wenn ihr einen Timer sucht, dann nehmt z. B. den hier: http://tomato-timer.com/ oder Hardware (achtet jedoch auf euren Gegenüber wegen dem Lärm):

Ein Pomodoro-Timer, der Namensgeber für die Technik. Bild von alexhung lizensiert unter CC 2.0 - Titel Respect the Pomodoro (Flickr)

Wer nicht weiß womit er starten kann, der startet z. B. so in den Tag:

  1. Pomodoro: 25 Minuten Mails lesen und beantworten (danach Mailprogramm aus)
  2. Pomodoro: 25 Minuten Aufgaben des Tages festlegen
  3. Pomodoro: 25 Minuten an der ersten Aufgabe arbeiten

Ein großartiger Nebeneffekt eines Pomodoros ist, dass man Selbstbeherrschung damit trainiert und damit sein Gehirn.

Und noch ein Tipp für die Praxis, gebt euren unmittelbaren Kollegen Bescheid wenn ihr mit der Technik arbeitet. Zum einen haben sie vielleicht selbst Interesse, zum anderen stören sie euch dann in der Zeit vielleicht nicht.

SVNWNK

Ihr macht dann mal Scrum...

Oder die Geschichte vom Oxymoron: Was Scrum zum Hallenfreibad macht.

Wenn Scrum nichts mehr mit Agile zu tun hat

Bild von Sir James (Wikipedia/CC 2.0)

Der Grundgedanke von Agile ist es, dem Team mehr Selbstverantwortung zu geben. Ein zentraler Punkt ist das Verständnis für die eigene Situation und Lage zu erhöhen. Nur wer versteht wo er steht und was er macht, der kann angemessen anpassen. Wer versteht, der kann gestalten. Wer Sinnhaftigkeit in seiner Arbeit sieht, der möchte gestalten. Die drei Punkte führen dazu, dass wir erfolgreicher, ausgeglichener und gesünder leben und arbeiten.

Wo steht Agile?

Gerade Agile zielt auf das Gestalten der eigenen Prozesse und Bedingungen ab. Ein aufgezwungenes Scrum als Methodik hat nichts mehr mit Agile zu tun. Es steht im krassen Widerspruch zu den agilen Prinzipien:

The best architectures, requirements, and designs emerge from self-organizing teams.”

”Build projects around motivated individuals. Give them the environment and support they need,
and trust them to get the job done.”

”At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
— http://agilemanifesto.org/principles.html

Wer diese Prinzipien ernst nimmt, der stimmt damit überein, dass ein Team nicht nur die Wahl des eigenen Prozesses in der Hand hat, sondern auch für die Veränderung verantwortlich ist. Wer es seinem Team noch nicht zutraut diese Reife zu besitzen, der kann das Team dabei unterstützen die notwendige Reife zu erlangen. Das vollzieht man beispielsweise durch den Einsatz von Transparenz und Analyse der Situationen bei Hand. Gemeinsame Planung, transparente Arbeitsorganisation, Retrospektiven, Reviews und kurze Feedback-Zyklen helfen.

Dadurch landet man wieder bei dem Dilemma, dass Scrum helfen kann. Das bewusst zu machen (Verständnis schaffen) und die Sinnhaftigkeit zu verdeutlichen, kann den Impuls für die Gestaltung und das Einlassen mit sich bringen.

SVNWNK

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

Das große M

Tom DeMarco nennt es die große "M"ethodik. Das große M stellt eine Dysfunktion in Organisationen dar. Man spricht davon, wenn blind auf eine Methodik vertraut wird und man die Methodik höher stellt als die Menschen, die sie ausführen müssen. Wem das vertraut vorkommt, dem ist der Teilsatz "Scrum-Einführung mit Management-Support" sicherlich bekannt.

Die Einführung einer Methodik vollzieht man auf zwei Arten:

  1. Methodik als Mittel angepasst an Situation, Plan und Organisation
  2. Methodik als Standard, auszuführen nach Rezept

Nutzt man eine Methodik, um sie wie bei 1. selbst an die eigenen Bedürfnisse anzupassen, wird man wenig an der Sinnhaftigkeit der Methodik zweifeln. Wichtig ist hier, sich seines Systems in dem man sich befindet klar zu sein. Obwohl die meisten Menschen sofort bejahen, dass sie diesen Überblick haben, wird auf den 2. oder 3. Blick meist klar, dass das nicht der Fall ist.

Wenig Raum in dieser Gasse - vielleicht eine Abkürzung aber sicher kein Raum für beste Ergebnisse.

Schreibt man eine Methodik wie bei 2. vor, die zwanghaft umgesetzt werden muss, verringert man den Status der Menschen, die man zur Methodik zwingt. So sagt man ihnen doch deutlich, dass die Kompetenz bei der Methodik liegt und nicht in den Köpfen der Menschen. Man degradiert sie und sie antworten mit angepasster Methodenhörigkeit als Protest, angedeuteter Inkompetenz als Widerstand oder offenen Anfeindungen als Ablehnung. Tritt ein Fehler auf, kann man ihn der Methodik zuschieben, man ist die Verantwortung los - prima!

Durch die Entmündigung verliert man das Commitment, da die bestmögliche Leistung und der Stolz der Menschen durch die Methodik blockiert wird.  Das ist nur die menschliche Seite. Die Imitation führt oft auch zu mangelhaften Ergebnissen, da Situationen nicht 1:1 übertragbar sind und methodenabhängige Folgeeffekte in jeder Umgebung wünschenswert sind.

Was ich nicht sage

Methoden "by the book" auszuführen ist schlecht. Das sehe ich nicht so.

Meiner Erfahrung nach waren beispielsweise die erfolgreichsten Scrums die, die "by the book" umgesetzt wurden. Jedoch lag dort auch immer der Fokus auf den Menschen und der Interaktion, und die Methodik war nicht Aggressor. Insbesondere dort wo ein Standard fehlt, kann eine Methode eine Baseline setzen. Wenn man seine Arbeitsweise ändert, lohnt es sich an einen Standard zu halten und sich davon aus fortzubewegen.

Was ich sage

Menschen benötigen die Herrschaft über ihre eigenen Prozesse. Keine aufgezwungen Prozesse, die fern ihrer Realität aufgezwungen werden.

Ein Beispiel:

Eine Abteilung wurde bestimmt der Prototyp für eine Scrum-Skalierung zu werden: 3 Teams, neu geschnitten und alle direkt nach Scrum arbeiten. Was für zwei Teams eingeschränkt in Ordnung war, war bei einem Team extrem kontraproduktiv, da sie bereits ihren besten Prozess gefunden hatten: ein Flow-System von der Anforderung direkt in die Produktion, optimiert von den Menschen, die bereits jahrelang Erfahrung mit ihrem eigenen System hatten. Einige neue Praktiken hätten sicherlich geholfen. Das fremde Paket zerstörte Motivation, Commitment und Durchsatz.

Was man noch bedenken sollte

Alle, die seit Jahren auf den Scrum-Hype aufspringen und alles Scrumatisieren verpassen eines: die Vielfalt es besser machen zu können. 

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