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.
ballon-106920_1280

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: