S.O.S! Was tun, wenn Teammitglieder keine Tasks schreiben wollen? (Teil 1)

Vor kurzem durfte ich die Vertretung eines ScrumMasters übernehmen. Ich sollte eine Retrospektive moderieren, die Sprint Plannings am darauffolgenden Tag und das sich daran anschließende Daily Scrum. In der Sprint Retrospektive, ohne ins Detail zu gehen, konnte ich einige Teammitglieder nicht dazu bewegen, Tasks zu schreiben. Auf die Frage „Was lief gut“ wurde mir entgegnet, dass in dem Sprint nichts passiert wäre, was eine Antwort auf die Frage verdienen würde. Interessanterweise auf die  anschließende Frage „Was könnte verbessert werden“ erhielt ich Aussagen wie: „Es könnte nicht besser sein.” Trotz widersprüchlicher Argumentationen der Teammitglieder konnte ich diese nicht dazu bewegen, sich konstruktiv am Geschehen zu beteiligen. Im Daily Scrum gab das Team ein ähnliches Bild ab. Einzelne Teammitglieder weigerten sich, mit ihren Signaturen auf einem To-do-Task kenntlich zu machen, dass sie Verantwortung übernehmen. Ich hörte beispielsweise Ausflüchte wie „Ich mache da dann schon irgendwo mit, wo ich gebraucht werde“.
 
Um ehrlich zu sein, ist mir so etwas auf diese Weise noch nicht passiert. Aufgrund der begrenzten Zeit, die ich mit diesem Team verbringen konnte, war ich in den Möglichkeiten kurzfristiger Interventionen eingeschränkt und meine Intuition sagte mir, dass ich in der kurzen Zeit eher noch mehr aufbrechen würde, statt Verbesserungen herbeizuführen. Daher habe ich mich für das Beobachten, ein vorläufiges Akzeptieren und das Respektieren des aktuellen Zustands entschieden. Ein Gespräch mit dem ScrumMaster des Teams steht aber noch aus. Und ich schreibe das, was ich erlebt habe, in diesem Artikel nieder, um es aufzuarbeiten und mir von euch Unterstützung, Feedback, Ideen, Anregungen zu holen.

Menschliche Grundbedürfnisse dürsten nach dem Optimum

Ich würde das Verhalten der Teammitglieder gern aus der Vogelperspektive betrachten und mache mir auf meinem Überflug ein Modell von Grawe zunutze. Schließlich muss das, was sich im Handeln dieser Menschen niederschlägt, irgendwo herkommen. Menschen wachen schließlich nicht morgens auf und sagen sich: „Heute übe ich mal Widerstand aus und finde alles schlecht.“
 
Was fehlt? Was kommt zu kurz? Was wurde verletzt?
 
Damit ein Mensch evolutionär gesehen “funktionieren” kann, sollten seine Lebensumgebung und -umstände so ausgestattet sein, dass ein Fortbestand gesichert werden kann und eine optimale Entfaltung möglich ist. Um die Voraussetzungen hierfür zu schaffen, müssen zwei Formen menschlicher Grundbedürfnisse befriedigt werden: die physiologischen (z.B. Hunger, Durst, Schlaf) und die psychologischen.

Vier psychologische Grundbedürfnisse

Unter den – relativ zu den physiologischen Bedürfnissen gesehen – noch wenig erforschten psychologischen Bedürfnissen versteht Grawe „Bedürfnisse, die bei allen Menschen vorhanden sind und deren Verletzung oder dauerhafte Nichtbefriedigung zu Schädigungen (…) des Wohlbefindens führen.“ (2) In Anlehnung an Epsteins 2003 formulierte „Cognitive-Experimental Self-Theory of Personality “ (1) hat Grawe vier psychologische Grundbedürfnisse des Menschen herausgearbeitet und untersucht:

  • das Bedürfnis nach Bindung,
  • das Bedürfnis nach Orientierung und Kontrolle,
  • das Bedürfnis nach Selbstwerterhöhung und Selbstwertschutz sowie
  • das Bedürfnis nach Lustgewinn und Unlustvermeidung.

Das Bedürfnis nach Bindung und das Bedürfnis nach Orientierung und Kontrolle möchte ich für mein Erlebnis mit dem Scrum-Team näher anschauen, beleuchten und hinterfragen, wo Ansätze für eine Intervention versteckt sein könnten. Dabei brauche ich aber eure Hilfe!
 

Das Bedürfnis nach Bindung

Menschen brauchen die Bindung zu einer oder mehreren Bezugspersonen. Bezugserfahrungen werden bereits in der frühen Kindheit verinnerlicht und im Gedächtnis abgespeichert. Hier spielen sowohl Verfügbarkeit als auch Einfühlsamkeit dieser Bezugspersonen eine gleichermaßen große Rolle. Bezugspersonen, die dafür Sorge tragen, dass sie immer einen erreichbaren Zufluchtsort bereitstellen und für Schutz und Trost sorgen, prägen das Handeln eines Menschen auf positive Weise. Fehlt der Bezug zu Personen, die ein Bindungsgefühl auslösen oder wollen vermeintliche Bezugspersonen keine starke Bindung herstellen, kommt es zu Stressreaktionen, die ihre Ursache in einer zu geringen Ausschüttung des Bindungshormons Oxytocin haben.
Was ich mich gerade frage: Wer kann in einem Scrum-Team für Bindung sorgen? Was passiert, wenn Bezugspersonen fehlen? Was kann man dagegen tun? 

Das Bedürfnis nach Orientierung und Kontrolle

Der Mensch hat das ureigene Bedürfnis, durch Handeln seine Umwelt in seinem Sinne zu beeinflussen. Er möchte nicht nur durch seinen individuellen Einfluss kontrollieren, sondern ebenso herausfinden, welche Handlungsspielräume er für sein Tun hat. Auf diesem Wege will er für sich ergründen, welches Wissen dafür nötig ist. Ich erinnere mich nur allzu gut an das Schreiben meiner ersten Diplomarbeit. Es ist ein so gutes Gefühl, Dinge zu wissen und durch die Gliederung einen Überblick zu bekommen. Und gleichzeitig ist es ein solcher Fluch, durch sein Wissen zu erkennen, wie viel man eigentlich noch nicht weiß. Schnell gerät man in Gefahr, panisch zu werden und den Fokus zu verlieren. Adrenalin wird zu einem ständigen Begleiter.
Was ich mich gerade frage: Wer oder was sorgt im Scrum-Team für Orientierung und Kontrolle? Wer oder was gibt einen Fokus? Wie kann das Bedürfnis kontinuierlich und dauerhaft befriedigt werden?
 
S.O.S! Was tun, wenn Teammitglieder keine Tasks schreiben wollen ist ein Aufruf an alle ScrumMaster, Teammitglieder, Manager, Führungskräfte, die mich bei Lösungen für das anfangs beschriebene Problem unterstützen können und wollen. Was denkt ihr? Wie hättet ihr euch an meiner Stelle verhalten? Was würdet ihr mir raten? Was kann ich tun, um eine Verbesserung im Handeln der Menschen zu bewirken? Habt ihr so etwas selbst schon mal erlebt und wie habt ihr reagiert?
 
In S.O.S! Was tun, wenn Teammitglieder keine Task schreiben wollen? (Teil 2) würde ich eure Feedbacks gerne veröffentlichen, kommentieren, diskutieren und auch ausprobieren wollen.
Haut in die Tasten und rettet mich!
 
Literatur
(1) Epstein, S. (2003). Cognitive-Experimental Self-Theory of Personality, in: Weiner, I., Million, B., Lerner, T.: Handbook of Psychology, Bd. 5. Personality and Social Psychology. New Jersey.
(2) Grawe, K. (2004). Neuropsychotherapie. Göttingen
(3) Peters, T. & Ghadiri, A. (2011). Neuroleadership – Grundlagen, Konzepte, Beispiele. Gabler.

Bastelecke Sprint Planning 2

Wofür nutzen wir das Sprint Planning 2? Für das Schreiben von Aufgaben zu den User Stories. Ähm, ja und noch wichtiger: Nein! Sicherlich formulieren wir auch die initialen Aufgaben für das Team zum Start des Sprints – es soll ja jeder starten können, ohne auf die anderen warten zu müssen. Allerdings ist das einzige nicht das wichtigste Ziel.

Was wollen wir mit dem Sprint Planning 2 erreichen?

Über allen Dingen, die wir im Sprint Planning 2 machen, steht das Abstimmen der Zusammenarbeit. Die Frage: “Wie machen wir es?” Um eine Antwort zu finden, benötigen wir ein gemeinsames Bild von den Geschichten, die wir bearbeiten möchten. Als Vorbedingung ist hier wichtig, dass wir das “Was” im Sprint Planning 1 bereits geklärt haben und nun an der Umsetzung des Bilds im “Wie machen wir es?” arbeiten können. Die Betonung liegt auf dem “Wie”.
Das “Wie” klären wir am besten, indem wir uns eine Arbeits- bzw. Diskussionsgrundlage schaffen: Ein Modell. In der Software-Entwicklung arbeiten wir hier mit Diagrammen, meist UML. Mit Modellen können wir unsere Ideen testen und stellen sicher, dass wir von der gleichen Sache reden, dass wir das gleiche Bild in unseren Köpfen haben. Wir schaffen mit Modellen einen gewissen Abstand, machen sichtbar und greifbar, was sonst nur in Köpfen und Worten steckt. Das wiederum ermöglicht es uns, unsere Schnittstellen abzustimmen, damit ermöglichen wir Zusammenarbeit. Kennen und vereinbaren wir unsere Schnittstellen, so können wir losgelöst voneinander einzelne Aufgaben lösen. Zudem befassen wir uns mit den unterschiedlichen Seiten der Schnittstellen und erfassen damit das Bild im Größeren. Haben wir nun ein gemeinsames Bild, so nehmen wir die Aufgaben zu jeder User Story auf, die wir initial erkennen. Auch das ist wichtig, unser Fundament muss das gemeinsame Verständnis sein.

Diagramme und Skizzen

“Diagrams capture the knowledge that all Team Developers must keep in their head in order to work efficiently.” (Robert C. Martin)
Der wahre Wert von Diagrammen liegt in der Kommunikation von Ideen anhand von einfachen Skizzen. Mit möglichst wenig Details Ideen auszutauschen und zu testen. Ein guter Weg, um eine User Story in Diagrammen abzubilden, ist der Weg über ein Verhaltensdiagramm (z. B. ein Sequenzdiagramm oder Aktivitätsdiagramm) hin zu einem Strukturdiagramm (z. B. ein Klassendiagramm oder ein Komponentendiagramm) und dann das sukzessive Verfeinern im gegenseitigen Wechsel in kleinen Zyklen (siehe Robert C. Martin in “Agile Principles, Patterns and Practices“).
Wann wird am besten ein Diagramm verwendet?

  1. Immer dann, wenn ein gemeinsames Bild notwendig ist.
  2. Immer bei wichtigen Punkten/Diskussionen.
  3. Immer dann, wenn etwas nicht klar oder strittig ist.
  4. Immer dann, wenn gleichzeitig an etwas gearbeitet werden soll.

Wann sollte man aufhören Diagramme zu zeichen? Auch hier bin ich mit Robert C. Martin einig: Immer dann, wenn das Coding ein besseres Ergebnis bringt und man sich um Details kümmern muss.

Was braucht das Team im Sprint Planning 2?

Vor allem Entscheidungen. Muss das Team auf eine Entscheidung warten, dann steigt das Risiko, dass der Sprint gerissen wird, dass es zu einer Blockade kommt. Entweder konnte man alles offen in der Zeit zwischen Sprint Planning 1 und 2 klären, oder man entscheidet die letzten offenen Punkte im Sprint Planning 2. Wenn niemand eine Entscheidung trifft, dann trifft die Entscheidung das Entwicklungsteam. Dank eines empirischen Prozesses haben wir die Möglichkeit, anhand des Ergebnisses auszusteuern. Zudem sind die geschaffenen Fakten genau das benötigte Mittel, das die meisten Menschen brauchen, um Entscheidungen zu treffen. Hier sind wir wieder bei Entdeckungen, die nötig sind, um Gedankengänge des Auftraggebers oder der Benutzer der Anwendung abzuschließen. Mit Entscheidungen über die Funktionen und die Details durch das Enwicklungsteam bringen wir letztlich den gesamten Prozess und die Produktentwicklung nach vorne.
Was braucht es noch? Zugriff auf den Source-Code ist wichtig, damit wir direkt nachsehen können und nicht auf Vermutungen und Befindlichkeiten basierend diskutieren müssen. Kennen Sie das auch:
A: “Das müsste doch nur eine Wenn-Dann-Klausel sein!”
B: “Nein, ich glaube da hängt ein echt kompliziertes Konstrukt dahinter!”
Hier heißt es, Fakten schaffen und nachsehen. Das spart Zeit und führt schneller zu einer Lösung. Unabdingbar für einen Software-Entwickler ist das Whiteboard. Wir diskutieren mit Hilfe von  Diagrammen, die wir immer wieder durch unser “Testen” im Dialog verfeinern. Zudem benötigen wir alle User Stories aus dem Sprint Planning 1, am besten in einer visualisierten Form auf einem Flipchart. Auf dem Flipchart finden wir bspw. die Punkte wie technische Constraints, Abhängigkeiten zu anderen Komponenten und Teams, unsere geplanten Akzeptanztests und die Akzeptanzkriterien.

Fazit

Wenn Sie alle diese Punkte beachten, dann sind Sie auf den Weg zu einem guten Sprint Planning 2 und einem Sprint, der erfolgreich mit gemeinsamer Interaktion durchgeführt werden kann. Es kann sein, dass Ihr Team noch Unterstützung im gemeinsamen Umgang mit UML braucht. Hier hilft es, eine Study Group einzurichten und etwas Freiraum für das Lernen von UML zu schaffen.
Viel Erfolg und Spaß im nächsten Sprint Planning 2! (Lächeln)