Das Potenzial von Scrum außerhalb der Software-Entwicklung

Während agiles Arbeiten mit Methoden wie z. B. Scrum oder Design Thinking für viele noch Neuland darstellt, ist es für uns bei bg nicht nur Teil unserer täglichen Arbeit, sondern auch unseres Denkens und Seins.

Ich selbst bin über Design Thinking (DT) zum agilen Arbeiten gekommen – damals völlig fasziniert von den Möglichkeiten, neue Produkte in einem kurzen Zeitraum zu entwickeln und zu verproben. Wie viele andere neue Dinge kann DT im ersten Moment regelrecht euphorisieren. Eine Kollegin sagte mir sogar, dass sie DT-Methoden ständig auch im Privaten nutzen würde: zur Urlaubsplanung, Wochenendgestaltung oder um eigene Ideen zu entwickeln.

Kann man nun agile Methoden wirklich in allen möglichen Situationen nutzen? Im ersten Moment eine vielleicht eher schwierige Vorstellung. Doch es gibt einen schlüssigen Grund, warum immer mehr Unternehmen agiles Arbeiten für sich entdecken und sich diese Arbeitsweisen über die letzten Jahre und Jahrzehnte immer mehr etabliert haben: Sie befähigen Teams dabei, schneller und produktiver zu arbeiten. Ein gutes Beispiel dafür ist Scrum – ursprünglich aus der Software-Entwicklung kommend, nun auch in der Hardware-Entwicklung im Einsatz und sogar von großen Kaufhäusern und Online-Shops genutzt.

Doch was, wenn man kein physisches Produkt entwickelt, sondern z. B. beratend tätig ist oder sein Geld mit Ideenentwicklung verdient? Schließen sich Agilität und bestimmte Branchen aus? Nicht unbedingt! In fast jedem Team und Unternehmen kann man „Bausteine“ von Scrum nutzen, um produktiver zu arbeiten und den Kunden schnellere und sichtbarere Ergebnisse zu liefern. Ähnlich wie meine Kollegin Elemente aus den DT-Methoden für ihre Urlaubsplanung genutzt hat, bewerte ich die Grundidee der Scrum-Meetings auch abseits des Entwicklungsumfelds als vorteilhaft.

Planung und iteratives Arbeiten

Viele gehen fälschlicherweise davon aus, dass es in Scrum keine Planung gäbe – ein Irrglaube, denn zur Planung kommt es nur an anderen Stellen: Anstatt ein Projekt vorab monatelang abzustimmen, arbeitet man in Iterationen (“Sprints”), zu deren Beginn ein Sprint Planning stattfindet. In diesem Meeting geht es darum, die Ziele des Sprints sowie den Weg der Zielerreichung zu besprechen. Durch Sprints erhalten Teams einen Rhythmus und eine Struktur, die nicht zu unterschätzen ist, da sie dem Team Orientierung geben. Man kann sich ein Scrum Team ähnlich wie ein Orchester vorstellen: Es gibt unterschiedliche Instrumente, aber alle folgen einem gemeinsamen Rhythmus, um ein zusammenhängendes, wohlklingendes Stück zu erzeugen.

Bei Scrum arbeiten Teams inkrementell und iterativ, d. h. die Entwicklung erfolgt in kleinen Schritten, deren Ergebnisse umgehend in das Gesamtprojekt oder -produkt eingebunden werden. Sprich: Am Ende jedes Zyklus’ wird ein Produkt oder Teil davon geliefert. Der Kunde bekommt in kurzen Abständen regelmäßig „Teile“ seines Produktes geliefert, anstatt erst nach Monaten das fertige Produkt zu sehen, das seine Ansprüche dann vielleicht gar nicht in vollem Umfang widerspiegelt. Die zyklische Abstimmung mit dem Kunden hat den Vorteil, dass Anpassungswünsche schnell umsetzbar sind und keine monatelange Arbeit verloren geht – ein Benefit, den mehr Unternehmen für sich nutzen sollten.

Die Voraussetzung von Scrum: den Fokus finden

Bevor wir mit Scrum und den Meetings starten, ist es wichtig, dass wir uns fokussieren. Warum sollte man agil arbeiten? Was wollen wir erreichen? Wenn wir uns nicht auf das Wesentliche konzentrieren, besteht (auch im agilen Bereich) die Gefahr, dass wir dem “Shiny Object Syndrome” verfallen: Wir überladen uns, wollen immer informiert sein, alles Neue und Aufregende ausprobieren, gehen zu allen (Agile) Meetups, hören Podcasts über Scrum, abonnieren diverse Newsletter und melden uns für 4 Agile-Konferenzen an.

Zuerst sind wir berauscht von all den Informationen, den neuen Ideen, den scheinbar unendlichen Möglichkeiten und der Inspiration. Doch die Ernüchterung folgt auf schnellem Fuße: Was fange ich wirklich mit all diesen Informationen an? Wie viel Zeit brauche ich, um sie zu verarbeiten? Wo fange ich an? Um diese Ernüchterung zu vermeiden, ist das WHY vor der Einführung von Scrum und anderen agilen Methoden so wichtig. Ist das Warum geklärt, können wir uns auf die Meetings konzentrieren.

Das Ziel und der Weg dorthin: Sprint Planning 1 und 2

Auch wenn ein Unternehmen keine neue Software entwickelt, sondern z. B. beratend tätig ist, kann ein Sprintziel wichtiger Bestandteil des täglichen Doings werden: Wo möchte ich in zwei Wochen stehen? Was sind meine (kurz- und mittelfristigen) Ziele? Ein Sprintziel festzulegen, schafft Orientierung, Motivation und Messbarkeit. Die große Frage des WHY sollte man am Ende des Sprint Plannings beantworten können. Im Sprint Planning 2 geht es dann klassischerweise um das HOW, also die Frage, wie ich die gesetzten Ziele erreiche.

Die tägliche Abstimmung im Daily

Das Daily dient dazu, die tägliche Arbeit des Teams zu synchronisieren, einen Überblick zu haben, wer gerade woran arbeitet und ob es zu bewältigende Herausforderungen (sog. Impediments) gibt.

Da selbst kleine Teams oft einen hohen Kommunikationsaufwand haben, kann dieses Meeting auch wunderbar außerhalb von (Software-)entwickelnden Teams eingesetzt werden. Die Teamleiterin oder der Teamleiter kann hierbei die Funktion des ScrumMasters übernehmen oder die Rolle des ScrumMasters kann in einem regelmäßigen Rhythmus weitergereicht werden. Durch das Daily erspart man sich E-Mails, regelmäßiges Nachfragen, was andere Kolleginnen und Kollegen machen oder wo sie sind, und es eröffnet einen Raum, in dem man Impediments aufzeigen und Unterstützung finden kann. Zusätzlich kann man das Daily nutzen, um mithilfe eines Burn-Down-Charts die bereits geschaffte Arbeit bzw. den Fortschritt zu dokumentieren.

Feedback in Review & Retrospektive

Jeder Sprint wird mit zwei Meetings abgeschlossen: Review und Retrospektive. Im ersten wird das Ergebnis des Sprints präsentiert. Während in der Software-Entwicklung hier normalerweise die Entwickler den Kunden durch die entwickelte Plattform führen, können Teams und/oder Unternehmen mit anderen Leistungsschwerpunkten dem Auftraggeber/Kunden andere Ergebnisse präsentieren: Prototypen, Materialmuster, Konzepte, Design- und Gestaltungsentwürfe – kurzum: alles, was man für den Kunden bewirkt hat.

Durch das Review und das gemeinsame Betrachten der Arbeitsergebnisse kommt es zu einem wertvollen Austausch zwischen Auftraggeber/Kunden und den Umsetzern, im Zuge dessen Erwartungen abgeglichen werden können. Es entsteht Raum für Feedback und die Möglichkeit, auf die geschaffte Arbeit zurückzublicken sowie (gemeinsam) Erfolge zu feiern.

In der Retrospektive, die nur innerhalb des Teams (d. h. ohne Kunden) durchgeführt werden soll, nehmen die Teammitglieder die Prozesse unter die Lupe und denken darüber nach, was verbessert werden kann. Das Themenspektrum reicht dabei von den Kommunikationsstrukturen bis zum Umgang mit Fehlern – alle Anregungen, die das Team weiterbringen, sind hier erwünscht. Wer sein Team erfolgreich führen will, nutzt diese Gelegenheit für Feedback und Prozessoptimierung und somit für kontinuierliche Verbesserung.

Fazit – ist Scrum für jedes Team geeignet?

Mit Scrum zu arbeiten oder Methoden wie Design Thinking zu nutzen, scheint zunächst verführerisch und leicht umsetzbar. Dennoch braucht es Disziplin, um den Fokus zu halten und iterativ zu arbeiten.

Wie eingangs erwähnt, sollte sich jedes Team bzw. Unternehmen zunächst Gedanken um das Warum machen, sodass Scrum oder einzelne Meetings zielgebunden eingeführt werden können und sich neue Meetings nicht mit den bereits vorhandenen überschneiden oder sogar zu gefühlten “Pflichtveranstaltungen” entwickeln.

Die Vorteile von Scrum sind jedoch nicht von der Hand zu weisen: Zielorientierte Planung, welche die aktuellen Umstände mit in Betracht zieht (Sprint Planning), regelmäßiger Austausch (im Daily), Feedback zur Projektentwicklung und zum Prozess (Review & Retro) schaffen nicht nur im Software-Umfeld bessere Rahmenbedingungen, sondern können auch in anderen Bereichen dazu beitragen, schneller, flexibler und kundenorientierter zu arbeiten.

Produktentwicklung am Beispiel des Scrum Flows in 25 Schritten erklärt

„Wir machen jetzt Scrum!“ Diesen Satz hört man häufig, wenn Unternehmen ihre Produktentwicklungsprozesse agil gestalten wollen. Doch was steckt hinter diesem Ansatz und wie funktioniert der Scrum Flow überhaupt? Eine Frage, mit der sich viele Projektbeteiligte, welche bislang nur wenig bis gar keine Erfahrung mit Scrum haben, oft schwertun. Macht sich auch in dir gerade das Gefühl von Überforderung breit, weil du nicht weißt, wo du anfangen sollst? Den Scrum Flow zu verstehen ist dabei eine Sache, ihn zu erklären eine ganz andere. Die nachfolgenden 25 Schritte sollen dir dabei helfen, eine gedankliche Struktur zu schaffen, an der du dich im Arbeitsalltag orientieren kannst. Den Scrum Flow gekonnt erklären? Für dich ab sofort kein Problem!

Der Scrum Flow

Scrum Flow 1. Am Anfang steht der Product Owner (PO) mit einer Idee. Sein Ziel ist es immer, ein Produkt auf den Markt zu bringen, welches sowohl sinnstiftend für den Nutzer als auch gewinnbringend für die Organisation ist. 2. Eine Produktidee alleine reicht aber nicht aus. Man braucht ein genaues Bild davon, was man erreichen möchte – die „Vision“. 3. Dieses Bild, die „Vision“, hat einen Rahmen und dieser Rahmen spiegelt den Kontext wider. 4. Der Kontext ist insofern wichtig, da sich die Produktvision immer in einem Rahmen bewegt, welcher durch die Organisation vorgegeben wird (z. B.: Passt die Produktvision zur Unternehmensvision/dem Geschäftsmodell? Werden regulatorische Anforderungen eingehalten?) 5. Der PO ist zudem für den Return on Investment (ROI) verantwortlich. Er steht in engem Kontakt mit dem Auftraggeber und berücksichtigt dessen Interessen, da dieser das Projekt finanziert. 6. Zurück zur Vision! Diese sollte möglichst mitreißend und motivierend sein. Warum? Weil der Product Owner ein Team braucht, das mit ihm gemeinsam an der Umsetzung dieser Produktvision arbeiten möchte („Prinzip der Freiwilligkeit“). 7. Und hier kommt das Entwicklungsteam ins Spiel. Das crossfunktional aufgestellte Expertenteam ist Teil des Scrum-Teams, welches durch sein Können für die praktische Umsetzung und die Qualität des Produkts verantwortlich ist (z. B. Fachleute, Developer und Tester). 8. Das Entwicklungsteam bildet dabei den Link zum User. Es geht darum, in fest definierten Zyklen Feedback zum Produkt einzuholen und dieses in die weitere Entwicklung einfließen zu lassen. 9. Damit die intensive Zusammenarbeit zwischen dem PO und dem Entwicklungsteam gut funktioniert, wird das Scrum-Team durch den ScrumMaster (SM) vervollständigt. Seine Hauptverantwortung liegt darin, dass das Scrum-Team insgesamt produktiv arbeiten kann und die Scrum-Regeln eingehalten werden. 10. Der SM arbeitet dabei kontinuierlich mit dem Management zusammen, da das Management für die Entwicklung und die Verbesserung von Strukturen und Richtlinien in der Organisation verantwortlich ist. 11. Zurück zur Vision! Nun muss sich der PO Gedanken darüber machen, welche Nutzerbedürfnisse durch das Produkt adressiert werden sollen. Kurzum: Welche Funktionalitäten müssen wir liefern, die auf unsere Vision einzahlen und gleichzeitig einen Nutzen für unsere Nutzergruppe schaffen? 12. Dazu schreibt der PO, entweder alleine oder gemeinsam mit dem Entwicklungsteam, erste User Storys (US). Diese User Storys werden in einem Product Backlog erfasst. Da der PO für den ROI verantwortlich ist, priorisiert er diese nach dem jeweiligen Nutzenwert. 13. In einem nächsten Schritt führt das Entwicklungsteam eine erste initiale Schätzung des priorisierten Backlogs durch. Das Entwicklungsteam beurteilt dabei, wie viel Funktionalität/Mehrwert eine US bringt (Es wird nicht der Aufwand geschätzt, da dieser vom Erfahrungsschatz und Können der jeweiligen Person abhängig ist). Als Ergebnis der Schätzung liegen nun sämtliche, mit Story Points bewertete US vor. 14. Der PO erstellt nun einen initialen Release Plan, indem er die US entlang einer Zeitachse in die Sprints verteilt, in denen diese voraussichtlich bearbeitet werden. Der Release Plan ermöglicht eine Vorschau bzw. Prognose, in welcher Zeit welche Funktionalität geliefert werden kann. Hierin ist vermerkt, wann voraussichtlich genug Funktionalität entwickelt wurde, um einen Release durchzuführen. 15. Wichtig ist, dass genug US vorliegen, die innerhalb eines Sprints erledigt werden können, damit der erste Sprint beginnen kann. Das Ziel an dieser Stelle ist nicht eine monatelange Planung, sondern so schnell wie möglich mit der Entwicklung loszulegen, um rasch Feedback zum Produkt generieren zu können. 16. Ist der erste initiale Release Plan erstellt, können wir nun von der strategischen Ebene (strategische Planungsebene) auf die taktische Ebene wechseln, auf der die tatsächliche Produktentwicklung in Form von Sprints vonstattengeht. 17. Das erste Meeting auf der taktischen Ebene ist das Sprint Planning 1 (SP1). In diesem ersten Sprint Planning wird die Frage geklärt, was im bevorstehenden Sprint erledigt werden soll. Der PO erläutert sein Ziel für den Sprint und erklärt konkret, was er sich unter den einzelnen US vorstellt. Das Entwicklungsteam stellt Fragen und entwickelt ein Gefühl dafür, was es in diesem Sprint bearbeiten kann. 18. Am Ende des SP1 steht das Commitment des Entwicklungsteams. Dieses Commitment ist ein „Akt der Freiwilligkeit“, weshalb das Entwicklungsteam bei seiner Entscheidung nicht durch den PO beeinflusst werden darf. Es ist Aufgabe des ScrumMasters, darauf zu achten, dass diese Regel nicht verletzt wird. Das Ergebnis ist das Selected Product Backlog. 19. Das nächste Meeting ist das Sprint Planning 2. Hier bespricht das Entwicklungsteam, wie die einzelnen US, welche für den gegenwärtigen Sprint committet wurden, umgesetzt werden sollen. Es entstehen erste konkrete Tasks, welche auf dem Taskboard festgehalten werden. 20. Im Laufe des Sprints gibt es ein tägliches Synchronisationsmeeting, das Daily Stand-up Meeting. Hier organisiert sich das Entwicklungsteam selbst und jedes Mitglied erläutert kurz und knapp, welchen Task es gestern erledigt hat, welchen Task es am aktuellen Tag erledigen möchte und welche Impediments (Hindernisse) es gibt. Ziel ist es, den Austausch im Team zu fördern, Entwicklungsfortschritte transparent zu machen und Impediments direkt zu identifizieren. 21. Der SM hört beim Daily Stand-up Meeting aufmerksam zu und nimmt die Impediments in sein Impediment Backlog auf. Seine Aufgabe ist es, dass alle Impediments, welche außerhalb der Verantwortlichkeiten des Entwicklungsteams liegen, gelöst werden. Hierzu steht er in engem Kontakt mit dem Management, da dieses die Entscheidungsgewalt über organisationsinterne Strukturen und Richtlinien hat. Indem der SM die Impediments gemeinsam mit dem Management löst, kann der Wandel zur agilen Organisation stetig vorangetrieben werden. 22. Am Ende des Sprints wird das vom PO abgenommene Produktinkrement vom Entwicklungsteam im Review vorgestellt. Das Review ist ein öffentliches Meeting, an dem jeder teilnehmen kann. Im Kern geht es darum, dem Kunden sowie dem Nutzer das fertige Produktinkrement vorzustellen und Feedback zu bekommen. Dieses Feedback wird vom PO im Product Backlog als neue US aufgenommen. 23. Direkt darauf folgt die nicht öffentliche Retrospektive. Dieses Meeting ist das Herzstück des Scrum-Prozesses, denn das Scrum-Team analysiert hierbei den eigenen Arbeitsprozess. Es geht darum, herauszufinden, wie das gemeinsame Arbeiten verbessert werden kann, um im nächsten Sprint noch produktiver zu werden. Die Impediments werden nach Wichtigkeit und Nutzen priorisiert und es wird geklärt, ob diese im Verantwortungsbereich des Teams oder der Organisation liegen. Letztlich werden (konkrete) Verbesserungsmaßnahmen abgeleitet. 24. Während des Sprints, der optimalerweise eine Woche dauert, findet das Backlog Refinement statt. Hierbei geht es primär darum, das Product Backlog mithilfe der gewonnenen Erkenntnisse aus dem Review (Kundenfeedback) zu aktualisieren. Die bereits vorhandenen User Storys werden überprüft und gegebenenfalls geschnitten (eine US wird in kleinere US unterteilt). Völlig neue User Storys werden vom PO vorgestellt und durch das Entwicklungsteam wiederum initial geschätzt. Bereits vorhandene User Storys werden in der Schätzung angepasst. 25. Dabei folgt der Scrum Flow dem Zyklus Plan-Do-Check-Act (Deming Cycle), welcher eine kontinuierliche Optimierung von Produkt und Prozess ermöglicht.

Auf den Punkt gebracht.

Die 25 Schritte des Scrum Flows machen deutlich, worum es bei der agilen Produktentwicklung geht. Es geht um das permanente Liefern von fertigen Produktinkrementen und darum, möglichst schnell Feedback zu generieren, um Produkte stets auf die Bedürfnisse des Kunden auszurichten. Der PO hat dabei eine besonders wichtige Position inne, denn er ist für die Value Proposition des Produktes verantwortlich. Er muss den Markt kennen, ihn verstehen und er muss wissen, was sich der Endnutzer des Produktes wirklich wünscht, ohne dabei die Wirtschaftlichkeit des Produktes aus den Augen zu verlieren.

The Pull of the Retro

The Retrospective is perhaps the most challenging part of the Scrum process for a ScrumMaster. Although there are several ways to run a retro, the basic idea is very simple. You want to find out what went well and what could be improved, to gather information that will help you to improve the team’s performance. The Retro essentially gives the ScrumMaster ‘material’ to work with; as the change agent, you need to know what the team wants to have changed. Engaging in discussions with the team to understand what the problems are and how they can be addressed are key parts of the process.

Getting a ‘feel’ for the team

For me, the Retro is primarily a barometer for a team’s mood. You can focus your attention on the tone in which the team members speak, how they express their opinions and what the contents are. Their openness and engagement are what you want to see, but maybe you realize that they are holding back a bit. In that case, the team members might lack a clear understanding of the main point of the Retro; or they might not feel comfortable enough to speak out and raise difficult (and potentially controversial) issues. Consequently, you have to ask yourself: What is preventing the team from being open, and therefore fulfilling the purpose of the meeting? What is required to give them more confidence?

One of my teams had already gone through several Retro cycles. Nevertheless, there was this feeling that we are going around in circles. The Product Owner was always present, and the team would not really speak about problems at the team level. Even after organizing categories to specify whether problems (and successes) are at team, sector or organization-wide levels, the problems at team-level remained underrepresented and would often boil-down to difficulties that actually lay in cooperation with other teams.

Individuals becoming a Team

Although the team had been performing very well, the Product Owner did not want to take the further steps recommended by the SM to improve the team’s performance further. Instead, the PO turned up for the Backlog Refinement and questioned the concept of the meeting; and what is more, he had no proper Backlog for the team to refine. Similar problems have been encountered in other meetings, including Dailys where the PO was openly dismissive of the pull principle by actively staring at a person whom he believed should take a particular User Story during the Sprint Planning 1.

Of course, there are many ways to address this. However, in order to ‘empower’ the team it is important to keep a cool head and not to argue during joint meetings, but rather explain the roles, the aim of the particular meeting and the principles of Scrum – day in, day out, if required. The team got the ideas and had a pretty clear picture of how things should run in an agile environment. After one particularly poor showing at the Backlog Refinement, I decided to communicate more openly and strongly what the team needs, and what the role of the PO consists of. At first glance, it seemed that this didn’t work out very well. The meeting ended without anything resembling a half-decent Backlog, with the PO throwing User Stories on the table in the shape of tasks, and a team visibly annoyed.

The Grassroots Retro

It was not entirely surprising to receive an update several hours later. The team held a spontaneous ‘crisis meeting’ and wanted to make these issues a subject in the next Retro. I welcomed this news with arms wide open, particularly because the team had developed a pull principle to Scrum itself.

Although the PO used to join those meetings, I offered to exclude him this time. The team agreed. We started the Retro with two boards. One symbolized the United Nations. All the topics on this wall would be directly discussed with the PO. The other one was Las Vegas. What happens in Vegas stays in Vegas. The logic behind it was to encourage the team members to show commitment and also become aware when they are not courageous.

To my positive surprise, everything ended up at the UN, while the themes were almost entirely focused on the dynamics within the team. After 1 hour we realized that we need more time, so we organized a second part to go through the themes and find potential solutions. The vast majority of the themes challenged the PO, how he is fulfilling the obligations towards the team, and produced concrete steps forward. The next steps were to formulate the points, prioritize them and for me to present them to the PO who needs to commit to them.

Discovering Openness

Overall, and irrespective of the possible outcome of the meeting between the PO and the SM, the team has succeeded in formulating and openly speaking about problems. Initially, they were not able to challenge the PO directly. By now, the team members have committed themselves to use Retros to raise essential questions to improve their ability to work effectively. I’ve realized that feeling the pulse of the team and reading between the lines are important, and I’ve also learned that it is crucial to invest time in change and provide clarity on roles and responsibilities. The results speak for themselves. In the next sprint, the team nearly completed the entire committed Sprint Backlog, and the members have also begun sparring to learn new skills from one another. When culture change is in focus, openness does go a long way.

Der Blick hinter die Fassade: die Retrospektive

Das tägliche Lernen und Reflektieren gehört zum Wissensarbeiter wie das tägliche Schleifen der Werkzeuge zum Waldarbeiter. In den immer wiederkehrenden Lernschleifen kann altes Wissen vertieft, neues Wissen integriert, beides miteinander verknüpft und hinterfragt werden. Sich bewusst die Zeit zu nehmen, um zu reflektieren und das Reflektierte zu dokumentieren, sollte ein fixer Bestandteil des Arbeitsalltags sein und zu einer Praxis werden, die selbstverständlich ist.

Reflexion im Team

Nach einem Sprint ist es üblich, einen Rückblick zu wagen und die Geschehnisse im Sprint noch einmal Revue passieren zu lassen. Hier ist es z. B. möglich, mit Fragen zu arbeiten:

  1. Welche signifikanten Ereignisse sind im jeweiligen Zeitraum passiert?
  2. Wie ist das Stimmungsbild?
  3. Was ist uns gelungen?
  4. Was können wir verbessern?

In diesem Scrum-Workshop geht es vor allem darum, Beziehungspflege im Team zu betreiben. Dadurch soll einerseits ein Gemeinschaftsgefühl entstehen und andererseits ein Raum geöffnet werden, um Dinge anzusprechen, die gut oder eben nicht so gut gelaufen sind – und das möglichst wertfrei. Dieses Treffen muss auch keinen Output generieren. In der Praxis erlebe ich häufig, dass ScrumMaster den Fokus auf das Ableiten von „Maßnahmen“ aus dem Gesagten legen, damit man im nächsten Sprint gewisse Regeln oder Verhaltensweisen befolgen kann. Und das ist großartig, wenn das Gesagte den nötigen Raum findet, um von allen gehört zu werden, und man daraus Verhaltensweisen definiert, die einem Orientierung geben. Doch das übergeordnete Ziel dieses Treffens ist es, die Zusammenarbeit im Team zu verbessern. Nicht mehr und nicht weniger. So stellt sich mir die Frage: Wie kann ich als ScrumMaster den Fokus auf die Zusammenarbeit legen?

Offene Retrospektiven gestalten

Für Teams, die sich kennen und miteinander frei über ihre Themen sprechen können, wäre es vielleicht angenehmer, wenn man das aus Büchern bekannte Retro-Format aufweicht. Hier kann man auch durchaus experimentieren. Was passiert eigentlich, wenn man mal den Meeting-Raum verlässt? Wenn man die gewohnte Retro mal ganz anders gestaltet? Vielleicht in einer zwangloseren Atmosphäre? Wie wäre es, den Druck rauszunehmen und die Retro als eine offene Stunde für das Team zu gestalten? Ohne Agenda. Ohne Fragen. Einfach mal darüber zu sprechen, was gerade ansteht und die Menschen im Team beschäftigt. Und die Teammitglieder entscheiden zu lassen, worüber sie sprechen oder wie sie diese offene Stunde gestalten wollen.

Darum ist ein offener Raum wichtig

Um einen offenen Raum ohne Rahmen zu gestalten, braucht es einen gewissen Reifegrad als Team. Doch genau in diesen Momenten passiert oft etwas ganz Wunderbares. Ohne Ablenkungen von Social Media oder anderen Verführungen. Genau in diesem Moment kann man Kontakt zu sich selbst herstellen und sich die Frage aller Fragen stellen: Wie fühle ich mich gerade? Natürlich kann sich in diesem offenen Raum auch Langeweile einstellen. Aber das ist der Punkt, an dem Kreativität aufkommt. Neue Denkwege können ergründet werden, Ideen entstehen.

Auf den Punkt gebracht

Meiner Erfahrung nach sollte man die Retro nicht unnötig verkomplizieren und stattdessen so einfach und klar wie möglich gestalten. Vielleicht hilft ja eine Frage, die den Ausblick in die Zukunft wagt: Was würde uns beim nächsten Sprint glücklicher machen? Im nächsten Meeting? Am nächsten Tag?

Wegweiser zu einem gelungenen Meeting oder Workshop

Großunternehmen setzen zum Teil auf das effektvolle Mittel, einen Kostenzähler sichtbar in Meeting-Räumen zu platzieren. Im Angesicht der steigenden Summen macht sich auf diese Weise schnell Verwunderung darüber breit, wie viel ein Meeting kosten kann. Der eigentliche Nutzen vieler Meetings bleibt in Relation zu diesen Kosten aber oft bescheiden. Neben der teils inexistenten Wirtschaftlichkeit nehmen viele Mitarbeiterinnen und Mitarbeiter Meetings zudem als frustrierend oder Zeitverschwendung wahr. Für die Akteure gleichen sie wiederum häufig einer Bühne, auf der sie ihre fehlende Vorbereitung überspielen müssen. Ganz unabhängig davon, ob nach agilem oder klassischem Modell gearbeitet wird.

Das alles ist menschlich und nachvollziehbar. Denn bei den vielen täglichen Aufgaben und der Meeting-Flut fehlt manchmal einfach die Zeit, um sich für jedes Meeting ausgiebig vorzubereiten. Ich möchte Ihnen hier eine Möglichkeit vorstellen, wie Sie Ihre Meetings, aber auch Workshops wirkungsvoller und nützlicher gestalten können. Meeting-Vorbereitung ist wie ein Muskel, der trainiert werden kann. Es braucht zunächst ein anfängliches Vertrauensgespräch mit dem inneren Schweinehund – und danach eine Prise Disziplin und Training. Der Return on Investment ist die Mühe definitiv wert. Die Anzahl der Meetings nimmt ab, die Qualität ihrer Ergebnisse und der Kommunikation allgemein nehmen zu.

Die folgende Checkliste kann Ihnen als Hilfsmittel dienen, um Meetings oder Workshops effizient und zielführend zu gestalten und den Return on Investment zu steigern. Sie können nach Belieben Fragen hinzufügen oder streichen, abhängig von dem Kontext, in dem Sie sich bewegen. Empfehlenswert ist es, sich zu Beginn alle Fragen anzuschauen, auf den Projektkontext zu transferieren, kurz innezuhalten und dann ehrlich für sich zu beantworten. Anfangs kann es schwierig sein, Antworten auf die Fragen zu finden. Manchmal widmet man sich einer Frage und im nächsten Moment eröffnen sich mehrere weitere daraus. Freuen Sie sich! Sie lernen gerade, den Projektkontext systematisch zu scannen und erfassen. Mit der Zeit fällt Ihnen das Beantworten und das Filtern nach den passenden Fragen für Ihren spezifischen Kontext immer leichter. Falls Sie sich im ersten Moment von den vielen Fragen überwältigt fühlen und Ihnen der Zeitdruck im Nacken sitzt, suchen Sie sich beispielsweise fünf Fragen aus und arbeiten diese in das Meeting ein. Jeder Schritt ist ein Schritt nach vorne, mag er noch so klein erscheinen!

Die Checkliste hat sich für mich persönlich als hilfreiche Gesprächsgrundlage bewährt – in meiner Rolle als Agile Coach, Ausbilderin für ScrumMaster und für die gemeinsame Vorbereitung von Meetings mit Kolleginnen und Kollegen. Sie kann sowohl für Meetings als auch für Workshop genutzt werden. Hier können Sie diese auch downloaden: Checkliste zur Gestaltung von Meetings und Workshops

Informationen sammeln

Definieren Sie vorab Ziele und erheben Sie alle relevanten Informationen. Das hilft, Abhängigkeiten und Beziehungen zu verstehen.

Workshop designen

Klären Sie die Rahmenbedingungen und legen Sie neben dem inhaltlichen Fokus auch die Methodik fest.

Durchführung vorbereiten

Teilen Sie alle organisatorischen Informationen rechtzeitig. Bereiten Sie den Raum vor und vergessen Sie nicht, Feedback einzuplanen.

Workshop abschließen

Erklären Sie den Transfer der Ergebnisse in den Alltag und fassen Sie gemeinsam die wesentlichen Erkenntnisse zusammen. Geben Sie abschließend einen Ausblick.

Die Checkliste zum Download: Checkliste zur Gestaltung von Meetings und Workshops

Illustration: Business vector created by rawpixel.com – www.freepik.com

How to formulate suitable check-in questions – what I have observed

“Check-in questions are childish,” so one member of the development team stated, which stimulated a vibrant discussion that filled our 15 minutes during our daily. “If we want to reach our goals, we need to be efficient and serious about our work.”

As a reflective person, I certainly scrutinized this statement and made a thorough investigation of the relevancy of check-in questions. And guess what I found? Check-in questions are not childish.

Why do we even “check in”? Why do we need to arrive? What benefit do we expect from asking a supposedly “random” question at the beginning of a meeting?

Before the serious business starts, it is an excellent method to deflate the “tension-balloon” and to talk about something everyone can contribute to; a topic that needs less rational thinking and rather stimulates an intuitive answer.

The art of the question matters

Think about it like this: Everyone comes to work in a certain mood, has hobbies, specific topics of interests or recent happenings that circulate his or her minds. I believe that you can get every person to speak about something they are passionate or currently thinking about.

It is about who

However, I have observed that the challenge lies within the “who.” Who am I sharing these thoughts with? Some individuals consider topics outside the scope of their business (e.g., philosophical, fictive, abstract questions) as personal and intimate; subjects they feel uncomfortable sharing in a large group of colleagues. Check-in questions hence become vexing and not pleasant.

How do I deal with it?

  1. Know your audience
    Are you dealing with a loquacious, young-spirited, very open-minded, knowledge-seeking and sharing team or is your team filled with timid, closed-minded, not very cooperative individuals? Or even a mix of both?
  2. Formulate check-in questions that suit your audience
    The more non-cooperative and closed-minded your team, the less likely it is to be successful with personal or fictive questions (e.g., What do you appreciate about yourself?). I have noticed that answering rating and guessing questions positively correlates with closed-minded teams, provided that the question is pragmatic, non-personal and relevant. For mixed teams choose questions that are fun, non-personal, value-creating; and for open-minded teams make sure your question is fun or challenging, informative and creative.
  3. Make participation voluntarily but very attractive
    Clarify, that answering check-in questions is voluntarily, but make them damn attractive to answer. Make people want to be part of the discussion.

Here are a few example questions for each group:

Open-minded

Closed-minded

Mixed

Consequently, a team that communicates well works well together. Vivid check-in time is an indicator for an open-minded and motivated team. Know your audience and slip in questions that trigger a conversation.

Lastly, a tip I learned from my colleague: The word “check-in question” may put people off – ask the question without mentioning that you are about to ask a check-in question.

Remote-Retrospektive mit der Hero’s Journey: ein Erfahrungsbericht

In der Rolle als Agile Coach ist es nur eine Frage der Zeit, bis man vor folgender Herausforderung steht: Das Team sitzt nicht zusammen am selben Ort und braucht eine Retrospektive, die mithilfe von Videotelefonie und Screensharing remote umsetzbar ist. Nun kommt natürlich auch noch der eigene Anspruch dazu: Die Retrospektive soll trotzdem außergewöhnlich sein und das Team zu einer Betrachtung der Zusammenarbeit aus einem anderen Blickwinkel anregen.

Mit einem hochmotivierten und aufgeschlossenen Kundenteam führte ich deswegen eine etwas andere Art der Retrospektive durch – inspiriert durch einen Blogbeitrag von Steffen Hartmann von Mayflower (Retrospektive – The Hero’s Journey).

Die Hero’s Journey im Überblick

Bei dieser Variante der Retrospektive betrachten die Teammitglieder ihre bisherige Zeit im Projekt als eine Heldenreise. Diese umfasst zwölf verschiedene Etappen – beginnend beim Leben als „Normalo“ über das Meistern von Herausforderungen bis hin zur Transformation zu einer neuen Persönlichkeit. Der selbst gestaltete Held ist dabei eine Abstraktion eigener und fremder Wünsche sowie Sorgen im Team. Die Teammitglieder können so geschützter als in einer klassischen Retrospektive auch diejenigen Punkte thematisieren, die sie aus der Ich-Perspektive heraus vielleicht nicht ansprechen würden.

Vor allem bei dezentralen Teams, die nur über Videotelefonie kommunizieren können, beschränken sich klassische Retrospektiven tendenziell auf ein oberflächliches Abarbeiten der üblichen drei Fragen:

Genau diesen immer gleichen Ablauf wollte ich verhindern. Wie ich dabei vorgegangen bin, möchte ich im Folgenden veranschaulichen.

1. Das Team vorbereiten

Um die Bereitschaft im Team für die doch eher ungewöhnliche Retrospektive zu erhöhen, versuchte ich zunächst, die Teammitglieder mental darauf vorzubereiten. Dazu stellte ich nach dem Daily einfach vorab die Frage: „Hättet ihr Lust auf ein Experiment bei der Retrospektive?“ Glücklicherweise schreckte dieses Team vor keinem Abenteuer zurück und schon kam das Commitment für die etwas andere Retro.

2. Vorbereitung der Hero’s Journey für eine Remote-Retrospektive

Damit die Retrospektive des dezentralen Teams in der vereinbarten Zeit von 90 Minuten durchführbar war, musste ich diese entsprechend anders vorbereiten als im genannten Blogbeitrag von Steffen Hartmann beschrieben. Die Entscheidung fiel auf ein PowerPoint-Format. Dafür habe ich die SAP-Scenes-Figuren einzeln in PowerPoint kopiert und bereits vorab alle Sprechblasen und Felder eingefügt, die in der Retrospektive abgefragt werden sollten.

Fragen für Retrospektive

Abbildung 1: Fragen für die Retrospektive

Insgesamt konnten die Teammitglieder zwischen neun verschiedenen Charakteren wählen, die in SAP Scenes zur Verfügung standen. Der Grund ist einfach nachzuvollziehen: Nicht jeder kann sich mit einem Superhelden mit Krawatte identifizieren. Um eine klare Ausgangslage zu schaffen, habe ich außerdem die Etappen der Hero’s Journey als erste einleitende Folie in die PowerPoint-Präsentation eingefügt:

Hero's Journey

Abbildung 2: die Hero’s Journey

Die Teammitglieder bekamen die vorbereitete Präsentation noch nicht vor, sondern erst während der Retrospektive. Sie wurden aber rechtzeitig informiert, dass sie jeweils einen Laptop zum Termin mitnehmen sollten.

3. Der spannende Teil: die Durchführung

Nun war es so weit. Das Experiment konnte beginnen. Nach einem kurzen Check-in per Video-Konferenz bedankte ich mich beim Team, dass es so offen für diesen Versuch war. Bevor ich die PowerPoint an alle Teammitglieder weiterleitete, erklärte ich in ein paar einleitenden Worten, warum ich mich für dieses Format entschieden habe. Aus meiner Sicht bietet es mehrere Vorteile.

Die Hero’s Journey:

Wie von Steffen Hartmann empfohlen zeigte ich nun das Video der Hero’s Journey.

Bevor es an die Arbeit ging, gab es noch ein paar letzte Hinweise:

Anschließend bekamen alle Teammitglieder die Präsentation per E-Mail und sollten die Fragen innerhalb von 15 Minuten beantworten.

4. Das Ergebnis

Nach Ablauf der Timebox schickte jedes Teammitglied die ausgefüllte PowerPoint-Folie von seinem Helden an mich zurück. Anschließend stellte einer nach dem anderen seinen Charakter vor. Da ich den Bildschirm teilte, wussten die zugeschalteten Teammitglieder immer genau, über welchen Charakter wir gerade sprachen.

Ich zeige in diesem Beitrag bewusst keine Original-Beispiele eines Helden, weil meiner Meinung nach gilt: Was in der Retrospektive passiert, bleibt in der Retrospektive. Stattdessen eine von mir zusammengestellte Form zur Veranschaulichung, die Teile der Wahrheit beinhaltet:

Antworten Retrospektive

Abbildung 3: die Antworten des fiktiven Helden Rubyman

Beim fiktiven Rubyman handelt es sich um einen erfahrenen Entwickler, der die Programmiersprache Ruby in Perfektion beherrscht. Seine Aussage „Nobody wants me“ rührt daher, dass das Unternehmen keinen entsprechenden Entwickler für das Team einstellen möchte. Also ist Rubyman ein Held, der dem Team aktuell noch fehlt, um die bevorstehenden Herausforderungen erfolgreich zu meistern.

Meine Aufgabe als Agile Coach war es dabei, zwischen den Zeilen zu lesen. Ich notierte die Erfolge und Herausforderungen auf Post-its und stellte sie dem Team im Anschluss vor. Wir wählten daraufhin zwei Maßnahmen aus, die wir im nächsten Sprint umsetzen wollten.

Das Fazit des Experiments

Das war definitiv eine etwas andere Retro, aber für das Team war es durchaus erfrischend. Das Teammitglied, das Rubyman vorgestellt hat, sagte ganz begeistert: „Endlich thematisiere nicht mehr nur ich, dass wir einen erfahrenen Entwickler benötigen, sondern Rubyman macht das selbst“. Wir haben viel gelacht und über die Kreativität im Team gestaunt. Als Moderator konnte ich auch sehr viel aus den Stärken, Schwächen und Aussagen der Helden über die aktuelle Stimmung im Team herauslesen, wodurch ich die Teammitglieder schließlich zielführender und individuell unterstützen konnte.

 

Titelfoto von Fredrick Kearney Jr auf Unsplash
Figuren von SAP Scenes

Bildwelten – wie Sie eine Retrospektive zur visuellen Reise machen

Die Retrospektive dient im Scrum-Prozess vor allem dazu, aus den Erfahrungen des aktuellen Sprints zu lernen und so die Zusammenarbeit nachhaltig zu verbessern. Der Ablauf einer Retrospektive ist immer ähnlich und besteht im Wesentlichen aus fünf Schritten:

Dass es trotz vergleichbarer Abläufe eine Vielzahl an Gestaltungsmöglichkeiten für Retrospektiven gibt, zeigt sich auf Websites wie Fun Retrospectives oder Retromat.

Wenn ich Teams durch eine Retro begleite, so nutze ich gerne Bildwelten, um die Kreativität im Raum zu stärken und die Teammitglieder zu neuen Sichtweisen anzuregen. Wie das funktioniert, möchte ich in diesem Blog-Beitrag am Beispiel der „Sailboat-Retro“ veranschaulichen.

Willkommen an Bord

Als sehr bildhafte Variante der Retrospektive eignet sich die Sailboat-Retro hervorragend, um von Beginn an zu signalisieren, dass alle Teammitglieder im selben Boot sitzen – und auf ein gemeinsames Ziel zusteuern. Der Name des Teams am Rumpf des Segelbootes unterstreicht das zusätzlich. In der Praxis bereite ich den Rahmen und die Grundstruktur bzw. wichtige Grundelemente der Bildwelt gerne schon vor dem Termin vor, um direkt starten zu können.

Zurückblicken, um voranzukommen

Nach dem Check-in, dem Ankommen im Raum, reflektiert das Team zunächst, was gut gelaufen ist. Für diesen positiven Rückblick bietet sich folgende Fragestellung an: Was ist der Wind in unseren Segeln? Was bringt uns voran? Was macht uns schneller?

Wenn das Team nun die Antworten auf Post-its gesammelt hat, macht es Sinn, diese direkt auf dem Flipchart zu clustern.

Es geht immer noch besser

Nachdem wir jetzt wissen, was gut funktioniert hat, geht es in weiterer Folge darum, Verbesserungspotenziale zu identifizieren. Auch hier steige ich gerne mit Fragestellungen in die Bildwelt ein:

Der Anker steht in diesem Fall für Verlangsamung, für ein Hindernis des Vorankommens, während der Hai aufkommende, in der Zukunft liegende Gefahren symbolisiert.

Das Team überlegt, schreibt seine Antworten auf Post-its und klebt diese auf die Freifläche am Flipchart. Was thematisch zusammenpasst, wird direkt geclustert, um Muster zu erkennen. Wenn sich ein großes Thema ablesen lässt, ist der Fokus der Maßnahmenfindung für den nächsten Sprint einfach zu setzen. Ansonsten nütze ich gerne Dot-Votings, um zu priorisieren. Jedes Teammitglied bekommt dabei zwei Punkte, die je nach individuell empfundener Dringlichkeit an die vorhandenen Themen vergeben werden können.

Volle Kraft voraus – mit konkreten Maßnahmen

Im nächsten Schritt soll das Team nun sinnvolle, umsetzbare Maßnahmen für den kommenden Sprint definieren. Wie können wir Hindernissen ausweichen und Gefahren vermeiden? Was müssen wir tun, um noch schneller zu werden? Die Maßnahmen, die sich aus diesen Fragen ergeben, nimmt das Team aus der Retrospektive mit. Und versucht, diese sofort in den darauffolgenden Arbeitstagen umzusetzen. Nach dem Check-out ist der aktuelle Sprint abgeschlossen.

Visualisierung wirkt

Meiner Erfahrung nach sind Bildwelten eine tolle Möglichkeit, damit sich Teams besser auf die Fragestellung einlassen können. Durch das Verankern der Antworten auf dem Flipchart lassen sich Muster schnell erkennen, was das Stimmungsbild im Team meist noch besser sichtbar macht. Außerdem kann dieser visuelle Ansatz dazu führen, dass Teams gewisse Aspekte ihrer Zusammenarbeit noch einmal unter anderen Blickwinkeln betrachten.

Alles, was Sie dazu brauchen, sind ein Flipchart, zwei dicke und ein dünnerer Marker in unterschiedlichen Farben sowie Post-its oder statisch haftende Notizzettel. Probieren Sie es aus, es macht Spaß. Und lohnt sich.

 

Foto: CCO Creative Commons – Pixabay

Lean Coffee – der Koffeinkick für Ihre Meetings

Morgens, halb zehn in Deutschland. Ein freundlicher Blick von Kollegen, ein leckerer Cappuccino und eine quadratische Waffel mit Milchcreme, Schokolade und Haselnüssen. Großartig – ich bin dabei!
Morgens, halb zehn in Deutschland. Für die meisten in den Büros zwischen Flensburg und Füssen bedeutet dies eher Regelkommunikation, Statusmeeting oder Abstimmungstermin. Im besten Fall gibt es eine Agenda, die dem Termin eine Struktur geben soll – ziemlich fremdbestimmt, aber immerhin. Im schlimmsten Fall gibt es keine Agenda, die Teilnehmer kommen unvorbereitet und einige sind erst Minuten nachdem die Türe geschlossen wurde wirklich präsent.
Wenn das die Realität ist, warum dann nicht damit umgehen? Warum nicht den Meetings eine Struktur, eine Agenda geben in dem Moment, in dem sie gebraucht wird? Zu Beginn! Lean Coffee bietet dafür ein großartiges Format: Einfach, pragmatisch und effektiv. Morgens um halb zehn, nachmittags um vier, am späten Abend, am frühen Morgen und jederzeit dazwischen.

Was Sie für ein effektives Kaffeekränzchen brauchen

Für ein Meeting im Lean Coffee Format benötigen sie nur Post-its, Stifte und einige Teilnehmer. Zuerst werden drei Spalten auf den Tisch gelegt. Links „Themen“, in der Mitte „In Diskussion“ und rechts „Erledigt“. Schon steht die äußere Struktur. Wie das Ganze noch besser geht, kommt in einigen Zeilen.
Im zweiten Schritt erhalten die Anwesenden fünf Minuten Zeit, um ihre Themen, die bei diesem Termin besprochen werden sollen, niederzuschreiben. Nach Ablauf der fünf Minuten werden diese Themen in die Spalte „Themen“ gelegt und nach Inhalten geclustert. Anschließend wird abgestimmt. Jede Person erhält fünf Stimmen und vergibt diese als Punkte (engl. Dot-Vote) auf die Themencluster. Nun werden die Themen oder Themencluster entsprechend der Anzahl der Punkte von oben nach unten in der Spalte „Themen“ priorisiert.

Diskutieren in der Timebox

Das wichtigste Thema wird anschließend direkt in die Spalte „In Diskussion“ gezogen und besprochen. Um die Diskussionen kurz zu halten, werden feste Zeiträume verwendet. Die erste Runde dauert acht Minuten. Nach Ablauf der acht Minuten stoppt der Moderator die Diskussion und fragt, ob noch weitere Zeit benötigt wird. Die anwesenden Personen entscheiden per Mehrheitsentscheid – Daumen hoch oder Daumen runter (engl. Roman-Vote). Senkt die Mehrheit den Daumen, dann ist die Diskussion zu dem Thema beendet und das Post-It wandert in die Spalte „Erledigt“. Gehen die Daumen der Mehrheit nach oben, gibt es Zusatzminuten – nämlich vier. Nach den vier Minuten wird die Prozedur wiederholt und es werden noch zwei Minuten, eine Minute und… dann hoffe ich für Sie, dass die Diskussion ein Ende findet.
Die Unterbrechung der Diskussion nach Ablauf der Timebox ist der kritischste Moment beim Meeting im Lean Coffee Format. Respektieren Anwesende die Timebox nicht, sprechen weiter, möchten nur noch diesen einen letzten Aspekt einbringen, dann verliert das Format seine Kraft und seine Effektivität. Diese wenigen Sekunden Selbstdisziplin sind die neuralgischen Momente, in denen sich entscheidet, ob das Lean Coffee in ihrem Team ein Erfolg wird oder ob es wie bisher weitergeht.
Persönlich finde ich das Lean Coffee Format super! Richtig gut wird es, wenn noch zwei weitere Spalte hinzukommen: „Aha-Effekte“ und „Aufgaben“. Diese beiden Spalten werden mit etwas Abstand rechts von „Erledigt“ angefügt. In „Aha-Effekte“ kommen die neuen Erkenntnisse, die Geistesblitze und neuen Perspektiven, die sich während des Austauschs ergeben haben. Und wenn Aufgaben entstehen, finden diese ihren Platz in To-Dos.

Ein Format, das alle einbezieht

Auf den ersten Blick ist es bereits ein tolles Format. Wenn man noch tiefer blickt, entfaltet es seine wahre Schönheit. Alle Teilnehmer werden gehört, Hierarchiestufen werden aufgehoben, Beiträge kommen gleichermaßen von extrovertierten Personen wie introvertierten, es spielt keine Rolle, ob die Person ein Junior ist oder bereits viele Jahre Berufserfahrung hat, und wortstarke Personen haben keinen Vorteil gegenüber denen, die eher leise Töne anschlagen. Allein die Qualität und Relevanz der Beiträge ist entscheidend und das Team erhält ein großes Stück Selbstorganisation und Demokratie. Gleichzeitig können Führungskräfte (lateral wie funktional) trotzdem Themen, die ihnen wichtig sind, einbringen. Die Spalte „In Diskussion“ trägt dazu bei, den Fokus zu halten. Das aktuelle Thema ist transparent und plakativ, wodurch abschweifende Diskussionen leicht identifiziert werden können. Und am Ende des Termins kann über ein Foto sehr schnell protokolliert werden. Testen Sie hierzu die kostenlose App „Office Lens“ von Microsoft. Diese App bearbeitet die Bilder automatisch auf optimale Lesbarkeit und schneidet sie entsprechend zu.
P.S.: Lassen Sie uns wissen, wie das Lean Coffee bei Ihnen aussieht. Für die ersten fünf Posts auf den Accounts von borisgloger bei Facebook oder Twitter oder per Mail mit einem Bild von Ihrem Lean Coffee gibt es eine kleine Überraschung und diese quadratischen Waffeln mit Milchcreme, Schokolade und Haselnüssen.

Was die Position des Scrum-Teams vor dem Taskboard über das Team aussagt

„Leistet mein Team gute Arbeit?“ Eine Frage, die viele Führungskräfte in Unternehmen umtreibt, wie zahlreiche Anfragen nach Projektbesuchen und Assessments beweisen. Doch braucht es Fragebögen, Interviews oder stundenlange Post-Mortems, um eine Antwort zu finden? Die Frage lässt sich häufig mit einer scheinbar einfachen Methode beantworten: durchs Beobachten.
Wenn ich zum ersten Mal ein Team besuche, das bereits agile Arbeitsweisen wie Scrum oder Kanban nutzt, achte ich bewusst und unbewusst auf viele kleine Hinweise, um eine Hypothese über den Teamerfolg und das Verhalten des Teams und des Unternehmens zu bilden. Ich versuche bewusst, nicht in Aktionismus zu verfallen und sofort alles auf links zu drehen. Denn es gibt Gründe, warum die Menschen so arbeiten, wie sie es gerade tun. Es geht also nicht darum, nach wenigen Tagen einen detaillierten 12-Punkte-Aktionsplan zu haben, sondern ein tiefes Verständnis für die Arbeitsweise der Menschen im Unternehmen zu entwickeln.
Erfahrungsgemäß ist die Stehung, das Catch Up, Stand Up oder Heads Up, oder wie auch immer Sie das tägliche kurze gegenseitige Update im Team, also das Daily Scrum, bezeichnen, eine tolle erste Möglichkeit, um diese Beobachtung durchzuführen. Neben dem üblichen Teilnehmerkreis, der Dauer und der Häufigkeit des Dailys sagt die Position der Teammitglieder vor dem Taskboard sehr viel über die Kultur und den Teamspirit aus.
In den zahlreichen Unternehmen und Projekten, die ich gesehen habe, zeichneten sich einige Muster immer wieder ab. 12 davon zeige ich Ihnen hier. Zur Erklärung: Der orange Kreis ist der ScrumMaster, Gelb symbolisiert die Teammitglieder, in Grün sehen sie den Product Owner und blau ist der Manager.

Muster 1 – das einsame Taskboard


Niemand kommt zum Daily. Man hat sich zwar die Mühe gemacht, die Arbeit sichtbar zu machen, doch das Hilfsmittel wird nicht genutzt. Wahrscheinlich wird das Taskboard nicht als hilfreich erachtet. Offensichtlich sind Zusammenarbeit und Koordination in diesem Team nicht notwendig.

Muster 2 – die Leere


Kein Taskboard, keine Gespräche, kein Treffen. Ob das besser oder schlechter ist, als das „einsame Taskboard“ sei mal dahingestellt.

 

Muster 3 – kein Taskboard


Das Team unterhält sich mehr oder weniger strukturiert. Das ist ein guter Anfang. Der Hauptzweck des Meetings – die kurze, zielgerichtete Unterhaltung zwischen den Teammitgliedern funktioniert. Ein Taskboard kann helfen, diesen Austausch zu fokussieren und zu strukturieren.

Muster 4 – das Zentrum

Die Teammitglieder berichten an den ScrumMaster. Der ScrumMaster steht viel zu sehr im Fokus und verhindert, dass sich die Teammitglieder offen und ehrlich austauschen. Das Team hat den Nutzen des Dailys für sich selbst wahrscheinlich noch nicht erkannt. In besonders schlimmen Fällen fragt der ScrumMaster die Teammitglieder einzeln ab und verlangt eine Rechtfertigung, wenn etwas nicht klappt. Selbstorganisation muss hier noch beigebracht werden.

Muster 5 – das alternative Zentrum


Die Teammitglieder berichten an den Product Owner. Ein Wort – Micromanagement. Anscheinend vertraut der Product Owner dem Team nicht ausreichend. Der ScrumMaster scheint auch schwach zu sein.

Muster 6 – die spanische Inquisition


Product Owner und ScrumMaster sitzen hinter einem Schreibtisch vor dem Taskboard und erwarten den Bericht der Teammitglieder. So ziemlich das Schlimmste, was einem Team passieren kann. Noch schlimmer wäre es nur mehr, wenn die Teammitglieder mit verbundenen Augen vor einer Wand stünden.

Muster 7 – das Meeting


Offensichtlich ist die alte Meetingkultur noch tief verankert. Die Teammitglieder sitzen an den Tischen. Im „Idealfall“ klappt jeder noch seinen Laptop vor sich auch und tippt wild vor sich hin. Es geht um Anwesenheit, nicht um Ergebnisse. Langeweile ist vorprogrammiert, Leidenschaft werden wir in so einem Meeting vergeblich suchen. Kann noch gesteigert werden durch das nächste Muster.

Muster 8 – das Klassenzimmer


Ähnlich wie „Das Meeting“, zusätzlich können sich die Teammitglieder jetzt nicht mehr in die Augen schauen. Auch hier arbeiten eher Fachexperten in einer Arbeitsgruppe. Zusammenarbeit gibt es hier wahrscheinlich nicht.

Muster 9 – der Experte


Das Daily findet ausschließlich mit dem ScrumMaster und dem „einzigen Teammitglied, das sich wirklich auskennt“ statt. Ab und zu gibt es auch mehrere Experten, die jedoch getrennt voneinander befragt werden. Die restlichen Teammitglieder werden ignoriert. Teamzusammenarbeit und Austausch wird man in diesem Team vergeblich suchen.

Muster 10 – noch ein alternatives Zentrum


Die Teammitglieder berichten an den Manager – Micromanagement in Vollendung. Der Product Owner ist entweder entmachtet oder nicht da.

 Muster 11 – der Lonesome Rider


Der ScrumMaster macht das Daily mit sich alleine, weil er das Team nicht braucht, um Transparenz zu stiften. Er weiß Bescheid (oder meint Bescheid zu wissen), was im Team gerade läuft. Hat den Sinn des Dailys komplett verfehlt. Offensichtlich hat der ScrumMaster auch wenig Respekt vor den Fähigkeiten der Teammitglieder. Eine alternative Interpretation ist, dass keines der Teammitglieder zum Daily kommt, weil sie den Mehrwert und Sinn nicht sehen. Vergleichbar mit Muster 1 und 2.

Muster 12 – der Reporter


Der ScrumMaster berichtet direkt an den Manager. Teammitglieder werden komplett außen vor gelassen – entweder, weil der ScrumMaster die Teammitglieder als nicht fähig genug einstuft oder diese keine Lust auf das Meeting haben. Vertrauen und Identifikation mit dem Produkt, das entwickelt wird, wird man hier vergeblich suchen.

Die Kraft des Taskboards nutzen: Wie macht man es besser?

Idealerweise stehen alle Scrum-Teammitglieder – also Entwicklungsteam, Product Owner und ScrumMaster – gleichberechtigt vor dem Board. Die Teammitglieder erzählen sich gegenseitig von ihrem Fortschritt, der ScrumMaster moderiert, achtet in den Ausführungen des Teams auf Hindernisse und erzählt auch selbst von den Themen, an denen er arbeitet. Der Product Owner interessiert sich auch für den Fortschritt des Teams und berichtet von den Themen, die bei ihm passiert sind. So gefällt mir das.

Starten Sie an dieser Stelle ein kleines Experiment. Beobachten Sie bei nächster Gelegenheit das Verhalten Ihres Teams. Überprüfen Sie, ob sich der aus der Beobachtung ableitbare Zweck mit der Funktion deckt, die das Team erfüllen soll. Passt das Gesagte mit dem sichtbaren Verhalten zusammen? Damit wird die Beobachtung auch zur Strategiearbeit: Was haben wir uns vorgenommen zu tun und was tun wir tatsächlich? Beobachtung als bewusste Führungsaufgabe benötigt etwas Zeit und Kontakt ins Team, kann aber zur Rekalibrierung des Veränderungsbedarfs führen und zur Steuerung genutzt werden. Konkret könnte das bedeuten, die Beobachtung zu teilen und zusammen mit dem Team in Bezug auf den angestrebten Zweck zu reflektieren.
Kennt ihr noch weitere Muster? Ich freue mich über eure Kommentare.

Scrum Meetings – Daily (Scrum)

A very important meeting is the Daily, where teams come together for 15 minutes every day, to discuss next steps on how to reach their sprint goal. It is no longer just about what have I done yesterday, what will I do today and what impediments are in my way…  
Find out how this meeting has evolved from its origins to a new agile version in my how-to video.

Scrum Meetings – Sprint Planning #1

In this video I talk about the Sprint Planning #1 meeting, which is used to create a common understanding and a mutual agreement on what the team will accomplish. Further I explain why it is essential to decompose all user stories based on five critical aspects. 
Curious? Then come and join me in my agile how-to video! 

Die Retrospektive: Maßnahmen einfach tracken

Donnerstagnachmittag, Retrospektive bei einem Automotive-Kunden. Der Gong schlägt, die Timebox ist vorbei. Ich blicke überrascht auf die Resultate: Viele Vorschläge, aber keine wirklich konkrete Maßnahme. Vor allem keine, die man in einem Sprint umsetzen könnte.
Was nun? Klassische Frage: Halte ich die Timebox? Nach dem Prinzip: „Schade, schön wäre es gewesen. Learning fürs nächste Mal.“ Oder fokussiere ich mich auf den Zweck des Meetings: Wir wollen unseren Prozess verbessern. Ich entscheide mich für den Zweck und gebe uns noch einmal 10 Minuten.
10 Minuten später.
Nachdem wir kurz in eine offene Diskussion zurückgefallen sind, haben wir zwei konkrete Maßnahmen abgeleitet. Ich lasse das Meeting abschließend bewerten und beende es. So weit so gut, das Meeting war erfolgreich. Wie geht es nun weiter?

Leichen vergraben?

Ich habe mir vorgenommen, alles gut zu dokumentieren. Auch wenn das Fotoprotokoll wahrscheinlich eine Leiche im SharePoint bleibt. Was mich eher beschäftigt ist: „Was waren eigentlich die Maßnahmen der Retrospektive einen Sprint zuvor?“ Ich kann mich nicht daran erinnern und noch schlimmer, eine Abfrage hat es auch nicht gegeben. Das muss besser werden, denke ich mir. Diesmal tracke ich die Maßnahmen effektiv.

Noch ein Board?

Ich dachte erst an Continuous Improvement Board (CIB). Klasse Idee, oder? Ich verhandle mit mir selbst: „Viel Platz für viele Maßnahmen. Werden die auch alle umgesetzt in einem Sprint? Naja vielleicht brauchen sie ja mehrere Sprints. Aber dann sind die Maßnahmen einfach nicht konkret genug. Ein weiteres Problem beim CIB: Es ist ein weiteres Artefakt. Ich hänge es gleich neben die wenig beachtete Definition of Ready und die kaum benutzte „Waste-Wall“.

Oder einfach nur ein Task?

Die besten Lösungen sind die einfachsten. In einem früheren Team hatte ich am Taskboard eine eigene Swimlane mit dem Namen „Kaizen“. Das war gut, aber ich suche die Herausforderung: Geht es noch einfacher? Ohne Verlust von Effektivität? Ich entscheide mich dafür, Tasks zu erstellen. Simpel, nachvollziehbar und transparent. Weiterer Vorteil: Die Maßnahmen werden nun täglich im Daily mitverfolgt, und zwar instinktiv.
Mein Learning: Die einfache Lösung ist oft weniger intuitiv, aber durchdachter als die komplexe.

Video: Das Daily Scrum – reinvented

 
Mich hat lange Zeit die Frage umgetrieben: “Wie lässt sich die Zusammenarbeit in Teams noch besser synchronisieren?” Die Antwort ist ganz einfach: Aus Daily Scrums werden Mini-Reviews und aus diesen wird wiederum ein kontinuierliches gemeinsames Arbeiten an einer einzigen Sache. Dann braucht man keine Daily Scrums mehr und ist noch einmal wesentlich produktiver.
Im folgenden Video erkläre ich die Ideen dazu und dann liegt es an euch, es einfach zu tun.
Viel Spaß beim Abschaffen der Daily Scrums/Standups!
Boris
 

Video: Retrospektiven

 
Bei diesem Video werden sich in der Community der Retrospective Facilitators sicher viele Stirnen runzeln und agile Coaches werden mir sagen, wie falsch ich doch liege. Dennoch: Ich sage euch hier mal, wie ich über Retrospektiven denke.
Ich bin der Meinung: Viele von uns haben aus vielerlei Gründen die Retrospektiven zu einer neuen Kunstform erhoben und dadurch zu einem Selbstzweck gemacht. Ich möchte euch empfehlen, noch einmal darüber zu reflektieren, ob wir nicht wieder zur eigentlichen Idee zurückkehren und die lautet: einfache Retrospektiven durchführen – ohne viel Schnickschnack.
Im Video findet ihr meine Begründung dazu.
Boris
 

Video: Sprint Planning # 2

 
Meine Auffassung des Zwecks des Sprint Planning Meetings # 2 ist radikal. Vielleicht muss man zu den ersten Scrum Evangelisten gehört haben, um diesen radikalen Ansatz aufrecht zu erhalten, der quer zur Auffassung vieler anderer liegt.
Aus meiner Sicht geht es beim Sprint Planning # 2 um eine einzige Sache: Es soll die Frage geklärt werden, wie man innerhalb gegebener Parameter – Zeit, Geld, Technologie – eine agile Lösung findet. Oder anders gesagt: Wie kann man alles das liefern, was man im Sprint Planning # 1 versprochen hat? Auf diese Weise müssen Entwicklungsteams kreativ werden, sich neue Dinge ausdenken. Ja, das ist hart, aber es macht auch irren Spaß.
Viel Spaß beim Anschauen — Boris
 

Video: Sprint Planning

Was macht man in einem Sprint Planning # 1 und wie hängt es mit dem Backlog Refinement zusammen? Bitte nutzt dieses Meeting zur Analyse dessen, was der User tatsächlich braucht. Dann ist dieses Meeting nämlich produktiv und wertvoll – ansonsten ist es nur rausgeschmissene Zeit.
Mehr dazu in diesem Video.
 

5 Punkte für ein effektives Daily

Scrum ist ein hocheffizientes Rahmenwerk für die Produktentwicklung, sofern es richtig gelebt wird. Leider erleben wir zu oft das Gegenteil. Die Scrum Meetings werden prozessual etabliert, aber es fehlt am qualitativen Mehrwert, der durch die Meetings entstehen sollte.
Immer wieder sehen wir Dailys, in denen der ScrumMaster vor dem Board steht, als gelte es sein Heiligtum zu bewachen. Das Team hat im weiten Bogen um ihn herum Aufstellung bezogen und jede Person sagt einen Satz, ohne dass sich die Kärtchen am Taskboard bewegen. Fast alle Storys hängen in der WIP-Spalte und die Tasks bekommen trotz Bewegungsfaulheit keinen Punkt dafür. Der Product Owner vergibt bei Gelegenheit noch Aufgaben an einzelne Teammitglieder und fährt anderen Teammitgliedern über den Mund.
Ein so oder so ähnlich durchgeführtes Daily ist leider ein sehr ineffizientes Daily. Gut, immerhin ist das Daily als Meeting etabliert. Es wäre weitaus schlimmer, wenn das Meeting überhaupt nicht stattfinden würde. Da es stattfindet und das auf eine transparente Art und Weise, können wir anfangen, es in eine effektive Richtung zu lenken.

1. Daily als Ort der Kommunikation

Das Daily ist KEIN Statusreport für den Product Owner und auch nicht für den ScrumMaster. Das Daily ist da, damit sich das Dev-Team austauschen und koordinieren kann. Die Mitglieder des Dev-Teams sprechen miteinander und erklären sich gegenseitig, was sie machen, wo sie bei der jeweiligen Story noch Hilfe brauchen bzw. wo es sinnvoll ist, im Pairing zu arbeiten. Der ScrumMaster achtet darauf, dass das Ganze im zeitlichen wie auch menschlichen Rahmen bleibt und ist hellhörig bezüglich Impediments. Der Product Owner steht für Rückfragen zu den Akzeptanzkriterien zur Verfügung oder kann sich einbringen, wenn er das Gefühl hat, dass das Dev-Team über das Ziel der Akzeptanzkriterien hinausschießt.
Umsetzung: Der SM fordert die Teammitglieder auf, vor dem Taskboard zu stehen und stellt sich selbst mit den Product Owner in den Hintergrund. Wenn der ScrumMaster oder der Product Owner in den Mittelpunkt der Kommunikation rutschen, erklärt der ScrumMaster wiederholt, dass das Daily nicht dazu da ist, um ihn oder den Product Owner auf den neuesten Stand zu bringen. Das Daily dient dem Informationsaustausch zwischen den Teammitgliedern. Der ScrumMaster hält bei Bedarf wiederholte Mini-Workshops ab, um den Sinn eines Dailys zu erläutern und coacht bei Bedarf den Product Owner in seiner Rolle.

2. Das Herz des Dailys – Aufbau des Tasksboards

Ein Taskboard besteht aus drei Spalten: To do, Work in Progress (WIP) und Done – nicht mehr und nicht weniger. Die horizontalen Zeilen ergeben sich aus den Storys, wo die Tasks zugeordnet sind.
Umsetzung: Der ScrumMaster baut ein Taskboard auf. Unsere beliebtesten Hilfsmittel sind: Pinnwände oder Metaplanwände, die mit Kreppband oder Garn und Stecknadeln in die Bereiche aufgeteilt werden. Moderationskarten sind optimal für die Spaltenüberschriften und die Storys, während verschiedenfarbige Post-its und Stifte das tägliche Aktionsmaterial sind.

3. Die Fragen für das Daily

Man orientiert sich an den 4 Fragen:

Diesbezüglich gibt es mehrere Optionen. Entweder man geht diese Fragen pro Teammitglied oder pro Story durch. Ich persönlich präferiere letzteres: Letztendlich geht es darum, zu sehen, ob die Storys fertiggestellt werden können und nicht darum, dass alle Teammitglieder ausgelastet sind. Wer etwas Neues ausprobieren will, geht einen Schritt weiter und lässt die Teammitglieder herzeigen, was Sie bereits produziert haben, sodass jedes Daily zum Mini-Review wird.
Umsetzung: Der ScrumMaster achtet darauf, dass zu jeder Story/Person die Fragen beantwortet werden. Wenn etwas vergessen wird, erinnert er daran. Die Fragen auf Moderationskarten neben dem Taskboard aufzuschreiben, ist eine einfache und gute Erinnerungsstütze. Beim Mini-Review sorgt der ScrumMaster dafür, dass die Teammitglieder zwischen den Präsentationen zum Taskboard zurückzugehen, um es auf den neuesten Stand zu bringen. Der ScrumMaster sorgt dafür, dass die Timebox von 15 Minuten eingehalten wird, indem er die Leute daran erinnert, sich kurz zu halten bzw. eine Uhr mitlaufen lässt, die alle daran erinnert, wie viel Zeit noch übrig ist. Tipp: Es gibt Timebox-Uhren mit kleiner werdendem Zeitbereich zu kaufen.

4. Das Team bewegt sich, nicht der ScrumMaster

Das Team bewegt die Tasks über das Taskboard. Wenn ein Task done ist, sollte er auch wirklich done sein und nicht mehr zurückkommen. Dabei hat jeder Task ein Namenskürzel. Auch wenn wir Consultants als ScrumMaster arbeiten, können wir uns nicht immer merken, wer von uns welchen Task erstellt hat – mit Namenskürzel auf dem Task hat man aber immer eine Anlaufstelle, wenn man sich über Sinn und Zweck eines Tasks im Unklaren ist. Sollte sich ein Task nicht in die nächste Spalte bewegen, bekommt er jeden Tag einen Punkt und zwar von den Teammitgliedern. Der ScrumMaster achtet auf diese Tasks und fragt während oder nach dem Daily, ob es ein bestimmtes Impediment gibt, das die Fertigstellung des Tasks behindert, oder ob der Task einfach nur zu groß ist.
Umsetzung: Der ScrumMaster bittet die Leute, selbst die Tasks zu schreiben und zu bewegen und reicht dabei auch gerne die Stifte. Auch wenn es sich am Anfang unangenehm anfühlt: Der ScrumMaster bittet die Leute wiederholt höflich (oder auch direkter), die Tasks selbst zu schreiben, zu bewegen und Punkte zu machen. Irgendwann wird er es nicht mehr tun müssen, weil es die Leute selbst tun werden.

5. Flow

Es wird immer daran gearbeitet, so wenige Storys wie möglich offen zu halten und so wenige Tasks wie möglich in progress zu haben. Im Allgemeinen gilt es, sich immer in die Richtung des Optimums einer offenen Story zu bewegen und eine Taskanzahl in progress zu haben, die geringer oder gleich der Anzahl der Teammitglieder ist. Wir wissen alle, dass Multitasking ineffizient ist und wir wollen einen schnellen Feedback-Loop mit dem Product Owner erzeugen. Sobald eine Story abgeschlossen ist, nimmt der Product Owner sie ab bzw. gibt Feedback, warum sie nicht abgenommen werden kann.
Umsetzung: Der Scrum Master vereinbart mit dem Team ein WIP-Limit auf Story-Ebene oder gibt eines vor. Er sorgt dafür, dass das WIP-Limit eingehalten wird, indem er es nicht zulässt, dass weitere Storys eröffnet werden. Sobald eine Story fertig ist, sorgt er oder sorgen die Teammitglieder dafür, dass der Product Owner davon erfährt. Der ScrumMaster sorgt dafür, dass es bald Feedback gibt, ob die Story abgenommen wird oder was die Abnahme verhindert.
 
Es gäbe noch viel mehr dazu zu sagen, aber diese fünf Punkte sind für mich die Basis für jede weitere Aktion – sie erschaffen im Kern eine gesunde Daily-Kultur. Dabei ist es wirklich schwierig, diese Punkte alle im Kopf zu behalten und kontinuierlich zu kontrollieren. Es ist ein Idealbild, dem man sich im im Laufe der Zeit annähern kann. Im Laufe der Entwicklung des Scrum-Prozesses wird der ScrumMaster immer mehr seiner Verantwortung an die Teammitglieder abgeben, sobald er sieht, dass sie das Konzept verinnerlicht haben. Am Anfang jedoch muss er durch Vorzeigen, Vorleben und häufiges Erklären die Grundlage und das Verständnis für die Vorgänge schaffen, die für langfristige Produktivität sorgen.

Scrum is about Daily Planning, not Daily Status

One of my main appreciations for Scrum stems from the fact that every role has clear responsibilities:
Product Owner – his product’s ROI (Return on Investment)
ScrumMaster – his team’s productivity (hence: master of the process)
Development Team – quality and delivery
Scrum asks the Development Team to meet in front of its task board once a day in a meeting called the Daily Scrum and answer four questions:

I am not happy with the simplicity of these four questions anymore, as I am encountering too many teams that have fallen into their trap. It seems that they are leading teams to thinking as individual warriors battling through their own jungle of tasks. However, the Daily Scrum is supposed to get rid of individual status reports and move towards planning as a team.

Now how do we do turn a status meeting into an actual planning meeting?

Consider this: you as a Development Team are responsible for the quality and the delivery of your product. You know that the Daily Scrum is a short daily planning meeting in order to achieve your sprint commitment in the best possible way considering your responsibilities. If I were a Development Team member, I would simply change the standard four questions to:

Yes, these questions may be longer. Yes, they will take some teams a little bit of time to get used to.
However, I believe that the answers to these questions are the real reason why teams should spend 15 minutes of each day in front of their task board to talk about their shared delivery and the quality of their product increments.
Try it out. Let me know what you think.

Quick Retrospective

The Retrospective meeting is one of the six meetings in Scrum. The main purpose of this meeting is to get an overview of the last sprint. The Development Team has the opportunity to reflect on the process and to identify the advantages and disadvantages of the current sprint and its work procedures.
I would like to introduce you to four different types of a quick retrospective, especially focused on teams who are participating in this type of meeting for the first time. It is common that team members are not really willing to open up and express their feelings, problems, experiences at the first couple of times. Therefore, only the Scrum-Team (DevTeam, SM, PO) is allowed in that meeting, others can only join with the DevTeam’s permission. It is a learning process and the team has to adapt to this new environment of openness. However, every team is more than welcome to use these methods regularly and for other intentions, eg. a short retrospective after every meeting to analyse how helpful and productive it was. A retrospective after a sprint review would give an insight on how stakeholders experienced the meeting.

Rocket Retrospective

Procedure
It is important that you limit the time to your time box and do not extend any parts of the meeting.
The first step is called “Appreciation” and it should not take longer than five minutes because your DevTeam members just have to write down all the positive changes that had an impact on them and their project.
The second step is referred to “Collection of Information”. Every team member gets a card and a pen and he/she has to write down something that should be implemented or something that should be eliminated. Additionally, it is necessary that the person explains what exactly the problem is, why it is a problem and what are the benefits if it is implemented/eliminated. The members have to finish this task within five minutes. Afterwards, all cards are put upside down on a table, so nobody can see what is written on them. Once all cards are on the table the ScrumMaster collects and shuffles the cards.
The last step is termed “Making a Decision”. Each team member has to pick up one card of the table and take “ownership” of it. Then he/she has to write at least one proposal of action on the back of the note. It could be something as simple as writing an email or meet with another team member for 10 minutes two times a week, etc. Once everybody has finished this task, they present their card one by one with the issues and proposed follow-up actions. If some cards are similar those team members get together and put their solutions together on the back.
The ScrumMaster should keep the cards and put them on a whiteboard for everybody to see. The ScrumMaster has to bring the cards at the next retrospective for the participants to give appreciation on them.

Gifts & Hooks

Procedure
The participants have to write down their strengths on paper within 10 minutes. Their strengths are called gifts because they have to list how they could contribute to the project to make it successful. Afterwards every participant has to list every ‘hook’, which are all the things that stand in their way to work more efficiently. At the end everybody shortly presents their list and then the discussion can start on how to remove those hooks preferably.

Genie in a Bottle

Procedure
The team tracked down an ancient bottle. A genie appeared when they opened it. The genie told the team that he/she will grant them three wishes regarding changes at their workplace. And the genie will fulfil them. Now the team splits up into groups of three and list their three wishes on a flip chart and hangs it on the wall for everyone to see. Every team explains why they think those three wishes are the most important ones . The ScrumMaster asks the participants what needs to change for the wishes to become true. Now the SM has a list of the most urgent impediments he/she has to take care of. The charts will be presented at the next retrospective again to see if anything has changed in the meantime.

Hot-air Balloon

Procedure
The ScrumMaster should draw a hot-air balloon on the whiteboard and then ask the participants to write notes and stick them on the following areas: fire, hot air, and forces pulling down. The team has to identify what helps them to go higher and what pushes the project forward by placing those post-its on fire and hot air. Meanwhile, the things that hinders them to work productively are the forces pulling them down. This should not take more than five minutes. Then the team has 10 minutes left to discuss the issues.

Pliiing, Gong & TickTack: Timeboxen beenden

Dass Timeboxing toll ist, weil es uns ermöglicht, fokussiert und priorisiert zu schnellen Ergebnissen zu kommen und komplexe Umfelder zu stabilisieren, habe ich schon im Blogbeitrag “Was ist so cool an Timeboxing?” geschrieben. Dieses Mal möchte ich meine beiden Lieblingswerkzeuge vorstellen, die mir beim Timeboxing helfen.

Der Timer

Eines der wichtigsten Hilfsmittel, das ich in meiner Arbeit als Design Thinker kennengelernt habe und nicht mehr missen möchte, ist der Timer mit Zeitscheibe zur Visualisierung der Restzeit. Die Restzeit wird dabei durch eine immer kleiner werdende Farbfläche sichtbar gemacht. Das erzeugt positiven Zeitdruck und hilft, Meetings „in time“ zu einem produktiven Abschluss zu bringen. Der Vorteil gegenüber unsichtbaren Timern (z.B. Countdown auf dem Smartphone) ist, dass die Restzeit die ganze Zeit über im Raum sichtbar ist – nicht als abstraktes Zahlenwerk, sondern einfach und plakativ.
Probieren Sie es in einem Daily aus! Der Nutzen für den ScrumMaster ist groß: Es ist die Zeit, die das Meeting nach 15 Minuten beendet, nicht der „böse“ ScrumMaster, der sein Team zur Eile drängt. Es genügt ein Einwurf wie: „Ihr seht, dass wir nur noch 5 Minuten haben?“ und nach Ablauf der Zeit: „Es tut mir leid, aber unsere Zeit ist rum! Ich hatte das Gefühl, ihr zwei wolltet noch etwas sagen? Können die anderen wieder an die Arbeit gehen und wir besprechen das jetzt gleich noch?“ Schauen Sie dazu auch in den Blogbeitrag über Smart Timeboxing.
Unter Begriffen wie TimeTimer und ZeiTimer finden Sie unterschiedliche Varianten am Markt. Es gibt elektronisch gesteuerte Timer: Diese benötigen eine Batterie und haben ein elektronisches Piepsen, das bei manchen Modellen eine Lautstärkenregelung bietet. Kleinere Varianten sind meist rein mechanisch und haben daher durchgängig ein tickendes Geräusch – das kann in längeren, sehr ruhigen Meetings stören. Der Vorteil dieser Varianten ist, dass sie keine Batterie benötigen, sehr gut in das Handgepäck von uns Consultants passen und oft eine magnetische Rückseite haben, mit der sie einfach an jedem Whiteboard halten.
Laszlo Stein

Klangschale und Gong

Mein zweitliebstes Werkzeug nach dem Timer ist der Gong. Bei meinem elektronischen Timer stelle ich gerne die Lautstärke aus und nutze dafür den Gong. Bereits 1-2 Minuten vor Ende der Timebox schlage ich ihn ganz sanft, so dass ein kaum hörbarerer Ton meine Kollegen auf das Ende dieser Phase vorbereitet. Am Ende dann kommt dann ein lauter Schlag.
Es dauert maximal einen halben Tag (5-8 Einsätze des Gongs), bis Menschen auf dieses Signal trainiert sind und Sie damit die Aufmerksamkeit einfach und ohne ein lautes Wort steuern können. Große Gongs und Klangschalen haben eindeutig die schöneren, tieferen Töne. Damit sind auch leise Schläge möglich. Ich persönlich bevorzuge Gongs mit gebogenem Rand, die flachen Gongs (Windgongs) scheppern mir bei den lauten Tönen zu sehr. Aber wie die großen Timer sind sie für des Consultants Handgepäck nicht geeignet. Ich habe deshalb eine sehr kleine Klangschale angeschafft – daher das „pling“! Denn je kleiner die Klangerzeuger, desto höher der Ton. Sanfte leise Töne sind damit nicht möglich, das hohe „pling“ ist sehr durchdringend. Auch Zimbeln können den selben Zweck erfüllen.
Mein Tipp: Gehen Sie in ein Musikgeschäft (oder auch einen Esoterik-Laden, neben Räucherstäbchen und Traumfängern gibt es dort auch oft Klangschalen) und probieren Sie Ihr zukünftiges Hilfsmittel unbedingt aus. Sie werden erstaunt sein, welche Vielfalt sich beim Vergleich der Instrumente auftut und Sie werden irgendwann den Ton hören, den Sie  gerne mitnehmen möchten.
Die Kraft dieser beiden Werkzeuge liegt in der regelmäßigen Benutzung. Sorgen Sie dafür, dass der Einsatz so schnell wie möglich „normal“ wird und Sie werden ein sehr viel leichteres Leben als ScrumMaster haben.
Pliiing…

In kleinen Schritten Feedback fördern

Wie kann es sein, dass ich immer wieder aufs Neue erlebe, dass in Unternehmen keine Feedback-Kultur gefördert wird? Die Richtlinien des lösungsorientierten Feedbacks sind zwar meist auf dem Unternehmenslaufwerk zu finden, aber dort verstauben sie in ihrer virtuellen Existenz, statt real angewendet werden. Das ist wirklich schade. Feedback ist unwahrscheinlich wichtig, um das Verständnis rund um die kontinuierliche Verbesserung zu fördern. Gegenseitiges Feedback im beruflichen Kontext zu geben und zu nehmen ist elementar, um eine lernende Organisation aufzubauen.
Aus diesem Grund habe ich es mir zur Gewohnheit gemacht, (fast) nach jedem Meeting, Training bzw. Workshop das Feedback meiner Teilnehmer einzuholen und – wichtig – auch Feedback an meine Teilnehmer zu geben. Hier meine drei Lieblingsmethoden.

Feedback-Tür

Einfach 4 Post-its an die Tür kleben (++, +, -, –) und die Teilnehmer bitten, beim Verlassen des Raumes einen Punkt auf das zutreffende Post-It zu zeichnen. Das geht schnell, ermöglicht Anonymität, und ist wenig disruptiv. Ich wende das häufig bei „Feedback-Neulingen“ an, obgleich die Methode eigentlich immer passt. Man kann bei dieser Feedbacktür den Schwerpunkt auch konkret auf „Return On Time Invested“ (kurz: ROTI) legen, um herauszufinden, wie viel Mehrwert der Termin den Teilnehmern gefühlt gebracht hat. (Achtung: Bei einem überwiegend negativen Resultat sollte jedoch unbedingt eine Nachbesprechung mit den Teilnehmern erfolgen.)

Blitzlicht-Gewitter

Beginnend bei mir selbst, sagt jeder reihum einen Satz. Wie geht es mir jetzt nach dem Termin, wie empfand ich das Meeting, was fand ich gut, was hat mir gefehlt – all das sind Elemente, die hier erwähnt werden dürfen. Kleiner Tipp: Es hilft, einen „talking stick“ herumzureichen (Stift, Ball, Spielzeug o.ä.), um sowohl die Disziplin als auch den Fokus zu fördern. Und wer eine sehr redselige Truppe an Teilnehmern hat, kann ruhig zur Packung Streichhölzer greifen. Wer länger redet, als ein Streichholz abbrennt, der verbrennt sich wortwörtlich die Finger 😉

Wie war der Termin?

Bei einer kleinen Gruppe, die sich ohnedies öfter sieht (z.B. Dev.Team), lohnt es sich, nach Abschluss des Termins die ganze Runde bzw. einzelne Personen zu fragen: Wie war der Termin? Was war gut? Was sollten wir das nächste Mal anders machen? So bekommt man Feedback und der nächste Termin kann nur noch besser werden.
Habt ihr auch das Gefühl, dass eine tatsächliche Feedbackkultur im beruflichen Kontext sehr selten zu finden ist? Wie geht ihr damit um?

Der ScrumMaster – zwischen Stühlen und Fronten

Ort: Meetingraum
Zeit: 08:47
Zweck des Meetings: Sprint Planning 1
Die Beteiligten meiden Augenkontakt. Hochrote Köpfe, betretene Stille. Es geht nicht mehr weiter. Soeben haben sich zwei erfahrene Entwickler des Teams mit dem Product Owner angelegt.
Streiten. Der Product Owner fordert eine sehr große Story für den zu planenden Sprint, weigert sich jedoch, sie zu splitten. Sie in zwei zu teilen. Die Gründe dafür verstehen die Entwickler nicht. Sie verweigern das Commitment. Als ScrumMaster kann ich der Diskussion aus fachlicher Sicht schon lange nicht mehr folgen. Ich fühle mich gelähmt, frustriert, fast unfähig, zum Ziel des Meetings, dem Commitment zu führen. Klar ist mir nur eines: Die Gründe für diese Bewegungslosigkeit liegen im Verborgenen. Weit unter der Oberfläche, denn die Entwickler überzeugen sachlich und argumentatorisch auf ganzer Linie.
Als klar wird, dass es nicht mehr weitergeht, wird das Commitment um einen verträglichen Zeitraum verschoben, um eine Klärung herbeizuführen und die Gemüter zu beruhigen.
Nach ca. einer Stunde kommt der Product Owner zum Team, lenkt ein und stimmt sichtlich erbost zu, die Story doch noch anzupassen. Die Situation scheint gelöst.
Weit gefehlt.
Nach ein bis zwei Stunden taucht die Story im Computersystem wieder auf und … ist unformuliert, aber nicht gesplittet. Die Verärgerung ist den Entwicklern am ganzen Körper und vor allem an ihrer Gesichtsfarbe anzusehen. Die Entwickler bitten mich mit meinen „politischen Fähigkeiten“ – so die Entwickler – um Hilfe und darum, zum Product Owner zu gehen und letztlich zu erbitten, was er doch zugesagt hatte: Die Story in zwei kleinere zu splitten. Ich stimme zu und mache mich sofort auf den Weg.
Ich, als Fachfremder, sehe meine Chance, mir weiteres Standing beim Team zu verdienen. Nun bin ich gefordert und kann meine Fähigkeiten unter Beweis stellen. “Hoffentlich”, denke ich. Es fühlt sich wie ein bewegender Schlüsselmoment für mich und die weitere Zusammenarbeit mit meinem Team an. Ist doch sonst so schwer spürbar, was man an einem langen Tag geleistet hat.
Reden. Ich betrete das Büro des Product Owners. Leider sitzt er noch nicht beim Team. Änderung ist jedoch in Sicht. Ich begebe mich freundlich zum Product Owner und frage ihn mit einem einladenden Lächeln, ob er mir drei Minuten seiner Zeit schenken kann. Ich setze mich zu ihm und danke für die Bereitschaft, über die Story zu sprechen. Ich nehme eine ähnliche Körperhaltung ein wie er, um eine positive Stimmung zu erzeugen und bitte ihn erneut, die Story zu teilen. Es braucht drei Minuten freundliche Worte und ein wenig Small Talk. Der Product Owner stimmt zu, die Story gemeinsam mit mir so umzuformulieren, dass das Entwicklerteam umgehend bereit ist, sein Commitment abzugeben.
„Wie leicht war das denn?“, frage ich mich, kehre voller Stolz zum Team zurück und verbreite die gute Nachricht. Das Team kann nun die neu entstandene und kleinere Story committen.
Verbinden. Ich spüre Freude, Stolz und Erfolg auf ganzer Linie. Mir wird bewusst, was es heißt, ScrumMaster zu sein. Wir ScrumMaster sind das Sprachrohr zwischen den Gemütern, die Mittler zwischen den Parteien, die Mediatoren und Psychologen. Die mit den geheimnisvollen Soft Skills, die Impediments jedweder Art aus dem Weg räumen. Es wird klar, wozu es uns ScrumMaster braucht. In vielen Fällen blockieren die Dinge aufgrund von Befindlichkeiten, Ängsten, Politik oder zwischenmenschlichen Themen.
In meinem Fallbeispiel wird sehr deutlich, dass es oft nur der richtigen Ansprache oder dem Schaffen einer positiven Stimmung braucht, um ein gemeinsames Ziel zu erreichen.
Erschöpft und zufrieden zugleich sinke ich in meinen Bürostuhl und kann kurz darauf das Sprint Planning 1 mit einem einstimmigen Commitment des Teams beenden.
Was habe ich aus meinem Erlebnis mitgenommen? Zum einen wird mir klar, wie wichtig regelmäßige und qualitativ wertige Estimation-Meetings sind, an denen immer alle Teammitglieder teilnehmen. Zum anderen sehe ich die Vorteile, als externer ScrumMaster tätig sein zu können. Frei von Ängsten oder gar Abhängigkeiten kann ich mit verschiedensten Vertretern eines Unternehmens kommunizieren.

How the Grinch did not steal the Christmas Retrospective

Have you ever encountered the situation that a large part of your Scrum-Team was absent during a Sprint?! I have. It‘s called the time between Christmas and New Year‘s. As a human being living in Western Europe, I very much enjoy that time. As a ScrumMaster in charge of making sure that the Scrum-Team is productive by adhering to the Scrum process – I wouldn‘t say that I‘m too keen on December.
This January, the situation reappeared. Returning from our holidays, the Team naturally questioned the point of carrying out the Sprint Retrospective, as not even half of the Team had been present for most of the Sprint. As a ScrumMaster, I believe that leaving out the final meeting for process improvement would break the rhythm. A rhythm that is necessary in seeking continuous improvement.
So instead of cancelling the meeting, I decided to make it extra-short and not limit the time scope to the last Sprint. I took a flip-chart, wrote the header “Within our Scrum-Team, I feel …“, drew a vertical line down its middle, and wrote on the left-hand side of the paper “productive“, while on the other side “unproductive“. I then asked each Scrum-Team member to limit one’s input to overall three cards per person.
The result was fantastic.

My Feedback Door showed that the Retrospective had fulfilled the necessary criteria: it had gotten everyone involved, taken little time, we had stayed focused, and we had again found some aspects that we could and would improve in.
Try it. I‘m sure you‘ll like it.

Das Review als Nicht-Meeting

Der Sprint ist zu Ende. Das Team legt die Arbeit nieder und geht in das Review. Und schon ist sie wieder da: Die steife Meeting-Atmosphäre, in der die erlegten Stories nacheinander vorgeführt werden, ScrumMaster und Product Owner im Mittelpunkt stehen, und Anwesende ungeduldig auf den Stühlen rutschen. Wenn es ganz schlecht läuft, muss das Team sich auch noch gegenüber Product Owner und Management rechtfertigen, warum etwas so und nicht anders umgesetzt wurde.
Ein gutes Review ist wie eine gute Retrospektive: In dem einen geht es um die Auseinandersetzung mit dem Prozess, in dem anderen um die Auseinandersetzung mit dem Produkt. Alles andere sollte im Review im Hintergrund verschwinden. So ist es für das Review zum Beispiel irrelevant, wie viele Stories das Team geschafft hat. Ebensowenig sollte das Team im Review irgend etwas vorführen müssen, das keinen Nutzer interessiert. Deshalb macht der Product Owner die Abnahme der fertigen Stories bereits im Sprint und nicht erst im Review.
Für ein erfolgreiches, spannendes und wirklich kommunikatives Review kommt es auf die richtige Perspektive an:

Wie gestaltet ihr Eure Reviews? Was hat funktioniert, was nicht?

ScrumMaster schützen den Prozess oder warum klein(st)e Veränderungen Applaus bekommen

„Wir wollen das Scrum of Scrums (SoS) anders gestalten – und zwar grundlegend. So, wie es jetzt gerade läuft, funktioniert es nicht.“
Mit diesen Worten begrüßte mich vor einiger Zeit ein Company ScrumMaster, den ich zurzeit coache. Er berichtete, dass das Scrum of Scrums seit einigen Wochen bei den Teams in der Kritik stehen würde, weil die dort besprochenen Inhalte den Teams wenig Mehrwert brächten und die dort investierten 15 Minuten Zeitverschwendung seien. Es sei vor allem herausgekommen, dass nicht jedes Team jedem anderen Team etwas zu sagen habe – und schon gar nicht jeden Tag. Vielmehr gäbe es Teams, die immer mit den gleichen Teams kommunizieren und genau das müsse man verstärken und statt einer großen Plattform mehrere kleinere Gelegenheiten schaffen, bei denen diese Themenverwandtschaften besprochen werden können. Man habe sogar schon einen Namen für diese neue Form der Zusammenarbeit gefunden: Meta-Scrums. Die ScrumMaster haben sich nach Rücksprache mit ihren Teams entschieden, das SoS- Setting mit „Meta-Scrums“ zu revolutionieren.
Ich lobte meinen Coachee für diese tolle Idee und unterstütze seine Ausführungen, indem ich auf seinen nachhaltigen Inspect-and-Adapt-Drang verwies. Ich schloss mein Lob mit einem nachdenklichen Seufzer. Leicht verunsicherte fragte mich der Company ScrumMaster, ob ich mit der Entscheidung nicht zufrieden sei.
Ich antwortete: „Ja und nein.“ Ich bestärkte ihn erneut darin, immer auf der Suche nach Verbesserungen bzw. Veränderungen zu bleiben und die Teams weiter als Meinungs- und Stimmungsbarometer zu nutzen (Ask the team). Ich erläuterte ihm aber, worin ich ein Problem erkannt habe. Meines Erachtens wäre eine Big-Bang-Lösung das falsche Signal an die Teams und würde der Reputation der ScrumMaster eher schaden. Warum? Der ScrumMaster hat die Verantwortung, den Scrum-Prozess zu bewahren und alles dafür zu tun, um die Produktivität seines Teams zu steigern. Mit der Meeting-Revolution würde jedoch der Prozess in Frage gestellt werden.
Wurde wirklich alles unternommen, um das kritikbehaftete SoS zu etablieren? Nein. Auf die Frage, ob alle ScrumMaster dafür gesorgt hätten, dass der Sinn des Scrum of Scrums in den Teams verstanden wurde und damit die (Selbst-) Verantwortung der einzelnen Teammitglieder geklärt sei, musste der Company ScrumMaster sich eingestehen, dass das „interne Marketing“ für das SoS Lücken aufwies. Seine Entscheidung für einen vollständig neu aufgesetzten Prozess kam noch stärker ins Wanken, als ich ihn bat, sich nochmal vollständig von seiner gefundenen Lösung zu entfernen und meine Fragen zu beantworten: Was war gut am alten SoS-Prozess? Was hatte das SoS bislang erfolgreich gemacht? Warum sollte man das SoS unbedingt behalten? Ich intensivierte meine Lösungsfokussierung, indem ich dem Company ScrumMaster riet, auch sein ScrumMaster-Team mit dieser Denkrichtung zu konfrontieren.

Alles anders

Gesagt, getan. Zwei Wochen später wurde ich bei meinem nächsten Besuch Zeuge eines lebhaften, gut besuchten, produktiven Scrum of Scrums. Am Ende gab es sogar Applaus! Die Teams applaudierten ihrer eigenen Performance. Verrückte Welt! Was ging hier vor sich? Wurde ich gerade Zeuge des ersten Scrum-Bestechungsskandals? Wurde verdeckt körperliche Gewalt an den Teams geübt?
Nein! Natürlich nicht. Aber wie war dann diese (Ver-)Wandlung zu erklären? Es klingt fast zu simpel, aber das ScrumMaster-Team hatte lediglich zwei klein(st)e Veränderungen vorgenommen:

Durch eine Verstärkung der Team-Autonomie wurde erreicht, dass das SoS einen neuen Anstrich erhielt. Faktisch wurde an (nur) zwei kleinen Schrauben im Räderwerk des Meetings gedreht. Das Ergebnis: klein(st)e Veränderung, große Wirkung. Es ist immer wieder beeindruckend, was möglich ist, wann man Teams mit einem Mehr an Autonomie ausstattet. Genau so verstehe ich das Prinzip der Selbstorganisation. Das erste Setting des SoS hatte einen kleinen, engen Rahmen mit wenig Freiheitsgraden, wenig Spielraum für Fehler und klaren Grenzen. Mit der Zeit werden die Teams freier, sicherer im Prozess und wünschen sich mehr Gestaltungsspielraum. Agil sein bedeutet, diese Freiheit zu geben und die Voraussetzungen dafür zu schaffen, dass der Prozess weiter funktioniert.
Die agile Haltung „inspect and adapt“ hat nicht den Anspruch, im großen Stile gelebt zu werden. Viel wichtiger ist es, konsequent dafür zu sorgen, dass der Hunger nach Verbesserungen nie gestillt ist. Alles ist möglich, alles kann/darf, aber nichts muss. Entscheidungen sind immer in die Zukunft gerichtet und sind daher immer mit Unsicherheit behaftet. Sie sind jedoch genauso wenig in Stein gemeißelt und können jederzeit justiert werden – wenn wir uns den Handlungsspielraum für Veränderungen bewahren, agil bleiben. Bevor jedoch ein neuer Weg eingeschlagen wird, sollten wir innehalten und uns (retrospektiv) umschauen, um für uns festzuhalten, was gut an dem Weg war, den wir gegangen sind und was wir von dem, was gut war, behalten sollten – nutze, was existiert und, wenn es dich erfolgreich macht, dann mach es größer.

Zählen ist doch ganz einfach, oder?

Auf der Suche nach Separators (Unterbrechern zwischen den Sequenzen “Was lief gut?” und “Was kann verbessert werden?”) für eine Retro bin ich auf drei ganz einfache und doch wirkungsvolle kurze Übungen gestoßen. Sie lassen sich ohne großartige Vorbereitung und Zeitaufwand durchführen und können je nach Retro-Ziel eingesetzt werden.
 
Variante 1 habe ich letzte Woche ausprobiert. Nach dem anfänglichen „Wie jetzt? Wir sollen bis 3 zählen? Ist das Dein Ernst?“, stellte sich schnell Überraschung ein. Es stellte sich nämlich heraus, dass es nicht so einfach ist, wie gedacht.
Durch die Kombination von kognitiver und physischer Aktivität verbinden sich unterschiedliche Bereiche im Gehirn. Dadurch wird auch das einfache Zählen bis 3 zu einer Herausforderung!

Variante 1: 1, 2 … 3

ca. 3-5 Minuten – mindestens 2 Personen

  • Jeweils 2 Personen tun sich zusammen und zählen bis 3. Dabei wechseln sich die Personen immer ab (Person 1 zählt 1, Person 2 zählt 2, Person 1 zählt 3, Person 2 zählt 1, Person 1 zählt 2 usw.).
  • Nach ca. 30-40 Sekunden hin und her zählen gibt es eine neue Vorgabe: Die Zahl 1 muss jedes Mal durch z.B. ein Klatschen ersetzt werden.
  • Wieder 30-40 Sekunden später wird die 2 durch hüpfen, stampfen, Füße anheben etc. ersetzt. Als Beobachter und Spielanleiter ist es lustig, die Gesichter der Zähler zu beobachten – man kann ihnen die Konzentration quasi ansehen.
  • Je nach Belieben kann man weitere 30-40 Sekunden später auch die 3 durch eine Geste ersetzen. Nicken, auf den Tisch klopfen, einmal in die Runde drehen etc. Vielleicht hat auch einer der Zähler eine gute Idee.

Nachher kurz fragen, was beobachtet wurde, bzw. wie man sich bei den Änderungen der Vorgaben gefühlt hat. Evtl. kann man die Brücke zur aktuellen Situation (Veränderung im Unternehmen, Scrum im Allgemeinen) schlagen: einfache Regeln können schwer zu befolgen sein, Koordination, zeitliche Abstimmung und Synchronisation sind nicht einfach. Bei Veränderungen braucht es immer wieder eine gewisse Zeit, bis man sich auf die neuen Rahmenbedingungen und das Gegenüber eingestellt hat.

Variante 2: 33 / 42

ca. 5 Minuten – mindestens 3 Personen

  • Teilnehmer stehen im Kreis und rufen nacheinander (z.B. reihum) die Zahlen von 1 bis 33 (oder eine andere beliebige Nummer – je nachdem, wie lange es dauern soll).
  • Immer wenn die Zahl durch 3 teilbar ist oder eine 3 enthält, wird ANSTATT die Zahl zu rufen, gemeinsam in die Hände geklatscht (oder eine andere Geste ausgeführt).
  • Wird ein Fehler gemacht, fängt man wieder bei 1 an – bis die Gruppe es zu der vorgegebenen Zahl schafft.

Hier muss man mitdenken und den anderen zuhören. Man kann nur als Team liefern!

Variante 3: Blindes Zählen

ca. 10-15 Minuten – mindestens 5 Personen

  • Die Teilnehmer stehen im Kreis und schließen ihre Augen.
  • Es soll laut bis 10 gezählt werden. Jede Zahl darf aber nur von einer Person und einmal genannt werden.
  • Wird eine Zahl von zwei oder mehr Personen laut genannt, fängt man von vorne an.

Hier ist Kollaboration gefragt. Möglicherweise kommt das Team drauf, dass eine Person komplett alleine zählt oder sie eine bestimmte Reihenfolge festlegen.
 
Wo ich das gefunden habe, gibt es noch mehr :-): http://agiletrail.com/2012/03/27/8-great-short-games-for-groups/ – vielen Dank fürs Teilen! Oder versucht das Linie-Überqueren von David aus.
Viel Spaß beim Ausprobieren und Variieren!

How internationally distributed Teams can improve their Sprint Planning 2

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 7)
Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum
Part 6: How internationally distributed Teams can improve their Sprint Planning 1
Stephanie G.: Having discussed Sprint Planning 1, let us continue with your tipps & tricks for Sprint Planning 2. How would you conduct this design meeting?
Ina K.: I would actually say that it‘s quite similar to Sprint Planning 1, apart from the Product Owner not being present. Sometimes the meeting is off to a slow start. If that‘s the case, the ScrumMaster should get involved and start filming people (see Christof’s answer in How internationally distributed Teams can improve their Sprint Planning 1) as well as make sure that the Team members who document the meeting rotate. Once the Team members properly get going, the ScrumMaster can retreat  and remain in a position of observation. Watch the Team – are they interacting enough? Do they seem to have a common understanding? Is everyone adding to the conversation? It‘s important to keep an eye out for such things, as the DevTeam members usually don‘t. Once they actually start looking out for it by themselves, the ScrumMaster has achieved wonders.
Hélène V.: The most important aspect of Sprint Planning 2 is that the common design solution that the Team has agreed upon is visualized and can be seen by all Team members. Only if this has happened, can the distributing of Tasks on a cross-location basis begin. Some Teams think that they do not need any visualisation … all I can say is that distributed Teams who believe this myth have a much higher chance of forgetting important aspects to their design.
Kristina K.: My Team had this issue. The fact that they typed up the Tasks into an electronic tool didn‘t help either, since it sometimes seemed that only the one who did the typing also did the thinking. The fact that the know-how was so unevenly distributed was an impediment in Sprint Planning 2, too. The lack of drawing meant that there was no real common Team understanding of the design – they didn‘t talk about how to implement the User Stories, but rather talked about what singular steps were necessary to implement them.
Bernd K.: We didn‘t really have what you can call a design session either. Sometimes the Team members used the flip charts for drawing, but then I had to take a picture (since the quality of our webcam was not good enough) and send it to the other Team members. This alone would take 5 minutes, by which time the moment for entering in the design discussion was over.
Generally, I did not enjoy Sprint Planning 2 – it often stretched out over three to four hours, which is two hours longer than a Sprint Planning for a two-week sprint should be. The problem was that our electronic tool did not have a word limit for Tasks, meaning that the Team often spent ages on writing them. This did not help to bridge the geographical gap either: the Team members in Romania were rather pragmatic, while the ones in Germany could be called the „philosophers“ – wishing to specify their Tasks and over-thinking the why what, when and where. While the Team dynamic of a co-located Team would have quickly eliminated this discrepancy with smiles or a nervous look, the Romanians were hidden behind a microphone and nobody knew what they were thinking.
Kristina K.: Oh dear, that sounds quite irritating. What I started implementing after a while was to ask the various locations to prepare several design options and to then challenge each other during Sprint Planning 2. In the end, we used the best idea out of all of them and wrote Tasks for it. This ensured that everyone on the Team had actually thought about the Stories, even if they‘re no expert.
Hélène V.: Yes, that‘s what I would recommend, too. After Sprint Planning 1, the Team should do a short mapping of the areas and topics that need discussing. You could then divide up the topics for each location i.e. location A takes the module on the database approach, location B focusses on another solution etc.
Christof B.: I agree with both of you, but I think that the decision of splitting up a Team for or in preparation of Sprint Planning 2 really depends on the Team constellation. If all roles are represented at all locations, I do think that the Sprint Planning 2 can be conducted as group work – meaning that each location grabs its own User Story, does its own mini-Sprint Planning 2 and then presents it to the rest of the Team after 30 minutes. After reviewing the outcome, the entire Team writes the Tasks together. However, this is only possible if both front-end and back-end are present at all locations. This option is not possible if i.e. testers and developers are in different locations.
Stephanie G.: It is so interesting that you all recommend splitting up the meeting, since I actually used to do the same. Only I did not split it in the way of one Story in each location, but rather one person from each location formed a Team, which would together work on one Story (see Pre-SP2 Design Sessions or How to use your Time during a Sprint Change?).
Christof B.: Sprint Planning 2 should not be underestimated. It is certainly not trivial, as it can be chaotic due to the necessary interaction between the Team members. After all, it is not only a meeting, but a creative process, design thinking, architectural brain-storming etc. A lot happens during SP2. I don‘t believe that its doable over the phone. It‘s even nearly impossible to do via video conference. I really think it‘s best if each location works on its own concept during Sprint Planning 2, which is only interrupted by SoS-like coordination meetings where the whole Team gets together again. For example, a design session for 30-45 minutes, followed by 10-15mins of presentation by each location including feedback.
Deborah W.: Funny. I never had any difficulties with Sprint Planning 2, meaning that I could always really enjoy this meeting. I thought it was one of the simpler ones when dealing with distributed Teams. Maybe it was an exception, but my Team members got really involved – even across locations. It was easier than SP1, since there was always less to show. Yes, we did draw a few diagrams and design the architecture, but not for too long. The topic was pretty clear to everyone, so the meeting was concise and short.
Stephanie G.: I love it when opinions diverge as much as yours right now. So before you all get jealous of Deborah‘s Team, let me quickly sum up the main points of advice:

 

Das Daily Scrum – ein How-To für das kürzeste Scrum Meeting

Als Management Consultant bekomme ich regelmäßig die Möglichkeit, die Scrum-Implementierung in den unterschiedlichsten Branchen und Unternehmen zu beobachten bzw. zu begleiten. Interessanterweise ähnelt in der Auslegung von Scrum kaum ein Unternehmen dem Nächsten – nicht einmal, wenn es um die Abhaltung der Scrum-Meetings geht. Selbst das kürzeste Meeting im Scrum Flow, das Daily Scrum, sieht stets anders aus. Vor allem bei Scrum-Neulingen habe ich die Erfahrung gemacht, dass ein gewisser, vorher gemeinsam mit dem Coach geübter Ablauf dem neuen ScrumMaster etwas Sicherheit bietet. Mein Vorschlag sieht meist so aus:

Zweck

Synchronisation innerhalb des Dev-Teams, um das Sprintziel und somit das Release zu schaffen.

Ziel

Als Team wissen wir, was erledigt werden muss, damit die committeten Stories auf Done gesetzt werden können.

Ablauf

  1. Das Dev-Team trifft sich im Halbkreis vor dem Taskboard. Der ScrumMaster steht seitlich ca. einen halben Schritt außerhalb dieses Halbkreises. Gäste stehen komplett außerhalb des Halbkreises.
  2. Begrüßung durch den ScrumMaster – ein “Guten Morgen” reicht aus. Hier ist ein motiviertes Auftreten wichtig: Wenn der ScrumMaster als Coach des Teams schon keinen Bock hat, wie soll das Team dann erst Lust bekommen? Der ScrumMaster startet mit einer Begrüßung und macht auf die geplanten Termine für den Tag aufmerksam.
  3. Falls jemand im Dev-Team noch keine Vorstellung hat, welche Arbeit er an diesem Tag leisten kann/ möchte/wird, sollte er sich gleich anfangs zu Wort melden, damit das restliche Team ihn für potenzielle Aufgaben in Erwägung ziehen kann.
  4. Nacheinander erzählt jedes Teammitglied seinen Kollegen Folgendes:
    1. Was habe ich seit dem letzten Daily umgesetzt? (falls fertig, wird der Task von Work In Progress in Done gehängt) Falls die Aufgabe wider Erwarten innerhalb des letzten Tages nicht fertiggestellt werden konnte, erklärt das Teammitglied kurz, wodurch die Aufgabe behindert wird. Dann wird ein Punkt auf das Post-It gemacht. Ggf. wird diese Störung am Impediment Backlog, auf dem Task bzw. an der Story visualisiert.
    2. Was werde ich heute tun? Hier zieht sich das Teammitglied eine Aufgabe aus der To Do Spalte der höchstpriorisierten User Story und hängt sie in Work In Progress. Falls möglich, plant das Teammitglied gleich Pair Programming mit einem Teamkollegen bzw. Unterstützung, die er in Anspruch nehmen möchte.
    3. Was behindert mich in meiner derzeitigen Arbeit? (Visualisierung nicht vergessen…)
    4. Wo benötige ich Hilfe?
    5. Meine heutige Verfügbarkeit
    6. Das nächste Teammitglied übernimmt und beantwortet dieselben Fragen gegenüber dem restlichen Team. Dies passiert reihum, bis das Team seine Arbeit synchronisiert hat und jeder weiß, was er heute mit wem bearbeiten soll.
    7. Ist eines der Teammitglieder nicht da, übernimmt ein anwesendes Teammitglied die Punkte des abwesenden Kollegen und hängt die jeweiligen Aufgaben auf dem Taskboard für ihn um.
  5. Der ScrumMaster fasst abschließend folgende Punkte zusammen:
    1. Neue Impediments, die in diesem Daily ans Tageslicht gekommen sind und um die er bzw. jemand im Team sich kümmern wird
    2. Inwieweit sind aktuelle Impediments schon gelöst bzw. ist dafür die Hilfe des Dev-Teams nötig?
    3. Neue Termine, falls ein detaillierter Abstimmungsbedarf zwischen Teammitgliedern sichtbar geworden ist
    4. Die eigene heutige Verfügbarkeit, ggf. einer Vertretung
    5. Falls der Product Owner anwesend ist: Spätestens jetzt noch fragen, ob er weitere  Anmerkungen hat
  6. Das Burn-Down Chart wird von einem Teammitglied aktualisiert.

Alles was man für dieses kurze Stand-Up benötigt, sind ein ScrumMaster, ein Dev-Team, ein Taskboard und ein Burn-Down Chart. Gäste, vor allem der PO, sind immer herzlich willkommen. Die Rahmenbedingungen von max. 15 Minuten, täglich, stehend, selber Ort, selbe Zeit dürfen deshalb aber nicht außer Acht gelassen werden.
Was haltet ihr von diesem kleinen “How-To”? Wie sieht der Ablauf des Daily Scrums bei euch aus?!

How internationally distributed Teams can improve their Sprint Planning 1

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 6)
Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum

Stephanie G.: Now that we have already spoken about the Daily, I would say we continue with the first meeting of a Sprint – the Sprint Planning 1. Anything you would recommend to watch out for in this meeting?
Kristina K.: I sometimes find that Teams do not really discuss Stories or ask questions about them prior to Sprint Planning 1. As a ScrumMaster, one should keep an eye out for this. Particularly with distributed Teams, one should try to arrange discussions that would normally emerge in an everyday Team setting i.e. during lunch time after an Estimation Meeting. I  could imagine that the distributed setting makes the use of the Sprint Planning Checklist even more important, as it provides the Team members with a clear structure and can inform them about the Story by way of going through a set of topics. As you can hear, I find the preparation for Sprint Planning 1 – meaning the discussing and clarifying of the upcoming User Stories – to be absolutely vital. Ideally, the Team members should enter the meeting already knowing the upcoming Stories really well, so that they have lots of ideas for i.e. Acceptance Criteria and a list of questions prepared. In the best case, the meeting is shorter than the planned time-box.
Ina K.: Yes, it‘s the Product Owner‘s responsibility to give the required information to the Team in advance and make sure that it has been registered by all of the Team members before going into the Sprint Planning 1. You‘ll laugh – but yes, this also includes the access to where the Product Backlog and any additional information can be found.
Hélène V.: I recommend that – at the very beginning of Sprint Planning 1 – the Product Owner should give an overview of his expectations of what he wants the Dev.Team to have achieved until the end of the Sprint.  It is important that everyone on the Scrum Team has one shared big picture of the product. After that, there‘s always the possibility of dividing up into smaller groups either cross-location or per location and only coming together in Scrum of Scrums.
Kristina K.: And don‘t forget to take more breaks than you normally would, since it‘s much more exhausting to do it over the phone. Also, make sure to involve everyone as much as possible, so that they don‘t fall asleep at the other locations.
Christof B.: Since the Sprint Plannings are the longest meetings in Scrum, it‘s important to be visually connected as well, as it‘s much more difficult to stay focused if you can‘t connect any faces to the voices. In the past, I‘ve actually attended the Sprint Planning of Ina‘s Team and it was always interesting to see how she would use a standard webcam and play film director with it. It‘s not very interesting to see static images – the mind stops noticing them after a while – but if you do it like Ina, who used to walk around the room, film people when yawning or chitchatting, it‘s much more entertaining and more real-life, I would say.
Stephanie G.: Ina, that sounds like you had quite a lot of fun during your meetings. But now I‘m wondering – what happens during the meeting itself?
Bernd K.: We actually came together for every second Sprint change, which was very helpful. For every other Sprint change, we generally used our tool iceScrum and while the PO would present his Stories one after another, each location would follow his talk on its respective screen. Whoever then had a question could use the computer mouse to circle the part in the User Story that needed more detailled explaining. However, we always had to ask explicitly whether the persons in Rumania had any questions, as they mostly had their microphones on mute due to the background noises in their office. Furthermore, the quality of the audio tool was not ideal, which meant that we had to repeat ourselves quite often. But the Sprint Planning 1 really made the progress of the Team quite obvious: in the beginning, the guidelines where more or less dictated, yet after a few months, the Team really began sitting down and typing up Requirements, User Acceptance Tests etc by themselves.
Deborah W.: We always used flip charts. I think that if you use actual paper, it might be easier for people‘s minds to start wandering off, while on the other hand, it‘s also much easier to get them involved again. We used flip charts on both sides and had static cameras streaming the image, and while the one location was writing, the other one saw the scene on their screen. We switched to the other location’s flip chart after every Story. The cameras were excellent, so we could decipher everything. Besides, we were also connected via teleconference. A piece of advice: if you don‘t have the chance to set up flip charts in all locations, then try to involve those watching with some small tasks – for example: get them to write down User Acceptance Tests in advance. Anything to get them mentally involved.
Christof B.: Yes, and don‘t forget to send the pictures of the flip charts to the other locations afterwards, so that they can print them off and hang them up on their own walls, too.
Stephanie G.: Alright – thanks a lot. Anything else to add that we haven‘t covered yet?
Ina K.: One last thing. What I always enjoyed doing as a ScrumMaster was to ask the Dev.Team a few – perhaps simple –  questions, particularly when a Team member looked slightly lost. This way, I make sure that nobody loses face by having to ask a question that should really be clear to all members of the Team. In the past, my questions have often triggered a discussion within the Team, showing that there had still been some slight confusion. Having asked my Team members for feedback, I‘ve also learned that a lot of questions aren‘t asked, as they think that it would be embarrassing and they‘d rather wait for Sprint Planning 2 in the hope that it comes up automatically. With this in mind, I would say that asking questions from an “outside perspective” almost belongs to the ScrumMaster‘s job description under the aspect of „Protect your Team“.
Stephanie G.: Thank you for all your input. Our readers will surely appreciate that a lot. Summing up the steps, you would recommend:

  1. Make sure  that the Team comes prepared and knows the Product Backlog.
  2. The PO should start the Sprint Planning 1 by presenting the big picture.
  3. If you can use flip charts, do so – but don’t forget to send the images to the other locations.
  4. Ask (some simple) questions to make sure that everyone has the same understanding.

Alright, now what about the next meeting – Sprint Planning 2?!

Die (Über-)Lieferung von Vertrauen

Nahezu jedes Unternehmen hat Erfahrungen mit der Beauftragung von Software-Entwicklungsprojekten und das sind zum Teil schlechte Erfahrungen. Durch solche schlechte Erfahrungen haben über die Zeit immer mehr Organisationen das Vertrauen in ihre Software-Entwicklung verloren. Ich möchte nicht behaupten, dass es nur furchtbare Software-Entwicklungsprojekte gibt. Aber ich behaupte, dass wir hier zu großen Teilen in einer Vertrauenskrise leben. Diese Vertrauenskrise hat nicht nur mit enttäuschten Erwartungen zu tun, sondern auch mit einer veränderten Welt, in der Vertrauen nicht mehr über langfristige Bindungen aufgebaut wird (Vertrautheit), sondern in der Schnelllebigkeit entstehen muss. Wir brauchen also einen anderen Weg, um Vertrauen über mangelnde Vertrautheit zu entwickeln. Kommen wir nochmal zurück zu den Software-Entwicklungsprojekten und verallgemeinern kurz: Umso weniger Vertrauen besteht, desto mehr Kontrolle möchte man ausüben. Vertrauen und Kontrolle versteht man weitläufig als entgegengesetzte Pole, die nicht gleichzeitig existieren können.

Wenn wir das Problem kennen, dann kennen wir doch auch die Lösung?

Vertrauen entsteht nicht über Worte, das wissen wir bestimmt, denn das ist neuronal in unserem Gehirn so verankert. Wir benötigen also Taten, die sich einer schnelllebigen Welt anpassen. Taten, die es ermöglichen, die Erwartungen eines Auftraggebers, eines Kunden und jene von Endnutzern mit dem Beauftragten abzugleichen. Wir als Software-Entwickler brauchen Lieferungen qualitativer, anwendbarer Software in kurzen Zyklen. Mit den Lieferungen zeigen wir, dass wir verstanden haben und liefern können was beauftragt wurde. Wir zeigen, dass wir den impliziten Anspruch auf Qualität halten können. Zudem rücken wir Kunden und Nutzer in den Mittelpunkt, beziehen ihn immer wieder in die Entwicklung ein und geben ihnen eine Stimme. Wichtig dabei ist, dass wir diesen Prozess wiederholen, ritualisieren, oft durchführen, damit wir als Software-Entwickler Verlässlichkeit zeigen können. Wir zeigen, dass es kein Glückstreffer war, sondern dass wir wiederholt qualitative Software  liefern können – wir zeigen professionelles Arbeiten. Im Scrum-Prozess stehen die Lieferung und das Präsentieren der fertigen Funktionen am Ende jedes Sprints, üblicherweise nach 14 Tagen. Am Ende jedes Sprints zeigt das Scrum-Team die lauffähigen Funktionen im Review den Kunden und Nutzern.
Da wir gerade beim Kunden sind, bleiben wir kurz bei ihm. Es wäre fahrlässig, würde der Kunde die Kontrolle aufgeben. Die beauftragte Software ist relevant für die Ergebnisse des eigenen Unternehmens und soll dazu beitragen, die Zukunft des Unternehmens zu sichern. Als Kunden brauchen wir also einen Kontrollmechanismus. Diesen Kontrollmechanismus sollte man nicht an Worten, konkret Verträgen, festmachen, sondern man sollte auch hier wieder auf Taten setzen. Ein wichtiges, wenn nicht gar das Kontrollelement des Kunden sind die Reviews, die er einfordern und aktiv daran teilnehmen sollte. Das Review ist die Fortschrittskontrolle und die Kontrolle des inhaltlich Gelieferten. Zudem ist es die Kontrolle über die Schnelllebigkeit der Märkte, denn wenn Sie als Kunde agil entwickeln lassen, bekommen Sie Kontrolle über Time-to-Market und haben Einfluss auf Änderungen – idealerweise sogar “Change for free“, solange sie auch den Umfang Ihres Produkts/Projekts anpassen. Dafür sollten Sie auch einen Vertrag aufsetzen, der das Ganze widerspiegelt. Auch das ist heutzutage möglich und sogar Wunsch bei vielen Software-Entwicklungen.

Fazit

Liefern wir als Software-Entwickler regelmäßig in kleinen Abständen mit hoher Qualität, so haben wir die Chance, zerstörtes Vertrauen aufzubauen oder dem gewährten Vertrauensvorschuss gerecht zu werden. Nutzen wir Rückkopplungspunkte wie Reviews dazu den Kunden einzubinden, lösen wir sogar das Paradoxon von Vertrauen und Kontrolle zu unserem Vorteil auf. Letztlich gewinnen beide, der Kunde und die Software-Entwicklung. Die Software-Entwicklung vielleicht sogar ein wenig mehr, denn sie hat etwas zurückzugewinnen und das gilt für die gesamte Branche.

The Pros and Cons of Electronic and/or Physical Taskboards

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 4)

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?

Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Stephanie G.: You‘ve coincidentally already mentioned it in the previous round – the popular subject of whether electronic or physical Taskboards are better. Did you all use electronic tools or is there another probable option for internationally distributed Teams?!
Deborah W.: We used an electronic tool for the Product Backlog, but had a paper Taskboard hung up on the wall at the main location, which was filmed non-stop by a webcam. Thus, it was continuously displayed on a live-stream and gave the other Team members the possibility to keep the window open in the background of their computer screens at all times. Sadly, we never managed to put up a large screen on the wall. But by doing it this way, it meant that if one person moved a Task, it could be seen by everyone. In order for this to work, however, you need an excellent camera in a good position (best if screwed into the ceiling). In my case, it also only worked because the management really insisted on it – the Dev.Team had wished for  a digital Taskboard from the first Sprint onwards. However, the management had seen this as a measure for pushing its employees towards more communication.
Hélène V.: What works even better in terms of pushing employees to communicate, is to have a physical Taskboard at every location. Every task has an identification number, so that during the Daily (and outside of it, of course, too) the conversation goes a little bit like this, “Today, I am taking Task 162 on user documentation and I will need Peter’s assistance for it, as I’m not entirely sure about the necessary layout”. The number is just the reference, so that everyone at every location can synchronously move the identical Task. This way, whenever a Task is finished during the day and a new one is started, the necessary synchronisation forces the Team members to communicate immediately – in whichever way they like (chat, telephone etc.).
Ina K.: See, that‘s what I tried to introduce in my Team as well. However, it was certainly not easy trying to explain the necessity behind synchronising two manual Taskboards. In the end, we simply used the tool iceScrum and had the Taskboard depicted at all times on a large screen in both Scrum Spaces. Although the effect of pulling the Task to “done“ goes missing, it was pretty cool watching how – if someone at the other location moved a Task – it would show up simultaneously on our screen.
Stephanie G.: Your answers sound like distributed Teams still underestimate the effect of physically experiencing versus watching something move on a screen. I have heard of Teams using both types at the same time – has one of you ever worked with “double” Taskboards?
Bernd K.: Yes, I‘ve seen Teams that use physical Taskboards, and JIRA for documentation. Thus, they use both…In my opinion, one can certainly do that, but you should watch out that it doesn’t start creating an overhead. Like Ina, I also have some experience with iceScrum, which is an alright open-source tool. My Team members weren‘t keen on it, but decided to use it anyway, as they needed it for generating documentation.  In my opinion, electronic tools may be useful for Backlog grooming, generating Burn-Down Charts, providing immediate Sprint Documentation etc., but they will never fully replace the agility and motivation that a physical Taskboard can offer.
Kristina K.: I actually found the electronic Taskboard to be a nuisance. We used Urban Turtle, since the Dev.Team saw a Taskboard made out of paper as too much overhead for a distributed Team. It really was of no help during the Daily: it took long to create new Tasks, the wrong Stories were accidentally discussed, it took ages to scroll down etc. Also, the tool did not place a maximum limit on the amount of characters that could be typed within a Task. I sometimes felt as if the simplicity of Tasks was ruined and turned into electronic essays or lists of reminders. The size of a sticky note limits exactly that. Honestly, if I could build my own electronic Taskboard, I would have a very long list of requirements, such as being able to see the whole board at once, allowing the writing of dots on Tasks that were not finished on the previous day (exclamation marks just don’t do it for anyone), better print views, simplicity of moving Stories into a Sprint, being able to read the titles of User Stories immediately etc.
Christof B.: I agree with my colleagues, but in the end, I believe that it doesn’t really matter what tool you‘re using, as long as everyone in the Dev.Team can work with it at the same time. This means that i.e. physical Taskboards should really have cameras set on them at all times and electronic tools should allow all Team members to see the moving of a Task at all locations at the same time. In future, this should work much more easily, as high-quality video conference systems will become more readily available on the market. However, I also believe that the Team constellation should have an impact on the choice of tooling: if the Product Owner and maybe some consulting architects are placed at one location, and the ScrumMaster plus his Dev.Team at another, I would most certainly say that a Taskboard made out of paper suffices. A picture of the Daily can then be sent to the PO every now and again.
Stephanie G.: I believe I can sum up and prioritize your suggestions in the following way:
#1 choice: Separate Taskboards made out of paper and sticky notes hung up on the wall at each location.
#2 choice: Paper Taskboard at main location with constant live-stream to screens hung up in other locations.
#3 choice: Electronic Taskboard with instant synchronisation (no tool preference).

Der ScrumMaster im Sprint Review oder warum Ja-Aber-Sager ein Impediment sind

In meinen Beobachtungen des Daily Business von Scrum-Teams stoße ich in regelmäßigen Abständen auf ein interessantes, aber auch bedenkenswertes und manchmal ärgerliches Phänomen. Viele ScrumMaster kommen beim Sprint Review ihrer essentiellen Verantwortung als Meeting Facilitator, Change Agent und Servant Leader nur bedingt nach. Immer wieder erlebe ich, dass das Sprint Review vom ScrumMaster als eine Art Auszeit genutzt wird. Während der Product Owner u.a. allen Anwesenden das Sprint Goal vorstellt, in diesem Kontext die ausgewählten Backlog Items erläutert, einen Ausblick auf die nächsten Userstories in der Roadmap gibt und das Entwicklungsteam die Ergebnisse des Sprints vorstellt, sollte der ScrumMaster die vornehmliche Aufgabe verfolgen, das Sprint Review zu moderieren. Moderation ist jedoch vielschichtig und wird von so manchem ScrumMaster nur eingeschränkt oder gar nicht umgesetzt.
Bevor ich allerdings hier tiefer erkläre, was mir bei der Umsetzung durch die ScrumMaster fehlt, möchte ich noch einen Schritt zurück gehen und beleuchten, warum das Sprint Review ein so wichtiges Meeting ist.
 

Warum das Sprint Review so wichtig ist

Glaubt man Boris Gloger und seiner Meinung in Scrum – Produkte zuverlässig und schnell entwickeln zur Sprint Review, kann die „Bedeutung dieses Meetings nicht genug betont werden“ (Gloger, 2011, S. 176). Das Sprint Review dient der Statuserhebung im laufenden Projekt und soll im Wesentlichen eine Antwort auf die Frage geben, ob „das Team geliefert (hat), was es versprach“ (a.a.O.). In noch unerfahrenen Scrum-Teams und Unternehmen, die noch am Anfang ihrer agilen Organisationsentwicklung stehen, wird das Meeting häufig als Präsentation durchgeführt. Das Sprint Review ist jedoch mitnichten eine Veranstaltung, in der den anderen (z.B. Management, Customer, Anwender, Fachabteilungen, Lieferanten, etc.) lediglich via Power Point das Produkt gezeigt wird. Vielmehr dient die Review (engl. Bewertung) als Einladung, „die Funktionalität auszuprobieren“ (Gloger, 2011, S. 178). Auf diesem Weg erhofft sich das Team, Feedback zu bekommen, „neue Ideen zu generieren und neue Möglichkeiten nutzen zu können“ (a.a.O.).
 

Feedback(un)kultur

Ein Feedback zu geben, ist jedoch eine hohe Kunst. Dieser sind leider nur wenige wirklich gewachsen, was dazu führt, dass das, was an Feedback bei jenen (Entwicklungsteam) ankommt, die damit ursprünglich den Wunsch und die Hoffnung verbunden hatten, Anerkennung für die getane Arbeit im vergangenen Sprint zu erhalten und/oder ungenutzte Perspektiven aufgezeigt zu bekommen, oftmals ernüchternd, manchmal sogar erschütternd und vor allem demotivierend ist. Den Klassiker der Feedback(un)kultur vertritt in diesem Zusammenhang die Gruppe der Ja-aber-Sager. Die Ja-aber-Sager sind während einer Sprint Review leicht zu erkennen. Haltet Ausschau nach Kopfschütteln und übermotivierten Meldeversuchen (z.B. Handmeldung, die durch Fingerschnipsen verstärkt wird), die von paraverbalen Ungedulsäußerungen (z.B. Seufzen) begleitet werden und schließlich in einem Wortbeitrag münden, die mit der Einleitung „Ja, aber“ ein (aus Sendersicht) plausibles und unumstößliches Gegenargument (z.B. Befürchtung, unüberwindbares Problem, etc.) liefern. Die Reaktion auf ein „Ja, aber“ ist fast immer die gleiche: Man (das Entwicklungsteam) rechtfertigt sich und es entbrennt ein fieberhafter Wettstreit darüber, wer Recht hat. Schließlich und letztendlich ist es die abgelaufene Timebox, die Schlimmeres verhindert. Zurück bleibt ein kritisiertes und verunsichertes Entwicklungsteam.
 
Möglicherweise habe ich das Szenario ein wenig überspitzt dargestellt und es geht keineswegs darum zu sagen, dass Ja-Aber-Sager unrecht haben. Nichtsdestotrotz erlebe ich regelmäßig solche Beispiele in ähnlicher Ausprägung. Und weil ein „Ja, aber“ zu keiner Zeit ein konstruktiver oder gewinnbringender Einstieg in einen ernsthaften Fachdiskurs ist, sondern „ein erbitterter Kampf um die Unanfechtbarkeit der eigenen Meinung“ (http://www.gedankenzirkus.de/wordpress/die-ja-aber-dummschwatzer), muss es eine aktive Instanz geben, die Regeln aufstellt und Ja-Aber-Argumente nicht einfach zur Kenntnis nimmt und so ein Entwicklungsteam mit der Kritik – im wahrsten Sinne des Wortes –  im Regen stehen lässt. Dieser Jemand ist und kann nur einer sein: der ScrumMaster.
 
Der ScrumMaster muss wie in jedem anderen Scrum Meeting auch in einem Sprint Review seiner Verantwortung in dreifacher Weise nachkommen:

  • Als Meeting Facilitator gibt der ScrumMaster für das Sprint Review Kommunikationsregeln vor und macht diese für alle Besucher transparent. Eine Regel könnte beispielsweise lauten: “Eine Wortmeldung beginnt nicht mit „Ja, aber“.” Er tritt als Moderator des Meetings auf und sorgt unter anderem dafür, dass sich die Beteiligten ausreden lassen und verschiebt (zeitintensive) Diskussionen auf einen späteren Zeitpunkt.
  • Als Servant Leader stellt sich der ScrumMaster schützend vor sein Team. Er bestärkt es, kritisches Feedback ebenso offen und dankbar wie positives anzunehmen, ohne es zu kommentieren oder sich zu rechtfertigen: don`t feed the feedback!
  • Als Change Agent setzt er sich im Rahmen des Sprint Reviews konsequent für die Einhaltung der vorgegebenen Kommunikations- und Feedbackregeln ein, um auf diese Weise Werte wie Wertschätzung oder Respekt zu stärken und sie über die Teamgrenze hinaus zu transportieren und unternehmensweit zu etablieren.

Rezept gegen Ja-Aber-Sager

Man mag es kaum glauben. Es sind nur zwei Worte und sie können trotzdem eine vernichtende Wirkung haben. Es scheint nahezu unmöglich, noch an positive Kommunikation zu denken, wenn die Kommunikation des Gegenübers alles andere als wertschätzend ist. So schwierig muss der konstruktive Umgang mit Ja-Aber-Sagern allerdings gar nicht sein, wenn es gelingt, den eigenen Ärger über den gerade geäußerten Widerstand zu reframen (umzudrehen) und dem Gegenüber mit Verständnis für seinen Einwand zu begegnen.
 
Also: Beginnt eure Reaktionen auf das Ja-Aber-Argument mit „Das verstehe ich…“, „Da hast du recht…“ oder „Das ist ein interessanter Punkt …“ und fügt dann das magische Wort „und“ ein, bringt euer nächstes Argument oder verstärkt das vorangegangene Argument durch mehr Detailtiefe!
 
Ein einfaches “Dankeschön” ist ein weiteres, sehr erfolgreiches Rezept gegen Ja-Sager. Ja, ihr habt richtig gelesen. Gerade wurde eure Arbeit des letzten Sprints nicht besonders wertschätzend beurteilt und ihr sollt euch bedanken, z. B. mit den Worten: “Vielen Dank für dein Feedback. Wir nehmen dein Argument mal mit ins Team und diskutieren es aus. Was hältst du davon, wenn du dann einfach dazukommst und wir schauen, was das für das Ergebnis unseres Sprints bedeutet. Wann hast du Zeit für uns?“


Literatur
B. Gloger (2011). Scrum – Produkte zuverlässig und schnell entwickeln. Hanser Verlag

Die Herausforderung und das Daily Scrum

Die größte Herausforderung für das Management ist es, Zusammenarbeit zu ermöglichen. Die größte Herausforderung für die Mitarbeiter ist es: zusammenzuarbeiten.
Zwei Hypothesen? Vielleicht. Vielleicht auch nicht.
Es ist zwar die Aufgabe des Managements, Zusammenarbeit zu fördern, zu fordern, zu ermöglichen, zu verbessern – trotzdem scheitern viele am eigenen Kleindenken und den eigenen Interessen, an einem unterschiedlichen Verständnis des Ziels oder mangelnder Abstimmung und gemeinsamen Planung und Anpassung. Komplexität kann nur von mehreren Menschen in der Interaktion aufgelöst werden, daher gilt es zusammenzuarbeiten. Gelingt uns das? Weitgehend ja, mitunter immer wieder verbunden mit größeren Anstrengungen. Eine Anstrengung betrifft das Management selbst.  Manchmal gelingt es Mitarbeitern zusammenzuarbeiten, wenn ihr Management auch zusammenarbeitet. Frage: Warum? Antwort: Anreize – mein Manager beurteilt mich, ich nehme stillschweigend an, dass eine übergreifende Zusammenarbeit nicht erwünscht ist und so ergibt sich der Rest… wäre zumindest eine Hypothese. Diametral dazu: die gute Zusammenarbeit in der Chefetage zeigt mir was gewünscht ist und ich übernehme das Verhalten als selbstverständlich.
Zusammenarbeit ermöglichen heißt: Ich schaffe einen Rahmen und helfe damit meinen Mitarbeiten bei der Zusammenarbeit. Bspw. unterstütze ich meine Mitarbeiter dadurch, dass ich ihnen einen Freiraum gebe, indem sie ungestört arbeiten können, indem ich Verantwortung und eigene Mittel im Gleichgewicht halte, sie als Experten anerkenne, ihre Entscheidungen respektiere und zum Schutz dieser Punkte bspw. einen ScrumMaster zur Seite stelle. Ein ScrumMaster unterstützt das Team bei der gegenseitigen Abstimmung im Team, bei Konflikten und moderiert die Kommunikation. Neudeutsch: Er ist ein Facilitator. So jemand schafft es üblicherweise, dass ein Team besser zusammenarbeitet. Am besten unterstützt ein Facilitator sein Team täglich. In Scrum ist das sowieso der Fall und ein täglicher Anlass ist das Daily Scrum.

Das Daily Scrum

An sich ein alter Hut. Dailies gab es schon vor Scrum, gibt es ohne Scrum, gibt es mit Scrum. Ein Scrum ohne Daily ist für mich kein Scrum – ganz klar. Nun stellt sich die Frage: Was macht ein gutes Daily aus?
Aus meiner Sicht ist das nicht viel und trotzdem sieht man es zu selten. Es bedeutet Zusammenarbeit und zwar im Sinn eines: “Wir planen den Tag.” D. h. wir als DevTeam möchten, dass jeder aus dem DevTeam bekannt macht, woran er gerade arbeitet, woran er arbeiten wird und möchte, ob er Unterstützung braucht oder wo er welche geben kann. Im Daily gibt jeder seine Arbeitsergebnisse kurz und knapp weiter. Frei nach: Wenn ein gemeinsames Bild geschaffen wird, dann lässt sich leichter planen, wie man zusammen weiter vorgeht. Die Basis dafür legt ein Team bereits im Sprint Planning 1 und insbesondere Sprint Planning 2, indem im Vorfeld das WAS und das WIE besprochen wurde. War das nicht der Fall, dann tun sich die meisten DevTeams während des Sprints schwer, gemeinsam den Tag zu planen.
Das DevTeam plant den Tag und was machen ScrumMaster und Product Owner? Beide haben im Daily ihre Aufgaben: Der Product Owner muss auskunftsfähig und erreichbar für das DevTeam sein, der ScrumMaster achtet auf den Kommunikationsfluss und auftretende Hindernisse.
Das DevTeam plant den Tag, das Daily Scrum gehört dem DevTeam? Ja, im Daily Scrum sprechen die Experten mit den Experten wie sie etwas umsetzen müssen, welche Schnittstellen fertig sind, woran wer arbeitet, woran wer plant zu arbeiten, wer wo helfen kann, wer wo hängt, wo etwas blockiert ist. Das klingt eigentlich nicht schwer, trotzdem bleibt die Interaktion eine Herausforderung. Zu dieser Herausforderung gehört vor allem auch die Selbstverantwortung des DevTeams: Vor allem Verantwortung zeigen, wenn etwas nicht funktioniert. Selbstdisziplin zeigen, indem man sich beschränkt, sich zurückhält und anderen zuhört, sich an die Timebox zu halten ist da nur ein Nebeneffekt.

…und wie unterstütze ich als ScrumMaster jetzt?

Einmal Abstand nehmen, darauf achten, wer mit wem im Daily redet. Ist es nur ein Statusbericht an Stakeholder, ScrumMaster oder Product Owner? Wenn ja, dann hilft es, dass sich alle Chicken ein paar Schritte vom Team und bspw. deren Taskboard entfernen.
Gehen die Teammitglieder nicht darüber hinaus zu sagen, was sie getan haben? Wenn ja, dann sprechen Sie vor dem Daily mit einzelnen Personen über das, woran sie gerne heute arbeiten würden und empfehlen Sie ihnen, den Wunsch auch im Daily kund zu tun. Um im Daily das Team-Mitglied zu erinnern, reicht dann oftmals ein ermunternder Blick, ein Räuspern oder Augenzwinkern.
Sind die Teammitglieder unsicher, was sie im Allgemeinen sagen sollen? Wenn ja, dann simulieren Sie im Vorfeld mit den Personen das Daily. Hier hilft es, die Person zu befragen, was wichtig für die anderen sein könnte, was der folglich nächste Schritt wäre, an dem gearbeitet werden soll, was die Person am liebsten als Nächstes tun möchte oder welche Probleme derzeit existieren und wie bzw. wer hier helfen könnte?
Letztlich kann man als ScrumMaster immer nur anschubsen und inspizieren ob sich etwas verändert, Dinge ausprobieren, pro-aktiv agieren und unterstützen. Auch hier gilt: Manchmal ist es besser sich zurückzunehmen und mal nichts zu tun, also einfach nur zu beobachten. Denn nur wenn Menschen eine Wahl haben, können sie die eigene Verantwortung wählen und ausfüllen.

Team Spirit stärken – "Magic Moments" gezielt nutzen

Team Spirit, Teamgeist, ist für jedes Team, und jeden, der in Teams eine besondere Funktion bekleidet, etwas außerordentlich Erstrebenswertes. “Teamgeist ist eine starke Form des Wir-Gefühls, die sich im Gegensatz zum bloßen Wir-Gefühl in gegenseitiger Unterstützung der Gruppenmitglieder ausdrückt, während das Gruppengefühl lediglich vom gemeinsamen Ziel getragen wird.” (Zitat Wikipedia) Man kann zweifellos davon ausgehen, dass ein vorhandener Teamgeist Elemente wie Motivation, Leistungsbereitschaft und Klima positiv beeinflusst und dass damit ein synergievoller Output des Teams gefördert wird. Gerade in Scrum-Teams, in denen ein hohes Maß an Kooperation, Kommunikation und Selbstorganisation zwingend ist, stellt sich somit die Frage, wie Teamgeist durch Teamentwicklung gefördert werden kann.
Teamentwickler können als spannendes Element sogenannte “Magic Moments” gezielt einsetzen, um aktiv den Team Spirit zu gestalten. “Bei Magic Moments handelt es sich um Phänomene im Zusammenspiel von Gruppendynamik und Arbeitsebene, die sprunghaft zu einer neuen Prozessqualität führen können.” (C. Nowak, E. Neubert- Liehm)*
„Magic Moments“ haben zum einen den wunderbaren Vorteil, dass sie in der Regel spontan in der Teamdynamik und im Arbeitsprozess in Erscheinung treten. Sie können aber zum Beispiel auch in Workshops “inszeniert” werden. “Magic Moments” haben einen ganzheitlichen Charakter, sie sprechen also Ratio, Emotionen und sogar körperliche Aspekte (z.B. Gänsehaut) in der Wahrnehmung von konkreten kollektiven Situationen an. Bewusste und unbewusste Erlebnisinformationen, Gedanken, Bilder und Szenen werden einerseits aktiviert, anderseits intensiv erlebt und perspektivisch abgespeichert. Und zwar sowohl individuell, als auch im kollektiven Teamgedächtnis und fördern so intensiv und nachhaltig das Gemeinsame im Sinne von Team Spirit.

 

Beispiele für Magic Moments

 

Teamentwickler (SrumMaster, Manager, Product Owner) brauchen eine sensible und differenzierte Wahrnehmung und Beobachtung, um “Magic Moments” zu erkennen und gezielt in den Team- und Arbeitsprozess einzubinden. Praktisch bedeutet das, das was auftaucht aufzugreifen und zu thematisieren. Gefühle und Erlebnisse wie Freude, Stolz, Euphorie, Aha-Erfahrungen usw. prägnant zu machen, zu intensivieren und ihnen Zeit und Raum zu geben. Diese Phänomene können im Alltag situativ auftauchen. Erfahrungsgemäß bieten alle gängigen Meetingformate in Scrum ideale Gelegenheiten. Bei der Gestaltung von Retrospektiven, Daily Scrums, Sprint Plannings, Estimation, Teamentwicklungsmeetings oder Change Management Workshops kann man mit kreativen, lebendigen Methoden und Techniken das Entstehen von “Magic Moments” fördern. Bilder, Symbole, Metaphern, Bodenanker, Rollenspiele, Outdoor-Aktivitäten etc. sind dafür ein gutes Ausgangsmaterial. Wichtig dabei: Das Team steht im Mittelpunkt, der Teamentwickler nimmt sich zurück. Jedes Team reagiert anders und nur das Team als Kollektiv kann letztlich entscheiden, was es als „Magic Moment“ empfindet und wie es damit umgehen will. Der Teamentwickler fungiert konsequent in der Rolle als Moderator und Feedbackgeber, evtl. auch vorsichtig als „Verstärker“.
TIPP: Lernen, wie man den Team Spirit stärken kann – im Training “TeamDevelopment” mit Dieter Rösner

Die Sprint Retrospektive – es kann noch viel verbessert werden (Teil 2)

In Teil 1 Die Sprint Retrospektive – es kann noch viel verbessert werden habe ich euch die Übung „Options Run“, als eine Möglichkeit vorgestellt, den Separator in eurer Retrospektive sinnstiftend auszufüllen. Heute habe ich für euch drei weitere Ideen, wie ihr Farbe in eure Separator-Time bekommt.

Snap-the-ball

Was auf den ersten Blick kinderleicht aussieht, entpuppt sich im Tun als Herausforderung und sensibilisiert dafür, dass auch leichte Aufgaben mit Sorgfalt und einer gewissen Portion Demut zu tun sind. Fragt eure Teammitglieder nach der Übung mal, was sie gedacht haben, als ihr ihnen die Übung vorgestellt habt. Hochmut kommt vor dem Fall.
Für diesen Separator benötigt ihr eine leere, auf einem Tisch stehende Plastikflasche und einen Tischtennisball. Diesen legt ihr auf die Öffnung der Plastikflasche. Die Teammitglieder stellen sich mit ein paar Meter Abstand zu der Flasche hintereinander auf und gehen zügig (nacheinander) und mit ausgestrecktem Arm auf die Flache zu und versuchen dabei, im Vorbeigehen mit dem Finger, den Tischtennisball von der auf dem Tisch stehenden Flaschenöffnung zu schnippen. Wichtig hierbei ist, dass ihr als ScrumMaster darauf achtet, dass eure Teammitglieder ihre Geschwindigkeit nicht kurz vor der Flasche abbremsen. Ihr werdet feststellen, dass die Koordination von Arm, Hand und Finger gar nicht so leicht ist. Wer dreimal hintereinander erfolgreich war, der ist Sieger des Separators.

Blindenführung

Vertrauen in ein anderes Teammitglied zu haben, ist für den Erfolg ein Teams essentiell. Sich auf eine andere Person verlassen zu können, blind zu vertrauen, ist ein Zustand, der nicht automatisch entsteht. Bei der Blindenführung agieren die Teammitglieder paarweise. A (sehend und stumm) führt B (blind). A kann sich entscheiden, wie er B führt – an der Hand, am Arm, an den Schultern. A entscheidet, welchen Weg er mit B beschreitet und welche Schwierigkeiten (z.B. Treppe, Tempovariation) er B hierbei zutraut. Wichtig bei dieser Übung ist, dass der ScrumMaster mehrmals betont, dass der Führende die absolute Verantwortung für den Blinden trägt. Im Rahmen der Timebox soll es die Möglichkeit, sich über die Gedanken, Gefühle, Wahrnehmungen in der jeweiligen Rolle auszutauschen.

Des Rätsels Lösung

Wahrnehmung erzeugt Wirklichkeit. Diese Erkenntnis ist für Teams kein Segen. Des Rätsels Lösung sorgt nicht nur für Heiterkeit, sondern soll euren Teammitgliedern verdeutlichen, wie schwierig Kommunikation sein kann, wenn unterschiedliche Bilder (Wahrnehmungen) die eigene Perspektive verzerren und auf diese Weise, weg von der Lösung führen. Das nachfolgende Rätsel ist lediglich ein Beispiel, um euch zu inspirieren:
Du betrittst ein Zimmer. Cäsar und Kleopatra liegen regungslos auf dem Boden. Sie sind tot. Der Teppich ist feucht und es liegen Glasscherben herum. Es ist keine Waffe zu sehen. Blutspuren sind auch keine da. Was ist hier passiert? 
Eure Teammitglieder sollen nun mit geschlossenen Fragen des Rätsels Lösung finden. Ist das Team dem Rätsel auf die Spur gekommen, zeigt sich deutlich, dass Menschen in Denkrillen kommunizieren. Jeder Mensch hat seine individuellen Denkarten und Denkwelten, die durch Erfahrungen und unterschiedliche Sozialisation geprägt sind. Dies für eine gemeinsame und erfolgreiche Kommunikation zu berücksichtigen, ist die Grundlage für Kongruenz von Verständnis.
Weitere Inspirationen finden sich beispielsweise in den Black Stories.

Die Sicherheitsfrage in der Retrospektive oder der Wert eines klaren Neins

Neulich durfte ich eine Retrospektive für ein kleines ScrumMaster-Team moderieren. Wir fingen mit der Sicherheitsfrage an: Bietet diese Retrospektive den Schutz, um die eigene Meinung ungehindert sagen zu können? Ich verteilte Zettel, auf denen jeder anonym mit “Ja” oder “Nein” antworten sollte.
 
Gute ScrumMaster hinterfragen alles. Und so kam dann auch hier schnell die Sinnfrage auf: Wozu stellen wir eigentlich die Sicherheitsfrage? Manche halten sie für unnötig, andere für überflüssig. In einer kleinen Gruppe, die sich gut und lange kennt, sind Vertrauensfragen einfach nicht üblich. Und dann stellt sich natürlich noch die Frage, was denn passieren soll, wenn jemand die Sicherheitsfrage mit “Nein” beantworten sollte. Wer auf diese Punkte keine guten Antworten hat, wird ein genervtes Augenrollen seiner Teammitglieder als Antwort bekommen.
 
Umso wichtiger ist es, den Sinn der Sicherheitsfrage klar vor Augen zu haben, um sie nach außen mit Überzeugung vertreten zu können. Unter allen Scrum-Meetings ist die Retrospektive mit Abstand das intimste. Ein Team, das sonst ständig das Produkt im Fokus hat, kehrt den Blick nach innen und reflektiert darüber, wie das Miteinander funktioniert. Allein das ist schon schwer. Wenn dann auch noch negative Gefühle wie Frustration, Enttäuschung, Wut oder Neid mitschwingen, haben wir es mit Zündstoffen erster Güte zu tun. Retrospektiven, in denen Teammitglieder sich anbrüllen oder durch abfällige Kommentare tief verletzen, sind keine Einzelfälle.
 
Die Sicherheitsfrage kann solche Situationen nicht vermeiden. Aber sie gibt jedem ganz am Anfang die Chance zur Reflektion: Wie gehe ich in diese Retrospektive rein? Fühle ich mich dabei frei oder eingeengt? Diese persönliche Reflektion geht dann als Signal an die gesamte Gruppe: Starten wir alle unbeschwert in die Retro? Falls nein, müssen wir innehalten und dem Betroffenen die Chance geben, sich zu äußern. Vielleicht wünscht er sich einen anderen Moderator. Vielleicht möchte er vom Team die Versicherung haben, dass man ihn diesmal endlich ausreden lässt. Solche Wünsche lassen sich manchmal schnell klären – manchmal aber auch nicht. Und manchmal sagt auch keiner etwas.
 
In jedem Falle wird die Sicherheitsfrage dann ein zweites Mal wiederholt und die Ergebnisse vorgelesen. Dann geht es mit der Retro weiter – auch wenn die “Neins” noch nicht verschwunden sind.
Wozu dann überhaupt die Sicherheitsfrage? Jeder im Team weiß nun, dass zumindest ein Mitglied sich in dieser Retro nicht frei fühlt. Und auch das ist ein Ergebnis sowie eine äußerst wichtige Information, die alle zum Nachdenken anregen sollte. Ohne die Sicherheitsfrage fiele es gewiss leichter, über Umstimmigkeiten hinwegzuschauen. Die Retro ist aber kein Heile-Welt-Spiel, sondern eine ernsthafte Auseinandersetzung. Deshalb brauchen wir die Sicherheitsfrage.
 
Weitere Tipps & Tricks zum Beispiel hier: http://www.akashb.com/blog/2012/05/28/agile-retrospectives-the-safety-check/

Die Sprint Retrospektive – es kann noch viel verbessert werden (Teil 1)

Die Retrospektive gehört zu den Nachzügler-Meetings im Scrum-Flow. Erst 2004, auf dem Scrum Gathering in Wien (vgl. Gloger, 2011, S. 180f.), erlebte die Agile Community die eigentliche Geburtsstunde des Meetings und es etablierte sich fortan zum unverzichtbaren Bestandteil des Scrum-Prozesses, weil Retrospektiven, fragt man Esther Derby, vor allem eins mit Teams tun: „Keep improving“ (Derby & Larsen, 2006, S. 2).
 
Retrospektiven haben das Ziel, auf der Grundlage des Erlebten (des vergangenen Sprints), Maßnahmen für die Zukunft (den nächsten Sprint) zu generieren, die sowohl die Arbeitsabläufe verbessern sowie  störende Blockaden (Impediments) identifizieren, analysieren und beheben sollen. Um das zu erreichen, stehen zwei Fragen im Fokus der Betrachtung: „Was lief gut?“ und „Was könnte verbessert werden?“ – Erfolgsfaktoren und Potentiale.
 
In meinen täglichen Beobachtungen erkenne ich sowohl in der Moderation als auch in der methodisch, didaktischen Führung des Meetings jede Menge „Luft nach oben“. In diesem Beitrag möchte ich daher das Augenmerk auf die oben bereits erwähnten Schritte 3 (finde funktionierende Prozesse) und 4 (finde nicht-funktionierende Prozesse) (vgl. Gloger, 2011, S. 184ff.) richten. Hier offenbart sich leider ein Trend, den ich nicht nur nicht gutheißen kann, sondern der meines Erachtens auch für eine gewinnbringende Retrospektive kontraproduktiv ist.
 
Die sechs Schritte einer erfolgreichen Retrospektive setzen einen stringenten und lückenlosen Ablauf voraus:
 
Schritt 1: Schaffe Sicherheit
Schritt 2: Sammle Fakten
Schritt 3: Finde funktionierende Prozesse
 
Separator


Schritt 4: Finde nicht-funktionierende Prozesse
Schritt 5: Leite Veränderungen ein
Schritt 6: Entscheide über die Wichtigkeit
 
Zu diesem gehört, dass zwischen Schritt 3 und Schritt 4 ein Zwischenschritt, der sogenannte Separator, eingesetzt werden soll. Dieser hat den Zweck, den „gemeinsamen Denkraum“ (a.a.O, S. 188f.) kurz zu verlassen, um eine spürbare Trennung der beiden Teile „gut“ und „verbesserungswürdig“ zu erreichen. Boris Gloger empfiehlt dafür kreative Arbeitstechniken und betont, dass er mit dem Zwischenschritt „keine Kaffeepause“ meint. Leider ist es aber allzu häufig so, als würde man zu einem kleinen Kind mit erhobenem Zeigefinger sagen: „Fass die Herdplatte nicht an!“
 
Der Separator wird entweder für eine Kaffeepause genutzt oder es wird einfach darauf verzichtet. In beiden Fällen, im zweiten noch mehr als im ersten, verstärkt sich das Risiko, dass die positiven Effekte und Energien (rewards) aus Schritt 3 nicht konserviert werden und durch die nachfolgende Rückschau der nicht-funktionierenden Prozesse, also negative Erlebnisse (threats), sich sogar neutralisieren können. Daher lautet mein deutlicher Appell an alle ScrumMaster und Retrospektiven-Facilitator:



Baut in eure Retrospektiven einen Separator ein, der mehr als ein Durchlüften der Räumlichkeiten ist oder Zeit für einen Toilettengang lässt!
 
Ich möchte euch eine etablierte und gleichzeitige aufheiternde und alle Beteiligten aktivierende Kreativtechnik für euren nächsten Separator vorstellen: den Options Run.
 
Was brauchst du dafür?

  • Einen 5 Meter langen Streifen aus Kreppband (auf dem Boden als Linie geklebt)



Was hast du als ScrumMaster zu tun?

  • Alle Teammitglieder inkl. ScrumMaster stehen an einem Ende der Kreppbandlinie (Start). Die Linie versteht sich als Brücke über einen Fluss. Ziel ist es, ans andere Ende des Ufers zu gelangen. Allerdings gibt es für die Überquerung Constraints.

 
Constraints

  • Der ScrumMaster muss als Letzter ans andere Ufer.
  • Jedes Überqueren ist mit einem Lob (Applaus) zu versehen und verdient die Wertschätzung des gesamten Teams.
  • Bei jeder weiteren Überquerung muss eine neue/andere/eigene Art der Überquerung gewählt werden.

 
Sinn und Zweck des Option Runs

  • Wertschätzung der Leistung jedes Teammitglieds
  • Jede (neue) Lösung ist gut, richtig, besonders. Es gibt kein Falsch!

 
Variante

  • Das Team wählt die kreativste Form der Überquerung aus und der Sieger erhält einen kleinen Preis.

 
In Die Sprint Restrospektive – es kann noch viel verbessert werden (Teil 2) stelle ich euch noch andere kreative Ideen für energiereiche Separatoren vor und weise auf weitere typische Fallstricke in der Retrospektive hin. 
 
 
Literatur
 
Derby, E. und Larsen, D. (2006). Agile Retrospectives: Making good teams great. The Pragmatic Programmers.
Gloger, B. (2011). Scrum – Produkte verlässig und schnell entwicklen. Hanser.

Sprint Planning with geographically dispersed teams located in different timezones

When working with geographically dispersed teams (where the members of one team are spread across different locations), the team members and I find it rather difficult to keep focused on the phone during the entire Sprint Planning 1 and 2. Even more so when considering the different time zones. As one part of the team comes in right after lunch, the other part is nearly on their way home, while the third part is starving for lunch. In this situation, the retrospectives showed that the quality of the Sprint Planning 2 and the common understanding of the design ideas should be improved. Additionally, I (as ScrumMaster) wished to improve the team members’ communication and their participation within both Sprint Plannings. For reasons of seniority, experience and cultural differences, it was always the same few members who participated in the discussions.
 
Noticing a possibility for killing two birds with one stone, I changed the set-up of the Sprint Plannings – despite some team members complaining about long planning sessions and that Scrum was creating too much overhead ;-). So I changed the Sprint Plannings in such a way that they would not be held within one day, but split into two different days, using the morning in Europe for the three hours overlap of working time. That gave us the opportunity to use two full hours for the Sprint Planning 1 and 2 on each day.
 
Furthermore, to increase the participation of the team members, I asked all members working in the same location to hold their own smaller version of a Sprint Planning 2 on the day or morning before the session with the whole team. By doing so, I automatically created some competition amongst the dispersed team to come up with the „best“ solutions and share them with the others. This was particularly interesting, as I had not split the pulled stories for the Sprint Planning 2, but instead asked every location to put forward a design for every story. Now that we had three different solutions on the table in the Sprint Planning 2, the team was able to discuss which one would be preferred or which combination of the different design solutions made the most sense. Since all members had participated in the design of a solution, their involvement and the variety of possibilities for implementation clearly increased. At the same time, the meetings were not as long and stiff anymore.
 
Plus: The additional time now available after the Sprint Planning 2 or before the Sprint Planning 1 could now be used for working through the feedback from the review, continuing on the development of technical topics, or even refactoring 😉
 
What advice do you have for working with geographically dispersed teams?
 
 
See also the interview series by Stephanie Gasche about internationally distributed Scrum-Teams.

Die Retro- als Introspektive

Ein Zweck der Retrospektive ist das Erarbeiten von Maßnahmen, um Teams produktiver zu machen. Wer aber die Retro allein auf Maßnahmenfindung begrenzt, der greift methodisch zu kurz. Eine gute Retrospektive schafft den Raum, um ein Team in sich gehen zu lassen und über die eigene Zusammenarbeit nachzudenken. Deshalb macht es Sinn, in regelmäßigen Abständen „Team-Retros“ durchzuführen, in denen nicht Maßnahmen, sondern die Selbstreflektion im Vordergrund stehen. Hierzu gibt es viele Übungen – heute möchte ich zwei davon vorstellen (die übrigens gut zusammenpassen):
 

Team-Ranking

Lege fünf DIN-A4-Seite als Skala auf dem Boden aus, beschriftet von 1 bis 5. Schreibe die Bedeutung dieser Zahlen als Erklärung an ein Flipchart:
 
5: Wir sind das beste Team der Welt!
4: Ich bin sehr zufrieden damit, wie es bei uns läuft.
3: Ich bin meistens zufrieden damit, wie es bei uns läuft.
2: Ich bin hin und wieder zufrieden damit, wie es bei uns läuft. Es könnte aber viel besser sein.
1: Ich bin gar nicht zufrieden damit, wie es bei uns läuft.
 
Erkläre die Übung dem Team und bitte alle Mitglieder, sich auf der Skala zu positionieren, indem sie sich dort aufstellen, wo sie sich jeweils sehen. Die Ergebnisse können ganz unterschiedlich ausfallen: Manche Teams stehen dicht gedrängt und alle behaupten dann, zwischen 3,75 und 4,25 zu stehen. In anderen Teams gibt es zwei oder drei „Ausreißer“, die bewusst Abstand markieren wollen, weil sie etwas loswerden wollen. Mir ist ehrlichgesagt die zweite Konstellation lieber, weil dann die unterschiedlichen Perspektiven auf die Teamarbeit deutlicher werden.
 
In jedem Fall aber gilt: Das Ergebnis akzeptieren (keine Suggestivfragen!), am Flipchart visualisieren (z.B. anhand von ausgefüllten Balken) und jedes Teammitglied bitten, eine kurze Erklärung zu seiner Stellungnahme abzugeben („ich stehe hier, weil…“). Eventuelle problematische Aussagen (z.B. negative Kommentare über Team-Mitglieder oder über den gesamt Prozess) sollten vom ScrumMaster kurz aufgegriffen und dann im späteren Teil der Retro („was wollen wir verbessern?“) unbedingt noch einmal thematisiert werden. Sonst wird das Team die Retro mit einem unguten Gefühl verlassen.

Nai-Kan

Bitte jedes Team-Mitglied, die folgenden drei Fragen für sich zu bearbeiten:

  1. Was hat das Team für mich gemacht?
  2. Was habe ich für das Team gemacht?
  3. Welche Schwierigkeiten habe ich dem Team bereitet?

Wichtig: Den Zeitraum vorher klären. Wenn ein Team zum Bespiel seit vier Sprints zusammen ist, dann sollte es die Fragen für diesen Zeitraum beantworten. Er kann aber durchaus länger sein – etwa für ein gesamtes Release (dann im Rahmen einer größeren Release-Retro).
 
Die Nai-Kan-Übung fällt nicht leicht. Für viele sind Teams nüchterne Arbeitsgemeinschaften, und dort ist es einfach nicht üblich, sich solchen Fragen zu stellen. Doch genau deshalb lohnt es sich, die Auseinandersetzung anzubieten. Die drei Fragen kreisen um Nehmen und Geben, sie sollen uns zur Reflektion über unsere Rolle in der Gruppe motivieren.
 
Teams, die schon länger zusammen sind, können von dieser Übung ebenfalls profitieren. Weil sie eingespielt und die Rollen fest verteilt sind, neigen sie häufig dazu selbstgefällig zu werden und den kritischen Blick zu verlieren. Diese Übung, die auf Geben und Nehmen fokussiert ist, stellt jedem Mitglied die Frage nach dem Gleichgewicht innerhalb des Teamgefüges.
 
Allerdings musst du dich als ScrumMaster bei der Übung wohlfühlen. Du musst davon überzeugt sein, und auch bei skeptischen Rückfragen dem Team erklären können, warum du diese Übung mit ihnen durchführst. Da die Fragen persönlich sind, bietet es sich an, sie zunächst im kleinen Forum vorzustellen (etwa dem Sitznachbarn), bevor sie ins Plenum gehen. Anschließend kann jeder für sich eine persönliche Maßnahme herausarbeiten, die aus der Beantwortung der Fragen 2 und 3 z.B. im Sinne des Starfishes (mehr davon; weniger; weitermachen; anfangen; aufhören) formuliert sein können.
 
Literatur
Esther Derby, Diana Larsen: Agile Retrospectives. Making Good Teams Great. 66-69.
http://de.wikipedia.org/wiki/Naikan
 

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

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

Menschliche Grundbedürfnisse dürsten nach dem Optimum

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

Vier psychologische Grundbedürfnisse

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

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

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

Das Bedürfnis nach Bindung

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

Das Bedürfnis nach Orientierung und Kontrolle

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

Bastelecke Sprint Planning 2

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

Was wollen wir mit dem Sprint Planning 2 erreichen?

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

Diagramme und Skizzen

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

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

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

Was braucht das Team im Sprint Planning 2?

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

Fazit

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

Willkommen zum Candle Light Dinner: Sprint Planning 1

In der Produktentwicklung im Allgemeinen und in der Software-Entwicklung im Speziellen sprechen wir davon, komplexe Systeme zu entwickeln. Komplexe Systeme definieren sich bspw. so: “.. each agent in a system is ignorant of all behaviors of the system. If an agent ‘knew’ the entire system, the complexity of the whole system would have to reside in that agent.” (Jurgen Appelo: Management 3.0: 2010: 108-109) Die ursprüngliche Definition stammt von Paul Cilliers und nennt sich Darkness Principle. Ausgehend von dieser Definition komplexer Systemen benötigen wir die Sicht von möglichst vielen Beteiligten, um einen einigermaßen vollständigen Blick entstehen zu lassen. Konkret: Wir benötigen nicht die Stimmen und Blickwinkel weniger oder eines Einzelnen, sondern die des gesamten Teams und der wichtigsten Beteiligten.
Genauer betrachtet heißt das auch: Wenn wir komplexe Systeme betrachten und abbilden möchten, tappen wir zu großen Teilen im Dunkeln. Wir haben einen dunklen Raum, möchten ihn erhellen und haben nur Kerzen zur Verfügung. Jede dieser Kerzen hat das Potential, einen gewissen Teil des Raums auszuleuchten, einige strahlen heller, andere flackern. In jedem Fall gilt es alle Kerzen zu entzünden, um möglichst viel zu erkennen. Genau das machen wir im Sprint Planning 1: Wir entzünden möglichst viele Kerzen.
Wir arbeiten in Teams zusammen, um das möglichst beste Bild entstehen lassen zu können. Etwas entstehen lassen, für das einer Person die Fähigkeit und der Blickwinkel fehlen. Dass sich das Potential mehrerer Menschen entfaltet, ist nicht immer einfach, jedoch eines dürfen wir nicht vergessen: Das Ergebnis unserer Interaktion ist unser Ergebnis von Zusammenarbeit.
Hinter dem Sprint Planning 1 versteckt sich die Idee, Menschen eine Stimme zu geben. Wir brauchen den Blick und die Geschichten von allen, damit wir verstehen, was die Anforderungen an das System sind. Es ist notwendig, dass jeder seinen Teil zum Ganzen beiträgt und dass dieser Beitrag gehört werden muss, damit wir erfolgreich zusammenarbeiten können. Es ist die Weisheit der Vielen, auf die wir zugreifen und wir müssen zulassen, dass jeder Informationen und Wissen besitzt, das für unsere nächste Mission unabdingbar ist. Diese Information nicht einzuholen wäre nicht nur respektlos – es wäre verschwenderisch und riskant.
Damit eine Diskussion entsteht, benötigen wir einen Anlass zur Diskussion. Wenn alles vermeintlich klar ist, ergibt sich wenig Diskussion, wenig Dialog. Doch genau den brauchen wir, damit wir klären können, was  interpretiert und was verstanden wird. Treffen wir auf zu genaue Instruktionen, so verhindern die Details oftmals, dass sich Menschen darüber austauschen. Wir benötigen also für einen gelungenen Austausch, für ein gelungenes Sprint Planning, auch eine gewisse Instabilität in den Anforderungen an unser Produkt. Genau so viel, dass der Dialog entstehen kann und genau so viel, dass es zum Zeitpunkt der Umsetzung keine Unterbrechung gibt. Herausfordernd, ja, und trotzdem kein Ding der Unmöglichkeit.

Wie wird das Sprint Planning zum Candle Light Dinner und nicht zum Drive-In beim nächsten Junk-Food-Palast?

Zunächst hilft es, nicht zu früh loszufahren und das Ziel sollte beim Losfahren nicht zu weit entfernt sein. Sonst trifft man auf dem Weg schon auf den nächstbesten Junk-Food-Palast oder ist zu früh im Restaurant – wir wollten ja ein Dinner und kein Lunch. Also lieber etwas später und dennoch rechtzeitig losfahren. Jetzt heißt es, richtig und rechtzeitig abbiegen und noch vor dem Eintreffen beim Restaurant alle Schlüsselfragen zum Menü geklärt zu haben. Hier nimmt man am besten auch alle Gäste mit ins Boot, d. h. jeder sollte vorher die Karte gesehen und gelesen haben, um Wünsche und Anmerkungen zu äußern. Nun können wir besten Wissens und Gewissens eintreffen. Im Restaurant angekommen, verhandelt und entscheidet man noch kurz über die Details: Wer sitzt wo, was möchten wir trinken, was essen wir und was gibt es zum Dessert? Während wir das tun, zündet unser Kellner die Kerzen am Tisch an und wir gleiten einem schönen Abend entgegen.

Should internationally distributed Teams be avoided?

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 2)

 
The sequel to Does distance cancel out the efficiency of internationally distributed Teams?
Stephanie G.: Internationally dispersed Teams sound pretty exhausting. Are you telling me that you‘re no fans?
Hélène V.: I think that I can speak for everyone present that putting together internationally distributed or dispersed Teams – although dispersed is even worse – are not what we would advise managers to do. Yes, Scrum can be applied in such situations – but a lot of the fun and simplicity are taken out of the process. It is a challenge, which – of course – we are all willing to take on, but if a manager would ask me for my opinion, I would certainly advise the setting up of co-located Scrum Teams. (nodding all around)
Bernd K.: If I were a manager and I had to choose between training people on-site or investing in skilled staff abroad, I would certainly take the ones that are on-site.
Deborah W.: I second Bernd. But one has to admit that the wonderful thing about agile methods and Scrum is that they offer great practices, such as Pair Programming, for transferring and building up the skills of one‘s employees. However, this really depends on the product, the people, the necessary skills, as well as the available time and budget.
Kristina K.: Time‘s the word. If we‘re talking about a project where certain skills will only be necessary for a few months, it would probably be smarter to buy this kind of know-how. If we‘re talking about three years, then I would go for the more sustainable option of ensuring that the skills are available on-site.
Ina K.: In the case of three months, I would also aim at having the people with the necessary qualifications and competence flown in and sit together with the rest of the Team. After all, there will always be a small percentage of Team achievement that cannot be reached due to it being distributed.
Hélène V.: I second that. As a manager, it is important to figure out how to motivate the naturally distributed Team members to spend the necessary time together in one location. If one takes your case for example, Stephanie, one could have offered the German and Indian Team members a salary for 12 months and the challenge for the entire Team to complete the product within one year. The Team spends that time together in the third location Vietnam and if they finish the product earlier, then the 12-month salary is still paid, but the Team members can return home early. This is just an example – it’s up to the managers to think about ways to motivate their Team members to get together in one location and maximise their productivity.
Stephanie G.: I like that idea. But it again points to the general opinion that you would all strongly recommend to avoid creating distributed Teams?!
Christof B.: As Hélène has already said,  if we were given the choice as managers, we would try to keep the Team in one place. There are, however, a few scenarios that I could live with. Firstly, the ScrumMaster would have to sit with the Dev.Team. If the Product Owner is not able to do so, he will simply have to start travelling more frequently in order to build up a good relationship. He would furthermore have to offer a dedicated hour per day (at least), where he is strictly available to the Team for answering any questions and give information or feedback. The other important thing to watch out for when splitting a Team is that it should be equally divided. It is super difficult when there are six persons sitting on one end of the telephone receiver, and only one or two on the other.
 
Stephanie G.: Thank you. So to sum up your statements, we may advise managers to


Am Ende wird alles gut oder warum Lieferungen ständig mit heißer Nadel gestrickt sind

Der aktuelle Sprint neigt sich dem Ende zu. Es ist Reviewtag. Nur noch wenige Stunden bis zur Demonstration der Sprintleistung. In den Teams herrscht rege Hektik. Ein Blick auf die Sprint Backlogs der einzelnen Teams verrät, dass kaum ein Team schon wirklich „fertig“ ist. Auf Nachfrage erhalte ich Antworten wie: Wir sind fast fertig oder zwei Tests laufen noch nicht rund oder eine Doku steht noch aus, die dann noch gereviewt werden muss. Auf den letzten Drücker erfolgt dann noch die Abnahme des Product Owners und mit heißer Nadel bekommt die noch nicht ganz fertige Userstory ihren grünen Haken, als Zeichen dafür, dass sie erledigt (done) ist. Kurzum: Ich beobachte immer wieder das gleiche Phänomen. Die Lieferung des versprochenen (Commitment) Geschäftswerts kommt fast immer in allerletzter Sekunde. In vielleicht fünf (und da greife ich schon hoch) von hundert Sprints sehe ich Entwicklungsteams, die am Tag der Review nichts mehr für die aktuelle Lieferung tun müssen: Es (potential shippable increment) ist getestet (nicht nur unit-getestet), die Funktionalität ist integriert.
 
Grundsätzlich spricht nichts dagegen, wenn eine Userstory, mit heißer Nadel gestrickt, auf den Punkt genau fertig wird. Das spricht auch für das Team. Es hat, wie versprochen, Qualität geliefert und kann gemeinsam einen Erfolg einstreichen. Interessanterweise äußern sich die Teams nahezu einstimmig über die Gründe, warum alles immer auf den letzten Drücker fertig wird: in den ersten Tagen des Sprints wird getrödelt. Man hat gerade einen Sprint hinter sich gebracht und schon soll man wieder Vollgas geben. Das fühlt sich so an, als säße man im Hamsterrad. Darüber hinaus ist man zu Beginn eines Sprints noch nicht so mit der fachlichen Materie vertraut, wie während des Sprintzyklus oder zum Ende hin. Das heißt, dass gerade am Sprintanfang noch viele Dinge unklar sind.
 
Einerseits ist es also verständlich, dass die Teams die ersten Tage im Schongang unterwegs sind und die Arbeitsatmosphäre eher an das sprichwörtliche „Kommst du heut`nicht, kommst du morgen“ erinnert, als an Erich Kästners „Es gibt nichts Gutes, außer man tut es (Anm. d. Verfassers: und zwar am besten sofort).“ Allerdings sinkt mit steigendem Zeitdruck die Qualität der Arbeit und damit auch die Leistungsfähigkeit. Schon vor 100 Jahren wurde das Yerkes-Dodson-Gesetz, das bis heute als allgemein gültig akzeptiert wird, niedergeschrieben. Es besagt, dass „die menschliche Leistung bei einer mittleren Erregung die besten Werte erzielt, bei zu geringer und zu hoher Erregung die schlechtesten. Um die optimale Leistungsfähigkeit ausnutzen zu können, ist eine mittlere Aktivierung und ein wenig Druck, um wach zu werden und in Schwung zu kommen, zu begrüßen. Je stärker der Druck jedoch steigt, desto rapider nimmt die Leitungsfähigkeit ab“ (Kratz, 2011, S. 28).
 
Was kann ein Scrum-Team nun unternehmen, was kann der Einzelne unternehmen, um beiden Seiten der Medaille gerecht zu werden?

Gegen Aufschieberitis

Aufgaben wachsen in dem Maße, in dem man sie vor sich herschiebt. Bleiben Dinge unerledigt, dann wächst nicht nur die Liste der Erledigungen, sondern das Unerledigte sitzt uns immer stärker im Nacken und übt einen unangenehmen Druck aus. Deshalb kann ich nur die Empfehlung aussprechen, den großen Frosch zuerst zu vertilgen („Eat the frog“) – jeden Tag. Fangt mit den Sachen an, die am wichtigsten sind und die am meisten Arbeit machen, auch, wenn sie noch so unbeliebt sind. Es wird euch den Druck nehmen. Und macht es nicht allein (nicht selten beobachte ich, dass die Anzahl der Reviews zu Beginn leider sehr gering ist). Geteiltes „Leid“ ist schließlich nur halbes. Und noch was: Eat the frog and reward yourself. Möglicherweise kommt der große Brocken erst mitten im Sprint, weil man beim Planen etwas unterschätzt hat. Auch dann gilt das gleiche Prinzip:
 

Der Fehler als Leistung, der Fehler als Chance



Winston Churchill hat mal gesagt: „Perfektion ist Lähmung.“ Und er hat recht damit. Die Hauptursache für Aufschieberitis ist laut Professor Lothar Seiwert, Zeitmanagement-Guru, unser Perfektionismus (vgl. Seiwert, 2009, S. 198): „Wer immer alles perfekt erledigen will, der wird nie fertig und ist somit gezwungen, immer mehr Aufgaben immer länger vor sich herzuschieben. Natürlich wollen wir alle unser Bestes geben. Doch: Muss deshalb immer alles perfekt sein?“
 
Software-Entwickler neigen ebenso wie Ingenieure zu einem starken Hang zur Perfektion. Es muss alles 100 Prozent vollkommen sein. Alles, was weniger ist als alles, ist definitiv zu wenig. Und genau das führt dazu, dass man den Fokus verliert und nicht mehr unterscheiden kann, ob etwas (überhaupt noch) wirklich wichtig und für eine Lieferung überhaupt essentiell oder gar vonnöten ist (Definition of Done). Hier würde ich mir eine intensivere Kommunikation mit dem Product Owner und seinem Team wünschen. Akzeptanzkiterien auf der Basis der Requirements müssen klar definiert sein und sollten vor allem als Minimalanforderung besprochen werden: Das möchte ich mindestens haben. Wenn ihr das habt, dann gebt Bescheid. Gebt euch untereinander öfter Feedback – insbesondere bei euren Reviews. Hinterfragt euer Handeln! Tun wir noch das Nötigste oder ist es schon mehr, vielleicht schon zu detailliert, zu viel.

Review am Freitag?

Ein von mir äußerst geschätzter Entwickler und Mitglied eines sehr produktiven Scrum-Teams äußerte sich zu der oben diskutierten Problematik dahingehend, dass er sich am Ende eines Sprints zwar zufrieden fühlt, aber er sei auch ausgelaugt und “satt”. Ihm würde es helfen, wenn die Review an einem Freitag vonstatten ginge. Man könne so den Sprint auch tatsächlich abschließen. Nach einem erholsamen Wochenende würde dann am Montag das nächste Sprint Planning folgen und man wäre für neue Aufgaben ausgeruhter und bereit.
 
Was denkt ihr? Seht ihr das auch so? Wie sind eure Erfahrungen mit Lieferungen, die auf den letzten Drücker passieren?
 
 
Literatur


Kratz, Hans-Jürgen (2011). Aufschieben. Nein danke! Tu`s gleich! Die beste Strategie für mehr Lebensqualität. Walhalla.
 
Seiwert, Lothar (2009). Noch mehr Zeit für das Wesentliche. Zeitmanagement neu entdecken. Goldmann.

Vorweihnachtsretro

Hat etwa noch jemand nicht genug von dem vorweihnachtlichen Trubel und ist noch auf der Suche nach einer Idee für die letzte Retro vor Weihnachten? Das Thema Tage bis zum Fest, der Weihnachtsbaum und Silvester drängen sich da quasi auf. Ich habe mir die Retro vom letzten Jahr noch einmal vorgenommen und versucht, auch für die Elemente Timeline und Verbesserungsmöglichkeiten vorweihnachtliche bzw. endjährliche Übertragungen zu finden. Vielleicht liefern die nächsten Zeilen ein paar Ideen. Je nach Team und Situation kann natürlich mit den Fragen, bzw. Beschriftungen der Kerzen und Kugeln etwas variiert werden.
Fragt doch mal euer Team, ob es die Kreise für die Retro nicht etwas erweitern will. Mit wem wird eng zusammengearbeitet? Wen könnte man zu einer etwas größeren Rückschau einladen? Wen möchte man  besser kennenlernen? Vielleicht wäre es ausnahmsweise auch mal an der Zeit, den ScrumMaster zur Retro einzuladen? Bestimmt auch für das PO- oder SM-Team mal eine schöne Abwechslung.
Zugegeben, es braucht etwas Vorbereitungszeit, aber es lohnt sich bestimmt.

Timeline – 24 Zeiteinheiten bis Weihnachten

Gemalte oder echte Weihnachts-Socken, Kärtchen, Geschenke, Zweige, Candy Canes etc. mit den Zahlen von 1 bis 24 beschriften und der Reihe nach im Raum aufhängen. Je nachdem, wie lange der betrachtete Zeitraum ausfallen soll, steht jede Zahl für einen bestimmten Zeitraum (z.B. eine Woche – halbes Jahr Rückschau, zwei Wochen – Jahresrückschau, zwei Tage – die letzten Sprints). Das Team sammelt Fakten und hängt sie an den entsprechenden Platz.

Was lief gut – Licht und Schmuck am Baum

Weihnachtsbaum_mit_Namen    Weihnachtsbaum_mit_Kugeln
Einen großen Weihnachtsbaum auf ca. 4 Flip-Charts malen (je nach Größe des Teams). Namen der Teammitglieder einmal unter den Baum auf Päckchen und einmal von oben nach unten am Baum auf Socken schreiben und so mit den Namen eine Matrix aufbauen.
Für jedes Teammitglied leuchtet eine Kerze in dem jeweiligen Feld der Matrix, an dem sich seine Namen treffen. Jedes Teammitglied schreibt nun auf, was für ihn oder sie z.B. ein erleuchtender Moment war, was ihn/sie am meisten motiviert, was für Ihn/sie in diesem Jahr besonders gut gelaufen ist in Bezug auf die Arbeit / Scrum Einführung / neues Team etc.
Weihnachtsbaumkugeln
Der Schmuck ist Symbol für gute Zusammenarbeit mit den Kollegen. Wieder wird die Matrix genutzt und jeder klebt für die Kollegen eine Kugel mit Beschriftung an den Baum, als Antwort auf z.B. die Fragen: 

Break / Separator
Jeder bringt seine Lieblingsweihnachtssüßigkeit mit, teilt mit den anderen und erklärt, warum er genau das so gerne zu Weihnachten isst. Oder vielleicht möchte jemand lustige Weihnachtspannen zum Besten geben? Ein kleines (!!!) Tischfeuerwerk sorgt bestimmt auch für den nötigen Break zwischen den beiden Teilen.

Was kann verbessert werden – Feuerwerk guter Vorsätze für das nächste Jahr

Das Team gestaltet das Feuerwerk des nächsten Jahres (an einer Metaplanwand oder einer mit Papier beklebten Tapete). Wie sieht das Gesamtbild aus? Welche Soundeffekte gibt es? Welche Farben? Was wird heller als dieses Jahr? Was lassen wir weg? Was nehmen wir neu dazu? Womit wollen wir experimentieren? Welche Kompetenzen brauchen wir dafür in unseren Feuerwerksexperten-Team? Wer soll das Feuerwerk sehen?
In diesem Sinne: Lasst die letzte Retro im Jahr zu einer schönen Rückschau, einem prachtvoll geschmückten Festbaum und einem aufregenden Ausblick auf das neue Jahr werden.

The Retrospective in Scrum. Thank you, EditGrid.

A while ago, I wrote a blog on how to hold a successful Retrospective with a geographically dispersed Team (see also “The Retrospective in Scrum. Bearing in mind Hofstede‘s Dimensions.“). Seeing as our Sprints always lasted a fortnight, I have collected a multitude of different ways for facilitating the Retrospective. Of this collection, I would like to share another option with you:
 
First of all, I would always advise to send information on the upcoming Retrospective ahead of time, so that culturally and linguistically diverse Teams can mentally prepare themselves. In your message, please provide information on the date, duration, location, equipment (webcams, telephone conference, paper etc.) and a rough agenda (not spoiling any surprises, of course). Furthermore, please inform the Team on the specific topic of the Retrospective (unless you would like the same issues to come up every single time). Such a topic could be “To understand the reasons behind …. why we’re not getting the committed Stories done / why we are finding so many bugs / why we never get a green build at first attempt etc.“. I have found that using online spreadsheets, such as Google Docs or EditGrid, can be a lot of fun and keeps the Retrospective very simple. If you chose to use such websites, please do not forget to send the link together with the above information.

 
 
I would like to now present to you one of the best agendas I have followed so far. This Retrospective had been part of a Sprint where the Team had worked very hard, but still had not managed to finish any of its committed Stories. I had set the duration at 1.5 hours and did not invite the Product Owner. I had the telephone conference on for the entire Retrospective, so that we could talk as well as work on the computers at the same time.
 
1) Check-In: At the beginning, I performed a little check-in exercise in order to set the stage. I asked every single one of the eleven developers to check in via one of these five emotional words: frustrated, confused, happy, sad, hopeful. This really helped, as it allowed every Team member to express his or her feelings about the failed Sprint and it meant that everyone‘s voice was heard at least once during the Retro.
 
2) Working Agreement: I asked the Team to come up with a Working Agreement that everyone would want to commit to. Such a Working Agreement should include rules of how the Team would like to work together, including rules like: all mobile phones are turned off during meetings, only one person speaks at a time etc. The short amount of ten minutes kept the Team focused and we came out with a Working Agreement consisting of 10 important points.
 
3) Hard Data: I then kindly asked the Team to use the online spreadsheet (in this case: EditGrid) and enter any hard data from the past Sprint that sprang to their minds. This provided the Team with a shared picture of the past two weeks. It could include events (meetings, decision points, milestones, celebrations etc.), metrics (Burn-Down Chart, velocity, defect counts, bugs etc.), Stories etc. Here, I gave the Team five minutes to enter the information and another five minutes to read through the data of one‘s colleagues and to place a plus next to all of those that one considered to have been high points and a minus next to the low points during the Sprint.
 
4) Strengths: Here, I had prepared a new, separate spreadsheet where the Team members could each enter the strengths of the Team. The Team had five minutes to write down 1-5 strengths in the appropriate columns, followed by another five minutes spent reading through the strengths identified by one‘s Team members. At the end of the ten minutes, I as ScrumMaster verbally summarised the Team‘s strengths.
 
5) Break: In order to psychologically divide the positive elements of the Retro from the negative ones, we took a short break at this point (especially good if there are Team members using headphones).
 
6) Topic: After the break, we immediately started with the topic of the Retro – in this case “Why are we not getting the committed Stories done“? On a separate spreadsheet, the Team members each had five minutes to enter up to three reasons that they thought were the cause for failing this Sprint. They then had five minutes to vote on the top three issues. As ScrumMaster, I noted down these prioritised three reasons on a separate sheet and read them out to the Team.
 
7) Discussion: The final 45 minutes of the Retrospective were spent in the telephone conference with shared desktop view, addressing each of the selected top three issues with the specific question of “What is one thing we could do differently?“. By focusing the Team in this way, we actually managed to get SMART (Specific, Measurable, Attainable, Relevant and Timely) measures out of the Retro and I was able to ask for the Team‘s commitment.
 
8) Check-Out: Similar to the initial exercise, I asked everyone to check out via one of the same five feelings: frustrated, confused, happy, sad, hopeful. This way, the Team and I were able to see the direct effect of the Retrospective on everyone.
 
9) End: I then closed the Retrospective by thanking the Team for their valuable input, repeating the committed measures and asking them whether and how the information of the Retro may be used (perhaps a “lessons learned“ document for the next audit) or not.
 
The Team has given me wonderful feedback on this way of performing the Retrospective. I believe that the specific topic as well as the placing of the focus on the medium of EditGrid helped in getting the Team members put their efforts into the same elements at the same time for a period of 1.5 hours. This joint effort was immediately noticeable in the quality of the measures, which the Team actually adhered to in a self-organized manner over the upcoming weeks. This may have also been influenced by the fact that all Team members had participated on an equal level and thus felt equally responsible for the input as well as the output (measures) of the Retrospective.
 
Go ahead, have a try & let me know how it went. I am looking forward to your feedback!
 
Book recommendation: Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen

Der Moderator, eine oft unterschätze Rolle in selbstorganisierten Prozessen

In einem meiner letzen Teamentwicklungsworkshops ergab sich folgende spannende Szenerie: Das relativ neu installierte ScrumTeam, bestehend aus sechs Entwicklern plus Product Ownerin und ScrumMaster, hatte die Aufgabe, selbstorganisiert eine neue Zuordnung in der Belegung neuer Räumlichkeiten zu diskutieren und zu entscheiden. Die selbst gewählte Zeitvorgabe war zwanzig Minuten. Als Teamentwickler beobachtete ich den Prozess von außen, mit dem Auftrag, ggf. zu intervenieren und Feedback zu geben. Das Team kommunizierte sehr sachlich und intensiv, in einer konstruktiven dialogischen Kommunikationsform. Mehrere Varianten wurden vorgeschlagen und Argument dafür und dagegen ausgetauscht. Die Zeit verstrich, ohne dass eine Entscheidung thematisiert, geschweige denn getroffen wurde. Aus meiner externen Perspektive stand einer “schnellen” Entscheidung eigentlich nichts im Wege, außer der Unsicherheit und Unentschlossenheit des Teams.
Nach den vereinbarten 20 Minuten intervenierte ich vorsichtig und fragte nach, was denn im Moment los sei. Zuerst unsicheres Schweigen und dann Erstaunen darüber, dass die 20 Minuten inzwischen schon vorüber waren. Auf meine nächste Frage, was denn nun weiterhelfen könnte, kam spontan die Antwort jemand sollte doch mal an das Flipchart gehen und visualisieren. Nach kurzer Bedenkzeit stand ein Teammitglied auf (nicht der ScrumMaster) und kam aus der Runde nach vorne. Er zeichnete als erstes die räumliche Situation auf, steuerte spontan den neuen Dialog, fasste zusammen und fokussierte innerhalb von zehn Minuten eine Entscheidung im Konsens, mit der alle sehr zufrieden waren.
Wäre das evtl. auch schneller gegangen und was wäre passiert, wenn das Team statt in einen konstruktiven Dialog in eine hitzige Debatte geraten wäre?
Selbstorganisation braucht klare Strukturen, wie z.B. Rahmenbedingungen, Ziele, Regeln, definierte Prozesse und eben auch transparente Rollen und Funktionen, um optimal zu funktionieren. Häufig “wählen“ sich daher Gruppen und Teams informell Moderatoren, spontan und nicht abgesprochen, aus den Anforderungen des Themas oder des Prozesses heraus. Entweder wird ein Teammitglied spontan initiativ und übernimmt von sich aus die Rolle, oder andere schlagen einen Kollegen vor. Dies kann sehr gut funktionieren, wenn das Team den jeweiligen Moderator akzeptiert und Erfahrung und Kompetenzen in der Gestaltung von Dialogen in Meetings und Workshops hat. Weniger optimal funktionieren wechselnde Moderatoren innerhalb eines längeren Prozesses. Hier gestaltet sich die Rolle nach meinen Erfahrungen häufig diffus und die Moderatoren können weniger gezielt und strukturiert auf den Ablauf einwirken.
Von Teilnehmern des ScrumMaster Pro Trainings "MeetingFacilitation" erarbeitetes RollenprofilAm funktionalsten ist es zweifellos, den Moderator im Vorfeld eines Meetings oder eines Workshops zu definieren und damit “formal” zu legitimieren. So kann eindeutig vereinbart werden, mit welchen Kompetenzen er ausgestattet ist und wie er seine Rolle ausgestalten soll und möchte. Dabei ist die Rolle Moderator ein genuiner Teil der Selbstorganisation des Teams und nicht wie häufig angenommen ein Außenstehender. Als Systemzugehöriger kann er nun als Moderator legitimiert steuern und intervenieren. Die Anforderungen an die Funktion Moderator sind in der Regel hoch und erfordern ein differenziertes Kompetenzprofil. Er soll und kann Ziele und Ergebnisse fokussieren, situativ führen und intervenieren, emphatisch auf das Team eingehen, kommunizieren, visualisieren und motivieren usw. Siehe Rollenprofil auf der Abbildung.
Je klarer die Rolle definiert und committet ist, desto effizienter kann der Moderator Selbstorganisationsprozesse unterstützen, seiner Funktion gerecht werden und sein methodisches und soziales Know-how einbringen.
Mein Appell:
Teams, würdigt eure Moderatoren, gebt ihnen die notwendige Legitimation und respektiert ihre Funktion und ihre Fähigkeiten zum Nutzen für alle.
Moderatoren, vertretet selbstbewusst eure wichtige Rolle und Dienstleistung für die selbstorgansierte Teamarbeit und übernehmt Verantwortung für das Gelingen von Meetings welcher Art auch immer.
 
TIPP: Meetings moderieren und zum Erfolg führen – lernen, wie es geht beim ScrumMaster Pro Training MeetingFacilitation mit Dieter Rösner.
 
 

Die wertvolle Meetingzeit sinnvoll nutzen, effektiv kommunizieren (Teil 1)

Zu viele Meetings? Oder ineffektive Meetings? Oder beides? Vielfach wird das Thema Meeting Management in dieser Art und Weise sehr kritisch reflektiert und beklagt.
Zu lange Sitzungen und vor allem zu viel Palaver, ohne dass dabei etwas rum kommt. Außerdem auch noch schlechtes Klima, Konflikte, mangelnde Umsetzung von Ergebnissen. Woran liegt es eigentlich und was könnte Abhilfe schaffen? Ganz sicher gibt es unterschiedlichste Ursachen für diese Problematik. Ich möchte mich hier auf ein Thema  beschränken: die Form der kollektiven Kommunikation in der Meetingpraxis. Meetings und Workshops sind per se komplexe Kommunikationsprozesse und daher ist die Art und Weise, wie mit- oder gegeneinander kommuniziert wird, häufig der Stein des Anstoßes.
Betrachtet man kollektive Kommunikation, kann man drei relevante Arten erkennen: Debatte, Diskussion, Dialog (den Monolog lasse ich hier bewusst außen vor). Welche dieser drei Arten in Meetings schwerpunktmäßig praktiziert wird, hat zwangsläufig (negative oder positive) Konsequenzen. Denn nicht alle sind wirklich funktional und für Meetings geeignet. Schauen wir uns die drei Formate genauer an.

Debatte. Französisch: debattre – schlagen, niederschlagen, Schlagabtausch.

Die Debatte ist in vielen Meetings gängige Praxis. Hier geht es in der Regel darum, die eigenen Interessen, Meinungen, Ziele  ohne Wenn und Aber durchzusetzen und als “Sieger” vom Platz zu gehen. Oft wird auch zu unsachlichen und unfairen Mitteln gegriffen und mit Killerphrasen unter die Gürtellinie “geschlagen”. Zum Sieger gehört zwangsläufig immer ein Verlierer und so wirken sich Debatten meist sehr negativ auf Klima und Kooperation aus. Commitments als Ergebnis von Meetings werden nicht eingehalten und die Umsetzung von Maßnahmen boykottiert. Und, nicht zu vergessen – Rache ist süß.


Fazit: die Debatte ist als Form der Kommunikation in Meetings und überhaupt im Team weitgehend ungeeignet.

Diskussion. Lateinisch: Discussio, discutere – Untersuchung, erwägen, zerteilen.

Sie ist sicher die häufigste Art der Kommunikation in Meetings. Argumente werden ausgetauscht, hin und her erwogen und von den unterschiedlichsten Perspektiven betrachtet. Auch hier stehen die eigenen Aspekte stark im Vordergrund und deren Durchsetzung im Sinne der Überzeugung der anderen angestrebt. In guten Diskussionsrunden wird jedoch, auch wenn’s mal hitziger wird, die Sachebene nicht verlassen. Das Problem mit der Diskussion ist jedoch zum einen die Gefahr, schnell in leidige Debatten abzugleiten. Zum anderen finden Diskussionen oft keine Ende, drehen sich im Kreis und Entscheidungsprozesse dauern endlos oder werden immer wieder vertagt. Außerdem setzen sich rhetorisch geschicktere oder dominante Teamkollegen stärker durch und es entsteht ein Ungleichgewicht im Team. Auf Dauer kann das zu Unlust, Frust und ähnlichen Symptomen wie bei der Debatte führen.


Fazit: Die Diskussion ist im Sinne von Information, Austausch und Klärung durchaus für die Teamkommunikation geeignet, jedoch für flüssige und schnelle Entscheidungen problematisch. Diskussionen brauchen auf alle Fälle einen kompetenten und starken Moderator.

Dialog. Altgriechisch: dia – durch, hindurch; logos – Rede; dialogos – Wortfluss, durch das Wort gehen.

Der Dialog stellt das Thema, die Sache und die gemeinsamen Interessen in den Mittelpunkt. Im Dialog werden die jeweiligen Positionen im Sinne gegenseitiger Angebote und Vorschläge sachbezogen dargestellt. Die unterschiedlichen “inneren Landkarten” werden transparent gemacht, abgeglichen und nach Konsens oder guten Kompromissen gesucht. Während des Dialogs lernen Menschen, in ihrem Anliegen gemeinsam zu denken und entwickeln eine kollektive Sensibilität für die Gedanken, Gefühle, Intentionen und Handlungen aller im Team. Pragmatisch gesehen führt ein reifer Dialog zu schnellerer Entscheidungsfindung, hoher Akzeptanz von Ergebnissen und fördert zudem ein positives Klima und Teamgeist. In der praktischen Umsetzung braucht dialogische Kommunikation Disziplin, soziale und personale Kompetenz jedes einzelnen und in Meetings, zumindest in der Anfangsphase, eine gute Moderation.
 
Einige Tipps, um die Teamkommunikation zu einem Dialog zu machen:

  • den Dialog z.B. in einer Retro ausführlich zum Thema machen
  • die beschriebenen Elemente und den Nutzen des Dialogs vorstellen
  • konkrete Dialogregeln gemeinsam erarbeiten und vereinbaren
  • für die ersten Einheiten, in denen dialogisch kommuniziert werden soll, einen “Dialogwächter” einsetzen, der konsequent auf den Umgang mit den Regeln achtet. ( nicht der Moderator)
  • den Wächter rotierend wechseln
  • hin und wieder eine kollektive Feedbackrunde im Team über die Dialogpraxis durchführen
  • läuft der Dialog gut, kann auf den Wächter verzichtet werden und jedes Teammitglied übernimmt situativ Verantwortung für das Gelingen der Kommunikation.

 
Hat ein Team eine reife Praxis im Dialog entwickelt, können Diskussionen gezielt hin zum Dialog  gesteuert werden und das Thema Debatten hat sich weitgehend erledigt. Sie werden überflüssig und in der Regel als massive destruktive Störung empfunden.
 
Über die spezifischen Kernkompetenzen die die Teammitglieder für den Dialog mitbringen sollten, handelt Teil zwei demnächst im borisgloger Blog.
 
TIPP: Scrum Meetings moderieren und zum Erfolg führen – Training “MeetingFacilitation” mit Dieter Rösner. Termine und Informationen hier nachlesen.

Ich, Du, Wir – von Austausch, Feedback und Weiterentwicklung in Teams

Gerade wenn Teams schon über einen längeren Zeitraum zusammengearbeitet und etliche Retrospektiven hinter sich haben, kann es sinnvoll sein, einen intensiveren „Boxenstopp“ einzulegen. Vor allem dann, wenn Ansätze von „Teammüdigkeit“, latente Konflikte oder schwächelnder Teamspirit wahrnehmbar sind. In solchen Situationen ist die NAIKAN-Übung eine interessante und wirkungsvolle Methode für einen intensiven und gründlichen Austausch im Team.
NAIKAN stammt aus Japan und wurde bereits Anfang der 1940er-Jahre als meditatives Verfahren zur Selbstreflexion entwickelt. Die Wortbedeutung ergibt sich aus NAI-Inneres und KAN-Beobachten (Schau) – also Innenschau.
 
NAIKAN ist in seinem Ursprung eine Methode zur individuellen Selbsterfahrung und Selbstentwicklung. Sie hilft Menschen, ihre ganz einzigartigen Wahrnehmungen, inneren Konstruktionen, mental-emotionalen Muster (die innere Beziehungslandkarte) bezogen auf die Erfahrungen mit anderen Menschen (biographisch) zu erforschen und zu reflektieren. Über Selbsteinsicht soll man dann zu neuen Erkenntnissen, Lösungen und Handlungsmöglichkeiten kommen.
Die Übertragung von NAIKAN auf Prozesse der Teamentwicklung ermöglicht eine wirkungsvolle Kombination individueller Reflexion und wirkungsvollem Team-Austausch. Diese Methode ist bewusst sehr einfach in ihrer Struktur, in ihrem Prozess und im Handling und ist ein klassisches Beispiel für menschliche Selbstverantwortung und Selbstorganisation – passt also sehr gut zu agilen Teams!
 
NAIKAN stellt in der Teamvariante folgende drei Fragen:


1). Was habe ich von diesem/meinem Team bekommen?

  • Was hat mir geholfen?
  • Was hat mich bereichert?
  • Was hätte ich ohne dieses Team nicht oder nicht so gut erreicht?

 
2). Was habe ich dem Team/meinem Team gegeben?

  • Was habe ich eingebracht?
  • Wie habe ich geholfen?
  • Was habe ich bewirkt?
  • Worauf habe ich verzichtet?

 
3). Welche Schwierigkeiten habe ich dem/meinem Team gemacht?

  • Wen oder was habe ich behindert?
  • Welche Nachteile habe ich bewirkt?
  • Wo war ich ungerecht?
  • Wo habe ich mich nicht teamgemäß verhalten?

 
Der NAIKAN Prozess läuft in folgenden 5 Schritten ab:


1). Zunächst wird die Methode kurz erklärt. Dann gibt der Teamentwickler ein kurzen (!!) und neutralen Rückblick auf die Teambiographie, zum Beispiel so: “Wenn ihr an die Zeit zurückdenkt, in der ihr nun schon als Team zusammenarbeitet, vom Start über die erste Monate…………….bis zum heutigen Tag.  Jeder hat so seine ganz eigenen Erfahrungen gemacht, hat sich auf seine Weise eingebracht, und hat seine individuelle „Geschichte“ erlebt……“
 
2). Jedes Teammitglied bekommt nun ein Blatt mit den drei Fragen und der Anweisung, sich intensiv mit den Fragen zu beschäftigen und die Antworten zu notieren. (Dafür sollte genügend Platz und Zeit zur Selbstreflexion zur Verfügung stehen)
 
3)  Wenn alle Teammitglieder ihre Antworten gefunden haben, tauschen jeweils zwei Kollegen ihre Antworten aus und geben sich Feedback. Dieser Vorgang sollte mehrfach wiederholt werden, evtl. bis jeder mit jedem im Austausch war.

 
4). Nun trifft sich das Team zu einer kurzen Sharing-Einheit. Sharing heißt, dass jeder Teilnehmer ein kurzes Statement zu seinem inneren Erleben, d.h. zu seiner Gefühlslage des soeben erlebten Prozesses kommuniziert. Jeder bringt sich mit 1-2 kurzen Sätzen ein („ mir ging es …..“, „ich war am Anfang angespannt und hatte dann ein immer angenehmeres  Gefühl“, ……etc.) Ganz wichtig: Im Plenum sollte es auf keinen Fall ein ausführliches Prozess-Feedback geben!!!!!
 
5). Die stille Runde: Jeder Einzelne nimmt sich nun noch einmal Zeit, ganz für sich seine gemachten Erfahrungen zu verarbeiten und bekommt den Auftrag, die positiven Momente mit dem Team und den Kollegen anzunehmen, zu würdigen und das, was er bei sich zukünftig ändern will, zu definieren. Es findet danach ganz bewusst kein weiterer Austausch (auch keine kollektiven Maßnahmen) mehr statt, da NAIKAN ganz auf die Dynamik von lösungsorientierter „Selbstheilung“ beim Einzelnen und dem Team setzt. Der NAIKAN Prozess wirkt „still“ in die zukünftige Beziehungspraxis des Teams hinein und entwickelt in Idealfall eine wahrnehmbare positive Dynamik.
 
NAIKAN arbeitet mit den beiden  Ebenen der Beziehungsbilanz (Fragen 1 und 2) und der Beziehungsbelastung (Frage 3) und ermöglicht es, in der strukturierten Selbstreflexion und dem kollegialen Austausch positive und ressourcenvolle Prozesse zu initiieren.
 
Der Teamentwickler sollte präzise An- und Vorgaben machen, die Einzelnen nur bei Bedarf vorsichtig unterstützen und Zweierfeedback- und  Sharingrunden diszipliniert führen. Seine Aufmerksamkeit ist bei dem was im Prozess passiert. Er muss genau darauf achten, dass vor allem der Einzelne in Ruhe (Schritte 2 und 5) mit sich selbst arbeiten kann.
 
 
TIPP: Individuelle Lösungsstrategien entwickeln, wenn es mal im Teamgetriebe knirscht – KonfliktManagement mit Dieter Rösner

Moral hat in der Retrospektive nichts verloren!

Das Team soll sich verbessern. Soll also aus Fehlern lernen und einfach noch schneller arbeiten? Viele Manager fragen sich, wie das gehen soll, wenn ihre Teams jetzt gerade eben nicht liefern, die Deadlines ignorieren, Produkte liefern, die nicht den Anforderungen entsprechen, uvm. Wie kann man erreichen, dass das Team schneller und effektiver arbeitet?
Selbst anders denkende Manager, die von den agilen Methoden infiziert sind, denen die traditionellen Denkmuster nicht mehr zusagen und die schon sehen, dass die traditionellen Denkmuster und Methoden in die Sackgasse geführt haben, fragen sich: “Wie soll mir die Forderung der Teams nach Autonomie, nach “Selbstbestimmung” helfen, mehr aus den Teams rauszuholen?” Denn machen wir uns nichts vor: Genau darum geht es. Auch und vor allem beim Management-Framework Scrum.

Darf man unzufrieden sein?

Manager und mittlerweile auch ScrumMaster sind unzufrieden mit der Leistung ihrer Teams. Aber dürfen sie denn unzufrieden sein? Glaubt man der agilen Ideologie, die vehement von einigen Agilisten vertreten wird, dann sind Forderungen an die Teams schlecht. “Teams sollen selbst entscheiden, wie sie arbeiten, wieviel sie liefern, und mit den Ergebnissen müssen die Manager halt leben.” Ich schreibe Ideologie, weil hier mit dem Element von ‘gut’ und ‘böse’ gearbeitet wird. Die ideologisch aufgeladene agile Diskussion des “schlechten” traditionellen Managements und des “guten” neuen agilen Weges führt uns alle in das Lagerdenken und ist in diesen Kategorien sinnlos. Denn es gibt keine höhere moralische Instanz, die definieren könnte, dass das eine “besser” als das andere ist. Dennoch führt eine Ablehnung eines moralischen Grundes nicht zur Beliebigkeit. Es ist nicht egal, ob man agil oder traditionell arbeitet. Man kann begründet sagen, dass agile Methoden und agiles Denken effektiver sind als traditionelle Denkrichtungen, wie Projektmanagement und hierarchische Organisationsformen, denn sie liefern empirisch nachvollziehbar bessere Ergebnisse. Die Standish Group hat das in ihrem Bericht von 2011 sehr deutlich gemacht.
copyright Gerhard PeyrerNein, als Manager darf ich unzufrieden mit der Leistung eines Teams sein. Ich darf nämlich genauso eine Haltung vertreten, wie es auch den Teams gestattet wird. Wir alle kennen den obersten Grundsatz der Retrospektive, nachdem jeder immer sein Bestes gegeben hat. Dieser gilt natürlich auch für das Management und für das Denken der Manager. Auch der Manager darf seine Art zu Denken haben, denn auch er kann nichts dafür, wie er denkt. “Du kannst nichts dafür!”, sagt der Psychologe Sean Maguire zu Will Hunting, im Film “Good Will Hunting”. Damit macht Maguire Will ein für alle mal klar, dass Hunting natürlich ein Produkt seiner Erziehung und der Umstände ist. Er ist im eigentlichen Sinne nicht schuld an dem, was er einmal getan hat, sondern bestenfalls verantwortlich im Sinne, dass er daraus etwas lernen kann. Aber er ist eben nicht moralisch böse oder schlecht. Genauso ist der Manager nicht schuld oder böse, wenn er versucht seine Leistungserwartungen an das Team zu kommunizieren. Er hat diese Erwartungshaltungen und das ist exakt gleich wichtig und genauso in Ordnung, wie die Aussage des Teams, dass es eben nur liefern kann, was es liefern kann. Lässt sich diese Aussage begründen? Bis dato fiel mir das immer schwer. Denn als naturwissenschaftlich geprägter Philosoph und Soziologe war mir zwar Norman Kerths Prime Directive immer vollkommen logisch erschienen, ich hatte mir aber bis dato nie die Mühe gemacht, sie zu fundieren.

Jenseits von Gut und Böse

Der Philosoph und Journalist Michael Schmidt-Salomon schließt diese Lücke nun für mich mit seinem Buch “Jenseits von Gut und Böse – Warum wir ohne Moral die besseren Menschen sind”: Er macht logisch-empirisch und sehr fundiert deutlich, dass wir Menschen nicht moralisch schuldig sein können. Damit meint er nicht, dass wir die “Taten (von Verbrechern) in irgendeiner Weise tolerieren oder gutheißen müssen” (S. 200), jedoch müssen wir anerkennen, “dass selbst die übelsten Verbrecher der Geschichte in dem Sinne unschuldig waren, dass sie unter Voraussetzung der Gültigkeit der Naturgesetze schlichtweg nicht anders handeln konnten, als sie gehandelt haben.” Wie er zu dieser These kommen kann? Er widerlegt auf den vorangehenden 199 Seiten seines lesenswerten Buches zwei Prämissen, die viele Menschen als gegeben hinnehmen, die aber schlichtweg falsch (da empirisch und logisch unhaltbar) sind:

  1. “Willensfreiheit ist eine Illusion … Es ist schlichtweg unmöglich, dass sich eine Person unter exakt gleichen Bedingungen anders entscheiden könnte, als sie sich de facto entscheidet. Das “Prinzip der alternativen Möglichkeiten” muss aufgegeben werden.
  2. ‘Gut’ und ‘Böse’ sind moralische Fiktionen, für die es in der Realität keine Entsprechung gibt.

Das führt Schmidt-Salomon unweigerlich zu der Prime Directive der Retrospektive: “Mit der Verabschiedung der beiden zentralen Prämissen des Sündenfall-Syndroms ist auch deren lebenspraktische Konsequenz obsolet: das moralische Schuld- und Sühneprinzip. Denn es macht keinen Sinn, einen Menschen in moralischer Weise für seine Entscheidungen verantwortlich zu machen, wenn er in einer konkreten Situation nur das wollen kann, was er aufgrund seiner Veranlagungen und Erfahrungen wollen muss.” (S. 201f) Genau das war zu beweisen: Norman Kerths Prime Directive sagt aus:
[quote author = “Norman Kerth”]”Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”[/quote]
Kerth schafft auf diese Weise eben nicht den falschen Rahmen der Beliebigkeit, des Fatalismus, wie es Michael Schmidt-Salomon nennt. Eine Argumentationslinie, die jedoch schwer fällt, wenn man nicht den klaren Unterschied zwischen moralisch falsch und ethisch falsch sieht. Alles, was das Team gemacht hat, ist moralisch weder gut noch schlecht, richtig oder falsch. Denn jeder im Team “konnte” nur tun was er “musste”. Im Nachhinein kann man beurteilen, ob das, was getan wurde, aus objektivierbaren Gründen sinnvoll im Sinne effektiver für die Zielerreichung war als etwas anderes. Das Versagen in diesem Hinblick kann man dann bereuen und es beim nächsten Mal besser machen, ohne sich dafür schuldig fühlen zu müssen.

Sich selbst vergeben

Diese Erkenntnis hilft vielmehr, den Mut zur Freiheit, den Mut zur Handlungsfreiheit zu stärken: “Wenn wir die Ergebnisse der logisch-empirischen Forschung Ernst nehmen und das Prinzip der Willensfreiheit verwerfen, so kann das sehr wohl zu einer Stärkung des Mutes zur Freiheit führen. Das Wissen darum, dass das Prinzip der alternativen Möglichkeiten bloß eine Chimäre ist, reduziert nämlich die Angst vor dem Versagen und damit den psychologischen Druck, vor dem der Unterwerfungswillige flieht. Wer weiss, dass er sich in der Vergangenheit nur in der Weise verhalten konnte, wie er sich unter den gegebenen Bedingungen verhalten musste, der wird zurückliegende Fehlentscheidungen wohl bereuen und auch daran arbeiten, künftig anders zu reagieren, er wird daraus jedoch keine Selbstvorwürfe ableiten, da es sinnlos ist, sich für etwas zu kasteien, was notwendigerweise so war, wie es war.” Das wiederum führt zu einer entspannten Haltung zu sich selbst: “Wer sich selbst vergibt, kann auch anderen besser vergeben und dadurch zu einem entspannten Verhältnis zu seinen Mitmenschen entwickeln.” (S. 203)
Da ist es – die Erkenntnis, dass ich nur handeln konnte wie ich musste. Das bedeutet: Heute kann ich es in Kenntnis dessen, was ich gestern “falsch” gemacht habe, korrigieren und etwas anderes, Erfolgversprechenderes ausprobieren. Das wiederum führt uns zum Credo des Handelns, dass zumindest mein Team im täglichen Tun beflügelt: “Doing as a Way of Thinking!”
Denn diese Haltung basiert auf dem Bewusstsein, dass man natürlich objektive Verantwortung für seine Taten übernimmt. Schmidt-Salomon macht uns das sehr schön klar: Es gibt eine “bedeutsame Unterscheidung zwischen Schuld- und Reuegefühlen” und weiter: “Beide Emotionen speisen sich zunächst aus einer gemeinsamen Wurzel. Wir empfinden Schuld beziehungsweise Reue, wenn wir zu der Einsicht gelangen, das wir uns falsch verhalten und dadurch irgendeinen Schaden ausgelöst haben. Der Unterschied zwischen diesen beiden emotionalen Reaktionen besteht allerdings darin, dass wir uns im Fall von Schuldgefühlen aufgrund unseres Fehlverhaltens als schlechte Menschen moralisch verurteilen, während wir im Falle der Reue unser Fehlverhalten zwar bedauern und auch nach Wegen der Korrektur, Wiedergutmachung und Vermeidung des Fehlers in der Zukunft suchen, aber auf eine moralische Verurteilung unseres Selbst verzichten.” Das klingt philosophisch und sehr abgehoben, zugegeben, aber es macht etwas absolut deutlich: In Retrospektiven verwechseln die Beteiligten, ScrumMaster und Teammitglieder exakt diese beiden Emotionen.

In einer Retrospektive geht es nie um Schuld …

…  doch allzuoft werden Emotionen ausgelöst, die von den darin nicht ausgebildeten ScrumMastern nicht richtig gelenkt werden. Das ist keine Kritik. Das ist wirklich schwer und oft scheitern auch erfahrene Therapeuten bei Gruppen genau an diesem Punkt. Sie schaffen es nicht, dass der Betroffene oder die Gruppe über sich selbst amoralisch urteilt und auf diese Weise arbeitsfähig bleibt. Gelingt es aber, nicht moralisch zu urteilen (und darauf war u.a. die  6 Step Heartbeat Retrospektive, die ich bereits vor 6 Jahren erfunden hatte, wie ich jetzt erkenne, getrimmt), dann gelingt etwas Faszinierendes: “Während Schuldgefühle uns quälen, lähmen, unsere gesamte Energie aufbrauchen können, fühlen wir uns mit Reuegefühlen in der Lage aktiv zu werden. Wir behalten unsere Selbstachtung.”

Kreativitätstechniken

Ich sitze an meinem Schreibtisch und möchte für mein Scrum-Team eine neue Retromethode entwerfen. Die Zeit vergeht und vor mir nur das leere Blatt. Schon drei Mal habe ich angefangen etwas aufzuschreiben. Drei Mal wieder gelöscht. Was soll ich mit ihnen machen? Was interessiert mein Team, die Leute sind doch alle so unterschiedlich? Womit begeistere ich sie?
 
Na, kommt euch die Situation bekannt vor?
Ich möchte was Cooles machen, um mein Team aus seinem Alltag herauszuholen und den Leuten eine frische Retro anbieten. Weg von 08/15 … Natürlich kann ich googeln. Mit Retrospektiven haben sich schon viele auseinandergesetzt. Aber ich möchte etwas Individuelles anbieten. Etwas, das die Persönlichkeit meines Teams herausstellt …
 
Was hindert uns daran, auch mal unsere Ideen zu sammeln. Und das ist gar nicht so schwer. Hier einige Möglichkeiten, um der eigenen Kreativität auf die Sprünge zu helfen:

  • Klingt simpel, aber hilft ungemein: einfach mal aufstehen. Im Büro oder noch besser im Grünen spazieren gehen. Die Gedanken vom eigentlichen Problem lösen und neue Eindrücke sammeln.
  • Ein Flipchart oder Brownpaper an die Wand hängen und einfach mal anfangen zu malen. Aber auch hier gilt: einfach die Gedanken fließen lassen. Es geht hier ja nicht um den neuen Picasso, sondern um das Fokussieren auf neue Gedanken.
  • Habt ihr Playmobilfiguren rumliegen? Ich stelle die Figuren in verschiedenen Konstellationen auf und überlege, wie sie in Interaktion treten können.
  • Eine klassische Methode ist das Mindmapping. Hier schreibt man das Thema/Problem in die Mitte eines Blattes und legt Äste von der Mitte aus an, um einfach alle Ideen unbewertet zu sammeln.

Und was ist aus meiner Retro geworden? Die Flipchartmethode hat meine Kreativität angespornt. Quasi die Idee in der Idee: Ich lasse mein Team malen. In Kleingruppen lasse ich sie zeichnen, was gut gelaufen ist. Die Kunstwerke werden vorgestellt, indem die jeweils anderen Gruppen erraten, was das Gezeichnete darstellt. Diese Übung bringt auf jeden Fall Spaß und Abwechslung zum Standardprogramm.

Phänomenologie des Impediments

Dieser Artikel ist aus der Vorbereitung eines Workshops für eines unserer Projekte entstanden. Mein besonderer Dank gilt dabei meinen werten Kollegen Mathis Christian und David Holzer, die mir geholfen haben, Impediments in ihrer ganzen Dimension zu verstehen.


Definition
Ein Impediment ist erstens alles, was das Team bei der Arbeit behindert. Solche Impediments müssen beseitigt werden, um dem Team den Rücken frei zu halten. Beispiele: Die Monitore sind zu klein, die Räume zu warm, der ScrumMaster weilt oft im Home Office. Ein Impediment ist zweitens alles, was ein gutes Team davon abhält, noch besser zu werden. Solche Impediments werden meist durch Maßnahmen beseitigt, die auf eine Verhaltensänderung im Team abzielen. Beispiele hierfür: Agile Entwicklungspraktiken werden kaum genutzt, User Stories haben schlechte Qualität, Entwickler und Tester arbeiten wenig zusammen.
 
Retrospektive
Eine gute Retrospektive wirkt wie ein geschickt ausgeworfenes Fischernetz: Sie bringt allerhand Impediments zu Tage. Wer nur in seichten Gewässern fischt, der wird immer das Gleiche und manchmal einen Stiefel zu sehen bekommt. Die Retro soll Raum für Reflektion und Abstand geben, ungewöhnliche Perspektiven eröffnen und dem Team dabei helfen, sich als soziales Konstrukt zu verstehen (mehr zur Retrospektive in diesem Blog-Beitrag meiner Kollegin Stephanie Gasche). Gegen Ende der Retrospektive bittet der ScrumMaster sein Team darum, die identifizierten Impediments in interne oder externe zu klassifizieren. Impediments sind intern, wenn das Team selber sich zutraut, die Verantwortung für die Lösung des Impediments zu übernehmen. Für externe Impediments ist hingegen der ScrumMaster verantwortlich.
 
Impediments – sichtbare und unsichtbare
Manche Impediments sind kaum zu übersehen. Die Wand, die ein Team in zwei teilt. Die engen Räumlichkeiten, die keinen Rückzugsort für einen entspannten Kaffeeplausch bieten. Andere Impediments liegen nicht sofort auf der Hand. Das Teammitglied, das im Daily Scrum immer wieder unterbrochen wird. Der Product Owner, der nur an drei Tagen in der Woche für sein Team da ist. Der ScrumMaster, der nicht moderieren kann. Das Management, das die Vergütung im Team von individuellen Leistungszielen abhängig macht. Nicht jedem fallen solche Situationen sofort als Impediments auf, obwohl sie das Team in ihrer Entwicklung behindern.
 

 


Impediment Backlog
Im Daily Scrum erklärt das Team seine Arbeit anhand des Taskboards. Der ScrumMaster tut das gleiche anhand des Impediment Backlogs. Dort finden sich, analog zum Taskboard, die offenen und geschlossenen Impediments sowie diejenigen, die in Bearbeitung sind. Impediments sollten in einer priorisierten Reihenfolge aufgehangen werden. Hängt ein Impediment länger als einen Tag in Bearbeitung, bekommt es einen Punkt. Das Impediment Backlog sollte Platz für interne und externe Impediments bieten (zur Unterscheidung intern/extern, siehe Retrospektive).
 
Impediments und Maßnahmen
Manche Impediments sind erstmal nur das, was ihr Name besagt: Hindernisse. Für andere Impediments bieten sich unmittelbare Maßnahmen an. Ist das Impediment ein internes, dann gehört die Maßnahme, gekennzeichnet mit dem Namen des verantwortlichen Teammitglieds und ihrer Impediment-Zugehörigkeit, ins Team Backlog. Sobald die Maßnahme in die Bearbeitung geht, wandert sie auf das Taskboard und hängt dort wie jeder andere Task auch. Parallel dazu wandert das Impediment auf dem Impediment Backlog in Bearbeitung. Ist die Maßnahme durchgeführt, überprüft das Team, ob das korrespondierende Impediment damit gelöst ist und auf erledigt gesetzt werden kann. Für die externen Impediments kann der ScrumMaster sich überlegen, ob er ein Taskboard für seine eigene Arbeit anlegen möchte.
 
Zeit
Manche Impediments brauchen Zeit und mehr als eine Maßnahme, um gelöst zu werden. Trotzdem dranbleiben! Ein Team, das durch eine Mauer getrennt war, hat einmal 56 Punkte auf das Impediment gemacht, bis der Zettel Masern bekam und die Mauer abgerissen war. Die Sturheit wurde belohnt. Andere Impediments lassen sich schneller lösen, wenn man sie herunterbricht und ein klares Ziel festlegt. Das Team ärgert sich, dass das Testen immer ganz zum Schluss kommt? Frage nach, worin genau der Mangel liegt – und was dagegen unternommen werden kann (z.B. ein Code-Kata zur testgetriebenen Entwicklung). Schaue zu, dass die Maßnahme im neuen Sprint umgesetzt wird. Frage dann, ob das Impediment – mangelndes Know-How – nun noch fortbesteht. So kann das Team entscheiden, ob weitere Maßnahmen nötig sind.
 
Skaliertes Impediment-Management

Wenn mehrere Scrum-Teams am gleichen Produkt arbeiten, wird der Koordinationsbedarf größer.  Abstimmungen, die bei zwei oder drei Teams vielleicht noch zwischen Tür und Angel erledigt werden konnten, werden bei weiterem Wachstum nicht mehr ausreichen. Deshalb machen wir jeden Tag 15 Minuten lang ein Scrum of Scrums (SoS), in dem sich Vertreter aus jedem Team treffen und austauschen. Der Fokus liegt dabei auf Abhängigkeiten und Impediments. Nicht jedes Impediments ist für das SoS relevant. Ein Kriterium ist Betroffenheit: Sind andere Teams vom Impediment betroffen, gehört es auf jeden Fall ins SoS. Ein weiteres Kriterium ist der Lerneffekt: Wurde für die Lösung des Impediments ein neuer oder ungewohnter Weg beschritten, kann das für andere Teams höchst interessant sein (Wie hat das Team es geschafft, das Impediment zu lösen? Mit wem musste es dabei sprechen?).  Impediments auf dem SoS-Board sollten parallel immer auf dem Impediment Backlog des Teams gepflegt werden. So kann der ScrumMaster dranbleiben und entscheiden, wann er seinem Team unter die Arme greifen muss.
 
TIPP: “ImpedimentManagement” – das Training mit Dieter Rösner zum Erkennen und geschickten Entfernen von Hindernissen, die ein Team an der effizienten Arbeit hindern. Alle Infos hier.

Scrum Lollipops

Jeden Morgen um 9:45 Uhr findet sich das Team vor dem Taskboard im Teamraum zusammen. Einer nimmt einen Stift in die Hand, der andere stellt die Uhr neben dem Taskboard auf 15 Minuten. Der Entwickler mit dem Stift in der Hand wartet auf meine kurze morgendliche Begrüßung und fängt an. „Also, was habe ich gestern gemacht…?“ Die Tasks werden neu arrangiert, einer bleibt in Progress und bekommt mit dem Stift einen Punkt aufgedrückt. Der Entwickler schaut in die Runde und sagt: „Hier muss ich einen Punkt machen, das dauert noch. Aber ich bin dran, das heute abzuschließen!“ Man merkt den anderen die brennenden Fragen an, aber sie halten sich zurück. Der Stift wird nach der Beantwortung der zwei weiteren Fragen „Was mache ich heute?“ und „Gibt es etwas, das mich an meiner Arbeit hindert oder stört?“ an das nächste Teammitglied weitergereicht. Einige haben ihre Aufgaben des letzten Tages auf einen Notizzettel geschrieben und tragen ihre Notizen bei der Beantwortung der drei Fragen vor. Der Entwickler bemerkt die fragenden Gesichter und ergänzt: „Wie das im Detail aussieht, erzähle ich euch nach dem Daily.“ Nach einem kurzen Blick in die Runde bleibt der fragende Blick beim ScrumMaster hängen. Ich nicke ab. Der Stift wandert weiter. Noch sind die 15 Minuten nicht vorbei, alle 8 Teammitglieder haben sich ausgetauscht und sind nun auf dem gleichem Stand. Sie haben sich synchronisiert.
 
Ein anderer Entwickler  steht nun beim TeamBacklog neben dem Taskboard und sagt: „Wir wollten uns doch nach dem Daily noch mal kurz zusammensetzen, um die technischen Details zu klären.“ Dabei zeigt er auf den Task, der aus der Retrospektive in das TeamBacklog übernommen wurde. „Sollen wir uns dazu in der Teamecke an den Tisch setzen?“  Die anderen folgen ihm und die aufgestockten Fragen entladen sich.
 
Nach dem kurzen An- und Abmoderieren bleibt mir nur die Frage: „Darf ich euch vielleicht einen Kaffee bringen?“
 
Die Mitglieder dieses Teams kennen sich größtenteils erst seit ein paar Tagen und Wochen. Sie befinden sich im zweiten Sprint. Wenn nach so zeitnaher, intrinsich motivierter Regelkonformität dem ScrumMaster nichts anderes bleibt, als das stolze Gefühl ein super Team übernommen und weiterentwickelt zu haben, dann bringe ich auch gerne einen Kaffee. Und schenke in Gedanken jedem mit einem Lächeln im Gesicht einen Lollipop.

Erfolgreiche Meetings in drei Minuten

„Vorbereitung ist die halbe Miete“, sagt eine Volksweisheit. Das trifft auch auf die Vorbereitung auf Meetings zu. Ein paar Fragen, die man sich vor einem Treffen stellt, erleichtern die Vorbereitung.
Bei der Vorbereitung kann man drei Ebenen unterscheiden: die inhaltliche, methodische und organisatorische Vorbereitung.
Bei der inhaltlichen Vorbereitung geht es – nomen es omen – um den Inhalt der Besprechung. Hier sollte geklärt werden, worum es eigentlich geht und was das Hauptziel der Veranstaltung ist. Geht es um Informations- oder Meinungsaustausch, oder sollten bereits Entscheidungen getroffen werden? Ist das schon ein Review oder erst ein Planungsmeeting? Geht es um das Kennenlernen oder um das Auflösen des Projekts? Welche Themen werden zur Sprache kommen und sollte ich als Moderator zur Vorbereitung noch etwas mehr über das Thema in Erfahrung bringen?
Die methodische Vorbereitung beinhaltet das Erstellen eines Regieplans oder einer Dramaturgie für das Meeting. Wie gestaltet man den Einstieg, welche Themen kommen vor, in welcher Reihenfolge werden die Themen bearbeitet, Planen der Maßnahmen, Pausen, Abschluss? Wieviel Zeit soll man den einzelnen Slots lassen bzw. zuweisen? Sollte die Gruppe der Teilnehmer bei einzelnen Slots (z. B. Maßnahmenausarbeitung) geteilt werden oder nicht? Sind Reaktivierungsübungen notwendig? 
In die organisatorische Vorbereitung fließen Themen zu Zeit, Raum und Medien. Welcher Personenkreis muss eingeladen werden und wie wird er eingeladen? Wann soll die Einladung rausgehen, was soll in der Einladung stehen? Findet der Termin auf jeden Fall statt, ist er an die Teilnahme einer bestimmten Person geknüpft oder ist eine Mindestanzahl an Teilnehmern nötig? Wo findet der Termin statt? Entspricht der Raum der Vorgehensweise, z. B. ist er groß und mobil genug, hat er die notwendige technische Ausstattung?
Diese Fragen helfen, den Handlungsbedarf schnell zu erkennen und rechtzeitig Maßnahmen zu setzen. Eine gute Inspirationsquelle ist es auch, die eigene Vorbereitung und die aufgestellte Agenda mit jemandem vorab zu besprechen und Feedback einzuholen. Ich bekam mal in einem Unternehmen folgenden Tipp: „Olga, falls du willst, dass Leute deiner Einladung und dem Termin zusagen, nenn bitte das „Meeting“ irgendwie anders – Arbeitstreffen, Workshop, etc. Das Wort „Meeting“ ist bei uns negativ behaftet.”

The Retrospective in Scrum

Bearing in mind Hofstede’s Dimensions.

The Retrospective is one of those personal meetings where I feel that my duty as a ScrumMaster is to enable each one of my Team members to freely voice his or her opinion. Another one of my tasks is – as always – to facilitate the smooth running of the meeting‘s moderation. Particularly when faced with a geographically dispersed Team, this can be somewhat of a challenge.
Thanks to Hofstede‘s cultural dimensions and personal experience, I have become particularly aware of the elements of individualism and power distance amongst different locations. Since my current Team covers six time zones and a couple of fascinating cultures, I am continuously trying to find the right approach to minimise the aspects of strong collectivism or large hierarchy without pushing any of my Team members into a situation where they might lose face.
One such way to hold a successful Retrospective is to divide up the Team into smaller groups and make sure that cultures, power and character traits are well mixed. This allows each Team member the possibility to voice his or her opinion and concerns on the last Sprint without the presence of the supervisor. Furthermore, I have found the medium of the chat rather fulfilling, as it enables my Team members to write more freely and speak more directly. In a chat session, nobody can be interrupted and language issues can be worked out more easily.

Building upon past Retrospectives, I would like to share some of my experience with you and guide you through a successful Retrospective with a geographically dispersed Team.

 
Start off by asking your Team members to prepare for the upcoming Retrospective by collecting their thoughts in a separate document prior to the Retrospective, from which they can then simply copy and paste into the chat. This ensures that the time spent chatting is used in the most efficient way.
The actual Retrospective is divided into two parts (depending on the size of your Team, you might even have three parts).
1) Split your Team into two hierarchically mixed-up, cross-cultural groups. Nominate one session moderator per group. Each group will have exactly 40 minutes to discuss and work through the following five topics by using chat.

Discussion #1

What specific events happened during the Sprint? (Split them up into when they happened: at the beginning, middle and end of the Sprint)
Explanation: Have your Team members write down three events that spring to their mind. Anything and everything, both personal and work-related things. The three events could be:

Anything that comes to your Team members‘ minds when someone tells them to reflect on everything that has happened over the past 2 weeks should be noted down. At least three events would be good, since something always happens in one‘s life over the course of one Sprint!

Discussion #2

What went well? For example: we fixed lots of bugs, we started considering the Definition of Done prior to actually moving a Story to Done on the Taskboard, communication improved thanks to the new telephone system etc.
While Discussion #1 lists specific events (personal and/or business-related) from the perspective of an individual Team member, Discussion #2 names things that worked well for the Team within this Sprint, which would be good to see repeated in the next Sprint.

Discussion #3

What could be improved? Explanation: The Team members should list issues or things that happened in the last Sprint that need improving for the next Sprint.

Discussion #4

The Team members need to prioritise the list of items that came out of discussing #3 and select the top three things which need improving the most.

Discussion #5

Brainstorm on measures that can be derived from these top three future improvements and think about how to present them in the next session.
 
2) The next and final session of the Retrospective will take 40 minutes and include all Team members via telephone conference. Here, the prioritised results from Discussion #3 and the proposed measures from each group chat should be presented to the other Team members. Together, discuss these prioritised improvements and measures and make sure that you come out of the Retrospective with three overall top priority measures that can and will be acted upon by everyone in the next Sprint in order to improve the Team‘s productivity. The ScrumMaster may facilitate this final session.

Tips & Tricks

I believe that if Discussion #1 were to be left unaddressed, a major element of the Retrospective (the personal element) would be left out. Discussion #1 sometimes gives you a special insight into personal issues that may have “infiltrated” the Sprint without anyone‘s notice. Furthermore, it often unveils underlying Team issues that may not be addressed by Discussions #2 and #3. Consider the following situation: one of your Team members writes down the event „Tuesday I worked all throughout the night because I had to fix bug X. As a result, I was tired and irritated the next day.“ By reading this, the other Team members immediately realises that s/he is not the cranky person they had thought her/him to be, but rather that they have let down their Team member. Nobody should have to work throughout the night, particularly not on their own.
This could be turned into future measures, such as: Everyone has to offer help to at least one other Team member per day. Every Team member has to ask at least once during the Daily Scrum whether s/he can help another team member. The often empty phrase of „How are you?“ should be taken more seriously.
If we had, however, combined Discussion #1 into Discussions #2 and #3, this event might have never come up. Sometimes these problems, such as staying up all night, are not named during Discussion #3, since Team members do not believe that their situation could be improved. When, in fact, their fellow Team members can help.
 

… keep the Timebox.
… ensure that the group members discuss the correct topics during the 40 minute chats. Often, Team members jump from Discussion #1 to Discussion #3 and back to Discussion #2. However, each topic should get its own time slot.
… summarise and list the results of the Discussions not only in order to bring them forward in the Team session, but to have them as documentation.
… note down the proposed future improvements in a list and help out with the voting process for prioritisation.
Depending on your Team members‘ personalities, cultures and language know-how, the chat sessions could be exchanged with telephone conferences.

Have fun and good luck trying this method! I am looking forward to hearing your feedback.

 
This article is the result of teamwork between Stephanie Gasche & Kristina Klessmann.

15 Minuten sind 15 Minuten

Bei der Beobachtung verschiedener Teams und der Durchführung des Daily Scrum bemerke ich gelegentlich, dass das Einhalten von 15 Minuten mitunter sehr schwierig ist. Nicht nur, dass die 15 Minuten teilweise überschritten oder extrem gedehnt werden. Zum Teil scheinen Sinn und Zweck überhaupt ganz zu fehlen.
 
Es geht im Daily Scrum nicht darum, nur einen Fahrplan einzuhalten, weil irgendjemand mal festgelegt hat, dass 15 Minuten auf der Uhr besser nachzuvollziehen sind, als 13 oder 17.
Der ScrumMaster ist gefordert, darauf zu achten. Allzu oft passiert es aber, dass man am Gesicht des ScrumMasters ablesen kann, dass er Verständnis für die Überziehung dieses täglichen Meetings hat. „Sie sollen sich ja austauschen, dafür ist das Meeting ja da, oder nicht?“ Ja und Nein. Manchmal ist der ScrumMaster so sehr Teil des Teams, da steht er im Kreis und hört sich die Inhalte und den regen Austausch an. Als Außenstehender würde ich dann gerne einschreiten und sofort fragen „Ist das für das Daily jetzt wichtig oder können wir das im Anschluss klären?“ Da heißt es, sich zurückzunehmen. Auch fällt es manchen ScrumMastern schwer, sich durchzusetzen und den Austausch zu unterbinden. Ja man läuft Gefahr, sich in diesem Augenblick unbeliebt zu machen, das gehört dazu. Aber warum halten wir uns in Scrum und auch im Daily Scrum an derart straffe Timeboxen?

Die Timebox macht sichtbar

Das Daily hat den Hintergrund, dass sich das Team täglich synchronisieren soll. Anhand der Fragen kann jedes einzelne Teammitglied den anderen mitteilen, was gestern an Tasks erledigt wurde, was heute erledigt werden soll und welche Hindernisse dabei aufgekommen sind oder eventuell noch anstehen könnten. Der ScrumMaster steht idealerweise mit Stift und Zettel bewaffnet dabei und notiert seine Aufgaben. Denn das sind seine Tasks. Für jeden Einzelnen im Team heißt es wiederum festzustellen, wer woran arbeitet und ob es bei den zu erledigenden Tasks zu Abhängigkeiten oder anderen Fragen kommt. Diese Fragen, die dann im Kopf aufkommen, erfüllen den Anlass des Daily Scrum. Zum einen handelt es sich bei der Synchronisation, basierend auf den drei Fragen, um die Feststellung des tatsächlichen und aktuellen Standes. Ja auch um einen Statusbericht darüber, welche Resultate bereits erzielt wurden, welche angestrebt werden und warum angestrebte Ziele nicht erreicht wurden. Kurz gesagt, das Daily bietet einen Anlass zur Kommunikation und Konversation.
Denn nicht IM Daily werden Probleme gelöst, sie werden in diesen 15 Minuten nur sichtbar gemacht. Alle Themen oder Fragen, die an dieser Stelle auftauchen, können NACH dem Daily miteinander und untereinander geklärt werden. Scrum gibt 15 Minuten vor, aber Scrum verbietet ja nicht, nach dem Daily noch kurz zusammenzustehen und sich auszutauschen. Scrum verhindert nicht, im Anschluss zum Schreibtisch des anderen zu rollen und nachzufragen. Und die Absicht liegt nicht darin, 15 Minuten Unruhe zu stiften, damit sich im Anschluss an das Daily wieder alle an ihren Schreibtisch setzen und leise vor sich hinarbeiten.
 
Dem ScrumMaster gebührt Nachsicht und Verständnis für vieles, aber nicht dafür, dass er sein Team nicht in 15 Minuten durch ein Daily begleiten kann. Es ist seine Aufgabe darauf zu achten, Sinn und Zweck zu verstehen und bei Unsicherheiten noch einmal darauf hinzuweisen.
15 Minuten sind 15 Minuten.

Sich zu verstehen ist auch Teamarbeit – ein Warm-up für das Sprint Planning

Mit einer anderen Person zu sprechen, dieser etwas mitzuteilen, sich mit ihr zu unterhalten, sich argumentativ auszutauschen, hat häufig zum Ergebnis, dass die beiden Gesprächspartner auseinandergehen und genauso klaffen ihre Bilder der Situation vollkommen auseinander. Bereits im Kindergarten machen wir beim Spielen erste Erfahrungen mit dieser Kommunikationsprämisse. Jedes Kind kennt „Stille Post“. Ein Kind flüstert einem zweiten eine Botschaft ins Ohr. Das zweite Kind gibt das, was es gehört bzw. verstanden hat, an ein drittes Kind weiter. Die Nachricht wird bis zum letzten Empfänger weitergegeben. Was am Ende der Kommunikationskette rauskommt, lässt die Spieler meistens in schallendes Gelächter ausbrechen. Denn es ist inhaltlich etwas vollkommen anderes als das, was kurz zuvor auf die Reise geschickt wurde. In der Kinderwelt ist es einfach ein lustiges Spiel. In der Kundenwelt und im Management von Wünschen und Anforderungen ist es ein Graus und trägt oftmals zu Missverständnissen und Fehlschlägen bei.
Der Anspruch zu “verstehen, was der Kunde haben möchte” und die sich daraus ableitende Forderung “sicherzustellen, dass er genau das auch bekommt” (Colin Hood, Experte Systems Engineering) sind hoch – insbesondere dann, wenn wir uns vor Augen führen, was es bedeutet, einen Anderen (in diesem Fall den Kunden) zu verstehen.
“Verstehen hat seinen eigentlichen Ort in menschlichen Gesprächen. Sofern wir eine Sprache zu sprechen gelernt haben, wissen wir (…) zu unterscheiden, ob wir jemanden verstanden zu haben glauben, oder ob wir, was jemand gesagt hat, verstanden haben, wenn er oder sie uns etwas mitteilt (das ist die Grammatik des Ausdrucks mitteilen: jemand teilt jemandem etwas unter Verwendung von Mitteln mit). Und wir sagen dann, wir  hätten ihn oder sie verstanden, wenn wir nicht nur das Gesagte (den ‚Inhalt’, die Proposition), sondern auch die bestimmte Art und Weise, in der uns jemand etwas mitteilt, richtig aufgefasst haben, und das heißt zunächst: Wenn unsere Auffassung unwidersprochen bleibt. In metaphorischer Annäherung: Wir haben verstanden, wenn wir sagen können, dass wir das, was uns jemand mitgeteilt hat, miteinander teilen. Wir beurteilen unser Miteinander-Sprechen  dann unter Verwendung des Ausdrucks ‚verstehen’, wenn wir, was und wie mitgeteilt wurde, gemeinsam haben.”  (Jan Müller, 2008)

Richtig verstehen und richtig weitergeben

Ein Product Owner ist bei der Erstellung seines Product Backlogs für das Erfassen der Kundenbedürfnisse und die Beschreibung der damit verbundenen Anforderungen verantwortlich. Um dies im Sinne des Kunden angemessen leisten zu können, gehört es zu seinen Aufgaben, die Bedürfnisse der Kunden, Enduser und anderer Interessenvertreter richtig zu verstehen und kontinuierlich zu bearbeiten. Verstehen zu wollen, was ein Kunde haben möchte, ist allerdings alles andere als einfach (und das nicht nur aufgrund des oben beschriebenen Verständnisses von “Verstehen”). Oft spricht man mit den falschen Personen, nicht selten weiß der Auftraggeber gar nicht, was er wirklich will oder der Kunde teilt uns bereits Lösungen mit, anstatt Anforderungen zu beschreiben. In jedem dieser genannten Fälle erhöht sich das Risiko, dass die Entwicklung eines Produktes in die falsche Richtung läuft und so eine “falsche” Lösung gebaut wird. Der Product Owner besitzt hoffentlich die Kraft der Unterscheidung und lässt es in die Anforderungen einfließen, die er schließlich an sein Entwicklungsteam kommuniziert.
Ist euch was aufgefallen? Wer genau gelesen hat, wird feststellen, dass das Aufgabenspektrum des Product Owners eine große Ähnlichkeit mit dem Stille-Post-Spiel hat. Der Kunde sagt dem Product Owner, was er will. Der PO überführt diese Wünsche in sein Product Backlog. Den wichtigsten und am höchsten priorisierten Ausschnitt des Backlogs bringt der Product Owner zum Entwicklungsteam ins Sprint Planning und dort wird dann geplant, was und wie die Anforderungen (übersetzt in User Stories) umgesetzt werden sollen. Wohl dem, der jetzt weiß, wie man richtig versteht. 
Ich habe eine gute und eine weniger gute Nachricht. Die weniger gute Nachricht ist, dass das mit dem Richtig-Verstehen nicht leicht ist. Das kann ich euch mit diesem Beitrag lediglich bewusst machen (Erkenntnis als erster Schritt der Verbesserung). Die gute Nachricht allerdings ist, dass es etablierte Mittel und Methoden gibt, das Richtig-Verstehen zu üben und besser darin zu werden.

Sprach-Übungsfeld Baustelle

Eine spielerische Methode möchte ich euch vorstellen. Oft scheitert Kommunikation, weil zu viel Information auf einmal weitergegeben wird und/oder nicht die gleiche Sprache gesprochen wird. Sprache ist ein nicht genormtes Ausdrucksmedium! Jeder Mensch ist in der Verwendung von Sprache von seiner (Alltags-)Umwelt, seinem fachlichen Hintergrund, seinen sonstigen Kenntnissen und seinen persönlichen (Lebens-)Erfahrungen geprägt. Sprache bringt das alles individuell zum Ausdruck. Missverständnisse in der Kommunikation sind quasi vorprogrammiert und nahezu unvermeidlich. Ein Widerspruch in sich: Es geht (scheinbar) nicht mit, aber (wohl auch nicht) ohne Kommunikation! Um sich dieses Dilemma vor Augen zu führen und am eigenen Leib zu erleben, empfehle ich, das Planspiel „Auf der Baustelle“ vor einem Sprint Planning Meeting auszuprobieren. Es wird euch Augen und Ohren öffnen – versprochen!

Auf der Baustelle – die Aufgabe und die fünf Rollen

Die Aufgabe ist es, mit verteilten und klar definierten Rollen ein Lego-Modell nachzubauen. Die fünf Rollen sind

Der Informant

Der Informant sieht das Modell und beschreibt es dem Boten. Er hat Kontakt zum Boten und zum Rückmelder.

Der Bote

Der Bote gibt die Informationen, die er vom Informanten erhält, an den Baumeister weiter. Er sieht weder das Modell noch den Nachbau des Baumeisters. Er hat Kontakt zum Informanten, zum Baumeister und zum Rückmelder.

Der Baumeister

Der Baumeister (Product Owner) baut nach den Informationen des Boten das Modell nach. Die dazu benötigten Teile besorgt er sich beim Materialverwalter. Er hat Kontakt zum Boten, zum Materialverwalter und zum Rückmelder.

Der Materialverwalter

Der Materialverwalter gibt dem Baumeister die Steine, die er anfordert. Er sieht weder das Modell noch den Nachbau des Baumeisters. Er hat Kontakt zum Baumeister und zum Rückmelder.

Der Rückmelder

Der Rückmelder darf sowohl das Modell wie auch den Nachbau sehen. Er hat Kontakt zu allen anderen. Seine Kommunikation beschränkt sich jedoch darauf, dass Fragen, die ihm gestellt werden, nur mit JA oder NEIN beantworten darf. Jede weitere Äußerung ist ihm untersagt.

Die Planung

Die Planungsphase dauert vom Zeichen „Start“ an 15 Minuten. Entscheidet ein Team, vor Ablauf der Zeit mit der Planung fertig zu sein, kann es früher mit dem Bau beginnen. Folgende Anweisungen sind in der Planungsphase vom Team umzusetzen:

Die Zutaten

Tipps zur Durchführung

Nach dem Spiel ist vor dem Spiel – Fragen für ein After Action Review

 
Viel Erfolg beim besseren Verstehen! 
Literatur
Peter Dürrschmidt et. al. Methodensammlung für Trainerinnen und Trainer. 2009. managerSeminare.

S wie Scrum

Nehmen wir an, ihr wollt euch bewusst machen, was euer Gehirn mit einem Begriff oder einem Ziel verbindet, welche Informationen, Ideen und so weiter es dazu gespeichert hat. Dafür gibt es ein Kreativitätsübung bzw. -methode: Die ABC Liste.
Schreibt dazu zunächst das Alphabet von A bis Z auf. Nehmt dann jeden Buchstaben und überlegt, was euch zu ein bestimmte Begriff einfällt, welche Assoziationen der Buchstabe also in euch auslöst. Schreibt  einfach auf, was euch ganz spontan zu einem Buchstaben durch den Kopf geht. Ihr könnt die Buchstaben der Reihe nach bearbeiten oder wild springen. Sie könnt zu jedem einzelnen Buchstaben etwas schreiben oder – wenn euch nichts einfallen sollte – auch einige weglassen. Wie ihr genau vorgeht, ist egal. Lasst es fließen.
Was läuft in eurem Kopf ab, wenn ihr an SCRUM denkt? Welche Assoziationen habt ihr persönlich zu SCRUM?
Macht mit!
Übrigens kann das auch ein gute Kennenlernen-Übung für die Retrospektive sein. Jedes Teammitglied zieht den Namen eines anderen und schreibt ein ABC Liste über ihn oder sie!Agile!

A Agile!
B Backlog – Begeistern – “Böööcks” (so klingt es, wenn ich “Bug” sage)
C Commitment
D Done – Design
E Effizienz – Emotionen
F Fehlertoleranz
G Goals
H (ich benutze allgemein diese Buchstabe nicht! Französin :))
I Initiative
J jubeln
K Kultur – Kommunikation – Kreativität
L Liefern – Lernen – Leadership
M Mindset – menschlich
N natürlich
O Offenheit – Ownership
P Produkt
Q Qualität
R Rolle – Respekt
S Sprint – Selbst-Organisation
T Timebox – Team
U User
V Veränderung – Vertrauen
W Wände – viele Wände
X Xperience
Y (da bin ich überfragt, so viele Wörter mit Y gibt‘s nicht. Es ist doch schlimmer als Scrabble!!)
Z Zusammen – Ziele

Was hat Fußball mit Zielen zu tun – und das alles mit Scrum?

Bei der Google-Suche nach Zielen werden innerhalb von 0,23 Sekunden ungefähr 49.300.000 Ergebnisse geliefert. Bei der Suche mit dem englischen Pendant „Goal“ liefert Google 866.000.000 in 0.14 Sekunden. Doppelbelegungen des Begriffes im Englischen könnten diesen fast 18-fachen Unterschied erklären: einerseits steht es für „Tor“ und andererseits für „Ziel“. Aber über Fußball wurde in den letzten Wochen ja allgemein viel – und auch viel qualifizierter, als ich es kann – gesprochen. Ich würde mich dagegen gerne mit den Zielen befassen.
Ziele lauern überall und sind äußerst vielfältig. Sie unterscheiden sich in ihrer zeitlichen Ausrichtung und können kurz-, mittel- oder langfristig sein. Dann im Umfang – mit Minimal-, Normal- oder Optimalzielen. Zudem gibt es komplementäre, indifferente oder konkurrierende Ziele, quantitative und qualitative Ziele, utopische oder realistische. Letzteres lässt sich zusätzlich durch eine weitere Kategorisierung beschreiben: erreichte oder nicht erreichte Zeile.
Die Güte der Ziele entsteht zum größten Teil durch die Zielformulierung. Sir John Whitmore, ehemaliger britischer Autorennfahrer und heute Coach und Berater, hat folgende drei Anagramme für die Zielformulierung verwendet: SMART, PURE und CLEAR.
SMART
S – specific (Präzise)
M – measurable (Messbar)
A – achievable (Erreichbar)
R – realistic (Realistisch)
T – time phased (zeitlich planbar)
PURE
P – positively stated (positiv formuliert)
U – understood (verständlich)
R – relevant (relevant)
E – ethical (ethisch)
CLEAR
C – challenging (herausfordernd)
L – legal (legal)
E – environmentally sound (umweltverträglich)
A – agreed (vereinbart)
R – recorded (protokolliert)
Bei jedem eurer Ziele solltet ihr euch fragen: Ist euer Ziel präzise, messbar, erreichbar, realistisch, zeitlich planbar, positiv formuliert, verständlich, relevant, ethisch korrekt, herausfordernd, legal, umweltverträglich, vereinbart und protokolliert?
Der Weg vom Ziel zu Scrum führt über die Betrachtung der Scrum-Artefakte mit dem Ziel, Ziele zu finden. Diese sind teilweise buchstäblich vorhanden – im SprintZIEL. In jeder User Story steckt das Schaffen von Mehrwert für Kunden als Ziel. Personas zielen auf besseres Verständnis der Kunden. Jedes der Meetings hat ein eigenes Ziel:

Es fing mit Zielen und Fußball an, also sollte es wohl auch mit beidem enden. „Nach dem Spiel ist vor dem Spiel“ wird zu „Nach dem Sprint ist vor dem Sprint“. Also viel Spaß beim Formulieren eurer Ziele!

Teamgeist, immer und überall

Teamgeist und Kommunikation werden mittlerweile überall großgeschrieben – keine Frage. Aber wie konsequent sind wir in der Umsetzung?
Vielleicht kennt ihr folgende Situation auch aus eurem Unternehmen: Ein unerwartetes Ereignis tritt ein – ein gravierender Fehler aus dem laufenden Betrieb, ein dringender Wunsch der Geschäftsführung, eine nicht aufschiebbare Kundenzusage. Und plötzlich wenden sich alle Augen auf die Person(en) im Unternehmen, denen die größte Kompetenz in diesem Themenbereich zugesprochen wird. Die Gesetze eines zuvor noch selbständig arbeitendes Teams gelten nicht mehr, sie weichen dem Druck, schnelle Ergebnisse liefern zu müssen und dem Wunsch nach “klaren Ansagen”. Kollektive Entscheidungsfindung, wie sie in Scrum-Teams gelebt wird, gilt plötzlich als unnötige Zeitverschwendung.
Ist an dieser Notfall-Strategie vielleicht etwas dran? Wie erfolgsrelevant ist Kommunikation im Vergleich zu anderen Faktoren wie fachliche Expertise oder analytische Fähigkeiten?
Eine Forschungsgruppe des Massachusetts Institute of Technology (MIT) hat dazu ein spannendes Experiment durchgeführt, das in der Mai-Ausgabe 2012 des Harvard Business Managers veröffentlich ist. Dafür haben die Forscher über sieben Jahre hinweg das Kommunikationsverhalten von 2500 Menschen in 21 Unternehmen und Organisationen aufgezeichnet, darunter Bankfilialen, Krankenhaus-Teams und Call-Center. Jede Person wurde mit einem kleinen, diskreten elektronischen Gerät ausgestattet, das über 100 Datenpunkte pro Minute aufzeichnet. Tonfall, Körpersprache, Häufigkeit der Kontaktaufnahme – das sind einige der soziometrischen Daten, die damit erhoben wurden.
Das Ergebnis der Untersuchung ist ebenso spannend wie aufschlussreich. Es zeigt, dass für die Aufstellung von erfolgreichen Teams eine gute Kommunikation wichtiger ist als alle anderen üblicherweise herangezogenen Faktoren, wie z.B. die Intelligenz oder Kompetenz der Teammitglieder.
Wie aber sieht ein gut kommunizierendes Team aus? Aus der Studie kristallisieren sich Eigenschaften heraus, die erfolgreiche Teams gemeinsam haben:

Ihr macht schon Scrum? Schaut euch doch mal ein Daily Scrum an und beobachtet in diesen fünfzehn Minuten, inwiefern die oben genannten Merkmale zutreffen. Ihr werdet auch ohne aufwändige Aufzeichnungsgeräte schnell ein Gefühl für die Kommunikationsmuster in euren Teams bekommen.
Wir von bor!sgloger glauben, dass Teams nicht dadurch erfolgreich werden, dass sie dazu angehalten werden. Ein Meeting kann angeordnet, ein Leistungsziel vereinbart werden. Aber wie kriegt ihr Teams dazu, auch beim Mittagessen und in der Kaffeepause das Gespräch zu suchen? Wie schafft ihr es, dass eure Teammitglieder montags zur Arbeit kommen und ihren Kollegen von einem Wochenenderlebnis – einer Lektüre, einem Gespräch, einem Geistesblitz – erzählen, der das Team weiterbringt? Das sind Dinge, die aus der inneren Dynamik eines Teams heraus geschehen müssen. Das ist Teamgeist.
Deshalb ist es auch so wichtig, Teams wachsen und gedeihen zu lassen. Dazu braucht es zum einen die richtigen Rahmenbedingungen – vom geeigneten Teamraum bis zu einer Unternehmenskultur, die Gruppen- über Einzelleistung stellt. Zum anderen braucht es eine Führungsrolle, die weiß, was das Team in sechs Monaten und in einem Jahr erreichen kann, und es entsprechend fördert. Wir nennen diese Rolle ScrumMaster.
Die Rolle des ScrumMasters wird gerne unterschätzt – viele sehe in ihm bloß eine Mischung aus Organisator, Erbsenzähler und Wachhund. Ein guter ScrumMaster vermag indes dem Team Atem einzuhauchen und es auf eine gemeinsame Reise zu schicken. Er gibt dem Team ein “shared sense of purpose” und schafft es, dass sich die Teammitglieder darauf freuen, den Tag mit ihren Kollegen bestreiten zu dürfen. In Scrum merken wir das am Pull-Prinzip. Nicht der Product Owner muss die Teams dazu bringen, Stories in den neuen Sprint zu nehmen. Nein, die Teams selber “ziehen” sich die Stories aus dem Product Backlog und committen sich darauf, weil sie Lust darauf haben, sie umzusetzen. Diese Umkehr im Denken – weg vom Drängeln und Vorschreiben, hin zum Ermuntern und Machen lassen – gilt es zu vollziehen.
Wie werdet ihr beim nächsten Notfall reagieren? Werdet ihr den Teams zutrauen, die Situation selber in den Griff zu bekommen? Oder werdet ihr als Experten einmal mehr einsame Helden im Kampf gegen die Windmühlen der Komplexität sein?
Alex Pentland: Kommunikation ist der Schlüssel. In: Harvard Business Manager, Mai 2012, S. 36-48.
Gilda Feller: Es muss schnell gehen, heute machen wir kein Scrum
ScrumMaster Pro Training TeamDevelopment

Schätztauchen

In dem Boot auf dem Roten Meer in Ägypten, kurz vor meinem allerersten Tauchgang, habe ich nicht mit meinem Tauchlehrer diskutiert, ob es die richtige Methode ist, auf die Innenseite der Taucherbrille zu spucken und meinen Speichel zu verteilen. Damit sie nicht beschlägt, während ich mich in 25 m Tiefe befinde und ich dann blind herumschwimme. Mein Tauchlehrer hat lediglich die kurze Anleitung gegeben, ist abgetaucht und … ich habs einfach gemacht.

Warum?

Er ist der Profi, also könnte es funktionieren. Der potentielle Diskussionspartner schwieg sowieso unter der Wasseroberfläche und Zeichensprache kann ich nicht so besonders gut. Die Zeit war knapp und ich beschloss, eben diese für den eigentlichen Tauchgang zu nutzen und ihn später zur Rechenschaft zu ziehen.
Zehn Jahre später befinde ich mich als Consultant von bor!sgloger auf einem anderen Schiff, in einer interessanten Projektsituation:
Wir haben 15 Minuten pro Scrum-Team, um mit ihnen ihr erstes Estimation Meeting durchzuführen. In Anbetracht der Zeit(-Not) bat ich das Team, mir zu vertrauen und in den nächsten 13 Minuten (2 Minuten waren schon aufgrund einer knappen, aber herzlichen Begrüßung und Vorstellung vergangen) zu schweigen und sich auf das Magic Estimation Meeting einzulassen.
“Ich verspreche, euch nach dem Meeting, in den kommenden Tagen zu JEDER Frage, JEDER Skepsis, JEDER Kritik bzgl. unserer Art und Weise zu schätzen, Rede und Antwort zu stehen. Wenn wir uns in den nächsten 12 Minuten einfach darauf einlassen und… einfach machen.
1 heißt User Story ist klein
2 User Story ist doppelt so groß
3 User Story ist wie 1 & 2
Fibonacci eben.
Die 13 sollte quasi euer Sprint-Limit darstellen und bei der 20 ist die User Story nicht “Sprint-Ready”, sprich zu groß und/oder komplex und/oder hat zu viele Features etc.
Euer Product Owner verteilt nun die User Stories, jeder schätzt die User Story, die er soeben erhalten hat und legt sie an die entsprechenden Storypoints.
Im Anschluss seht ihr euch die von euren Teamkollegen geschätzte User Stories an und schätzt ab, ob sie mit eurem Bauchgefühl d’accord gehen. Wenn ja – einfach liegen lassen und falls nein – einfach umlegen. Er darf es selbstverständlich zurücklegen. Nach dem dritten Mal wird die User Story aus dieser Runde herausgenommen und ist somit JETZT nicht mehr relevant.
Vielleicht wisst ihr von einem Teamkollegen, dass er mit dem Feature bzw. dem Thema einer User Story Erfahrung hat, und vertraut ihm bei seiner Schätzung.    
Das einzige Instrument, das ihr nun braucht, ist euer Bauch. Beruhigt ihn damit, dass ihr mich in den nächsten Tagen auf ein heißen Stuhl setzen dürft.
Wir haben nun noch 10 Minuten – also: Ab geht`s!
Grinsen, Stirnrunzeln und ein letztes “der ganz heiße Stuhl… hihi” – und es wird geschätzt.
Bei allen drei Teams, die ich in den nächsten 45 Minuten betreut habe, hat es tatsächlich ohne Probleme funktioniert. Aber warum? Warum wird das Schätzen immer wieder thematisiert und so gern stundenlang diskutiert?
Weil die Zeit dafür “da” ist.
Selbstverständlich habe ich in den nächsten Tagen viele Gespräche geführt und Erklärungen geliefert. Sehr oft habe ich dasselbe in verschiedenen Formulierungen und Beispielen beschrieben, den hervorragenden Blog meiner Kollegin Klessmann verteilt, und habe sogar mit Müll geschätzt. (Die Putzkolonne hatte aufgeräumt, es standen verschiedene volle, blaue Müllsäcke und diverse Pappkartons herum … Doing as a way of recycling. True story.) Wenn wir keine Zeit haben, uns mit etwas genauer zu beschäftigen, fällt es uns Menschen doch wesentlich einfacher zu vertrauen, intuitiv Entscheidungen zu fällen und unseren Bauch gewähren zu lassen.

Natürlich werde ich weiterhin Erklärungen und Fragen zu unseren Methoden liefern. Die erste Erkenntnis hinkt jedoch oft dem Vertrauen und dem Tun hinterher. Die kleinen Verbesserungen kommen dann ganz von allein:

Gelerntes verlernen oder warum gute ScrumMaster keine Antworten geben

Wenn Mike Cohn davon spricht, dass der Übergang zur Agilität mit Scrum schwer ist, dann meint er Eigenheiten wie: Der angestrebte Endzustand ist unvorhersehbar, Veränderungen treten schneller als jemals zuvor ein oder dass der Wandel nicht ausschließlich von oben nach unten oder von unten nach oben erfolgt. Scrum wirkt sich nicht nur auf alles aus, was Menschen tun, sondern konterkariert auch das, was sie irgendwann mal gelernt und für gut befunden haben. Vor Scrum mussten Tester zum Beispiel prüfen, ob Spezifikationen eingehalten werden. Entwickler  dagegen sollten erst nach der Problemanalyse und mit einem (perfekten) Lösungsentwurf in der Tasche mit dem Programmieren loslegen. Und jetzt, mit Scrum? Tester müssen lernen, die Bedürfnissen der Anwender zu verstehen und Entwickler müssen lernen, dass man auch ohne perfekten Entwurf mit dem Programmieren beginnen kann.
Kurzum: Sie müssen Gelerntes wieder verlernen und stattdessen auf eine unvertraute Art und Weise denken und handeln. Scrum ist deutlich anders.

Linear-kausal war einmal

Die Menschen, die die verantwortungsvolle Rolle des ScrumMasters übernehmen, sind vom Anderssein bzw. Anderswerden nicht weniger betroffen – ganz im Gegenteil. Der ScrumMaster muss in diesem Wirkungsgefüge, dem offenkundigen Widerspruch begegnen, zwar ein führender Helfer des Teams zu sein, aber das ohne Anspruch auf Autorität realisieren zu müssen. Damit beschränkt sich die Autorität des ScrumMasters erstmal (nur) auf die Kontrolle des Prozesses. Anders als ein Projektleiter kann er sich in seinem Tun nicht auf die Position „Sie machen das jetzt, weil ich es Ihnen sage“ beziehen. Um dem Team bei der Anwendung von Scrum zu helfen oder Hürden jeglicher Art aus dem Weg zu räumen, braucht der ScrumMaster somit ein Werkzeug, mit dem er dieses (scheinbare) Autoritätsdefizit überwinden kann. Dazu muss auch er gewohnte Handlungsarten ablegen bzw. verlernen. Wir sind es gewöhnt, linear-kausal zu denken: Aus A folgt B und A ist „schuld“, dass B entsteht. Linear-kausales Denken ist immer vergangenheitsbezogen und damit ursachenorientiert. Das heißt, es gibt konkrete Ursachen für bestimmte Auswirkungen und damit eindeutig nachweisbare Verantwortliche für bestimmte Ergebnisse. So nachvollziehbar ein Ergebnis sein wird, so gefährlich ist der Versuch, Komplexität auf diese vereinfachende Weise zu reduzieren und dabei Wechselwirkungen vollkommen zu ignorieren.
Gute ScrumMaster suchen niemals nach Ursachen oder Schuldigen, sondern analysieren, welche „Muster von Kommunikationen, Beziehungen und Handlungen im Zusammenhang mit anderen Mustern zu einem Ergebnis führen“ (Radatz, 2000, S. 67), d.h. sie denken systemisch. Systemisch Denken heißt, in Auswirkungen zu denken und davon auszugehen, dass nie nur einer allein Schuld an der Entstehung einer bestimmten Situation hat, wenn mehrere, in welcher Form auch immer, beteiligt sind/waren. Daher ist es auch vollkommen unerheblich, wer der Ver-Ursache-r war. Ein systemisch denkender ScrumMaster blickt nicht in die Vergangenheit (Problemsicht), sondern in die Zukunft (Lösungs- und Zielsicht):
[quote author = “Steve de Shazer”]”Problem talking creates problems. Solution talking creates solutions.”[/quote]
De Shazer möchte vor allem so verstanden werden, dass die Lösung (das Ziel) mit dem Problem niemals etwas zu tun hat. Wenn man also einen Menschen bei seiner Problemlösung unterstützen möchte, dann bringt es nichts, ausführlich über das Problem und dessen Ursachen zu konferieren.
Merke: Das Problem hat nichts mit der Lösung zu tun.

Warum warum niemanden weiterbringt

Natürlich schließt systemisches Denken die aktive Auseinandersetzung mit der Vergangenheit nicht aus, aber eben nicht, um Ursachenforschung zu betreiben oder misslungene Handlungsmuster zu analysieren. Statt analysierend-statisch über Vergangenes nachzudenken, geht es darum, zukunfts-, verhaltens- und zielorientierte Aspekte zu erfragen und mit dem Befragten wohlgeformte Lösungsbilder zu erarbeiten:

Weg von Problemfragen … … hin zu Lösungsfragen
Welche Ursachen hat das Problem? Was müsste wer/wann zukünftig anders tun, damit ein besseres Resultat herauskommt?
Wer hat es verursacht? Was müsstest du vor allem/als erstes tun/unterlassen?
Wer hat mehr Schuld? Was willst du mit deinem geänderten Verhalten erreichen?
Was ist das Schlimmste daran? Was soll in Zukunft anders sein?
Was ist in der Vergangenheit schief gelaufen? An welchem Verhalten von dir würde jemand anders merken, dass du dein Ziel erreicht hast?

Wenn ihr euch als ScrumMaster jetzt an systemischen Fragen versuchen wollt, dann beginnt mit zweierlei:

Ihr fragt euch jetzt sicher: Warum?
Wenn man die Gründe für etwas herausfinden will, dann ist es wenig erkenntnisreich, nach dem Warum zu fragen. Menschen antworten auf eine Warum-Frage meistens mit bereits zurechtgelegten Antworten. Und diese fördern das Verständnis der Situation kaum. Ein Warum, Wieso oder Weshalb ist fast immer mit negativen Konsequenzen verbunden und zieht den Befragten wieder tiefer in den Problemsog.
Wie fragt man, wenn man nicht warum fragen soll? Eine Inspiration findet ihr, wenn ihr die Geschichte aus der Zauberwerkstatt vom „empfindlichen Fragezeichen“ lest. Probiert es aus. Und wann merkt ihr, dass ihr eine gute Frage gestellt habt? Je länger der Befragte braucht, um die Frage zu beantworten, desto einschneidender war sie.
Eins steht fest: Wer richtig fragt, muss keine Antworten geben, weil sich die Befragten in vielen Situation ihre Antworten selbst geben und die Wirkung einer Frage dazu führt, die eigenen Gedanken zu ordnen, zu strukturieren und aus einem anderen Blickwinkel zu betrachten bzw. zu hinterfragen.
 
Literatur:
Sonja Radatz (2000). Beratung ohne Ratschlag. Systemisches Coaching für Führungskräfte und BeraterInnen. VSM.
Alexa Mohl. Metaphern-Lernbuch: Geschichten und Anleitungen aus der Zauberwerkstatt. www.junfermann.de
Steve de Shazer (2010). Worte waren ursprünglich Zauber. Von der Problem zur Lösungssprache. Carl-Auer.

Spielerisch für Veränderungen sorgen

Um einen Tisch sitzen sechs Product Owner und ein ScrumMaster. Die POs sind mit Post-its und Stiften bewaffnet. In der Mitte des Tisches liegt eine Spielkarte. Sie ist verdeckt. Der ScrumMaster dreht die verdeckte Karte um. Darauf ist eine Kreidetafel mit folgendem Inhalt zu sehen: „Wegen Zu geschlossen! Neueröffnung März 2007“. Der ScrumMaster gibt die kurze Anweisung: „2 Minuten Zeit. An die Stifte, fertig, los!“ – und die Product Owner beginnen mit dem Schreiben.
Ihr fragt euch, was hier gerade passiert? Hier spielt ein Product Owner Team „Happy Aua“. Das ursprünglich von Bastian Sick entwickelte Bilderspiel aus dem „Irrgarten der deutschen Sprache“ dient leicht abgewandelt als Kreativitätswerkzeug und soll Product Owner auf spielerische Weise dabei unterstützen, das Formulieren von Produktvisionen zu üben. Je origineller und lustiger der Kommentar zur Karte formuliert ist, umso besser. Die Abstimmung, welcher der Kommentare der jeweils Beste ist, erfolgt gemeinsam.

Spiele bei der Arbeit?

Führen und spielen? Veränderung und Spaß? Schließt das eine das andere nicht aus? Aus meiner Sicht sollten Arbeiten, Lernen und Spielen nicht voneinander getrennt werden. Spielen steht für eine Interventionsform, die Menschen in eine Welt entführt, in der alles passieren kann. Auch, wenn noch immer überwiegend die Meinung in der Arbeitswelt vorherrscht, dass Spiele für die Freizeit reserviert oder lediglich Kindern gestattet sind, finden Menschen wie Arne Gillert, Autor des Buches „Der Spielfaktor. Warum wir besser arbeiten, wenn wir spielen“, in Unternehmen immer stärker Gehör. Er behauptet: „Wer spielerisch an die Arbeit geht, gelangt ernsthaft zu neuen Lösungen.“ Trockene Arbeitsthemen oder schier unlösbare Situationen bekommen durch spielerisches Denken und Handeln neue Impulse, weil dabei eine Quelle (fast) vergessener Ressourcen angezapft wird.
Wann habt ihr das letzte Mal Kindern beim Spielen zugesehen?  Kinder lernen in ihrer frühen Entwicklung so viel und so schnell – und seid euch sicher:  Lernen ist Arbeit – wie nie mehr wieder in eurem Leben. Wie tun sie das? Sie spielen. Sie spielen den ganzen Tag lang. Dabei befinden sie sich in einer Welt, in der ihr Geist fokussiert, hochkonzentriert und 100% aufnahmefähig ist. Die gewonnenen Erkenntnisse und Erfahrungen, das Neue, werden so wirksam im Gedankengut verankert. So sind sie für den Rest des Lebens abrufbar und es kann wiederum Neues damit assoziiert werden.
Bürotätigkeiten, Meetings, Seminare, Schulungen, Workshops oder Vorträge – all das ist Arbeit. Und allzu oft beschäftigt sich diese Arbeit nur mit Begriffen von Dingen und eben nicht mit den Dingen selbst und ihren Beziehungen zur Umwelt. Der Mensch aber braucht Entfaltungsmöglichkeiten seines individuellen Lern- und Arbeitsstils. Um dabei jedem auf seine eigene Weise gerecht zu werden und gleichzeitig für den zu vermittelnden Lernstoff Aufmerksamkeit zu bekommen, müssen Möglichkeiten geschaffen werden, die Information in die jeweilige Individualsprache, die Assoziationswelt jedes Einzelnen zu transferieren.

Spielen kann das.
Spielen erhöht nicht nur die Aufnahme- und Lernbereitschaft. Spielen ist uns allen vor allem vertraut. Schließlich waren wir alle mal spielende Kinder. Und Vertrautes schenkt uns die Freude des Wiedererkennens. Freude steuert wiederum Aufmerksamkeit, öffnet unsere Bereitschaft, (Lern-)Energien zu mobilisieren und ein Gefühl zu erleben, das uns im Kontinuum des Arbeitsalltags häufig verloren geht, nämlich die kindliche Gier nach neuen Erfahrungen: die Neugier. Neugierde kompensiert nicht nur die Angst vor Fremdem, sondern ist der Schlüssel zu in uns schlummernden Handlungsräumen wie Kreativität, Experimentierfreude, Freigeist oder Spontaneität.

Spielen braucht Handlungsräume

Spielen findet überall dort statt, wo die Folgen des eigenen Handelns begrenzt sind – also dort, wo ein Fehlverhalten keine Katastrophen oder Repressalien nach sich zieht. Schon die Bereitstellung eines sicheren Rahmens (z.B. Hier darf heute wirklich alles passieren) sorgt dafür, dass Menschen Neues ausprobieren wollen/werden.
Das schönste Spiel im Rahmen eines Sprints ist die Retrospektive. Sicher fragt ihr euch jetzt, ob ich die gleiche Retrospektive meine wie ihr. Ja und nein. Fragt doch mal euer Team: „Was lief gut?“ und fragt es ebenso „Was könnte verbessert werden?“ Allerdings probiert  zum Einstieg mal das „Spinnennetz“ aus (vermutlich kein Scrum-Team, aber hier gibt es ein kurzes Video zu einer Outdoor-Variante):

Sorgt für (Spiel-)Räume, die eine ungestörte Erarbeitung individueller Lösungen ermöglicht und ihr werdet sehen, dass die Teammitglieder dabei bereitwillig Verantwortung übernehmen.

Spielen ist Handeln, Spielen ist nicht Planen

Vor kurzem habe ich ein Kind beim LEGO-Spiel gefragt: „Was wirst du jetzt bauen?“ Ohne aufzusehen, zuckte es mit den Schultern und murmelte: „Das weiß ich nicht.“ Eine halbe Stunde später stand dort ein kleines Kunstwerk. Ich hätte das SO niemals hinbekommen! Das Kind hatte keinen Planungsworkshop belegt, bevor es mit dem Bauen anfing, sondern legte einfach los.
Natürlich ist es wichtig, einen Plan in der Tasche zu haben, weil die Ausrichtung unseres Handelns auf ein größeres Ziel nun mal dazugehört, um so den besten Weg zu diesem Ziel herauszufinden. Aber wie gut sind Pläne wirklich? Eigentlich sollten wir es aus den Erfahrungen der abertausend gescheiterten Projekte, denen scheinbar wasserdichte Pläne zugrunde lagen, besser wissen.
Versteht mich nicht falsch! Spielen bedeutet nicht, dass Planen überflüssig ist. Es ist sogar essentiell. Allerdings geht es darum, über das Maß nachzudenken. Wie viel Planung ist tatsächlich nötig, um anfangen zu können. Nicht selten ist weniger wirklich mehr. Erfolgreiche Beispiele dafür sind die Schätzspiele „Magic Estimation“ und „Planning Poker“. Traditionelle Aufwandsschätzungen funktionieren nun mal nicht und verschwenden nicht nur Zeit, sondern sind relativ zu ihrem Effekt gesehen vollkommen übertrieben. Deshalb traut euch und spielt!

Spielen fängt im Kopf an

Wenn ich in meinen Trainings mit den Lerngruppen spiele, stelle ich – zwar in unterschiedlichen Ausprägungen – aber trotzdem immer wieder das Gleiche fest: Ist das Spiel erstmal angefangen, dann machen die Spielenden kaum bis keinen keinen Unterschied zwischen der Realität und dem, was Spiel ist. Wer spielt, der stellt sich etwas vor und taucht ab in seine (Spiel-)Welt. Die Vorstellungskraft gehört mitunter zu den mächtigsten Denkwerkzeugen des Menschen.
Nehmt das Daily Scrum als Versuchsballon. Schenkt jedem Teammitglied ein Überraschungsei. Die Schokolade ist euer Geschenk an jeden aus eurem Team. Der jeweilige Ü-Ei-Inhalt definiert das individuelles Motto des Tages oder der Woche oder des aktuellen Sprints. Lasst das Team immer wieder einen Bezug herstellen. Analogien, Metaphern, Geschichten lockern die Stimmung im Team auf und sorgen für ein Mehr an Leichtigkeit im Tun.
David Holzer, Trainer & Scrum Consultant

Scrum Guide 2011: Jeden Tag ein Event

Ich habe am aktuellen Scrum Guide von Ken und Jeff den schleichenden Verlust essenzieller Scrum-Werte kritisiert. Meinetwegen kann man mir Kleinkariertheit oder Erbsenzählerei vorwerfen. Was ist denn schon dabei, wenn wir forecasten anstatt uns zu committen, sind Offenheit und Transparenz nicht das Gleiche? Nein, gerade die subtilen Unterschiede in der Wortwahl sind die Ursache dafür, dass eine Idee plötzlich nicht mehr den Vorteil aller im Blick hat, sondern den Vorteil einzelner Interessensgruppen. „Unverbindlichkeit“ ist für mich der Grundtenor, der sehr oft mitschwingt. Auch bei den Scrum Meetings, die jetzt als „Events“ bezeichnet werden, werde ich diesen Eindruck nicht vollkommen los.
Events statt Meetings? Ich weiß ja nicht, was ihr bei Events so tut: Aber ich habe Spaß, schlage mir den Bauch am Buffet voll und hake es dann in meiner Erinnerung als lustig oder langweilig ab. Ich stelle mir gerade das Daily Event mit Brötchen und Sekt vor, mit dem ScrumMaster als Nummerngirl und mit den abstrusen Wünschen des Product Owner als Showeinlage. Meetings in Scrum sind keine Partys. Am Ende gibt es Ergebnisse und Arbeitsaufträge, also wäre vielleicht „Workshop“ eine gangbare Alternative gewesen, um das Gefühl zu vermitteln, dass es sich doch tatsächlich um Arbeit handelt.
Sprint Planning Meeting. Ich verstehe ja die Idee eines Plans, aber hier hätte Ken die Chance gehabt, nachzuschärfen, dass es nicht um den Plan geht, sondern um den Dialog.  Klar entsteht ein Plan, aber im Planning Meeting ging es immer ums Planen. Alle Beteiligten sollen sich miteinander im Dialog einigen, was sie gemeinsam in diesem Sprint erreichen sollen.
Vollkommen am Ziel vorbei ist für mich – sowohl im alten als auch im neuen Scrum Guide – die Formulierung, dass es hier um „work“ geht. Nicht, dass die Teilnehmer nicht über Arbeit reden dürfen, aber der Fokus auf Arbeit ist falsch. Das Entwicklungsteam muss im ersten Workshop erst einmal verstehen, was überhaupt gebraucht wird und aufbauend auf diesem Verständnis im zweiten Teil designen. Das ist eine vollkommen andere Fokussierung (siehe Werte), als wenn ich sofort über das Planen von Arbeit rede. Leider sagt Ken auch, es ginge darum zu bestimmen, was das „Development Team can assess what it can accomplish  …“ Leider hat Ken, obwohl er es besser weiß, hier noch immer nicht den springenden Punkt herausgearbeitet: Es geht nicht ums KÖNNEN, sondern ums WOLLEN. Wer will, findet einen Weg. Wer nur KANN, kann sich rausreden.
Zum Thema Schätzen im Sprint Planning Meeting 2: Bitte vergesst es einfach. Ken und Jeff haben ihre Ideen dazu vor 15 Jahren entwickelt. Sie sind überholt. Basta. (Wer wissen will warum – mein Blog ist voll davon).
Daily Scrum. In einer aktualisierten Version des Guides hätte ich erwartet, dass die drei Fragen endlich verschwinden. Ja, es war die große Errungenschaft von Jeff, aus dem 4-Stunden-Meeting des Borland Quattro Teams,  in dem sich das Team synchronisiert hat, mit diesen Fragen ein 15 minütiges Daily Scrum zu machen. Aber er hat mit diesen Fragen auch den Eindruck erweckt, dass das Daily Scrum ein Status Meeting ist. Es hat uns Coaches Jahre gekostet, dieses falsche Verständnis des Daily Scrum wieder aus den Köpfen zu bekommen. Heute nutzen alle ein Scrumboard – damit sind diese drei Fragen obsolet. Ich hätte mir im neuen Guide endlich den Hinweis erwartet, dass es beim Daily Scrum um die Idee des gemeinsamen Arbeitens geht.
Was man im neuen Guide  leider immer noch findet, ist die Idee des Vergleichs zwischen actual und plan. Dieses Verständnis  hat mal dazu geführt, dass wir in die Burn-Down Charts Trendlinien eingezogen hatten. Wir wissen heute, dass die Trendlinien ebenfalls zu Produktivitätsverlusten, statt gewinnen geführt haben.
Sprint Review. Bitte überlest den Teil des Guides. BITTE! Hier reden die beiden noch von einer Abnahme des Gelieferten durch den Product Owner. Sie verstehen das auch immer noch so. Komplett sinnfrei, wenn man Story für Story liefert. Wenn man will, dass der PO zum Scrum-Team gehört: Wieso sollte er dann ein Approval aussprechen und wieso vor der gesamten Firma? Es funktioniert so nicht. Wir von bor!sgloger stehen mit dieser Haltung alleine da. Aber alleine waren wir auch mit unserer Meinung, dass man Taskboards statt Listen führen und Dailys als Dialog sehen sollte, die Tasks nicht auf weniger als einen Tag runterbrechen soll, im Sprint Planning 2 den Code anzuschauen, …
Dass das Team im Review darüber redet was falsch lief? Ist auch eine Reminiszenz an die alte Idee des Sprint Reviews. Da hat es 4 Stunden gedauert. Heute gibt es dafür die Retrospektive.
Cancelling a Sprint. In der Beschreibung der Rollen sagen Ken und Jeff, dass niemand dem Entwicklungsteam sagen darf, wie es den Inhalt des Product Backlogs in Produktinkremente umsetzen soll. Im Event-Bereich des Scrum Guide sagen sie, dass nur der Product Owner einen Sprint abbrechen darf. Ich halte diese Extrempositionen für problematisch und bei genauerer Betrachtung widersprechen sie sich auch. Wieder ist es wohl die heftige Wortwahl, die mich irritiert: „no one tells the Development Team …“ In der Praxis fördert das zwei kontraproduktive Haltungen: Die eine nennt sich Größenwahn und die zweite heißt Angst. Angst davor, mit anderen Leuten außerhalb des Entwicklungsteams über die eigene Arbeit zu reden und sich dadurch wertvollen Input zu holen. Rollenabgrenzung bedeutet nicht, Meinungen und Sichtweisen anderer zu ignorieren. Genau das vermittelt aber das harsche „no one tells …“. Interessanterweise soll  das Team dann beim Abbruch eines Sprints aber gar nichts mehr zu sagen haben? Nur der Product Owner hat die Autorität, er darf aber unter Einfluss des Teams handeln. Es gibt Situationen, in denen das Team selbst am besten beurteilen kann, ob ein Sprint noch zu retten ist oder nicht. Und dann sollte es nicht erst den PO beeinflussen müssen, sondern abbrechen dürfen.
Wieder wird so getan, als wäre es ein Desaster einen Sprint abzubrechen. Wieso? Wenn das Team eine Story nach der anderen liefert, dann breche ich ab, wenn ich eine Story nicht liefern kann, oder wenn ich sehe, dass wir in eine vollkommen verkehrte Richtung laufen, wenn wir aus Druck weiter arbeiten oder… alles ganz normal und meistens auch der wirtschaftlichere Weg.
Sprint Goal. Vielleicht liegt es am „Forecast“, aber es wird nicht deutlich, ob PO und Team denn nun ein Sprint Goal vereinbaren oder nicht. Auf Seite 10 oben des Scrum Guide „forecastet“ das Team den Lieferumfang des Sprints. Machen wir es doch einfacher.  Wenn wir uns eine Sache von KANBAN abschauen sollten, dann die: Es wird einfach explizit eine Story nach der anderen geliefert – damit überholt sich die Idee des Sprint Goals von selbst.

Scrum Essentials: Das Ende der Meetings

“Oh Mann … schon wieder ein Meeting.” So oder so ähnlich hört man es immer wieder. “Scrum produziert ja so viele Meetings. Das ist so öde und unproduktiv.” Ich kann diese Stoßseufzer mittlerweile immer besser verstehen, weil uns mehr und mehr Teams um Hilfe bitten. Wir sollen mal einen Blick darauf werfen, warum Scrum bei ihnen nicht so läuft, wie es immer versprochen wird. Die Antwort ist oft ganz einfach: Weil in diesen Teams die meisten Dinge nicht so umgesetzt werden, wie wir es empfehlen.

Mit der Reihe Scrum Essentials möchte ich Euch die Best Practices der letzten Jahre näherbringen. Fangen wir mit den Meetings in Scrum an:

  1. In Scrum gibt es keine Meetings!
  2. Jedes so genannte Scrum Meeting ist eine Arbeitssitzung = Workshop.
  3. Jeder Workshop muss klare Resultate liefern.
  4. Es ist immer die Mitarbeit aller Teammitglieder gefragt.
  5. Jeder Workshop MUSS so KURZ wie möglich gehalten werden.
  6. Der ScrumMaster ist dafür verantwortlich, dass jeder Workshop optimal abläuft.
  7. Immer wenn sich zwei oder mehr Mitarbeiter in einem Gespräch “festreden”, sollte der ScrumMaster sofort beginnen, dieses Meeting zu moderieren und dadurch für klare Ergebnisse sorgen.
  8. ALLE Scrum Workshops sind ausnahmslos notwendig.
  9. Weitere Meetings, die nicht originär zur Lösung einer Story beitragen, sollten möglichst vermieden werden.
  10. Workshops und Meetings müssen immer einen zeitlichen Rahmen (=Timebox) haben.

Mehr Scrum Essentials gibt es in den nächsten Tagen und Wochen.