Coaching-Tipps

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

Die „Kannst-du-mal“-Strichliste

  • Von Henning Wolf, April 2017

    Letzte Woche habe ich mit einer Runde von Delivery Leads zusammengesessen, die u.a. die Scrum Master Rolle für ihre Teams übernehmen. Wir sprachen über die Scrum-Meetings und typische Herausforderungen für die Teams und wie man mit ihnen umgehen kann. Dabei fiel mir ein Tipp wieder ein, dessen Anwendung ich schon in einigen Teams gesehen habe, auch unsere Moneypennys haben das schon mal gemacht.

    Das Problem vieler Teams ist es, dass sie neben ihren geplanten Aufgaben auch noch die Kategorie „Kannst-du-mal“-Aufgabe kennen. Das können ganz unterschiedliche, meist kleine Aufgaben sein, die man für andere Teams oder Kollegen erledigt. Wahrscheinlich kosten sie netto nur 5-10 Minuten, aber eben auch Fokus und Konzentration bezüglich der eigentlichen Aufgaben.
    Jetzt wollen wir nicht zusätzlich einen aufwändigen Verwaltungsprozess für den Kleinkram einführen oder womöglich das blöde „no-ticket-no-service“-Spiel spielen. Es wäre aber schon hilfreich zu erkennen, wie groß das Problem tatsächlich ist. Deswegen führen manche Teams an ihrem Board oder auch einem anderen Platz eine KDM-Strichliste (KDM = kannst du mal). So kann man später schauen, wie viele KDMs tatsächlich im Sprint oder pro Woche entstanden sind. Wer es gerne versierter mag, der kann einfach für jeden KDM einen Post-it an die Wand kleben und daraus eine lustige Schlange über dem Board bilden. Oder man schreibt sogar ein Stichwort, seinen Namen, den Namen des Anforderers, Start- und Endzeit dazu, dann kann man später bei Bedarf noch weiter auswerten.
    Bei unseren Moneypennys ist daraus die Rolle „Master-Moneypenny“ (MMP) entstanden. Die MMP ist für KDMs zuständig. Alle anderen Teammitglieder können so störungsfrei arbeiten.  

Ausprobieren vor Ändern

  • Von Markus Gärtner und Henning Wolf, März 2017

    Manche Änderungen scheinen uns oder unserem Team oder unserer Organisation zu groß. Damit geht einher, dass man der Änderung keine echte Chance gibt, weil es so sowieso nicht funktionieren wird oder nicht alle mitmachen. Manchmal haben wir ganz konkrete Ängste oder Bedenken oder einfach nur Unsicherheiten ob der Auswirkungen dieser Änderung.

    Viel weniger Widerstand erzeugt das Ausprobieren. Wenn wir also vielleicht nur einen Aspekt der Änderung oder nur einen kurzen Zeitraum auswählen, in dem wir das Neue/Geänderte einmal ausprobieren. Anschließend reflektieren wir, was passiert ist. Wurde es besser? Wurde es schlimmer? Sind unsere Befürchtungen eingetreten? Wie können wir die Änderung mit unserem jetzigen besseren Wissen so anpassen, dass sie leichter durchzuführen ist?

    Und: Theoretisch funktioniert das immer, weil sich alles kleiner schneiden lässt; trotzdem wird dieses Vorgehen nicht für jede Änderung Sinn ergeben. Aber vielleicht hilft es dir an der einen oder anderen Ecke. Das würde Markus und mich freuen.  

Effiziente Retro mit „The One“

  • Von Henning Wolf, Februar 2017

    Ich bin ein großer Fan von Retrospektiven, ich mache sogar regelmäßig welche mit meiner Frau! Dabei folgen wir in der Regel den fünf Phasen erfolgreicher Retrospektiven von Esther Derby und Diana Larsen.

    Wenn es schnell gehen soll oder man einen anderen Impuls setzen möchte in der Retrospektive, dann ist „The One“ geeignet:
    Die Idee ist, dass wir uns nicht wie sonst über Beobachtungen, Bewertungen und Ursachenanalysen einem Lösungsraum an Maßnahmen nähern, sondern direkt mit Lösungsideen einsteigen. Wir stellen uns gemeinsam die Frage:
    Wenn wir nur eine Sache im nächsten Sprint ändern können, was ist diese eine Sache?

    Du kannst dann je nach deinen Vorstellungen Varianten davon spielen. Lass' doch mal in 5 Minuten jeden für sich einen Vorschlag aufschreiben oder Gruppen von zwei oder drei Kollegen zusammen. Dann kannst du die Vorschläge vorstellen und gegeneinander antreten lassen oder auch erst ein Auswahlverfahren anwenden, indem z.B. zwei Kollegen oder zwei Gruppen zusammen entscheiden müssen, welche Idee sie besser finden.

    Am Ende macht es meist Sinn, dass man sich noch Zeit zum Verbessern und Konkretisieren der Idee nimmt. Insofern entsteht dadurch oft trotzdem mehr als eine Maßnahme für den nächsten Sprint.  

Storyblocker

  • Von Stefan Zumbrägel, Dezember 2016

    Mein Team arbeitete in einem Konzernumfeld gemeinsam mit anderen Teams an einem großen Programm. Das Team war sowohl für die Entwicklung neuer Funktionen als auch für den Support von bestehenden Funktionen verantwortlich.
    In dem Programm gab es die Vereinbarung, dass Supporttickets in bestimmten Zeiten bearbeitet werden mussten, unabhängig von der Sprintplanung.

    Die Supporttickets wurden von meinem Team am Sprintboard transparent dargestellt und im Daily, wie Tasks aus den Storys, gezogen und geplant. Allerdings führte das zu einer Fragmentierung des Teams, die sich vor allem darin zeigte, dass die gemeinsame Arbeit an Storys sehr stark zurückging. Es gab keine Zeit, in der das gesamte Team gleichzeitig an den Storys arbeitete. Das erschwerte das Pairprogramming sowie Rückfragen an andere Teammitglieder, da diese evtl. mit einem Supportticket an einer ganz anderen Stelle unterwegs waren und sich jedes Mal wieder in die Story hineindenken mussten.

    Das Team war damit sehr unzufrieden. Vor allem weil es das Gefühl hatte, viel Zeit mit warten oder umdenken zu verbringen. Es fühlte sich zwischen den verschiedenen Erwartungen von außen und von sich selbst zerrieben.

    Die Lösung des Dilemmas wurde unter dem Titel „Storyblocker“ entwickelt. Zunächst einmal war das ein simpler Eintrag in allen Kalendern der Teammitglieder am Vormittag zwischen Daily und Mittagessen. Damit einher ging die Vereinbarung des Teams, in dieser Zeit ausschließlich an Storys zu arbeiten. Somit waren in dieser Zeit alle Teammitglieder gedanklich mit Storys beschäftigt. Pairprogramming konnte in dieser Zeit gut gemacht werden und Rückfragen konnten gut beantwortet werden, da alle gedanklich schon in den Storythemen steckten.

    Damit konnte das Team einen deutlich höheren Fokus erreichen. In einem ersten Rückblick gab das Team an, dass sich auch die Bearbeitung der Supporttickets schneller anfühlte, da es weniger Störungen durch Rückfragen zu Storys gab.

    Auch als ScrumMaster und PO haben wir uns an diesen Blocker gehalten. Termine für Refinements oder Arbeitstermine mit dem Team zu bestimmten Themen, wurden bewusst außerhalb des Storyblockers gelegt. Das Team war mit dem Blocker so zufrieden, dass sie jeglichen Versuch, in diese Zeit etwas anderes zu legen, sehr kritisch hinterfragt und im Zweifelsfall abgelehnt haben. Erfreulicherweise hat sich dies sogar auf das Linienmanagement ausgewirkt.

Mach' konkrete Ansagen!

  • Von Claudia Reitenbach und Peter Rößler, November 2016

    Du hast dein Meeting vorbereitet und überlegst, wie du methodisch vorgehen willst. Prima! Im Meeting erklärst du der Gruppe, was als nächstes passiert und willst anschließend den Startschuss zu einer Aktivität geben. Du richtest Dich an die Gruppe: „Könntet ihr vielleicht dazu bitte aufstehen?“. Die Reaktion: Stille. Kaum einer rührt sich oder die Gruppe reagiert nur zögerlich. Kennst Du das auch?

    Ein einfacher Tipp, der Klarheit und Orientierung schafft: Mache ganz konkrete und direkte Ansagen an die Gruppe. Kein „vielleicht“, kein „ko?nntet“ , kein “würdet” oder sonstige Abschwächungen, sondern ein klares „Steht jetzt bitte alle auf!“ (evtl. unterstützt mit einer passenden Geste). Beobachte doch mal in deinem nächsten Meeting, wie klar deine Moderation ist. Für viele fühlt es sich oft erstmal befremdlich an, so direkt und forsch zu sein. Du wirst aber schnell merken, dass es der Gruppe ungemein hilft, klare Ansagen zu bekommen. Wenn es dir schwer fällt, die konkreten Ansagen im Meeting zu finden, schreibe dir die Ansagen in der Vorbereitung auf oder u?bertrage sie in deinen Moderations-Ablaufplan. 

Besser mit Blockern

  • Von Wolfgang Wiedenroth, Oktober 2016<br/><br/>Es geht um ein Adminteam mit elf Teammitgliedern, die mit Kanban und einem physikalischen Kanbanboard arbeiten. Schon auf den ersten Blick kann man am Board die vielen roten Post-its sehen, die wir als Markierung für geblockte Tickets benutzt haben. Wir haben außerdem eine gemeinsame Regel festgelegt, dass wir auf die Blocker den Grund für die Blockade schreiben. Dies hat uns erlaubt, systematisch auszuwerten, wo die Blocker herkommen und was sie bewirken. Wir hatten in vier Wochen 86 Blocker, die in Summe zu 516 Tagen Blockzeit geführt haben! Diese Blocker haben wir dann nach Art und Gründen geclustert, was zu sehr nützlichen Erkenntnissen darüber geführt hat, welche typischen Ursachen zugrunde liegen. Dabei hat es sehr geholfen, sich auf die größten Cluster mit den meisten und längsten Blockaden zuerst zu stürzen und dafür Verbesserungsmaßnahmen zu finden. Das hat in der Folge zu deutlich weniger Blockaden und besseren Durchlaufzeiten geführt. Bei einem der großen Cluster hat eine Besprechung mit einem der Abteilungsleiter geholfen: In den nächsten Wochen waren schon prompt und ohne großen Aufwand ein Drittel weniger Blocker aus diesem Bereich, weil dort die Prozesse entsprechend verändert werden konnten.

Team-Sprechstunde einführen

  • Von Stefan Zumbrägel, September 2016

    Mein Team arbeitete in einem skalierten Umfeld mit weiteren Teams in einer Multi-Projekt-Umgebung. Alle Teams waren Komponententeams mit jeweils etwas Grundwissen über die anderen Komponenten. Dadurch waren die Teams trotz der bestehenden Abhängigkeiten in der Lage zu einem gewissen Grad autonom zu arbeiten. Innerhalb ihrer Komponente waren die Teams für den kompletten Prozess bis zu Produktivsetzung und den anschließenden Support zuständig.

    Da die Komponente meines Teams eine sehr zentrale in dem System war und sich einige Teammitglieder zudem in den bestehenden Communities of Practice engagierten, kam es immer wieder vor, dass Personen aus anderen Teams oder aus dem Linienmanagement mit Fragen an einzelne Teammitglieder herantraten. Dies war im Projektumfeld und im Unternehmen die Kultur und hat zunächst aus Sicht des Teams kein Problem dargestellt.

    Mit der Zeit wurden diese Anfragen aber mehr und wurden bald vom gesamten Team als Störung empfunden. Es war schwierig, im Pairprogramming oder allein über einen längeren Zeitraum konzentriert an den Sprintinhalten zu arbeiten.

    Das Team war in einer Zwickmühle. Man wollte auf der einen Seite die Teams unterstützen, aber selber konzentriert arbeiten. So entstand die Idee Team-Sprechzeiten in Anlehnung an Öffnungszeiten bei Behörden einzuführen. Nur in dieser Zeit stand das Team für Anfragen von außerhalb zur Verfügung. Es wurde eine Stunde pro Tag angeboten. Außerhalb dieser Zeiten wurden Anfragen freundlich aber bestimmt abgewiesen. Konkret haben wir Schilder an den Türen mit den Sprechzeiten angebracht und zum Teil das Telefon auf den ScrumMaster weitergeleitet.

    Als ScrumMaster war ich gerade in der ersten Zeit stark gefordert, das Team bei der Aufrechterhaltung dieser Regel zu unterstützen. Zum einen moralisch, zum anderen vor allem in der Argumentation mit und gegenüber den anfragenden Personen. Diese „Pförtnerrolle“ war nach einer Eingewöhnungszeit nicht mehr notwendig.

    Das Ergebnis war sehr positiv. Wenig überraschend: Das Team konnte in der ungestörten Zeit viel effizienter und stressfreier arbeiten. Die Anzahl der Anfragen ging stark zurück. Es wurde nicht untersucht woran das lag, die Vermutung ist aber, dass selber Lösungen gefunden oder Anfragen gebündelt wurden und damit besser beantwortet werden konnten. Außerdem gab es viel positive Resonanz für die konsequente Umsetzung. So kam aus anderen Teams die Rückmeldung, dass es so zwar einen kleineren Zeitraum gibt für Fragen, dafür aber auf jeden Fall jemand da ist und sich Zeit für die Anfrage nimmt.

Fit for Purpose Survey

  • Von Wolfgang Wiedenroth, August 2016

    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”.

    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.

Problem und Rahmen statt Lösung

  • Von Henning Wolf, Juli 2016

    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

  • Von Henning Wolf, Juni 2016<br/><br/>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.<br/><br/>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.<br/><br/>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

  • Von Doreen Timm, Mai 2016<br/><br/>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.

Den ersten Schritt machen

  • Von Alex Bepple, April 2016

    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.

Offene Priorisierung

  • Von Henning Wolf, März 2016

    Ein it-agile-Kollege hat bei einem unserer Kunden folgendes erlebt:
    Der Kunde stellt ein Produkt her und hat seine Produktentwicklung in Teams organisiert, die jeweils für die Entwicklung bestimmter fachlicher Aspekte des Produktes zuständig sind. Alle Teams hatten damit zu kämpfen, dass es sehr viele Stakeholder gab mit sehr vielen (bestimmt guten) Ideen. Da waren die Fachabteilungen, das Marketing, der Kundenservice und auch noch die anderen Teams. Das führte zu sehr langen Listen von Wünschen, was dei Teams erledigen sollten, vielen Umprioriserungen auf dieser Liste und vielen Nachfragen, wann denn mit bestimmten Features zu rechnen sei.
    Du kannst dir vielleicht vorstellen, dass all diese Wunschlisten, Umpriorisierungen und Nachfragen weder das Team schneller noch die Stakeholder glücklicher gemacht haben.
    Eines der Teams hat deshalb für sich beschlossen, dass es so nicht weitergehen könne. Sie haben im Entwicklungstakt von zwei Wochen ein offenes Priorisierungsmeeting anberaumt. Zu diesem Meeting waren alle Stakeholder und letztlich alle in der Firma herzlich eingeladen. Das Team hatte die Erfahrung gemacht, dass es sinnvollerweise nicht an mehr als 2-3 neuen Features gleichzeitig arbeiten kann und noch nie mehr als 6 neue Features in zwei Wochen fertiggestellt hat. Beim ersten Priorisierungsmeeting war der Entwicklerraum voll mit Stakeholdern und das Team erklärte seine neuen Spielregeln: Keine Liste mehr, hier und jetzt wird über die zwei Sachen entschieden, die wir definitiv als erstes bearbeiten und mit sehr hoher Wahrscheinlichkeit in zwei Wochen fertig haben. Zusätzlich nehmen wir gerne noch 3 weitere Themen mit und beginnen mit denen, wenn es geht. Wenn nicht, bringen wir es ins nächste offene Priorisierungsmeeting wieder mit und müssen gemeinsam neu entscheiden.
    Was sich im Folgenden entspann war eine sehr nützliche Diskussion der Stakeholder untereinander, welches Feature für das Unternehmen am wichtigsten sei. Das war für die ersten 2-3 Features meist einfach zu entscheiden. Und insbesondere war es für die Stakeholder einfacher zu entscheiden als für das Entwicklungsteam.
    Diese Art der Priorisierung war für die Stakeholder eine Umstellung, aber insgesamt ist sie sehr erfolgreich. Ich habe letzte Woche mal nachgefragt, das TEam macht es heute noch genauso. Es ist eines der erfolgreichsten und beliebtesten Teams, weil es sehr zuverlässig liefert. Dank der offenen Priorisierungsmeetings sogar zuverlässig das wichtigste, was gerade ansteht.


    Mein Kommentar: So ist es clever! Die Stakeholder erkennen so, dass es nicht primär am Entwicklungsteam liegt, wenn sie etwas nicht (jetzt) bekommen, sondern an den anderen Stakeholdern und unternehmensweiten Priorisierungen. Zudem müssen sie sich selbst darum kümmern, dass ihre für sie und das Unternehmen wichtigen Themen erledigt werden. Das hält sie vermutlich auch davon ab, sich parallel noch mehr Dinge auszudenken. Oder die neuen Ideen dann auch schon selbst als ihre neuen allerwichtigsten Themen mitzubringen.
    Ich weiß aber auch, dass du jetzt vielleicht denkst, dass das so bei dir und eurer Konstellation leider nicht möglich ist. Das glaube ich auch. Gleichzeitig solltest du aber die Anregung mitnehmen, darüber nachzudenken, wie die Stakeholder untereinander ihre Prioritäten im Sinne des Gesamtinteresses selber abgleichen können. Zudem würde ich dir empfehlen, nicht der Verwalter von Stakeholderideen zu werden. Das sollten und können sie gut selber erledigen.

Wissensinseln visualisieren

  • Von Henning Wolf, Februar 2016

    Schon vor einiger Zeit hatte ich in einem Projekt mit einer großen Produktentwicklung zu tun - knapp 100 Entwicklern in 10 Teams. Es gab grob eine fachliche Zuordnung der Teams zu bestimmten Modulen des insgesamt schon sehr sehr großen Softwaresystems (Java). Immer mal wieder tauchte das Problem auf, dass es Anforderungen gab, für die bestimmte Ecken des Systems geändert oder erweitert werden mussten, mit denen sich nur wenige Entwickler auskannten. Das machte die Entwicklung langsam, weil um diese Abhängingkeiten von einigen Spezialisten herum geplant werden musste. Uns schien es zumindest auf Teamebene sehr klar, dass etwas unternommen werden muss. Und leider war auch klar, dass es Geld kosten würde bzw. erstmal noch langsamer macht. Ein Okay des Managements war also unumgänglich. Uns war aber auch klar, dass wir dafür genauer benennen können müssen, wo das Problem liegt und woran man erkennne würde, dass es besser geworden ist.
    Deshalb haben wir das aktuelle Architekturbild hergenommen und eine Abfrage unter allen 100 Entwicklern gemacht, wie gut sie sich - in Schulnoten ausgedrückt - in den jeweiligen Teilen des Systems auskennen. Dazu haben wir uns eine Farbmarkierung ausgedacht, wie wir welches Modul in Abhängigkeit von der Durchschnittsnote (oder Anzahl Leuten, die besser als 4 vergeben haben) einfärben.
    Das Bild war nicht ganz so erschreckend, wie wir gedacht haben, zeigte aber klare Hotspots, an denen dringend mehr Knowhow aufgebaut werden musste. Das war über die Visualisierung (ähnlich nebenstehend) auch für Manager leicht nachvollziehbar.

    Zudem konnten wir nach einiger Zeit die Umfrage erneut durchführen und die Verbesserungen über die Zeit beobachten.

Vom Problemfilm zum Zielfilm

  • Von Nadine Wolf, Dezember 2015

    Wenn ich bei mir oder anderen beobachte, dass Gedanken oder Gespräche sich nur um das Problem drehen und keine schnelle, einfache Lösung auf der Hand liegt, finde ich einen Perspektivwechsel immer hilfreich. In meiner Weiterbildung zum systemischen Coach heißt dies: Aus dem Problemfilm in den Zielfilm. Das Schöne daran ist, dass man nicht gleich zur Lösung geht, sondern zunächst ganz frei und kreativ ein Szenario entwirft, wie man sich den Zustand eigentlich wünscht.

    Also angenommen, das Problem ist gelöst...
    • ...was ist dann anders?
    • ...wie sieht mein Tagesablauf dann aus?
    • ...was sage/fühle/tue ich?
    • ...woran merken das meine Kollegen?
    • ...was geht dann vielleicht nicht mehr?
    • ...was ist dafür möglich?

    Dafür hilft es mitunter auch an die Vergangenheit zu denken: Hat es Zeiten gegeben, in denen ich das Problem nicht hatte? Was war da anders?

    Mit den Antworten auf diese Fragen hat man ein Ziel, ein Bild, ein Gefühl zum Wunschzustand in sich. Nun kann man überlegen, was ein erster Schritt in diese Richtung sein kann.

Gewaltfreie Kommunikation (GFK)

  • Von Sebastian Keller, September 2015

    Gewaltfreie Kommunikation (GFK) von Marshall B. Rosenberg ist ein Kommunikationsmuster um Konflikte zu deeskalieren. In selbstorganisierten Teams werden Entscheidungen gemeinsam getroffen. Dabei kommt es vor, dass Teammitglieder hitzige Diskussionen führen. Im schlimmsten Fall schaukeln sich solche Gespräche hoch, bis Teammitglieder nicht mehr miteinander reden oder arbeiten wollen. Man kann ein Muster bei diesen Gesprächen feststellen: Die Beteiligten wechseln sich im Dialog schnell ab und sprechen nur noch über ihre eigenen Standpunkte. Sie nehmen sich keine Zeit sich gegenseitig zu verstehen.

    GFK schlägt vor, Aussagen mit vier Bestandteilen zu formulieren:
    • Beobachtung
    • Gefühl
    • Bedürfnis
    • Wunsch

    "Bei den letzten vier Daily Standups habe ich beobachtet, dass du dich hingesetzt hast (Beobachtung). Ich bin irritiert und nervös (Gefühle) weil ich gegenseitigen Respekt und Authentizität gegenüber unseren Regeln brauche (unerfülltes Bedürfnisse). Möchtest du mir bitte sagen, was du gehört hast, was ich gerade gesagt habe? (Wunsch)"
    Mit GFK würde so jedoch der Dialog nicht beginnen. Das andere Teammitglied wäre wohl überrascht und würde vielleicht aggressiv reagieren. "Ich mach doch bei diesem blöden Meeting mit! Was willst du denn noch?"

    Mit GFK ist der erste Schritt, sich Selbstempathie in einem inneren Monolog zu schenken. Dabei geht man die vier Bausteine wie im obigen Beispiel durch, um sich über seine Gefühle und die unerfüllten Bedürfnisse klar zu werden. Dann beginnt man den Dialog mit dem Schenken von Empathie an den, den man ansprechen will. "Wenn wir ein Daily Standup machen und du dich hinsetzt (Beobachtung), bist du verärgert (Gefühl) weil du Vorankommen im Team und Klarheit über den Nutzen dieses Meetings brauchst (Bedürfnisse)?" Es ist OK, wenn man falsch liegt.
    "Nein, ich mag dieses Meeting. Ich hab mir vor vier Tagen den Knöchel verstaucht. Mir tuen schon fünf Minuten stehen weh"
    "Du hast also Schmerzen (Gefühl) und brauchst Entlastung für deinen Fuß (Bedürfnis)?"
    "Ja!"

    Das "Ja" ist das Zeichen, dass sich das Teammitglied verstanden fühlt. Jetzt ist ein guter Zeitpunk über seine eigenen Gefühle und Bedürfnisse zu reden.
    "Wenn du mir sagst, dass du wegen Schmerzen beim Standup nicht stehen kannst (Beobachtung), bin ich erleichtert (Gefühl), weil ich Transparenz brauche, wenn eine Teamregel nicht eingehalten wird (erfülltes Bedürfnis). Möchtest du mit mir überlegen, wie wir es für uns im Team einfacher machen, Transparenz herzustellen, wenn wir uns mal nicht an eine Regel halten (Wunsch)?"

    GFK hilft dabei den Dialog zu entschleunigen, sich gegenseitig zu verstehen und eine Lösung zu finden die alle Bedürfnisse erfüllt.

Stakeholder-Management

  • Von Doreen Timm, August 2015

    Häufig hat man es mit mehreren Stakeholdern zu tun, die Wünsche anmelden. Die verschiedenen Wünsche sind häufig unvereinbar, vor allem bzgl. der gewünschten Termine. Zunächst sollte man sich selbst davon frei machen, das Problem für die Stakeholder lösen zu müssen. Das funktioniert nämlich nicht.

    Idealerweise gibt es eine klare Produktvision und damit auch eine klare Linie bzgl. der Priorisierung von Features. Dann kann man die Wünsche der Stakeholder gegen die Produktvision halten und passend priorisieren. Wichtig ist dann, unangenehme Nachrichten (z.B. "Wir werden deine Wünsche in den nächsten drei Monaten nicht berücksichtigen, weil andere Dinge für die Produktvision wichtiger sind.") direkt und klar zurückzumelden.

    Wenn so eine klare Richtung bzgl. der Priorisierung fehlt, muss man das gemeinsame Gespräch mit den Stakeholdern suchen. In einem Workshop sollten dann alle Wünsche auf den Tisch gelegt und gemeinsam diskutiert werden.

    Als Moderationstechniken in so einem Workshop eignen sich z.B. "Buy a Feature" oder "Prune the Product Tree" (beide aus dem Buch "Innovation Games"). Gerne kann man den Scrum Master bitten, bei der Moderation des Workshops zu unterstützen.

Von der Sitzung zur Stehung zur Gehung

  • Von Anna Lorenz, Juli 2015

    Wenn wir zusammenkommen, um etwas zu besprechen, tun wir das meist in Form einer Sitzung. Die Erfahrung der meisten ist, dass dieses Format häufig nicht produktiv ist. Oft fehlt diesen Meetings der Fokus und die Moderation. Durch die Vorbereitung aller Teilnehmer und das Einsetzen eines Moderators kann man es verbessern.
    Eine andere Möglichkeit etwas zu verändern besteht darin, die Besprechung im Stehen durchzuführen (in Ahnlehnung an das Daily Scrum im Stehen). Stehen ist unbequemer als Sitzen, deshalb werden Mammut-Sitzungen von mehreren Stunden unwahrscheinlicher. Außerdem bringt Aufstehen sofort mehr Sauerstoff ins Gehirn. Dadurch sind die Teilnehmer konzentrierter und aufnahmefähiger.

    Im wahrsten Sinne des Wortes kann man noch einen Schritt weitergehen und aus der Stehung eine Gehung machen. Dann besprechen wir uns während wir einen Spaziergang machen, so wie Steve Jobs es sehr häufig praktiziert hat. Gehen bringt noch mehr Sauerstoff ins Gehirn. Außerdem nehmen wir eine sich ständig verändernde Umgebung wahr, was die Kreativität fördert. Schon Friedrich Nietzsche sagte: „Trau keinem Gedanken, der dir im Sitzen kommt.“

    Und nicht zuletzt adressiert die Gehung ein Problem, das wir in allen Unternehmen sehen: zu wenig Meeting-Räume.

    Von Nilofer Merchant gibt es einen kurzen TED-Talk zu dem Thema: Got a meeting? Take a walk

Pairing zum Wissenstransfer

  • Von Henning Wolf und Stefan Roock, Juni 2015

    Viele kennen Pair Programming als Spezialform des Pairing und machen gute Erfahrungen damit. Unserer Erfahrung nach ist das Pairing-Konzept aber viel breiter anwendbar als nur bei der Programmierung. Wir verwenden es zur Einarbeitung neuer Mitarbeiter sowohl bei unseren Moneypennies als auch bei den Beratern. Wir haben mit Pairing auch sehr gute Erfahrungen gemacht, um Kollegen im Vertrieb auszubilden. Welche Bereiche gibt es in deinem Unternehmen, in denen du Wissenstransfer wünscht. Ist Pairing möglicherweise die geeignete Form dafür?

Good enough for now (gut genug, um fortzufahren)

  • Von Stefan Roock, Mai 2015

    In Gruppenprozessen wie z.B. Workshops gibt es häufig ein Spannungsfeld aus dem Wunsch nach Vorwärtskommen und der Notwendigkeit, die Beteiligten mitzunehmen. Die einen haben ein Thema gedanklich längst abgeschlossen und wollen zum nächsten Schritt weitergehen. Die anderen sind noch mit dem Thema beschäftigt und wollen weitere Fragen klären. Die erste Gruppe fühlt sich gelähmt, die zweite gedrängt. Diese Situation kann der Diskussion jegliche Energie entziehen.
    Ich arbeite dann gerne mit der Idee "good enough for now" (gut genug, um fortzufahren). Ich versuche gleich zu Beginn ein Verständnis in der Gruppe darüber zu schaffen, dass nicht alle Fragen geklärt werden können oder gar die perfekte Lösung konzipiert werden kann. Stattdessen müssen wir regelmäßig darüber reflektieren, ob der erreichte Diskussionsstand gut genug ist, um fortfahren zu können. Das kann man z.B. über Handmeldungen schnell herausfinden. Wenn Teilnehmer noch nicht soweit sind, dass sie fortfahren können, frage ich sie ganz konkret, was für sie noch geklärt werden muss. Daraus entsteht dann ggfs. eine konkrete ToDo-Liste für die weitere Diskussion. Und natürlich kann man gemeinsam darüber reflektieren, ob die Fragen wirklich an Ort und Stelle geklärt werden müssen. Häufig reicht es für die Teilnehmer aus, wenn sie die Gewissheit haben, dass das Thema nicht verloren geht und nach dem Workshop adressiert wird.

Erwartungsmanagement und ROTI

  • Von Peter Rößler, April 2015

    Peter hat zwei Tipps für Meetings kombiniert, die beide mit Erwartungsmanagement und dem Wunsch nach produktiven und wertvollen Meetings haben. Zum einen beginnt Peter Meetings gern mit einer kurzen Abfrage der Erwartungen. So lässt sich von Anfang an hoffentlich der Fokus des Meetings so setzen, dass die meisten profitieren. Manchmal wird vielleicht klar, dass die Erwartungen überzogen oder zu vielfältig sind. Dann lieber früh Klarheit darüber haben.
    Nach ungefähr der Hälfte der abgelaufenen Meetingszeit stellt Peter dann die Frage, ob denn das Meeting in Bezug auf die Erwartungen in die richtige Richtung läuft oder noch mehr oder anderer Fokus hergestellt werden muss. So kann unterwegs gegengesteuert werden, bevor am Ende alle frustriert sind.
    Schließlich fragt Peter am Ende von Meetings gerne den "Return on time invested", kurz ROTI ab. Dafür wird eine Skala z.B. von -2 bis +2 aufgemalt mit folgender Bedeutung:
    • -2: totale Zeitverschwendung
    • 0: Aufwand und Ertrag standen ungefähr im Gleichgewicht
    • +2: bringt mehr Nutzen als die investierte Zeit gekostet hat

    Man kann den ROTI einfach auf einem Flipchart ankreuzen lassen, man könnte ihn auch auf verdeckten Zetteln einsammeln. Manchmal nutzt Peter den ROTI nur als Feedback für sich, manchmal diskutiert er das Ergebnis auch noch mit den Teilnehmern, um daraus zu lernen: Warum ist es für dich eine -1? Was war konkret so wertvoll, dass du eine +2 gegeben hast?
    In Abwandlung des Perfection Game, dem Coachingtipp vom letzten Mal, könnte man auch fragen: Was hätte passieren müssen, damit du einen um einen Punkt höheren ROTI hättest geben können?  

Force Field Analysis

  • Von Henning Wolf, Januar 2015

    Ich glaube, dass es auf meinem ersten Scrum Gathering war, vermutlich 2011 in Amsterdam. Da habe ich einen Workshop bei Rachel Davies besucht und Sie hat mir dort unter anderem die Force Field Analysis beigebracht. Die Technik ist viel älter, wie ich heute weiß, und geht auch nicht auf Rachel zurück, aber darum geht es bei Coaching-Tipps ja auch nicht. Die Hauptsache ist, dass sie nützlich sind.
    Die Force Field Analysis ist immer dann hilfreich, wenn wir nach einem Hebel für Veränderungen suchen. Wir stellen uns einen Zustand vor, entweder den aktuellen oder einen gewünschten. Jetzt überlegen wir uns, welche Kräfte positiv auf diesen Zustand, sein Zustandekommen und seine Stabilität wirken. Dies sind die Driving Forces oder eben treibenden Kräfte. Auf der anderen Seite gibt es die Kräfte, die negativ auf den Zustand wirken, ihn verändern wollen oder instabil machen. Dies sind die Restraining Forces oder eben der Widerstand. Nun kann man sich für die treibenden Kräfte und die Widerstände noch jeweils überlegen, wie stark diese sind (und dies z.B. durch unterschiedlich dicke Pfeile visualisieren).
    Die Hebel für Veränderung liegen jetzt vor uns; welchen wir wählen, wird auch davon abhängen, wie einfach oder chancenreich uns das Verstärken von treibenden Kräften oder das Abschwächen von Widerständen scheint. Ich finde aber besonders schön, dass die Technik bewusst macht, dass wir einen Mix aus Hebeln auf beiden Seiten finden müssen. Außerdem müssen wir nicht alle Widerstände einzeln brechen, die treibenden Kräfte müssen nur relativ stärker sein als die Widerstände.

    May the force be with you!

Pareto revisited (80:20-Regel)

  • Von Henning Wolf, Dezember 2014

    Die meisten von Ihnen kennen sicherlich das Pareto-Prinzip (oder eben die 80:20-Regel). Ich glaube, dass 20% der Coachingtipps für 80% des Coachingerfolgs verantwortlich sind, deswegen wiederhole ich hier gerne bekannte Tipps. So rufen wir uns das wieder ins Gedächtnis und können vielleicht konkreten Nutzen daraus ziehen.

    Vilfredo Pareto (1848–1923) untersuchte die Verteilung des Bodenbesitzes in Italien und fand heraus, dass 20% der Bevölkerung 80% des Boden besitzen. Dieser Effekt wird heute häufig auf viele Bereiche verallgemeinert. Dabei sollte man es mit den Prozentzahlen nicht zu genau nehmen, dennoch kann man feststellen, dass nur ein sehr kleiner Teil des Einsatzes für einen großen Teil des Effektes verantwortlich ist. Und im Umkehrschluss ein (zu) großer Teil des Aufwandes in (zu) wenig Effekt investiert wird.

    Für Product Owner: Die meisten Produkte enthalten Features, die kaum oder gar nicht genutzt werden, vermutlich machen nur 20% der Features 80% des Nutzens aus. Auf diese sollten wir uns als Product Owner als erstes stürzen. Aber selbst für jedes einzelne Feature kann man sich überlegen, ob es nicht auch einen 20%-Kern enthält, der 80% des Nutzens hervorbringt (und sich damit den Rest erstmal oder dauerhaft ersparen). Beim Beurteilen des Aufwands mag es ähnlich sein: Sprechen Sie doch bewusst als Product Owner Ihre Entwickler darauf an, welcher Teil eines Feature den größten Aufwand macht. Vielleicht ist es ein Teil, auf den Sie (erstmal) verzichten können.

    Für ScrumMaster und Verbesserer: Vermutlich liegt in 20% unserer Verbesserungsideen und Problembehebungen 80% des Hebels. Deswegen ist das Priorisieren und Beschränken auf einige wenige Maßnahmen je Retrospektive oder Veränderungsschritt so wichtig. Meistens wird es vermutlich hinkommen, wenn wir Teams und Gruppen die Priorisierung selbst übernehmen lassen, es ist jedoch keine Garantie. Aber eine Diskussion über die Hebelkraft von Maßnahmen kann vielleicht helfen zu entdecken, dass man sich nur an Maßnahmen mit kleiner Wirkung herangetraut hat (die wohl 80% aller Maßnahmen ausmachen dürften).

    Für alle: Ich bin an diesen Tipp erinnert worden durch ein Zeitmanagementseminar und eine Unterhaltung mit meinem Kollegen Holger Bohlmann. Er hat mir aus einem privaten Projekt berichtet, in dem ein einzelnes Feature die wesentliche Begeisterung auslöste und dadurch alles andere fast egal war in seiner Qualität. Unseren Perfektionismus sollten wir uns also für nur 20% unserer Tätigkeiten aufsparen, zumindest wenn wir herausgefunden haben, welche 20% dies sind. Alles andere können wir dann entpannter in "Good-Enough-Quality" produzieren.