Sei du selbst die Veränderung, die du dir wünschst für diese Welt!

Mit diesem Zitat von Mahatma Ghandi möchte ich eine Überleitung zu den kleinen alltäglichen Dingen schaffen, die jedoch schnell deutlich positive Wirkung haben können. Das kann heißen, die Teammitglieder am Morgen mit einem freundlichen Händeschütteln zu begrüßen, ihnen häufig ein Lächeln zu schenken oder mit regelmäßigen anerkennenden Worten zu ihrem Verhalten oder ihren Taten Respekt zu zollen. Es wird sich zeigen, dass ihre Erwartungen diesbezüglich übertroffen werden, denn sie sind diese Verhaltensweisen aus ihrem Berufsleben sehr wahrscheinlich nicht gewohnt. Ich selbst bin beruflich mit der Philosphie „behandle andere so, wie du selbst behandelt werden möchtest“ aufgewachsen. Daher erlebe ich, wenn ich mich daran halte, dass es aus dem Wald heraus schallt, wie ich es hinein rufe. Die anderen sind der Spiegel eines selbst. Dies meine ich hier im positiven Sinne. Schenke ich den Teammitgliedern einen respektvollen und freundlichen Umgang, so erhalte ich diesen zurück.

Taten sagen mehr als 1000 Worte!

Stehe zu dem was du sagst, besonders zu dem, was du ankündigst. Das ist eine Erkenntnis, die ich aus vielen Erfahrungen teilen möchte. Teammitglieder, Mitarbeiter, Kollegen oder andere merken sich in der Regel sehr gut, was angekündigt wurde. Es herrscht also eine Erwartungshaltung. Auch wenn sie noch so klein ist. Das können wir gut finden oder eben auch nicht. Aber es ist so. Wir haben sie durch Worte erzeugt. Also sollten wir unseren Worten auch Taten folgen lassen. Nicht nur das. Ob ich vorgebe, also sage, ein engagierter Kollege, in unserem Falle SrumMaster zu sein, oder es tatsächlich vorlebe, ist ein großer Unterschied. Fragen wir uns also. Ehrlich und im Stillen mit uns selbst. Bin ich wirklich für die Teamkollegen da? Habe ich ein Ohr für ihre Themen? Lebe ich Engagement vor oder sehe ich eigentlich zu, stets sehr pünktlich den Arbeitsplatz zu verlassen und bin meist der Erste, der geht?

Schaffe Transparenz!

Ganz egal, ob als ScrumMaster, Manager, Führungskraft … Man steht im Fokus. Gewollt oder nicht. Die Berechtigung den „Hut“ zu tragen, der uns zum ScrumMaster macht, müssen wir uns immer wieder durch Taten verdienen. Hier hilft uns die Transparenz. Häufig ist die Arbeit eines ScrumMasters nicht so sehr sichtbar. Wir hacken nicht den halben Tag in unseren Computer. Wir sind häufig nicht zu sehen, da wir in irgendwelchen Meetings stecken und abends können wir keine Verkaufszahlen präsentieren. Machen wir doch also einfach transparent, was wir den Tag über so tun. Machen wir es sichtbar. Wir brechen uns keinen Zacken aus der Krone. Und, ich finde es geht die Teammitglieder sehr wohl etwas an, was ich für sie und unser Team den lieben langen Tag so tue. Das funktioniert sehr gut über ein persönliches Taskboard, das in Papierform (Flipchart) an unserem Platz hängt, sowie ein ebenso sichtbares Impediment Backlog. Unsere Aufgabe ist es schließlich, Impediments aufzuspüren und aus dem Weg zu räumen. Das darf gerne sichtbar sein. Erledigte Impediments oder Tasks wandern über unser Board. Ein Gradmesser für unsere Leistung. Für uns und unsere Teamkollegen. Letztlich möchte ich mich noch dafür aussprechen ebenso transparent zu machen, wo ich mich befinde. Auch das kann man am persönlichen Taskboard ersichtlich machen. „Im Meeting/Raum xyz oder auch „in der Mittagspause“ sind mögliche Varianten, dem Team zu zeigen, dass ich es respektiere.

Die Beispiele, die ich heute beschrieben habe, sind sehr leicht umzusetzen, haben jedoch große Wirkung. Denn häufig scheitert es einfach im Kleinen und in der Häufung dieser Kleinigkeiten. Wer kennt es nicht?! „Mein Chef sagt mir nie Guten Morgen“ oder „…nie werde ich gelobt“. Diese und andere Aussagen haben wir alle schon gehört oder vielleicht sogar gemacht. Gehen wir also mit positivem Beispiel voran und sorgen für eine gute Stimmung. Lieferung, Qualität, Produktivität und Profitabilität sind zwar die klaren Erwartungen und Ziele, die ein Scrum-Team verfolgt und erfolgreich macht. Das, was uns letztlich jedoch glücklich macht neben unseren Erfolgen, ist eines: Stimmung.

Abschließend möchte ich eine Frage zum Nachdenken stellen:

„Ob groß oder klein. Begeisterung ist nichts anderes als übertroffene Erwartung. Was tue ich dafür?“

Related posts:

1. Was sind StoryPoints?
2. Schätzen vs. Planen?
3. Taskboard Design

Auf meinen vielen Reisen habe ich stets die beste Möglichkeit zu reflektieren. Sei es im Zug, Taxi, Bus, Flugzeug oder in der U-Bahn – ich genieße es, diese Zeit damit zu überbrücken, dass ich meine Gedanken über die letzten Stunden schweifen lasse. Im Zug von München nach Oldenburg reflektierte ich letztens über das Team Booster Training, das ich in den letzten zwei Tagen bei Dieter Rösner absolviert hatte. Wir waren eine spannende Gruppe (bestehend aus zehn Männern und mir als Quotenlady), die durch die Teamentwicklungsübungen innerhalb von 16 Stunden Training, einem Sushi-Dinner in der Innenstadt und einem Absacker-Weizen an der Hotelbar langsam aber stetig zusammenwuchs. Die erste Übung, die wir jedoch als „Team“ durchführen hätten sollen, war der Sin Obelisk. Diese Übung wird mir noch eine Weile in Erinnerung bleiben.

In diesem Spiel geht es darum, anhand von (teilweise unnötigen) Informationen auf Spielkarten eine einigermaßen simple Rechenaufgabe im Team zu lösen. Das Spiel zeigt die Dynamik von Teams sehr gut auf. Wer mehr zu diesem Spiel erfahren möchte, kann es gerne hier (http://www.teamentwickler.eu/sin-obelisk) nachlesen.

Unsere Durchführung war das reinste Chaos. Da ich normalerweise aus dem Blickwinkel des Coaches ein Team beobachte, fand ich es spannend, mal Teil eines DevTeams sein zu dürfen. Oh boy, hab ich das schnell bereut! Obwohl ich nun doch ein Weilchen im agilen Umfeld tätig bin und schon einige Teams gesehen habe, verlief die Kommunikation und Rollenteilung letztendlich so chaotisch, dass ich mich mental komplett ausklingen musste und die Hälfte des Spieles nur von der Seitenlinie aus zusah.

Weshalb kam es dazu? Und weshalb hat niemand darauf reagiert, dass sich ein Teammitglied abseilt? Oft gibt es keine simple Antwort auf diese Frage, doch in diesem Fall schon. Zwei Themen spielten darauf ein: Rollentrennung und Misskommunikation. Der ScrumMaster war kein ScrumMaster, sondern agierte stattdessen als DevTeammitglied. Das DevTeam hat es – u.a. als Resultat daraus – nicht geschafft, auf einer Ebene zu kommunizieren. Die Liste an Frustrationen, die innerhalb von 40 Minuten aufgrund dieser zwei elementaren Fehler zustande kamen, ist lang.

Hauptproblem: Kein gemeinsames Ziel

Die Fragestellung der gewünschten Lösung war einigen Personen bis zum Schluss unklar. Die (mangelnde) Visualisierung wurde nur dank eines Dev.Teammitglieds gestartet. Der ScrumMaster war Schriftführer und Rechenmeister zugleich. Die Konversationen liefen kreuz und quer. Wenn eine Frage auftrat, wurde sie nur zur Hälfte beantwortet, da sich alle ständig gegenseitig unterbrachen. Unnütze Informationen, die schon als solche identifiziert worden waren, wurden weiterhin öfters in den Raum geworfen. Der Kunde wurde nicht eingebunden. Obwohl eine (falsche) Lösung in der Hälfte der Zeit ausgerechnet wurde, verschwendeten wir die gesamte Timebox (Sprint), statt den Kunden früher um Feedback zu bitten. Als ein Dev.Teammitglied für (Kommunikations-)Ordnung sorgen wollte, kam eine direkte Ansage vom mitentwickelnden ScrumMaster: „Ich bin hier der ScrumMaster.“ Das i-Pünktelchen war für mich erreicht, als ein Einzelgänger im Dev.Team die korrekte Antwort fand, diese vom Kunden bestätigt bekam und das Team in seiner Dynamik weiterhin auf seinem eigenen, aber falschen (Rechen-)Weg beharrte.

Die multiplen Vergleiche zu einem echten Scrum-Team werde ich nicht explizit aufzählen. Die kann man schnell erkennen bzw. spätestens nach dem eigenen Ausprobieren der Übung vermutlich bestätigen. Doch eines möchte ich hervorheben: Unsere Ausübung des Sin Obelisks hat die Wichtigkeit der ScrumMaster Rolle auch für alle Skeptiker verdeutlicht. Hätte der dezidierte ScrumMaster seine Führungsrolle komplett eingenommen, hätte er darauf geachtet, dass das WAS klar ist, bevor wir uns in das WIE stürzen. Er hätte jedem eine Stimme gegeben und das Kommunikationschaos entbündelt. Das Feedback des Kunden wäre frühzeitig eingefordert worden und er hätte sich über jeden Verbesserungsvorschlag aus dem Team gefreut. Und so wären wir gemeinsam und vermutlich schneller zur Lösung gekommen – ohne dass ich von der Seitenlinie zuschauen musste und ein Dev.Teammitglied die Lösung alleine fand.

Doch eines muss ich dem ScrumMaster lassen: In der anschließenden Retrospektive war er sehr reflektiert und äußerte viel Selbstkritik. Hätten wir die Übung ein weiteres Mal spielen können, bin ich mir sicher, dass wir eine eindeutige Verbesserung erzielt hätten. Und nicht nur, weil wir die richtige Antwort dann schon kannten…

Termine zu den nächsten Scrum Supplements Trainings mit Dieter Rösner findet ihr hier.

Related posts:

1. Der ScrumMaster ist eine Versicherung (Mike Beedle)
2. Fussball EM und 3 Sprints | Scrum ist überall !
3. ScrumMeetings moderieren oder „ein ScrumMaster hat nichts zu tun“

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:

• Das SoS wurde im Rahmen des Dailys wieder fokussiert thematisiert, indem die ScrumMaster ihre Teammitglieder fragten, ob es spannende Themen, wichtige Informationen (z.B. Abhängigkeiten), hilfreiche Neuerungen oder andere Exklusivitäten gibt, die sie im SoS vorstellen möchten.
• Den Teams wurde vollkommen frei gestellt, was und wie sie ihre Themen im SoS einbringen.

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.

Related posts:

1. Die drei weiteren Rollen in Scrum
2. 5 min on Scrum | Es gibt noch viel zu tun
3. Skills | ScrumMaster | Führung

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!

Related posts:

1. Warum sind soziale Systeme so schwer steuerbar? Ein Erklärungsversuch.
2. Vorweihnachtsretro
3. ScrumMaster vs. ScrumMasterin

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:

• Just as you would with a co-located Team, make sure to visualize the design concepts, so that all Team members are on the same page. The writing of rough Tasks should only happen at the very end.
• if necessary and possible, split up the User Stories amongst the various locations, where the Team members can draw up the concept and afterwards present it to the rest of the Team.

Related posts:

1. Sprint Planning with geographically dispersed teams located in different timezones
2. Pre-SP2 Design Sessions or How to use your Time during a Sprint Change
3. How internationally distributed Teams can improve their Sprint Planning 1

Ein ScrumMaster sollte daher stets auf der Hut sein. Er sollte zumindest um den Halo-Effekt wissen und nicht nur sich, sondern auch sein Team vor seinen Fallen schützen. Denn es ist gerade das System “Team”, das den Sirenen des Halo-Effekts auf besondere Weise verfällt: “teams tend not to be blamed for their failures“. Charles E. Naquin and Renee O. Tynan von der Universität von Notre Dame fanden in “The Team Halo Effect: Why Teams Are Not Blamed for Their Failures”  Nachweise dafür, dass “the nature of the causal attribution processes used to diagnose failure scenarios leads to individuals being more likely to be identified as the cause of team failure than the team as a collective. Team schema development, as indexed by team experience, influences this effect, with individuals who have more team experience being less likely to show the team halo effect.”

Wenn das Team halo-ziniert

In zwei interessanten Studien belegen Naquin und Tynan ihre Hypothesen, die für jeden ScrumMaster Anlass sein sollten, sich und die Performance seines Teams kritisch zu hinterfragen. Ich gebe diese Empfehlung, weil Teams, genauso wie Individuen (vgl. Attributionstheorie von Weiner, die zu den kognitiven Emotionstheorien zählt), zwar die Ursachen ihrer Erfolge den eigenen Fähigkeiten zubilligen, Misserfolge werden jedoch meist (nicht immer, aber überwiegend) äußeren Einflüssen (und eben nicht mangelhafter Planung, unzureichender Kommunikation, schlechter interner Aufgabenverteilung oder fehlender Schwerpunktbildung) zugeschrieben. Der selbstkritische Blick wird durch die eigene Hybris verfälscht und durchgehend abgeschwächt. Selbst Retrospektiven, also die eigens für ein Team geschaffene Plattform, offen, direkt und schonungslos eine Inventur der eigenen Performance zu machen, um möglichst produktiver zu werden, geben im Schritt 4 “Was könnte verbessert werden” ausreichend Gelegenheit für Halo-zinationen: z.B. “Wir haben viel zu viele Meetings, um überhaupt was arbeiten zu können”, “Wir sind viel zu heterogen, um unsere Arbeit zu teilen oder an den gleichen Aufgaben gemeinsam zu performen”, “Wir können das SP1 und das SP2 ruhig mischen. Das geht doch dann alles viel schneller”, usw.

Das Phänomen des Halo-Effekts ist typisch, menschlich und nicht vollkommen auszuschalten. Aber es lässt sich eindämmen, indem der ScrumMaster es offen anspricht und den Mut hat, seinem Team den Spiegel vorzuhalten. Er ist der Prozesshüter. Er ist verantwortlich, dass die Produktivität steigt. Gelingen kann das, wenn das Team seine Leistung ohne Halo-zinationen beleuchtet und auf dieser Grundlage hinterfragt. Nur so kann die “Weisheit der Vielen” zur Entfaltung kommen und die wirklichen Stärken einer Gruppe zum Ausdruck bringen. Das Ganze ist immer mehr als die Summe seiner Teile und demnach sollte der Fokus des ScrumMasters immer auf beiden “Systemen” liegen bzw. sie gleich wichtig analysieren und verbessern wollen: das Individuum und das Team. Ich sehe viel zu selten, dass ein ScrumMaster das Team als Ganzes betrachtet und coacht (außerhalb der Retrospektive). Die Kunst dabei ist, das Team so zu sehen, als wäre es ein Individuum. Aber eben eines mit unterschiedlichen Charakteren – eine ganz besondere Herausforderung.

Literatur

Charles E. Naquin &Renee O. Tynan (2003). Team Halo Effect: Why Teams Are Not Blamed for Their Failures. Journal of Applied Psychology Copyright 2003 by the American Psychological Association, Inc.
2003, Vol. 88, No. 2, 332–340. University of Notre Dame

ScrumMaster sind Meister der Effekte und Illusionen (Teil 1) – der Othello Effekt

Related posts:

1. Education Paradigms & Softskills
2. People needs to “hear and view” colleagues.
3. People needs to "hear and view" colleagues.

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

Related posts:

1. How internationally distributed Teams can improve their Sprint Planning 2
2. Sprint Planning with geographically dispersed teams located in different timezones
3. How internationally distributed Teams can improve their Sprint Review

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.

Related posts:

1. Value Based | Nutzen Schaffen (2)
2. Scrum und Festpreis
3. Führung in Scrum | Manager | Teil 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
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards

Stephanie G.: Now that we have discussed internationally distributed Teams in broader terms, I would like to get to the more practical part of this interview. Let‘s start with the most frequent meeting: the Daily Scrum. Would you say that it‘s more difficult to stay within the time-box of 15 minutes in comparison to co-located Teams? Is there something that you would really advise watching out for during the Daily?

Ina K.: No, I wouldn‘t say that it‘s any different in terms of keeping the time-box. It‘s all about keeping an ear open for discussions that don‘t belong in the Daily. Sometimes it‘s just a matter of using the microphone and asking the Team, “Is the current discussion of interest to everyone? Could we perhaps talk about this afterwards?“ The ScrumMaster should always ponder over how the Daily Scrum could be made even more efficient, since a lack of concentration and focus by the Team members leads to a downward spiral of effectiveness. I always found it important to act as a kind of motivator, meaning that I would try to make the Daily Scrum at least a little bit entertaining. As a ScrumMaster, it is important to get a feeling for the Team – what jokes do they enjoy, what are their character traits, do they prefer technical discussions, do they ever speak of their private lives etc.?! Once you understand your Team, it is much easier to integrate the Team members from the other locations into the Daily. I have seen far too many ScrumMasters (no matter whether co-located or distributed, actually) that sluggishly stand in the background waiting for the meeting to be over – if you don‘t show any enthusiasm for what you propagate, why should your Team members?!

Kristina K.: Actually, in contrast to Ina, we didn’t stick to the 15 minutes, as the Team seemed to need a bit of extra time in order to make the meeting most effective. At the time, I found this to be more important than sticking to a time-box of exactly 15 minutes. It is no surprise, as my Team consisted of about 11 Dev. Team members and several locations. The English language levels varied strongly, the technology was a definite impediment and – as I have already mentioned during the previous question (Interview 4 link) – the tool did not facilitate the flow of the meeting. Still, I always continued analyzing the meeting in terms of its time-box, as this helped me to develop new ideas that could help my Team plan their day better as well as maybe hold an effective meeting in less  time.

Christof B.: That‘s true, Kristina, your situation is not so unusual. Distributed Teams are often larger than co-located ones. If that‘s the case, one simply has to accept the fact that it may take slightly longer than the standard 15 minutes. Also, communicating over the telephone with each other makes the meeting more exhausting (which is why Ina‘s tips are great, by the way) and if the technology was not specifically selected for the Team‘s needs, the likelihood of having to repeat yourself a lot is rather high. Staying within the 15 minutes time-box can really be quite difficult.

Stephanie G.: I‘ve also experienced that the technology has a large impact on the efficiency of the Daily. What do the others think?

Deborah W.: As a ScrumMaster, it‘s important to make sure that all the technology is set up properly well in advance. Ten minutes should suffice if it ensures that the equipment is ready to be used right from the start. As Christof mentioned – depending on the transmission (sadly, most Teams do not have the budget that we had spoken of earlier – see Interview 3), you might have to set the time-box at 20 minutes. When my Team started out, we only used to be able to hear each other, but after less than a week, the Dev. Team independently bought a webcam, so that they could combine the voices with images.

Bernd K.: Oh dear – speaking of transmission. I can‘t even count how many times our connection broke off during any kind of meeting. Also, we didn‘t have a webcam, so it was very important to ensure that everyone knew whose turn it was and who was currently speaking. Whether this is done by saying one‘s name before speaking, through colour codes in the Taskboard tool or some other way, is up to the Team.

Christof B.: I always liked the idea of having a Speaker Token, which can be passed around depending on who wants to go next. You can also play Ping Pong with the Team members in the other locations – Team member in location A followed by Team member in location B, then someone in location A again etc – but this makes it even more difficult to stay within the 15 minutes and the ScrumMaster really has to keep an eye out on who‘s up next. The advantage is that people stay more focused.

Bernd K.: Oh, that sounds quite good, Christof. I‘ll try that out next time. But generally, the Daily was interesting, as it showed a large cultural difference between the Team members in Romania, who were rather held back, and those in German, who would talk quite a lot. As a ScrumMaster, I had to ensure that everyone got his or her turn to voice the current progress of the Tasks.

Stephanie G.: I can imagine that if – as you say – the Team members in Germany were quite talkative, that must have made it difficult to stay within the time-box, as well?! I know my Team always wanted to use this meeting to discuss everything right away and get all questions answered – although these questions had mostly little to do with planning the work for the day.

Bernd K.: That‘s exactly one of the issues that we had. The Team was simply trying to use the opportunity that the connection between the two locations was already established. So I tried to separate the „Now“ and „Later“ a bit more strictly and pushed them towards using group chat rooms more frequently or setting up a telephone connection in the middle of the day in order to coordinate their work. I also encouraged the Team members individually to start picking up the phone and directly calling each other outside of the Daily, too.

Hélène V.: Bernd, I am completely with you. I would really advise to start using the Daily for shortly coordinating everyone‘s availability for the upcoming 24 hours. When sitting together in one room, it‘s easy to figure out the best available time for meeting up and discussing something. This isn‘t the same for distributed Teams. Another option would be to simply say that the Daily is automatically followed by another synchronisation meeting a few hours later. That way, coordination takes place more often and it becomes more natural for the Team members to talk to each other several times throughout the day. But I can say this about the Daily: It really is a challenge to ensure that everyone knows exactly what each Team member is currently working on. This is not just difficult for distributed Teams. But it is important to use the Daily for making this transparent! No matter which tool the Team uses, it should be elusive on what progress has already been made and what is still missing.

Stephanie G.: Thank you! You‘ve given our audience quite a few useful tips. Let‘s see whether I can summarise them as:

• Keep discussions short by objectively asking “Is the current discussion of interest to everyone? If not, could we perhaps talk about this afterwards?“.
• Enable the synchronisation of the work progress across locations.
• Ensure that the distributed Team members speak to each other again at some point over the upcoming 24 hours – whether it be during a second Daily, group chat, staying in the line after the Daily etc.
• Add your personal touch as a ScrumMaster and remember that it‘s up to you to make the meeting more fun and thus more efficient. 
• If the 15 minutes are not possible, make sure to set a different, but equally short time-box and work on eliminating the impediments that are hindering the Team from achieving the original time-box.
• As with every meeting, make sure that the technology is up and running well in advance.

Related posts:

1. How internationally distributed Teams can improve their Sprint Planning 2
2. How internationally distributed Teams can improve their Sprint Planning 1
3. 5 min on Scrum | Daily Scrum (2)

Ich gebe zu, man könnte es als luxuriös bezeichnen, eine komplette Woche mit einem neuen Team zu verbringen, bevor der tatsächliche Sprint startet. Mittlerweile betrachte ich es aber als notwendig, vor allem wenn das Team vorher nicht zusammen und nicht mit Scrum gearbeitet hat. Vor allem aber, wenn die Teammitglieder nicht daran gewöhnt sind, zu diskutieren und sich einzubringen.

Was man eine ganze Woche lang macht?

1) Scrum Basics vermitteln

Jeder hat über den Flurfunk oder die Unternehmenskommunikation im Rahmen der Einführung von Scrum bestimmte Buzzwords mitbekommen. Manche haben sich selbst eine Vorstellung gemacht, andere nachgelesen und wieder andere können mit den Begriffen nichts anfangen. Also, in Kürze – einen Tag – Rollen, Meetings, Artefakte. So legt man zumindest gleich zu Beginn die Grundlage für ein gemeinsames Verständnis – und eine gemeinsame Sprache verbindet zusätzlich.

2) Das Team kennenlernen

Ob ScrumMaster, Product Owner oder Teammitglied: Jeder ist neu im Team. Daher sollte man sich die Zeit nehmen, sich über die gewöhnliche Vorstellungsrunde mit Namen und Abteilungskürzel kennenzulernen. Ich bereite zwar eine Art Story Map vor, lasse dann aber die Teammitglieder durch Punkte entscheiden, was sie machen wollen, um sich, Scrum, die Hintergründe und den organisatorischen Rahmen kennenzulernen.

3) Vision und Backlog

Sich (als ScrumMaster) Zeit nehmen, den Product Owner gründlich auszufragen: Was ist das Produkt? Wer die Nutzer? Und welchen Nutzen wollen wir für sie bereitstellen? Kann man eine Vision erarbeiten oder fehlt es dafür an etwas?

Oft wundert man sich, dass es ein Team gibt und man vermeintlich starten kann, aber noch gar nicht richtig klar ist, was gemacht werden soll. Wenn man Glück hat, ist es für eine “strategische Runde” noch nicht zu spät, bevor die Verwirrung das ganze Team erfasst. Im besten Fall kann der PO nochmal drüber schlafen und nochmal weiterentwickeln, schärfen oder verwerfen, bevor er das Ergebnis zum ersten Mal mit dem Team diskutiert.

Vor allem einen nicht fertige Vision, ein mageres Backlog und die gemeinsame Erarbeitung der Personas mit dem Team laden zum Teilen der Meinungen ein. Durchstreichen erwünscht – und das ist “analog” einfacher als in einer ppt. Gemeinsam geschriebene User Stories, selbst wenn man nachher nicht alle braucht, machen deutlich, wie schwierig oft der Nutzenaspekt ist. Vor allem wenn man den Kunden bereits kennt und in der Regel einfach abarbeitet.

Gebt den Teammitgliedern etwas Zeit, wenn sie nicht gleich zu Beginn eifrig diskutieren. Oft sind sie es nicht gewöhnt, gefragt und gehört zu werden.

4) Infrastruktur und Wissen

Einen Raum beziehen, Rechner neu aufstellen, ein Taskboard bauen, weitere benötigte Infrastruktur- und Testumgebungen identifizieren, ggf. eine Schulung zu für das Team wichtigen Inhalten organisieren.

5) Definition of Done

Was ist selbstverständlich? Was wäre gut, wenn man es tun würde? Und was würden wir gerne tun, haben aber nicht die Mittel? Arbeitsweisen und Begriffsverwendungen variieren oft schon, wenn man die Seite des Flurs wechselt, ganz zu schweigen von Abteilungen. Das Sammeln der Antworten auf die Fragen oben ist für mich eine Herangehensweise, dem Team die Möglichkeiten und weniger die Doku-Regeln hinter der DoD zu vermitteln. Außerdem füllt sich das Impediment Backlog fast wie von selbst und das Team gibt bereits vor dem ersten Planning ein Commitment ab – und sei es nur um zu versuchen, die selbst gesteckten hohe Qualitätsziele zu erreichen.

First Things First – sich Zeit für die strategische Planung nehmen, bevor man in der Taktik der neuen Situation versinkt. Es lohnt sich und ist genauso ein Bestandteil von Scrum wie die Sprints.

Related posts:

1. Die drei weiteren Rollen in Scrum
2. Schätzen vs. Planen?
3. Vom Los- und in die Freiheit lassen