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?

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

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

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 

Transparenz - Sicher, dass ihr damit umgehen könnt?

Enterprise, you want to go agile - sicher das ihr das möchtet?

Hab ihr das ernsthaft vor, dann stellt euch auch die Frage: "Können wir mit den Folgen, Effekten und Seiteneffekten von Transparenz umgehen?"  

Wenn ja, dann nehmt das "wir" und fügt stattdessen folgendes ein:

Management, Menschen und Kultur

Die Effekte von Transparenz reichen weit und ankern tief in der Unternehmenskultur. Es geht darum, wie im Unternehmen mit Problemen umgegangen wird: Heißt ihr Probleme willkommen, verneint ihr sie oder schlimmer, beugt ihr euch vor ihnen und gebt auf und sagt dabei: "Das ist wie es läuft - akzeptiert es." 

Eine weitere Frage ist wie lange dauert es bei euch Probleme zu lösen und ab wann greift Frustration um sich und geht man in eurer Organisation mit einer solchen Frustration um? Die Schlüsselfrage ist hier: Seid ihr fähig euch schnell genug dabei zu verbessern und Probleme zu lösen, bevor das System vor Ärger zu schäumen anfängt? 

Ein paar Fragen die wehtun könnten

Ich empfehle, stellt sie euch:

By ZooFari (Own work) CC-BY-SA-3.0, via Wikimedia Commons

  • Es werden die bisher ungelösten Probleme angesprochen - seid ihr bereit Zeit und Anstrengung aufzuwenden, damit das Unmögliche möglich wird?
  • Werdet ihr jedes Problem ernst nehmen, dass angesprochen wird?
  • Wie geduldig ist die Kultur eurer Organisation?
  • Wie lange werden die Leute es aushalten, bevor sie bei täglich sichtbaren Problemen die Nerven verlieren?
  • Was passiert, wenn eure Leute festsitzen, lösen sie ihre Probleme dann selbst?
  • Was passiert, wenn eure Leute festsitzen und sie über die Anzahl der auftretenden Probleme frustriert werden?
  • Was passiert, wenn eure Leute fürchten oder bemerkten, dass sie zu wenig leisten?
  • Wie werdet ihr reagieren, wenn Menschen Teil des Problems sind?
  • Wie gehst du damit um wenn du (z. B. als Manager) Teil des Problems bist? 
  • Fühlen sich deine Leute wohl, wenn sie ausgezogen zur Arbeit kommen? 
  • Woran wirst du erkennen, wann Transparenz schadet? 
  • Was ist der Unterschied zwischen Offenheit und Transparenz? 
  • Was versprecht ihr euch von Transparenz und teilt ihr diese Ziele mit? 

Es gibt noch viel mehr zu fragen, aber wenn Du an dieser Stelle dich bei einigen dieser Fragen unwohl fühlst, dann rate ich dir über deine flächendeckende Transition zur Agilität nachzudenken - zumindest solange, bis Du dir ein Bild zu diesen Fragen machen konntest. Sagst Du stattdessen: "Transparenz ist überhaupt kein Problem bei uns", dann hast du entweder eine großartige Organisation (und es stellt sich die Frage, ob Agile hier noch gebraucht wird) oder Du hast den Kontakt zur Kultur deiner Organisation verloren. In jedem Fall kann ich nur raten sich gerade mit solchen Fragen ernsthaft auseinander zu setzen, denn auf die oben genannten Effekte werdet ihr stoßen - da sind sie jetzt schon, nur nicht so sichtbar und auffallend.

Last, but not least: Geh zu dem Leuten hin, die die Arbeit tun und hol dir dort Informationen aus erster Hand, damit du Einblick erhältst wie die Arbeit wirklich getan wird. Frag nach Problemen und schärfe deinen Blick echte Verbesserungen, nicht für Strohfeuer. Sei bescheiden und hilf deinen Leuten!

SVNWNK

this article in English: click