Coaching-Tipps

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

Die Auflösung des Teams zelebrieren

  • Von Henning Wolf, Oktober 2018

    Wir kommen immer wieder in Situationen, in denen es notwendig ist, eine Gruppe oder sogar ein lang bestehendes Team aufzulösen. Egal ob am Ende eines Projektes, weil das Produkt nicht mehr weiter entwickelt wird oder aufgrund von Umstrukturierungsmaßnahmen.

    Bei it-agile haben wir zum Beispiel gerade eines unserer Business-Teams aufgelöst mit dem wir seit einiger Zeit intensiv zusammengearbeitet haben. Um hier einen guten Abschluss zu finden, habe ich eine Methode mitgebracht, die wir im Rahmen eines Coachingprogramms kennen gelernt habe. Leider habe ich keine Quelle dafür - daher nenne ich es „Was ich noch zum Team sagen möchte“.

    Eine Person startet mit einer kurzen Aussage „Was ich noch zu meinem Team sagen möchte ...“. Diese Aussage wird nicht kommentiert. Danach wird ein Gegenstand (Sprechstein, Stift, ...) an den rechten Nachbarn weitergegeben mit der Frage „Und was möchtest du noch zum Team sagen?“. Diese Person hat zwei Optionen:

    • eine kurze Aussage machen und den Gegenstand mit derselben Frage an den nächsten Nachbarn geben
    • „passen“ und den Gegenstand ohne eine Aussage, aber mit der Frage an den nächsten Nachbarn geben 

    Die Zeremonie endet, wenn eine Runde lang alle Teammitglieder gepasst haben.

    Wir fanden es für uns einen schönen Abschluss und es ist mir danach leicht gefallen mich auf die noch etwas ungewisse neue Zukunft einzulassen.

     

     

Kreative Raumgestaltung beflügelt

  • Von Tom Zigan, September 2018

    Schon mit geringen Mitteln können etwas zu formal geratene Räumlichkeiten aufgelockert werden und setzten so ungeahnte kreative Enerige frei.

    Die Ausgangslage ist mir schon (zu) oft begegnet. Um zum Raum für das „Product Development Meeting“ zu gelangen, gehe ich durch lange Flure mit grau melierter Auslegware, weiß gestrichenen Wänden und teilweise vergilbten Plakaten, welche dabei sind sich vor Scham, das sie schon lange nicht mehr wahrgenommen werden langsam selbst von ihrem Platz entfernen. Angekommen sieht der Meeting-Raum oft entsprechend aus, eventuell gekrönt durch teilweise herabhängende Jalousien und eine Topfpflanze der man wünscht es doch bald hinter sich zu haben. In solchen Umgebungen wird es mit der Kreativität oft zäh.

    Was kann also getan werden? Insbesondere in Umgebungen, die erst überzeugt werden wollen? Eigeninitiative ist hier gefragt. Ein paar Vorschläge:

    • kreatives Spielzeug bereitstellen, welches das Denken unterstützt. Schaut mal auf Floh- oder Stadtteilmärkten, oft finden sich dort nette Dinge für sehr wenig Geld. 
    • wenn möglich stellt die Tische zumindest aus der Mitte des Raums und bildet einen Stuhlkreis für besser Kollaboration
    • noch bequemer ist es eventuell auf mit Luft gefüllten Sitzsäcken oder Gymanstikbällen
    • schmückt die Wände mit farbenfrohen (vielleicht sogar selbstgemalten) Visualisierungen, etc. (Nehmt z.B. Malertape und klebt es gerollt auf die Rückseite des Plakates, damit ihr die Plakate möglichst oft wiederverwenden könnt)
    • Hängt Zitate von kreativen Vordenkern auf, welche z.B. die gemeinsamen Werte repräsentieren
    • Stellt eine kleine blühende Pflanze in die Mitte des Raums, als Symbol eurer Initiative

    Ganz wichtig: Sprecht die Menschen in eurer Arbeitsumgebung an. Fragt sie danach, was sie benötigen um kreativ zu sein. Ihr werdet überrascht sein! Alles was hilft, ist nötig. Sucht euch Mitstreiter, jeder kann beitragen.

    Abschließender Tipp: Alle Dinge die ihr benutzt, sollten schnell ohne Rückstände wieder zu entfernen sein. Damit vermeidet ihr zu Beginn eurer Initiative Ärger mit den Hütern der bestehenden bisherigen Ordnung. Irgendwann bekommen diese schon mit was ihr macht und ihr könnt Ihnen dann das „Warum“ erklären und sie wahrscheinlich schon mit Erfolgsgeschichten überzeugen.

    Viel Spaß beim Ausleben eurer Kreativität

Remote Bucket Estimation mit Trello

  • Von Beatrice Eicke, August 2018

    Wenn du Bucket Estimation nicht kennst, hier die superkurze Erklärung von mir: Es gibt Orte je Schätzgröße, und die Entwickler sortieren ohne größere Kommunikation die zu schätzenden Backlog-Items auf diese Orte. Wenn sie sich nicht einig sind und deshalb eine Karte viel hin- und hergeht, wird sie auf einen Parkplatz gelegt und später besprochen. Hier die Erfahrung von Beatrice: „Bisher waren wir ein glückliches Team an einem Ort, aber seit einer Weile sind wir ein glückliches Team mit Ergänzung von anderen Standorten. Die meisten Entwickler kannten bereits Bucket Estimation. Wir haben uns ein kleines Trello-Board aufgebaut, dort alle zu schätzenden Einträge als Tickets angelegt und Spalten für die T-Shirt-Größen XS, S, M, L, XL, XXL. (Aus diesen Überschriften leite ich später Storypoints ab, das funktioniert bei uns ganz gut.) Die Entwickler sind nun alle an ihren Rechnern und gleichzeitig auf dem Trello-Board unterwegs und verschieben Einträge. Am Ende schaut jeder noch mal, ob er das Gefühl hat, dass die bereits zugeordneten Einträge richtig hängen. Ansonsten markiert er den Eintrag mit einem Sticker. Das passiert aber gar nicht so oft, wie es vielleicht zu befürchten war. Bei etwas über 70 Storys wurden gerade einmal 10 markiert und später in gemeinsamer Runde diskutiert. Ein anderes Mal nur 5 von 43 Storys. Und schnell sind wir auch in diesem Verfahren: Meist reichen uns 25 bis 30 Minuten für unsere Bucket Estimation. Die Ergebnisse sind für unsere Planung anschließend genau genug, und darauf kommt es doch schließlich an.“

Liberating Structures als Moderationsinspiration

  • Von verschiedenen it-agile Kollegen, Juli 2018

    Liberating Structures sind eine Sammlung von (aktuell) 33 Mikrostrukturen, die von Keith McCandless und Henri Lipmanowicz zusammengetragen wurden. Nach deren Ansicht unterdrücken die konventionellen Strukturen, in denen Menschen täglich zusammenarbeiten, unabsichtlich die Einbeziehung und das Engagement der Beteiligten. Der Einsatz von Liberating Structures kann dir in Meetings und Workshops helfen, alle Teilnehmer einzubeziehen und zu Beteiligten zu machen. Dabei führen Liberating Structures kleine Veränderungen in die Art und Weise ein, wie wir uns besprechen, planen, entscheiden und zueinander in Verbindung stehen. Die Mikrostrukturen sind leicht zu erlernen und können mit zunehmender Erfahrung auch miteinander kombiniert werden, sodass dadurch komplette Meeting- oder Workshopsequenzen erstellt werden können. „1-2-4-all“ ist eine dieser einfachen Mikrostrukturen, mit der du sofort starten kannst: 1) Stelle eine Frage in Bezug zu einem zu lösenden Problem, zur Vorstellung eines Themas oder eines Vorschlags (z. B.: Welche Chancen siehst du, um Fortschritte bei dieser Herausforderung zu erzielen? Wie würdest du mit dieser Situation umgehen? Welche Ideen oder Maßnahmen würdest du vorschlagen?) 2) Jeder macht sich alleine Gedanken zur gewählten Problemstellung (1 Minute). 3) Dann werden diese Ideen zu zweit weiterentwickelt (2 Minuten). 4) Ideen aus den Paaren werden in Vierer-Gruppen verfeinert (4 Minuten). 5) Stelle die Frage „Welche Idee fand eure Gruppe besonders bemerkenswert?“. Jede Gruppe stellt eine wichtige Idee vor (5 Minuten). Dieser Schritt kann bei Bedarf wiederholt werden. Innerhalb von 12 Minuten kannst du Ideen und Antworten auch von großen Gruppen zusammentragen. Dabei ist jeder Einzelne bei der Suche nach Antworten beteiligt. Nebenbei werden geschützte Räume geschaffen, in denen Machtgefälle weniger Einfluss nehmen. Alle 33 Liberating Structures sind auf der deutschen und englischen Webseite gut dokumentiert.

Frühzeitig mehr ist mehr

  • Von Wolf-Gideon Bleek, Juni 2018

    Wenn wir Teams helfen, in einen guten Arbeitsrhythmus zu kommen ist die Frage „Wieviel darf gleichzeitig in Arbeit sein?“ immer eine der wichtigsten. Wir raten aus Erfahrung dazu, so wenig wie möglich gleichzeitig zu bearbeiten und fordern auch mal ein Team auf, nur an genau einer Sache zu arbeiten, bis diese abgeschlossen ist. Wir sprechen dann von einem niedrigen Work-in-Progress-Limit. Weniger gleichzeitig zu tun hilft den Teams, mehr zu schaffen. Nun haben wir in den letzten Wochen und Monaten mit vielen Kunden das Agile Fluency Game von Diana Larsen und James Shore gespielt. Hier merkt man einen kontra-intuitiven Effekt ganz deutlich. Durch Retrospektiven und die Zusammenarbeit im Team zahlt es sich tatsächlich aus, möglichst viele agile Praktiken gleichzeitig zu lernen. Je früher die Team-Mitglieder von einer Praktik wissen (z.B. Continuous Integration, Pairing, Test-Driven Development) umso früher haben sie die Chance, diese auszuprobieren und darüber zu lernen. Lernen kann man tatsächlich an vielen Praktiken gleichzeitig, wohingegen man sich nur schwer auf mehrere Features konzentrieren kann. Und: Frühzeitiges Lernen zahlt sich aus! Je früher ein Team die (positiven) Erfahrungen mit den einzelnen Praktiken macht, umso eher kann es sie regelmäßig einsetzen und umso eher wird es in einen Fluss kommen (Agile Fluency).

Von der Wirkung aus gedacht

  • Von Sabrina Spiegel und Stefan Zumbrägel, Mai 2018

    In der gemeinsamen Arbeit beim Kunden, haben meine Kollegen Sabrina Spiegel und Stefan Zumbrägel bemerkt, dass sich die Teams schwer damit getan haben ein Sprintziel zu formulieren. Das Ergebnis waren Ziele wie „alle Items müssen fertig werden“ oder „an Kontent XY wird weitergearbeitet“. Das Problem dieser Ziele war, dass sie niemand mehr beachtet hat. Der Fokus auf zu erstellende Features brachte auch im Sprint Review Probleme bei der Vorstellung der Sprintergebnisse. Um diesem Problem zu begegnen, haben wir uns eines Punktes aus dem Bereich User Story Mapping bedient: von der Wirkung her denken. Wie verändert sich dadurch das Sprintziel?

    Bei der Suche nach einem Sprintziel haben wir uns mit dem Team die Frage gestellt:

    • Was verändert sich spürbar oder sichtbar für den Benutzer durch die Entwicklung in diesem Sprint?
    • Und vielleicht noch viel wichtiger: Welchen Mehrwert hat er davon, wenn wir z. B. 2 Wochen an dem Produkt gearbeitet haben?

    Das hatte verschiedene positive Effekte auf die Arbeit im Team:

    • in jedem Sprint entstand ein MVP Minimal Viable Product und damit die Möglichkeit Feedback zu bekommen
    • Flexibilität in der Featureausgestaltung während des Sprints
    • besseres Feedback im Review
    • ein viel stärkerer Fokus auf den Benutzer

    Spannend ist auch, dass wir diese Denke im Weiteren auch auf die Planung von Releases übertragen konnten.

Scrum-Erklärung in vielen Sprachen

  • Von Ralf Lethmate, April 2018

    Mein Kollege Ralf Lethmate stand vor einiger Zeit vor der Herausforderung, dass sein Team nicht nur aus Deutsch- und Englisch-sprachigen Mitgliedern bestand. Da war es gerade bei der Scrum-Einführung wichtig, dass man ein möglichst gutes gemeinsames Bild von Scrum entwickelt. Dafür gibt es den Scrum Primer von Bas Vodde und anderen. Es werden die Scrum-Rollen, Scrum-Meetings und Artefakte erklärt. Neben Englisch und Deutsch gibt es den Primer aktuell auch in Chinesisch, Französisch, Spanisch, Italienisch, Bulgarisch, Koreanisch und Vietnamesisch. An der Deutschen Übersetzung hat übrigens unser Kollege Markus Gärtner mitgewirkt.

Story Owner

  • Von Sabrina Spiegel, März 2018

    Meine Kollegin Sabrina Spiegel hat vor einiger Zeit mal etwas Neues mit ein paar Scrum-Teams ausprobiert: Story Owner Das scheibt sie dazu:

    „Da wir ein Team von 25 Leuten sind, gibt es pro Story immer einen Story Owner, der eine Spontigruppe bildet, die dann die Story bearbeitet. Der Story Owner wird im Sprintplanning ernannt, und er sagt dann, welche Fähigkeiten er braucht, damit die Story umgesetzt werden kann. Zum Glück melden sich die meisten Leute freiwillig, um an der Story zu arbeiten. Es hilft, wenn der Story Owner ein Auge darauf hat, ob die benötigten Fähigkeiten dabei sind (Fähigkeiten nicht Personen). Danach hat der Story Owner Sorge dafür Sorge zu tragen, dass seine Story fertig wird (wobei er nicht derjenige sein muss, der sie umsetzt). Das heißt insbesondere, wenn Mitglieder der Spontigruppe auch in anderen Gruppen an anderen Storys beteiligt sind, dafür zu sorgen, dass nach Priorität der Storys untereinander an den Storys gearbeitet wird. Für uns hat dieses Vorgehen bewirkt, dass wir jetzt mehr Storys im Sprint wirklich fertigbekommen. Nachricht senden

Return On Time Invested mit Selbsteinschätzung

  • Von Benjamin, Februar 2018

    Vielleicht kennst du Return On Time Invested (ROTI) schon, mein Kollege Benjamin Igna nutzt es für sich noch mal auf eine andere Art und Weise. Folgendes schreibt er dazu: „Bei meinem letzten Kunden durfte ich etwas Neues ausprobieren. Ich war dabei, klassischen Führungskräften neue agile Führung zu zeigen. An diesem Tag widmeten wir uns dem Coaching-Begriff, und ich hatte mir vorgenommen ein ganz klassisches Coaching als Masterclass-Format durchzuführen. Ich hatte das vorher erst ein Mal beim Kunden (und mehrere Male in der Coaching-Ausbildung) gemacht und war dementsprechend aufgeregt. Schon nach der ersten Pause bemerkte ich, wie anstrengend eine solche Session war, und beschloss meinen Fokus auf meinen Coachee zu konzentrieren. Doch dadurch verlor ich das Gespür für die restliche Gruppe. Ich hatte mir vorgenommen die ROTI (Return on time invested)-Abfrage zu benutzen, um zumindest nachträglich ein Stimmungsbild der Gruppe zu bekommen. Dabei spanne ich zwei Achsen auf. Auf der einen Achse steht der gefühlte Wert und auf der anderen die investierte Zeit für den Tag. So kann jeder einen Punkt machen wie spannend/wertvoll der Tag für ihn war (rote Punkte). Ich machte mir während der Pause ein paar Gedanken dazu, wie ich den Tag einschätzte, und markierte hinter dem Flipchart meine Perspektive (hier mit einem grünen Punkt dargestellt). Mir war klar, dass ich nicht meine Aufmerksamkeit gleichzeitig auf meinen Coachee und das weitere Publikum verteilen kann, ohne dass ich die eine oder andere Partei vernachlässige. Deshalb fand ich einen Abgleich meiner Wahrnehmung mit der Wahrnehmung der Teilnehmer besonders wertvoll. Nach der Auswertung des Roti konnte ich sehen, wie die Teilnehmer den Tag einschätzten und wie gut ich unter Belastung die Gruppendynamik im Blick halten kann. Ich werde auch zukünftig gerade in anstrengenden Situationen die ROTI-Abfrage mit dem grünen Punkt verwenden, um mich selber in verschiedenen Kontexten reflektieren zu können.“

Wir unterbrechen dich! Teil 2

  • Von Frank Reichart, Dezember 2017

    m letzten Newsletter hatte mein Kollege Sebastian Keller beschrieben, wie er als Moderator freundlich (aber bestimmt) Leute unterbricht. Newsletter-Leser Frank Reichart schrieb mir dazu folgende Ergänzung:

    „Hier mein Ausprobier-Tipp: Als Moderator braucht man gar nicht selbst zu unterbrechen, sondern man kann ein 'Unterbrecher-Team' bilden. Zum Einstieg suche ich mir drei Teilnehmer, die freiwillig die Hüterrolle für Zeit, Fokus und Anstand übernehmen. Dabei wird angekündigt, dass die Hüter explizit berechtigt sind zu unterbrechen, sollten sie in ihrem jeweiligen Gebiet Potenzial erkennen. Jeder Hüter bekommt ein andersfarbiges Fähnchen, auf dem seine Rolle steht. Damit winkt er, wenn er unterbrechen möchte. Kam bisher immer gut an und wurde auch genutzt (Verantwortung involviert).“ Danke für den Tipp, Frank!

Ich unterbreche dich! Teil 1

  • Von Sebastian Keller, November 2017

    In diesem Newsletter stammt unser Agiler Tipp von meinem Kollegen Sebastian Keller, der einen Moderationstipp aufgeschrieben hat: „Unterbrechen ist unhöflich” bekommen wir schon im Kindesalter zu hören. Speziell Erwachsene darf man nicht unterbrechen. Als Erwachsene werden wir oft sogar wütend, wenn wir unterbrochen werden. Wir sind es gewohnt, von jemandem unterbrochen zu werden, damit er seine Meinung sagen kann, obwohl wir in dem Moment gehört und verstanden werden wollen. Auf der anderen Seite wünschen wir uns schon manches Mal, jemanden einfach zu unterbrechen, damit wir unsere Meinung sagen können. Oder warten bis jemand Luft holen muss, damit wir schnell etwas sagen können. Es gibt noch eine andere Motivation zu unterbrechen, die speziell für Moderatoren wichtig ist, um den Fluss einer Diskussion lebendig und aufrecht zu erhalten. Wir unterbrechen nicht, um unsere Meinung zu sagen, sondern um bei der Person zu bleiben, die gerade spricht. Warum sollte ich sie aber dann unterbrechen? Es kann mehrere Gründe geben:

    • Jemand redet schon sehr lange. Unterbreche und wiederhole in deinen eigenen Worten, was du bisher verstanden hast. Das beruhigt oft denjenigen, der schon lange redet. „OK, ich wurde verstanden. Ich brauche nichts mehr sagen.”
    • Jemand fängt an, in eine andere Person Dinge hineinzuinterpretieren. Unterbreche, um weitere Verletzungen zu vermeiden.
    • „Er ist einfach immer unaufmerksam”. Frag mit deinen Worten, was der Person jetzt gerade wichtig ist. „Ist dir gerade Aufmerksamkeit und Fokus wichtig?”. Oder bitte um eine konkrete Situation und Beobachtung. „Magst du mir sagen, auf welche Situation du dich beziehst.”
    • Jemand fängt ein neues Thema an, um das es jetzt gerade nicht geht oder steigt an einer Stelle in Details ein. Unterbreche, um wieder den Fokus zu finden. „Wollen wir morgen nicht…” Versuche wieder zu erraten, um was es der Person gerade geht, sag, warum du gerade nicht über dieses Thema reden willst und schlag eine Alternative vor. „Ist dir wichtig, dass wir auch über die Planung von morgen reden?“ – „Ja” – „Mir ist wichtig, dass wir erst die Planung von heute abschließen. Passt es dir, wenn wir danach über den morgigen Tag sprechen?” Nachdem du unterbrechen willst, brauchst du dich nicht zu entschuldigen und kannst jede Unterbrechung mit dem Namen der Person beginnen: „Sebastian, ich unterbreche dich.” Vielleicht ist das zu Beginn für die Person irritierend. Darum hilft es, mit dem Team vorher auszumachen, dass der Moderator unterbrechen darf.

Wie geht es dem Nachbarn?

  • Von Maria Oerlinger, Oktober 2017

    Von unserem Tipp aus dem letzten Newsletter inspiriert, hat mir Maria Oerlinger aus Duisburg einen Tipp geschrieben. Sie hat ihn selbst von einer Kollgein auf der Bremer Sommeruni für Informatikerinnen und Ingenieurinnen erhalten. Ursprünglich stammt er aus dem Buch „Was ist eigentlich Ihre Lieblingsfrage?“ von Amelie Funcke und Axel Rachow. Hier der Tipp: Eine kleine Methode, die ich bei einer agilen Firma in der Retrospektive eingesetzt habe, würde ich auch verwenden, wenn das Team sich voneinander zu entfernen droht oder in einem klassischen Umfeld die agile Arbeitsweise mit all ihren „soften“ Faktoren gerade erst eingeübt wird: Das verschobene Blitzlicht. Statt der Frage „Wie geht es dir? In einem einzigen kurzen Satz, bitte!“ stellt man dabei die Frage „Wie geht es deiner rechten Nachbarin?“ (Linker Nachbar geht natürlich auch.) Dies fördert die Achtsamkeit und führt dazu, dass man eine andere als die eigene Perspektive einnimmt.

Meeting-Speed-Retro

  • Von Peter Rößler, September 2017

    Für diese Rubrik frage ich immer wieder meine Kollegen nach Input. Oft denken sie, dass ihre kleinen Ideen, Tipps oder Tricks nicht groß genug wären für den Agilen Tipp im Newsletter. Meistens stimmt das aber gar nicht. Von den Lesern des Newsletters bekomme ich zumindest häufig das Feedback, dass auch die kleinen Tipps gute Anregungen sind. In diesem Monat stammt der Agile Tipp von meinem Kollegen Peter Rößler:

    Ich helfe einem neuen Kunden von uns bei der Scrum-Einführung. Nicht alle Scrum-Meetings funktionieren für das Team, manche hinterlassen regelrecht Frust bei den Teilnehmern. Ich habe mir angewöhnt am Ende der Meetings die folgenden zwei Fragen zu stellen:

    •  „Was war für dich wertvoll an diesem Review-Meeting?“
    •   „Was hat es nicht wertvoll gemacht?“ Ich war überrascht, wie einfach und schnell über diese Fragen die Selbstreflexion bei den Teilnehmern passierte. Ich konnte in ihren Gesichtern sehen, dass ihnen klar wurde, dass sie selbst für den Erfolg der Meetings verantwortlich sind. So lernen wir uns aktuell von Meeting zu Meeting voran, wie es am besten läuft. Vielleicht frage ich nächstes mal noch:
    •   „Was wirst du beim nächsten Review-Meeting machen, damit es besser gelingt?“

Review in Stationen

  • Von Stefan Zumbrägel, August 2017

    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. Die Zusammenstellung des Sprintbacklogs war auf Grund der Priorität aus dem Companybacklog von Sprint zu Sprint sehr unterschiedlich. Mal hatten wir sehr viele unterschiedliche Themen im Sprint, die wiederum sehr spezielle Personen interessierten. In einem anderen Sprint passten alle Storys zu einem Thema und es gab eine große Menge an interessierten Personen.

    Neben der Arbeit im Sprint, für die vor allem die vielen unterschiedlichen Themen nicht förderlich waren, konnten wir die Auswirkungen im Review am stärksten spüren. Entweder wurde deutlich, dass sich Personen nur für einzelne Themen interessierten und den Rest der Zeit mehr oder weniger interessiert, aber vor allem passiv teilnahmen. Das führte zu Reviews mit zwar vielen Teilnehmern aber sehr wenig Energie. Ein zweiter Aspekt war, dass das Team versuchte, allen Themen ungefähr gleich viel Zeit einzuräumen. Dadurch wirkte der Termin sehr gehetzt, die Zeit musste immer im Blick behalten und manchmal sogar Diskussionen unterbrochen werden, um nicht Themen am Ende nur noch sehr kurz betrachten zu können. Im anderen Fall waren so viele Personen da, dass das Review eher Vorlesungscharakter hatte. Die Menge an Teilnehmenden führte dazu, dass sich nur wenige Personen, und in der Regel diejenigen die eh immer was sagen, an den Diskussionen beteiligten. Auch kamen wir schnell in ein zeitliches Problem.

    Wie zu erahnen ist, war es in beiden Fällen sehr schwer, gutes und differenziertes Feedback zu bekommen. Zudem war das Feedback der Teilnehmenden auch entsprechend. Es musste sich also etwas grundlegend in der Gestaltung des Reviews ändern.

    Daraus entstand die Idee, das Review in verschiedene Stationen einzuteilen. Im Raumen wurden Tischgruppen gebildet, hier stand jeweils ein Laptop / PC sowie ein Flipchart zur Verfügung. Am Beginn des Reviews gab es eine kurze Vorstellung, was im Sprint passiert ist und geschafft wurde (eine Art Keynote). Im Anschluss wurde die Aufteilung der Stationen vorgestellt und die Teilnehmenden konnten sich auf die einzelnen Stationen verteilen.

    Die Stationen waren entweder gleich oder mit unterschiedlichen Themen besetzt, je nachdem, wie die Inhalte des Sprints aussahen. An jeder Station war mindestens ein Entwickler, um Rückfragen zu beantworten und das Feedback aufzunehmen. Das gab dem Team die Möglichkeit, auf die unterschiedlichen Gegebenheiten zu reagieren.

    • Bei unterschiedlichen Inhalten an den Stationen konnten wir speziellen Themen ausreichend Zeit einräumen. Durch die Parallelisierung wurden die sonst vorhandenen Leerlaufzeiten aufgehoben und der Zeitdruck war deutlich kleiner. Die Rückmeldung der Teilnehmer war zudem sehr positiv; sie konnten sich ausgiebig mit ihren speziellen Fragestellungen beschäftigen. In diesem Modell war es aber auch wichtig, Zeit einzuräumen, um mehr als eine Station besuchen zu können. Wir haben sowohl mit festen Wechselzeiten und mit dem freien Wechselangebot gute Erfahrungen gemacht.
    • Bei großen Gruppen konnte durch mehrere gleiche Stationen die Anzahl der Personen pro Station klein gehalten werden. Dadurch war die Interaktion mit den Teilnehmern deutlich höher. So konnten mehr Personen das fertige Produktinkrement ausprobieren und es konnte gezielter auf einzelne Fragen eingegangen werden.

    Bei beiden Ansätzen haben wir im Anschluss eine Runde durch alle Stationen gemacht, in der eine Person (Teilnehmer oder Entwickler) kurz das Feedback aus der Runde vorgestellt hat. 

Priorisierung nach Bock-Prinzip

  • Von Anna Lorenz, April 2017

    In diesem Monat stammt der Agile Tipp von meiner Kollegin Anna Lorenz: Wenn ich mit Teams während Retrospektiven entscheide, was wir an konkreten Maßnahmen auswählen (Decide what to do), dann verwende ich gerne die Priorisierung nach Bock-Prinzip. Das funktioniert bei mir folgendermaßen: Wir sammeln im Team gemeinsam alle Maßnahmen, die wir vorher bereits identifiziert haben. Wir gehen kurz mit Daumen-Voting drüber, um zu entscheiden, ob wir daran glauben, dass uns die jeweilige Maßnahme wirklich weiterhilft – nur die mit Daumen oben bleiben drin. Dann gebe ich die Moderationswand frei und fordere die Teilnehmer auf als Team maximal drei Maßnahmen zu ziehen. Dabei darf jeder erstmal nur eine ziehen, für die er dann der Kümmerer ist, also verantwortlich dafür, dass die Maßnahme vom Team umgesetzt wird.

    Als Moderatorin sage ich sowas wie: „Bitte schau dir die Maßnahmen an und ziehe maximal eine, für die du richtig Energie hast. Du kümmerst dich dann in dem Sprint um die Umsetzung der Action. Insgesamt sind nur drei Maßnahmen erlaubt (abhängig von Sprintlänge und Team, etc.).“ Es kommt auch vor, dass keiner aufsteht. Dann sprechen wir darüber: „Warum will sich keiner kümmern?“ oder „Sind das noch nicht die richtigen Maßnahmen?“ Ich habe damit schon interessante Erfahrungen in Teamdynamiken gemacht. Einmal habe ich sogar ein Flipchart (mit einer Maßnahme drauf) zerknüllt und es wirken lassen.

Stories mit den Entwicklern schreiben

  • Von Benjamin Igna, Juni 2017

    Das Problem

    Unser Kunde war ein großes Finanzinstitut, der sich seine IT von einer großen Firma machen lassen hat. Externe Entwickler sollten also die Produkte umsetzen, die sich unser Kunde ausgedacht hatte. Dazu kam die Tatsache, dass die Entwickler aus einem ganz anderen kulturellen Kontext kamen, und zwar aus Indien. Wir hatten also Kommunikationsprobleme. Der Fachbereich hat Stories geschrieben und in das Planning gebracht. Nur wenige Tage nach dem Planning konnten sich die Teammitglieder nicht mehr genau an die Details aus dem Planning erinnern.

    Die Lösung

    Jetzt hätte man hier mit mehr Dokumentation Abhilfe schaffen können, doch wie das mit Dokumentation so ist, hat erstens kaum einer Lust dazu und zweitens müssen die Entwickler die Dokumentation dazu später auch noch suchen/finden/lesen und ganz wichtig: verstehen.
    Wir haben uns für eine andere Vorgehensweise entschieden. Wir schreiben die Stories alle gemeinsam. Das bedeutet, unser Product Owner kommt in das Backlog-Refinement mit einem ersten Wurf der Story, stellt diese vor und wir formulieren gemeinsam die Story für das Backlog. Das erzeugt einen höheren Wiedererkennungswert bei den Teammitgliedern, was wiederum dazu führt, dass wir weniger dokumentieren müssen.
    Nachdem wir das einige Zeit lang gemacht haben lernten wir, dass es viel weniger auf das gemeinsame „schreiben“ ankommt als darauf, die gemeinsame Kundenperspektive einzunehmen und darüber zu diskutieren, sich also gegenseitig kennen zu lernen. Die Stories funktionieren nun als Schlüssel für unsere Köpfe. Wir schreiben teilweise nur noch Stichworte auf und wissen genau, was sich dahinter verbirgt.

    Die Wirkung

    Natürlich kostet das gemeinsame Aufschreiben und die Diskussionen viel Zeit. Doch ich bin davon überzeugt, dass sich diese Investition lohnt. Denn heute sind wir besser abgestimmt, haben weniger Nachfragen sowie mehr Alignment für das Team.

Retros für alle

  • Von Dieter Eichert, Mai 2017

    Der Tipp in diesem Monat stammt vom Newsletter-Leser Dieter Eichert, der im Change Management arbeitet. Dort haben sie die Idee geboren, den nicht direkt mit Scrum/agil arbeitenden Fachbereichen die agile Idee näher zu bringen, in dem sie Retrospektiven für alle angeboten haben. Dieters Kollegin Wiebke Seebode, die die Retros durchgeführt hat, schreibt dazu: Die Retros waren je nach Bedarf und Teamgröße zwischen 1 und 3 Stunden lang (dann aufgeteilt in 2 x 1,5 Stunden). Folgende Fragen waren an die Wand gepinnt:

    • Was hat gut geklappt?
    • Was hat nicht so gut geklappt?
    • Was behindert mich daran, meine Arbeit optimal zu erledigen?

    Zusätzlich gab es noch eine Wand für Learnings, die während der Retro ausgearbeitet wurden.

    In der ersten Runde haben wir keine Einschränkungen gemacht in Bezug auf Zeitraum oder Bereich (im Team, außerhalb, extern), bei Folgeterminen betrachten wir den Zeitraum seit der letzten Retro. Wiederholungen finden je nach Team/Bedarf alle 3-6 Monate statt. Die Teilnehmer hatten zunächst Zeit, alles auf Karten zu schreiben, was ihnen einfällt (grün für klappt gut, rot für klappt nicht, blau für Störer). Dann wurden die Karten angepinnt und gemeinsam besprochen: Wie sieht der erste Eindruck aus (z.B. Verhältnis grüne Karten zu roten Karten), dann die einzelnen Karten. In den Gesprächen ergaben sich Learnings, die vom Moderator direkt auf gelbe Karten geschrieben und angepinnt wurden. Die Boards wurden in einem Fotoprotokoll festgehalten.

    Tipp: bei den Learnings sollte direkt ein Kümmerer festgelegt werden.

    Thematisch war auffällig, dass es viel um Kommunikationsprobleme jeglicher Art ging, die im Alltag nie wirklich geklärt werden. Oft hilft es da schon, sich das Problem einfach mal bewusst zu machen, und dann gemeinsam mit den entsprechenden Parteien (oft teamübergreifend) zu sprechen, um gegenseitiges Verständnis zu erreichen. Das führt zu

     

    • weniger Frust (ich kenne die Problematik der Gegenseite und ärgere mich nicht mehr so, wenn nicht alles nach meiner Wunschvorstellung läuft),
    • freundlicherem Umgang (man rückt zusammen durch die gemeinsame Sichtweise),
    • schnelleren Lösungen (da nicht so viele Korrekturschleifen gedreht werden müssen),
    • effektiverer Planung (ich weiß, worauf ich Rücksicht nehmen muss),
    • Prozessoptimierungen (es wird offensichtlich, wo es noch nicht rund läuft).

    Das Feedback war durchaus positiv. Besonders erwähnt wurde, dass es super hilfreich war, sich einfach mal bewusst Zeit zu nehmen, um sich Gedanken zu machen. Die Zeit kann durch daraus entstehende Optimierungen mehrfach wieder eingespart werden.

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


    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


    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.

"Why" übersetzt sich eher zu "Wofür"

  • Von Henning Wolf, November 2015

    Der letzte Coaching-Tipp war "Start with why, in everything you do!"

    Dazu gab es allerhand Rückmeldungen von euch, insbesondere und zu Recht, weil im Deutschen das "Warum" doch anders rüberkommt als im Englischen das "Why", insofern ist ein "wofür" nach allgemeiner Ansicht die bessere Übersetztung. Danke dafür.

    Als Ergänzung erreichte mich noch folgender Kommentar:

    Zum aktuellen Newsletter: DIE FRAGE NACH DEM WARUM

    Mir gefällt, der Tipp an sich – zu wissen „warum" ist mega wichtig; dass Henning reingeschrieben hast, warum er den Tipp gut findet und was sonst schief läuft; dass im Text durchkommt mit welcher inneren Haltung die Frage nach dem Warum gestellt wird.

    Kritisch finde ich, dass die Frage oft genau so schlicht gestellt wird: „Warum?“ und dass sie so schlicht auch nach hinten losgehen kann.

    Beispiele:
    Ich (51, Teamleiter, weiblich, Typ: introvertierte Berlinerin) stelle diese Frage. Reaktion: „Jede Frage ist ein Angriff“, „Du bist aber garstig heut“, „Das ist doch klar“ - alles schon gehört. Ich frage deshalb lieber: "Was ist denn der Grund für …..?" Oder sogar im Konjunktiv „Was könnte denn ….? Und damit entspreche ich vielleicht einem Klischee, der Effekt ist dabei aber, dass die Antwort auf ein „Warum" wieder im Mittelpunkt steht.

    Kollege aus dem Requirements Engineering (unter 30, männlich, Typ: schwarzgekleidetes Wesen, dass einem mit Technik freundlich weiterhilft) stellt die Frage. Reaktion: Der Kollege erhält ein „in Scrum macht man das so“. Das „Warum“ wird oft interpretiert als: So jung, - der hat sicher keine Ahnung. Unter 30 und in schwarz muss man erst mal beweisen, dass man a) Ahnung hat und b) durchaus in der Lage ist mit Kommunikation umzugehen. An dieser Stelle ist es besser mehr Kontext zu der schlichten Frage zu geben und so als junger Kollege Kompetenz zu zeigen."

Mit "Warum?" beginnen

  • Von Christoph Kämpfe, Oktober 2015

    "In meinem Urlaub ist mir ein guter Coachingtipp von Christian Dähn eingefallen – der bei uns Anfang des Jahres noch recht aktiv unterwegs war: Start with why, in everything you do!

    Der Tipp hilft mir sehr gut, dass ich nicht bereits mit Annahmen starte, sondern erst einmal die Aufgabe hinterfrage, die Motivation verstehe und richtig abgeholt werde, um mich dann mit dem Problem auseinander zu setzen.

    Die Frage hilft auch häufig meinem Gegenüber Ordnung in seine Gedanken zu bringen, warum sie dies oder jenes wollen."

    Vielen Dank, Christoph! Besonders gut gefällt mir an dem Tipp, dass er einfach umzusetzen ist. Dabei denke ich, dass es auch für unser eigenes agiles Handeln hilft, wenn wir unsere Intentionen klar machen. Zu oft erlebt man sonst Diskussionen auf der Ebene "so macht man das aber in Scrum nicht". Interessant ist ja aber eher, warum jemand etwas machen möchte, dass so in Scrum nicht vorgesehehen ist (und warum das wohl in Scrum nicht so sein soll). So lässt sich hoffentlich mit mehr Klarheit eine Lösung finden, die besser passt.

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?  

Perfection Game

  • Von Henning Wolf, März 2015

    Feedback ist kein leichtes Thema. Da finde ich das Perfection Game gut geeignet, von dem ich mal vor ein paar Jahren gehört habe. Ich weiß, es gibt formalere Abwandlungen davon, aber ich wende es gerne wie folgt an:

    • Jemand stellt einen Vorschlag oder eine Idee vor und man klärt reine Sachfragen ohne Bewertung.
    • Jetzt überlegen sich alle Feedback-Geber, wie sie den Vorschlag oder die Idee auf einer Skala von 1 bis 10 (mit 10 entspricht perfekt) einordnen würden.
    • Bevor man seine Bewertung abgibt, sagt man erst, was einem gut gefällt. Dann nennt man seine Bewertung und sagt, was passieren müsste, damit man dafür eine 10 geben würde.

    Oft weiß man vielleicht nicht genau, wie eine perfekte Lösung wirklich aussehen würde oder die Veränderung dahin ist riesig und unrealistisch. Dann kann man eine Abwandlung des Spiels verwenden und sagen, was passieren müsste, damit die Bewertung um 1 steigt.

     

     

Timeboxing in Besprechungen

  • Von Jörg Höninger, Februar 2015

    Timeboxing in Besprechungen: banal und tatsächlich schwierig einzuführen…

    Auf dem Seminar „Management agiler Teams“ im letzten Jahr wurde mit einer Uhr gearbeitet. Die Agendazeiten wurden eingehalten. Sobald die Uhr klingelte, wurde entschieden, ob noch mehr Zeit spendiert wird oder jetzt Schluss ist.

    Seitdem versuche ich dieses Prinzip in unsere Besprechungen zu bringen, der Erfolg hält sich (noch) in Grenzen. Ich bleibe aber hartnäckig dran…

    Wenn jemand für ein Thema 15 min. veranschlagt und dann 30 min. benötigt, ist das einfach nicht in Ordnung. Alle anderen Punkte fallen entweder hinten runter oder werden noch reingequetscht. Das ist unfair allen anderen Teilnehmern gegenüber. Und dann auf die Mittagspause zu verzichten oder zu spät zu anderen Meetings zu kommen, ist auch nicht ok. Es erhöht einfach unnötig den Stress bei den Betroffenen.

    So, kein allzu revolutionärer Coaching Tipp, ich halte aber eine gute Besprechungsorganisation für ein hohes Sparpotential. Zusätzlich könnten einige Besprechungen zielgerichteter geführt werden, ohne endlose Diskussionen, die nicht wirklich zum Erfolg beitragen.

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.