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

READY TO PLAY: Definition of Ready (DoR)

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

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

Deswegen ein Beispiel für eine Definition of Ready:

Pflicht:

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

Optional:

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

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

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

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

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

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

SVNWNK

Rezept eines Sprint Plannings (SP 1)

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

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

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

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

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

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

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

Vorbereitung

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

Materialien

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

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

Ablauf

Set und Setting (5min)

Ziel: Ermitteln der Kapazität des Sprints.

Lead: ScrumMaster

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

Setting the Stage (10min)

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

Lead: Product Owner

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

Vorstellen der Items (90 min)

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

Lead: Product Owner

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

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

Optional: Festhalten der Akzeptanzkriterien pro Item auf einem Flipchart.

Commitment und Negotiation (15 min)

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

Lead: ScrumMaster

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

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

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

SVNWNK

Wenn Teams ausbrennen

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

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

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

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

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

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

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

Entschlusslosigkeit

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

Das Thema versandet und wird nicht fertig bearbeitet.

Konsens ohne Folgen

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

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

Freude über Misserfolge

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

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

Reizbarkeit im Binnenkontakt

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

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

Feindseeligkeit gegenüber anderen Subsystemen

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

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

Reflexionsverweigerung

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

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

Abschluss

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

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

Fragen, die sich anbieten sind:

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

SVNWNK

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

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

Problemlösen

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

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

Verstehen und Wissensgrenze

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

Optionsraum öffnen

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

Diskussion und Experiment

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

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

SVNWNK

 

Die Hand am Ball

10:30, Daily Scrum

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

Beruhigungsgesten

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

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

Man unterscheidet drei Arten von Beruhigungsgesten (Adaptoren):

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

Objekt-Adaptor

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

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

SVNWNK

Mehr zu Thema

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

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 

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.

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