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