Agile Coaching-Tipps von it-agile (3)

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.  

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.  

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

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, indem 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 superhilfreich war, sich einfach mal bewusst Zeit zu nehmen, um sich Gedanken zu machen. Die Zeit kann durch daraus entstehende Optimierungen mehrfach wieder eingespart werden.

Von Benjamin Igna, Juni 2017

Das Problem

Unser Kunde war ein großes Finanzinstitut, das sich seine IT von einer großen Firma machen lassen hat. Externe Developer sollten also die Produkte umsetzen, die sich unser Kunde ausgedacht hatte. Dazu kam die Tatsache, dass die Developer aus einem ganz anderen kulturellen Kontext kamen, und zwar aus Indien. Wir hatten also Kommunikationsprobleme. Der Fachbereich hat Storys geschrieben und in das Planning gebracht. Nur wenige Tage nach dem Planning konnten sich die Teammitglieder:innen 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 Developer 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 Storys 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 Teammitglieder:innen, 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 kennenzulernen. Die Storiy 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 kosten 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.

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 dazu 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 etwas 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.

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 aufgrund 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 Teilnehmer:innen, 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:in oder Entwickler:in) kurz das Feedback aus der Runde vorgestellt hat. 

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 Leser:innen 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 Fragen zu stellen:

•  „Was war für dich wertvoll an diesem Meeting?“
•  „Was hat es nicht wertvoll gemacht?“ Ich war überrascht, wie einfach und schnell über diese Fragen die Selbstreflexion bei den Teilnehmer:innen 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 Meeting machen, damit es besser gelingt?“

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

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.

Von Frank Reichart, Dezember 2017

Im 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!