Coaching-Tipps

Hier finden Sie hilfreiche Tipps für den Alltag von Scrum-Mastern, Agile-Coaches und Agile-Leader

Fit for Purpose Survey

  • Auf dem Kanban Leadership Retreat Anfang Juli in Barcelona habe ich eine tolle Umfragetechnik gelernt, die ich gerne mit dir teilen möchte. Es geht um die Frage, ob unser angebotener Service (oder unser Produkt, unsere Entwicklung, Schulung etc.) eigentlich seinen Zweck erfüllt. In der Kanban-Welt sprechen wir von „fit for purpose”. Das Bild zu diesem Tipp zeigt David Anderson beim Erklären des „Fit For Purpose Survey“.

    Um den Stand der Fitness herauszufinden hilft uns meist eine rein quantitative Aussage wie eine Schulnote wenig. Deswegen sammeln wir an zwei Stellen auch qualitative Daten: 1. Was war denn eigentlich der Zweck? 2. Wie kam es zur Beurteilung, dass dieser Zweck eben so erfüllt wurde und nicht besser oder schlechter.

    Die Umfrage sieht wie folgt aus:
    a) Zu welchem Zweck hast du [diese Schulung besucht | dieses Produkt verwendet | an diesem Meeting teilgenommen | diesen Newsletter gelesen]?
    b) Wie gut wurde dieser Zweck erfüllt:
    5 – vollständig erfüllt und sogar übertroffen
    4 – vollständig erfüllt
    3 – im Wesentlichen erfüllt, ein paar kleinere Bedürfnisse nicht erfüllt
    2 – wesentliche Bedürfnisse nicht erfüllt
    1 – wenig, etwas wert, aber die meisten Bedürfnisse nicht erfüllt
    0 – nichts Nützliches, für den Zweck ungeeignet
    c) Wieso hast du bei b) genau diese Antwort gegeben?


    In der Auswertung fasst man die Werte wie folgt zusammen:
    5 und 4 – für den Zweck angemessen
    3 – neutral
    2, 1, 0 – für den Zweck unangemessen 

    Die Ergebnisse werden als ein sogenannter Box-Score notiert, also z.B. [75 - 10 - 15] (18/20) mit der Bedeutung, dass 75% gesagt haben, dass der Service für den Zweck angemessen ist, 10% neutral und 15% den Service für nicht angemessen halten. Dahinter steht, dass 18 von 20 Befragten eine Antwort gegeben haben.
    Der Vorteil des Box-Score gegenüber einem Durchschnitt liegt auf der Hand, wenn man folgende Werte vergleicht: [50 - 0 - 50] und [0 - 100 -0]
    Beide ergeben einen Druchschnitt von 0, aber das Ergebnis mit 50%, die es für den Zweck angemessen halten ist vermutlich besser. Man könnte daraus z.B. auch schließen, dass man die 50% der unzufriedenen Kunden zukünftig nicht mehr bedienen sollte.  

    Man könnte die Umfrage noch so erweitern, dass mehr als ein Zweck angebeben werden kann. So erhält man noch detailliertere Ergebnisse. 

Probleme und Rahmen statt Lösung

  • Der Agile Tipp in diesem Monat richtet sich vor allem an Führungskräfte, egal ob Scrum Master, Product Owner, Teamleiter, Manager:
     
    Stellen wir uns folgende Situation vor: Wir haben zwei Teams, die ungefähr dasselbe leisten können und aktuell mit unterschiedlichen Projekten betraut sind. Jetzt kommt ein neuer Kunde und wir wollen auch diesen bedienen. Technologisch und fachlich ist der Rahmen für den neuen Kunden derselbe, den unsere beiden Teams verwenden und gut beherrschen.

    Ansatz 1: Lösung
    Ich bin persönlich ein großer Freund stabiler Teams. Als Manager bin ich froh, dass die Teams gut funktionieren. Ich will sie deshalb nicht auseinanderreißen. So entscheide ich, dass eines der Teams den neuen Kunden übernimmt. Ich vermute, dass perspektivisch die aktuellen Aufgaben von Team 2 weniger werden, weil deren Produkt im Produktlebenszyklus weiter ist. Ich gebe deshalb Team 2 den neuen Kunden. Die sind vermutlich nicht begeistert und fühlen sich ungerecht behandelt, aber mit gutem Zureden werden sie das schon machen. Im Hinterkopf merke ich mir, dass Team 2 bei mir etwas gut hat und die nächste Belastung für Team 1 reserviert ist.

    Ansatz 2: Problem und Rahmen 
    Ich spreche mit beiden Teams (oder Teamvertretern). Ich gebe ihnen das Problem. Zudem setze ich einen möglichst klaren Rahmen für die Lösung, z.B. Teamstabilität. Ich stehe bereit, um Lösungsvorschläge zu diskutieren, vielleicht behalte ich mir sogar vor, am Ende die Entscheidung zu treffen. Aber ich erwarte mindestens einen Vorschlag, wie wir den neuen Kunden bedienen können.

    Diskussion
    Ich persönlich neige zu Ansatz 1, weil ich ungeduldig bin und mich für wirklich schlau halte und tolle Ideen habe. Dafür erlebe ich aber auch, dass Ansatz 1 zu weniger Verantwortungsübernahme für die Lösung führt. Und jede ungeklärte Detailfrage zur Lösung wieder bei mir aufläuft.
    Deshalb weiß ich, dass es wirklich schlau wäre, wenn uns öfter Ansatz 2 gelingt. Denn er birgt die Chance, dass wir auf bessere Lösungen kommen, weil die handelnden Personen selbst (in unserem Fall die Teammitglieder der beiden Teams) Wissen und Ideen haben, die ich nicht hatte. So könnte die Lösung sein, dass der Schmerz geteilt wird. Vielleicht verantwortet Team 2 heute eine gemeinsame API der beiden Teams, die Team 1 übernimmt, wodurch zumindest etwas mehr Freiraum für Team 2 entsteht, um den neuen Kunden zu bedienen.
    Es ist nicht leicht, den Rahmen ausreichend gut zu beschreiben. Entweder man vergisst Wesentliches oder macht ihn so eng, dass die Lösung alternativlos wird. So bietet es sich vielleicht an, dass man zusammen eine Lösungsdiskussion führt und die entstehenden Lösungen mit ihren Konsequenzen gemeinsam durchdenkt. Dabei ist es wichtig, dass man Ideen, die auf den ersten Blick absurd scheinen, nicht zu früh ausschließt. 

    Das Tolle an diesem Tipp: Ich habe dir damit nur ein Problem und einen Rahmen gegeben, die Lösung für dich/euch musst du selber finden.

Komplexithoden und Systemdenken

  • Normalerweise bitte ich für diese Kategorie Kollegen, einen Agilen Tipp aus der Praxis mit uns teilen. Diesmal stammt der Tipp von mir, womit einhergeht, dass die betrachtete Praxis eher eine ganze Organisation und deren Weiterentwicklung betrifft als ein einzelnes (Scrum-)Team. Übertragen lassen sollte es sich trotzdem.

    Kurt Lewin hat einmal gesagt: „Es gibt nichts Praktischeres als eine gute Theorie.“ Darüber sprachen wir letzte Woche als ich an der Denkwerkstatt Komplexithoden mit Niels Pfläging teilgenommen habe. Wir haben über viele der guten Anregungen aus dem Buch Komplexithoden diskutiert und kamen bei Problembeschreibungen oder Herausforderungen immer wieder darauf, wie schwer es ist, einen systemischen Blick zu behalten. Das soll für unseren Zweck hier erstmal nicht mehr bedeuten als die Einsicht, dass in Organisationen das meiste zu beobachtende Verhalten am System und seinen Regeln, Prinzipien, Bedingungen liegt, nicht an den Menschen selbst. Je nach Autor liegt der direkt den Menschen zuzuordnende Anteil der Probleme bei 1% bis max. 15%. Diese Erkenntnis muss sich in unseren Lösungen und Veränderungen widerspiegeln.

    Ich weiß nicht, wie es dir damit geht, aber ich neige schon dazu, Leute als Problem zu sehen. Ich denke Sachen wie „der kann das nicht“, „die versteht das nicht“ oder “die beiden sind da eine Fehlbesetzung“. Ich könnte sogar recht haben, es nützt mir nur wenig. Denn ohne die systemische Sicht, kann ich dem Problem nicht auf den Grund gehen: Was in unserem System hat dazu geführt, dass die Situation so gekommen ist, wie sie gekommen ist? Dem kann man sich z.B. mit der „5-Why-Methode“ nähern, also so oft „Warum“ fragen bis man bei der Wurzel des Übels angekommen ist. Dadurch wird man Spielregeln oder Rahmenbedingungen des Systems verändern und so personenunabhängig die Organsiation besser machen.

    Deshalb sind Theorien so nützlich, weil sie uns zwingen, den Schritt heraus zu machen. Das System von Außen zu beobachten.   

Die Entdeckung der Langsamkeit

  • Meine Kollegin Doreen Timm ist schwanger und hat schon deshalb an der einen oder anderen Stelle wider ihrer Natur die Langsamkeit neu entdecken müssen. Jetzt hat sie mir berichtet, welche Kraft darin lag in einer Konfliktsituation bei einem ihrer Kunden:

    „Die Situation war so: Wir waren ungefähr in der Mitte des Sprints, ich habe als ScrumMaster ein Daily Scrum moderiert. Bei uns nimmt natürlich auch der Product Owner am Daily Scrum teil. Es kam zwischen den Entwicklern und dem PO zu einem lautstarken Streit über ein Feature. Den Entwicklern ging es um die Ausprägung des Features, die technische Umsetzung und die dahinterliegende Architektur. Schnell schlugen die Wogen hoch: Ist das Feature so überhaupt sinnvoll? Was daran schafft denn dem Kunden wert? Dabei war bei diesem schnellen Schlagabtausch zu spüren, dass der Druck im Team hoch ist. Alle waren einerseits auf der Suche nach einer schnellen knackigen Lösung, andererseits wurde bald schon nicht mehr nur dieses eine Feature, sondern das ganze Sprintziel in Frage gestellt. Diese Eskalation im Daily Scrum ereignete sich in nicht einmal 10 Minuten. Ich habe schließlich als ScrumMaster interveniert und die Hektik und den Druck aus der Diskussion genommen. Dazu habe ich das Sprintziel auf ein Flipchart geschrieben und jeden im Team reihum gebeten, dass er in seinen Worten beschreibt, was das für ihn bedeutet, während alle anderen aufmerksam zuhören. Das fühlte sich für die meisten erst wie ein Rückschritt an, weil die Geschwindigkeit aus der Diskussion raus war. Darüber konnten wir aber sehr schnell feststellen, dass es zu der Frage Einigkeit gab, die den Konflikt ausgelöst hat. Mental hatten wir uns alle auf eine längere Diskussion eingestellt, waren aber schon nach einer Viertelstunde damit durch. Gemeinsam erstaunte uns, wie gut es uns getan hat, das Tempo und den Lösungsdruck aus der Diskussion zu nehmen. Nur so konnten wir zu einer neuen, besseren Lösung für unser Problem gelangen. Herrlich, wenn man mit der Entdeckung der Langsamkeit neue Optionen schafft.“

    Danke, Doreen, für diesen Tipp. Ich habe es meistens eher eilig, mal sehen, wie gut mir die Entdeckung der Langsamkeit gelingt.

Den ersten Schritt machen

  • Meine Kollegin Doreen Timm ist schwanger und hat schon deshalb an der einen oder anderen Stelle wider ihrer Natur die Langsamkeit neu entdecken müssen. Jetzt hat sie mir berichtet, welche Kraft darin lag in einer Konfliktsituation bei einem ihrer Kunden:

    „Die Situation war so: Wir waren ungefähr in der Mitte des Sprints, ich habe als ScrumMaster ein Daily Scrum moderiert. Bei uns nimmt natürlich auch der Product Owner am Daily Scrum teil. Es kam zwischen den Entwicklern und dem PO zu einem lautstarken Streit über ein Feature. Den Entwicklern ging es um die Ausprägung des Features, die technische Umsetzung und die dahinterliegende Architektur. Schnell schlugen die Wogen hoch: Ist das Feature so überhaupt sinnvoll? Was daran schafft denn dem Kunden wert? Dabei war bei diesem schnellen Schlagabtausch zu spüren, dass der Druck im Team hoch ist. Alle waren einerseits auf der Suche nach einer schnellen knackigen Lösung, andererseits wurde bald schon nicht mehr nur dieses eine Feature, sondern das ganze Sprintziel in Frage gestellt. Diese Eskalation im Daily Scrum ereignete sich in nicht einmal 10 Minuten. Ich habe schließlich als ScrumMaster interveniert und die Hektik und den Druck aus der Diskussion genommen. Dazu habe ich das Sprintziel auf ein Flipchart geschrieben und jeden im Team reihum gebeten, dass er in seinen Worten beschreibt, was das für ihn bedeutet, während alle anderen aufmerksam zuhören. Das fühlte sich für die meisten erst wie ein Rückschritt an, weil die Geschwindigkeit aus der Diskussion raus war. Darüber konnten wir aber sehr schnell feststellen, dass es zu der Frage Einigkeit gab, die den Konflikt ausgelöst hat. Mental hatten wir uns alle auf eine längere Diskussion eingestellt, waren aber schon nach einer Viertelstunde damit durch. Gemeinsam erstaunte uns, wie gut es uns getan hat, das Tempo und den Lösungsdruck aus der Diskussion zu nehmen. Nur so konnten wir zu einer neuen, besseren Lösung für unser Problem gelangen. Herrlich, wenn man mit der Entdeckung der Langsamkeit neue Optionen schafft.“

    Danke, Doreen, für diesen Tipp. Ich habe es meistens eher eilig, mal sehen, wie gut mir die Entdeckung der Langsamkeit gelingt.

Zuhören

  • Mein Kollege Alex Bepple hat mir aus einem seiner Beratungseinsätze bei einem größeren Konzern den folgenden Tipp geliefert:

    „Die Bereitschaft zu Agilität war da, es war auch schon mit einer an Scrum angelehnten iterativen Entwicklungsweise gestartet worden. Da stellte sich sehr schnell die Frage, wie wir mit dem Aufwand für das Testen umgehen wollen. Immer nur manuell testen und das in so kurzen Zyklen, das ist keine Lösung. Es war also klar: Wir müssen etwas in Richtung Testautomatisierung tun. Aber was genau und womit beginnen? Darüber gab es in vielen Meetings sehr viele Ideen, viele Diskussionen. Es wurden viele Probleme identifiziert und Spekulationen darüber angestellt, warum und ob eine Lösung überhaupt funktionieren könnte. Zudem begannen Gespräche damit, welche Voraussetzungen erst geschafft werden müssten, bevor man damit beginnen könnte.
    Da habe ich mir einen der Entwickler geschnappt, der sich mit dem System und den Gepflogenheiten des Hauses gut auskannte und mich mit ihm abends verabredet. Zu zweit haben wir den ersten Test binnen knapp zwei Stunden automatisiert.
    Dieser erste Test hat die Diskussionen total verändert. Schluss mit der Theorie! Es gab einen ersten konkreten Bezugspunkt, es gab keine Ausreden mehr, was man noch klären müsste und bedenken sollte. So ging es los mit der Testautomatisierung.

    Dabei will ich gar nicht behaupten, dass es immer so glatt laufen wird. Es hätte natürlich schiefgehen können. Aber dann hätten wir jedenfalls gewusst, welche Bedenken stimmen und mit welchen Problemen wir uns wirklich beschäftigen müssen. Ich habe mir trotzdem gemerkt, dass ich langwierige Diskussionen lieber in die Richtung lenken will, den ersten kleinen Schritt zu machen, auf dessen Grundlage wir besser weiterdiskutieren können.“