ScrumMasters Advice: Fragilität vs. Risiko

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

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

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

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

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

Was uns leichter fällt

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

Empfehlung

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

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

SVNWNK

Review-Prozesse im Team (ein Beispiel)

Code-Reviews

Ein Beispiel aus der Praxis: Gemäß unserer Definition of Done erfolgen im Team Code-/Funktions-Reviews (C/F-Reviews).

Prozess bzw. Team-Konvention

Konkrekt: Wir reviewen im Regelfall die implementierte Funktion und den dazugehörigen Code pro abgeschlossener Aufgabe. Dafür haben wir auf unseren Taskboard eine Puffer und WIP-Spalte für "Verification" eingefügt. 

Layout:
Story || TODO || In progress || Waiting for verification || In verification || DONE

Hängt ein eine Aufgabe im Pufferspeicher "Waiting for verification", dann muss diese Aufgabe innerhalb eines Tages verifiziert werden.

Ausnahmen (Interactions over Processes and Tools)

Werden Aufgaben im Pairing erledigt, sind Code- bzw. Funktions-Reviews normalerweise nicht notwendig. Code-/Funktions-Reviews werden standardmäßig für jede Funktion durchgeführt, außer die Team-Mitglieder sprechen sich dafür aus, dass es nicht notwendig ist.

Ungeachtet des Prozesses kann jeder Entwickler ein Review einberufen. Eigentlich recht einfach ;-)

SVNWNK


Macht TDD glücklicher?

Gerald Hüther schreibt in seinem Buch Lernlust über Selbsterkenntnis und Selbststeuerung:

Menschen, die sich selbst regulieren können, werden bei aller Euphorie über eine gefundene Lösung das Ausgangsproblem noch einmal einer Prüfung unterziehen.

Er beschreibt die Prüfung des Ausgangsproblems als "Ausdruck der Fähigkeit zur Selbstregulation" und die Selbstregulation als Fertigkeit um mit den eigenen Unzulänglichkeiten umzugehen. In diesem Zusammenhang ergeben Experimente/Studien zudem, dass Menschen die eine höhere Selbstregulation aufbringen in der Tendenz stabilere Partnerschaften, bessere Ausbildung, mehr Geld, weniger krank und mehr Freude hatten.

Was kann das mit TDD zu tun haben?

In TDD (test-driven development) kehrt man zyklisch, nach jedem Lösungsschritt, zur Ausgangslage zurück und prüft, ob die gefundene Lösung das Ausgangsproblem behebt. Wir machen uns Tätigkeiten, die wir oft wiederholen zu Gewohnheiten.

Nun meine These:

Wenn wir davon ausgehen, dass mit stetigen Einsatz von TDD das Vorgehen "Prüfen der Lösung gegenüber der Ausgangslage" zur Gewohnheit werden kann, besteht dann nicht auch die Chance, dass wir das Verhalten in andere Bereiche außerhalb des Codings übertragen.

Wenn das so ist, dann haben wir dadurch vielleicht die Chance ein klein wenig glücklicher zu werden, oder? ;-)

SVNWNK

Was haben Sekretärinnen und ScrumMaster gemeinsam?

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

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

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

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

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

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

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

Von Sekretärinnen und ScrumMastern

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

SVNWNK

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

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

Wie viel Zwang verdient ein Team?

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

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

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

Ein Widerspruch?

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

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

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

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

Fazit

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

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

Lean Startup Experience - That's My Kid

Das ist mein Kind - die Geschichte

Stell dir eine Welt vor, in der die wichtigsten Ereignisse deines Kinds in Bilder festgehalten sind. Du zeigst sie deinen Eltern und Freunden:

Schau mal, hier krabbelt es, das sind die ersten Zähne, hier schon ersten Schritte, da das erste Fahrrad, autsch, der erste kleine Unfall mit dem Fahrrad...

Wie gerne halten wir die wichtigsten Momente unserer Kinder fest. Die Wichtigsten? Puh, da hätte ich tausende Photos pro Jahr zu, das kann ich doch keinem mehr zeigen - oder? Mit so viel Auswahl kann ich gar nicht umgehen. Die Alben sind voll, das dauert Stunden die anzusehen. Eigentlich möchte ich eine kurze Galerie zu meinem Kind! Sortiert nach den Ereignissen, die mir vorgeschlagen werden. Zugriff gewähre ich nach meiner Auswahl.

Der erste Entwurf

Keine leichte Aufgabe, der wir uns stellen. Da wir nicht wissen, ob ihr das braucht, möchtet. Wir suchen Feedback und haben die erste App schon erstellt. Zwar mit Papier, Stift und Schere, aber dafür können wir es testen. Die Mittagspause winkt und wir ziehen los, um unseren Prototypen in der Nürnberger Innenstadt zu testen.

Hinterlasst uns doch bitte einen Kommentar, ob ihr eine solche Anwendung möchtet, oder was ihr braucht. 

Hier unser erster Entwurf: 

Arbeitsplatzschmerzen - Nicht nur für Wissensarbeiter

Wenn der Arbeitsplatz schadet

Es ist wenig verwunderlich, dass große Firmen wie Google stolz auf die Arbeitsplätze für ihre Mitarbeiter sind und sie der Welt zeigen.  Ist doch der Arbeitsplatz entscheidend bei der Wahl für oder gegen ein Unternehmen. Denn über die Arbeitsplatzgestaltung lässt sich viel auf die Unternehmenskultur schließen. Der Arbeitsplatz drückt aus, was unausgesprochen bleibt: wir atmen etwas der Kultur ein, zumindest suggeriert unser Hirn uns das, und wir stellen Erwartungen und treffen Annahmen. Obwohl Kultur spannend ist, möchte ich hier über die Gestaltung von Arbeitsplätzen von Wissensarbeitern schreiben. Über unterschiedliche Arbeitsplätze, die ich gesehen und über das was ich dort gefühlt habe, über das was für mich wichtig ist an einem Arbeitsplatz.

First things first

Wenn Du deine Leute über ihren Arbeitsplatz entscheiden lässt, dann zahlen sie dir das tausendfach zurück. Überstimmst Du sie bei der Gestaltung des eigenen Arbeitsplatzes, dann zerkratzt Du ihre Verbindung zu dir. 

Ein Beispiel: Die Bürowände gehören den Menschen, die dort arbeiten und nicht irgendeinem Hausdienst, Management oder externen Beratern. Keine Diskussion!

Pigs und Chicken auf der Arbeit

Ein Arbeitsplatz im Hauptquatier von Zappos. By lizzielaroo CC-BY-SA-2.0  or CC-BY-SA-2.0, via Wikimedia Commons

Der Arbeitsplatz sollte der Ort sein an dem gearbeitet wird, sofern der Arbeitsplatz einem nicht daran hindert.

Ein Muster dem viele Agile Transitionen folgen ist Colocation. Sicherlich ist Colocation mächtig, jedoch ist das Wichtigste dabei die Leute selbst zu fragen, in welchen Konstellation sie gerne zusammensitzen möchten: ein Raum, zwei Räume, wie viele Leute in einem Raum, was auch immer. Als Chicken sollte man nicht über sie bestimmen, sie in einem Pferch einsperren. Vertraue den Leute, die die Arbeit verrichten und nenne ihnen die Einschränkungen und den Rahmen.

Separation, Fragmentierung und ungezwungener Austausch

Viel Schaden wird am Arbeitsplatz dadurch angerichtet, dass Teams auseinander gerissen und separat untergebracht werden. Wahrscheinlich leidet die Arbeit darunter, wenn Teammitglieder losgelöst voneinander. Was dabei definitiv verloren geht, ist der ungezwungene Austausch untereinander. Über diesen Austausch bauen sich Verbindungen und damit eingehend Vertrauen auf und es entstehen Handlungsspielräume. Man verliert viel, wenn man Teams nicht zusammen sitzen lässt.

Zudem fördern verstreute und verteilte Teams Verschwendung (Waste). Wenn man es vermeiden kann, dann sollte man solche Teams nicht in Betracht ziehen - mit einer Ausnahme: das Team möchte es selbst so. Teams, die bestimmt werden agieren üblicherweise weit unter ihren Möglichkeiten. Verteilte Teams, die bestimmt werden tun sich noch weitaus schwerer.

Boxenstop von McLaren 2006 in Malaysia. By Kamalsell (Flickr) CC-BY-2.0, via Wikimedia Commons

Teams auf verschiedene Standorte aufzuteilen ist schädlich, aber Teammitglieder in ihren Aufgaben zu fragentieren ist weitaus schlimmer. Arbeiten Leute an mehr als einem Projekt, Produkt oder was auch immer, dann führt das dazu, dass sie weniger fokussiert arbeiten und mit enorm mehr Störungen umgehen müssen. Sie ringen und stolpern die meiste Zeit, da es ihnen schwer fällt mit der Anzahl der menschlichen Interaktionen umzugehen. Das hindert sie wiederum, sich in einen Flow-Zustand zu begeben. Bevor es ihnen gelingt etwas abzuschließen, reißt sie wieder jemand heraus und stiehlt ihre Aufmerksamkeit. Man fühlt sich dann wie ein Formel 1 Auto, das für immer beim Boxenstop steht: viel Power, doch keine Performance, da ständig jemand einem die Reifen und andere Teile wechselt. Leider ist dieses Szenario weit verbreitet und erzeugt mehr Verschwendung als Wert.

Ruhe und der Flow-Zustand

Von einem Flow-Zustand spricht man, wenn Menschen beim Arbeiten in eine Leichtigkeit verfallen. Um einen Flow-Zustand zu erreichen, benötigt man Zeit. Üblicherweise erledigt man während eines Flow-Zustands außerordentlich viel. Um dorthinzukommen muss man sich konzentrieren, dafür braucht man Ruhe. Um einen Arbeitsplatz zu schaffen, der das unterstützt, fragt man am besten die Leute selbst. Sie werden sehr gute Vorschläge machen, was sie benötigen um ungestört zu arbeiten. Lässt man sie, werden sie ihren Arbeitsplatz verbessern. Besser man ist zuvorkommend und hilf ihnen dabei, den besseren Arbeitsplatz zu schaffen. Das Prinzip Colocation unterstützt auch dabei, um in einem Flow-Zustand zu kommen: Teammitglieder tendieren dazu zur gleichen Zeit ruhig zu werden und ihre Arbeit zu verrichten, das führt für gewöhnlich zu weniger Unterbrechungen und Störungen. Fragmentierung von Teams, wie oben angesprochen, führt letztlich zu wenig bis gar keiner ruhigen Zeit zum arbeiten.

Natürlich und ...

Sicherlich ist das was ich hier schrieb nichts Neues, nichtsdestotrotz wird es viel zu oft überhört. Oftmals hat es gar nicht so viel damit zu tun, dass bspw. das Management unfähig ist diese Konzepte anzunehmen, es fällt Menschen viel schwerer die alten Ideen zu vergessen, wie John Maynard Keynes sagen würde.

SVNWNK

this article in English: click 

 

Debriefing - Das Schließen einer Welt

Zielsetzung und Rahmen

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

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

Fragen

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

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

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

Methoden

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

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

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

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

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

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

Noch ein paar Worte

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

SVNWNK

 this article in English: click

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

  

Misstrauen ist keine Option

Misstrauen schließt Türen

Misstrauen ist keine Option, weil es keine Optionen eröffnet. Es zerstört sie lediglich, was dazu führt, dass der Entscheidungsspielraum eingeengt wird. Auf der anderen Seite öffnet Vertrauen die Optionen hinter verschlossenen Türen: "Vertrauen erschließt durch die Reduktion von Komplexität Handlungsmöglichkeiten, die ohne Vertrauen unwahrscheinlich und unattraktiv geblieben und somit nicht zum Zuge gekommen wären" - sagt Luhmann.

Dieser Satz trifft es, und ich finde es ist wert ihn öfter zu lesen.

Vertrauen herstellen

Es scheint offensichtlich, dass wir mit Vertrauen uns mehr Handlungswege eröffnen. Zudem erschließen wir uns durch Vertrauen auch die Wege, die vorher unwahrscheinlich jedoch attraktiv waren. Hierfür müssen wir Vertrauen herstellen, was nicht einfach fällt. Hier ein kleines Beispiel, bei dem ich vertrauen wollte:

"Ich putze unseren Kleinbus - wir waren im Urlaub und hatte jede Menge Zeug im Wagen und ich legte alles außen vor den Bus. Als ich ins Haus gehen wollte, um kurz etwas auszuwaschen, kam ein mir unbekannter Zeitungsjunge an. Innerhalb eines Bruchteils einer Sekunde schloss sich die von mir favorisierte 'Tür' - geh rein und wasch das aus - stattdessen dachte ich darüber nach außen zu bleiben, um auf die Sachen aufzupassen. Ich hielt für einen Moment inne, dann entschloss ich mich dem Jungen zu vertrauen und ging nach innen."

Ein Zeitungsjunge aus Iowa City. By Arthur Rothstein: US Farm Security Administration (http://www.loc.gov/pictures/item/fsa1997013024/PP) [Public domain], via Wikimedia Commons

Solche Dinge passieren ständig, jeden Tage. Ich denke wir reflektieren selten darüber, erscheinen solche Ereignisse uns doch meist unwichtig. Auf der anderen Seite bin ich davon überzeugt, dass solche kleinen Entscheidungen die Grundlinie für unser Verhalten prägen. Warum nicht aktiv davon lernen, indem wir darüber reflektieren und uns nicht nur darauf verlassen, dass unsere Erfahrung die richtigen Schalter in unseren Hirnen schaltet (Neurobiologisch ist das so erforscht). Wenn wir nicht erkennen wie wir handeln und unser Verhalten bestimmen, dann bestimmt unser Verhalten ganz leicht uns. Hier hilft, dass stetig bestätigende Erfahrungen uns die Stärke gibt Vertrauen herzustellen. Wenn wir die Essenz von unserem Handeln einfangen und es uns bewusst machen, sollte einfacher sein Vertrauen herzustellen.

Reduzieren von Komplexität durch Vertrauen

Um mit der eigenen Arbeit voran zu kommen, ist es wichtig anderen zu vertrauen. Dort wo man anderen vertraut, mischt man sich nicht ein und stört nicht. Vertraut man, so macht man sich weniger Gedanken darüber wie etwas erledigt wird, welche Weichen man stellen muss und an welchen Stellschrauben kontrolliert wird. Vertrauen heißt: man eröffnet sich die Möglichkeit mit den eigenen Tätigkeiten zu beschäftigen und dazu die Option Dinge durch andere fertigzustellen. Verzichtet man darauf sich über die Arbeit der anderen im Detail Gedanken zu machen, so reduziert man Komplexität. Dazu gehört auf dem Weg zu lernen und das auch anderen zugestehen. Zu guter letzt ist Vertrauen der wichtigste Teil wenn man etwas starten möchte. Je mehr Vertrauen, desto mehr Wege stehen einem in die Zukunft offen.

SVNWNK 

this post in English: click

Ich habe fertig

"Ich habe fertig"

Als Trappatoni 1998 seine Pressekonferenz mit den Worten "Ich habe fertig!" beendete, war allen Anwesenden unmissverständlich klar, was er mit fertig meinte. In der Software-Entwicklung sieht das oft noch anders aus. Es stapeln sich Berge von unsichtbarer, ungetaner Arbeit, Aufgaben und Aktivitäten, die zum Ende einer Story, eines Sprints und eines Releases anstehen. Damit mag eine Entwicklung für den einen "fertig" sein, für den anderen bedeutet es den Anfang weiterer Aktivitäten, bevor die Funktion tatsächlich abgeschlossen ist. Fertig (done) ist oft ein weites Feld, welches es zu beackern gilt und es benötigt eine Änderung der Arbeitsweise um am Ende ein stabiles Produktinkrement zu liefern. Eine gute Definition of Done ist nicht mit einer Definition getan, üblicherweise ist es ein Weg zur Professionalisierung: "Therefore, a group defines their DoD as their current technical and organizational ability - typically starting below the perfection challange. [...] Over time, as the group improves, their DoD expands until it is equal to truly potentially shippable." (Craig Larman, Bas Vodde, Practices for Scaling Lean and Agile Development, 2010, p. 170)

Wenn es ein Weg ist, dann stellt sich berechtigterweise die Frage: "Wo stehen wir gerade und was hat dazu geführt, dass wir noch keine Definition von fertig haben?"

Jeff Sutherland und Ken Schwaber führen für den zweiten Teil der Frage folgende Gründe an: "Many of the Scrum Development Teams with which we have worked were initially unable to develop ready-to-use increments of software bye the end of a Sprint. Transparency wasn't required from them in the past, so they often do not have the technical skill or adequate tools to rapidly build transparent software functionality" (Jeff Sutherland, Ken Schwaber, Software in 30 Days, 2012, p. 91) - für den ersten Teil der Frage gilt: "Ask the team."

Wir haben über offene Tätigkeiten und Aktivitäten gesprochen, die nicht im normalen Entwicklungsalltag aufgenommen wurden. Wie bringt man nun die gesammelten, ungetanen Aktivitäten in die Software?

Dazu gibt es zwei Möglichkeiten:

  1. Man führt sie durch, oder fängt an sie durchzuführen
  2. Man führt sie nicht durch und erzeugt technische Schuld (technical debt) und erstickt an ihr

Führt man die offenen Aktivitäten durch und ist man dem fallenden Wasser noch sehr nah (Vorsicht, schlechtes Wortspiel), dann tendieren viele Organisation dazu extra Phasen (Sprints) einzubauen, damit stabilisiert man vor einem Release das Produkt und bereinigt die gefundenen Fehler (Hardening). Das gleicht oft einer Springflut, die auf eine Staumauer zu rast.

Wir übersehen bei einem solchen Vorgehen gerne: "'Hardening' - an aspect of Undone Work - is so common that some do not see it for what it is: a failure, not a solution." (Craig Larman, Bas Vodde, Practices for Scaling Lean and Agile Development, 2010, p. 175)

Hardening läuft wesentlich einer Sache entgegen: Qualität kann nicht nach der Entwicklung entstehen, sie muss Teil der Entwicklung sein. Ziel darf nicht sein bspw. etwaige Fehler einzusammeln, stattdessen ist es Ziel den eigenen Prozess so zu gestalten, dass Defekte in Funktionalität und Design während der täglichen Arbeit bereinigt werden. 

Djikstra sagt dazu: "Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging - they should not introduce bugs to start with." (Djikstra, The Humble Programmer, 1972) - und geht noch einen Schritt weiter und spielt auf testgetriebene Entwicklung an - für mich ein wesentlicher Bestandteil von fertig. In jedem Fall sagt er, dass der Entwicklungsprozess seine Fehler unmittelbar am Anfang zu suchen hat und am besten keinerlei Fehler produzieren sollte - ein klarer Ausspruch gegen Hardening-Phasen, sondern vielmehr:

"Work of iteration = Product Backlog Items + Definition of Done" (Craig Larman, Bas Vodde, Practices for Scaling Lean and Agile Development, 2010, p. 171)

Stellt sich nun die Frage, was gehört in eine Definition von Fertig? Auch hier fragen Sie am besten ihr Team was es bereits leistet, gerne leisten würde und informieren Sie sich darüber was in ihrem Umfeld Standard ist. Zielführend ist es sich an den oberen 20% zu orientieren, über den Rand hinauszusehen und den Standard nur als Nulllinie für Verbesserung anzusehen.

Hier ein Beispiel für ein paar wichtige Merkmale einer Definition von Fertig für die Level Story, Sprint und Release:

Story-Level (fertig für jede Story)

  • Clean code
  • Unit testing with TDD
  • Continuous integration
  • Automated acceptance testing
  • Technical documentation

Sprint-Level (fertig für jeden Sprint)

  • Performance testing
  • Exploratory testing
  • User handbook
  • Process test
  • Installation notes

Release-Level (fertig für jedes Release)

  • Process tests with current live data
  • Packaging and installation notes
  • Key user training

Wie sehen nun Schritte auf einem Weg zur Definition of Done aus?

  1. Brainstorming: Welche Aktivitäten kennt das Team bereits  und welche werden vom Team ausgeführt?
  2. Zuordnen der Aktivitäten zu den einzelnen Level: 
    1. Wann kann das Team wann liefern? Startend auf dem Story-Level fragen Sie das Team welche Aktivitäten es pro Story zum heutigen Stand liefern kann (keine Wunschträume). Alles was nicht pro Story geliefert werden kann, wird auf das Sprint-Level geschoben.
    2. Erneut die Frage: Was kann das Team liefern? - dieses Mal für das Story-Level (weiterhin keine Wunschträume). Alles was nicht pro Sprint geliefert werden kann, wird auf das Release-Level geschoben.
    3. Nun sind alle Aktivitäten in die drei Kategorien Story-Level, Sprint-Level & Release-Level eingeteilt. Sofern es Tätigkeiten gibt, die existentiell für die Produktion, d. h. für den Praxisgang sind eröffnen Sie ein weiteres Level (Produktions-Level) und wiederholen die obigen Schritte für Release- und Produktions-Level.

Nun haben Sie eine initiale Definition von Fertig. Eine Definition von Fertig ist ein Arbeitsstand, ein sogenanntes lebendiges Dokument, das sich verändern, verbessern sollte. Das heißt konkret: Geben Sie ihnen und ihrem Team immer wieder die Chance und Aufgabe zur Reflektion der Definition von Fertig. Hierfür ist es wichtig die Definition zu visualisieren, am besten im Stil eines Boards, bei dem sich die Aktivitäten verschieben lassen. Als bspw. ScrumMaster finden Sie heraus wo welche Aktivitäten am sinnvollsten aufgehoben sind. Sind Tätigkeiten teuer, lohnt es sich wahrscheinlich diese für mehr als eine Story durchzuführen. Gibt es Tätigkeiten, die sich ein Level zu weit oben, z. B. im Release-Level wiederfinden, dann gilt es herauszufinden was die Hindernisse sind, um diese Aktivität früher durchzuführen. Es handelt sich tatsächlich um Hindernisse, für die meist die Mittel z. B. das Wissen/Fähigkeiten fehlen.

Abschließend noch ein Satz: Das Team definiert hiermit auch seinen Arbeitsethos, das Selbstwertgefühl für die eigene Arbeit. Das Meiste was Sie hier finden ist nicht verhandelbar, im Sinne von "wir können das mal weglassen", vielmehr ist es ein Teil der Motivation, warum ihr Team seine Arbeit macht. Zwingen Sie ihr Team dazu darauf zu verzichten, dann kostet sie das spürbar Produktivität.

In diesem Sinne: "Ich habe fertig." 

SVNWNK