Mein Blog besteht dieses Mal mit Absicht nur aus dieser Frage. Ich möchte damit zum Nachdenken anregen: Was passiert, wenn man Konflikte oder andere Probleme einfach „beseitigt“, anstatt genauer hinzuschauen, was dahintersteckt?

Hätte es ipad, ipod und iphone gegeben, wenn der geniale, aber auch exzentrische Jobs seine Teams nicht zu Höchstleistungen getrieben hätte? Würde es heute Smartphones geben und Tablets? Ob wir das alles brauchen, ist eine andere Frage. Ich jedenfalls liebe mein ipad und ich bin keine Apple-Jüngerin. Es ist etwas Besonderes, es in der Hand zu haben, fast ein Handschmeichler. Auch mein iphone ist ein haptisches Vergnügen und die App Integration von Twitter, Facebook & Co macht richtig Spaß. Ich habe auch Android-Tablets und Smartphones, aber Apple ist irgendwie besonders.

Hätte jemand anderer Tablets und Smartphones erfunden? Ich weiß es nicht. Fakt ist, dass die Produkte von Apple zumindestens meine Welt verändert haben und ich mich frage, was gewesen wäre, wenn jemand das “Ekelpaket” Steve Jobs einfach rausgeworfen hätte.

Just think about it.

Related posts:

1. Über das Schreiben | Leidenschaft
2. Über das Schreiben | Schreibblockaden
3. Über das Schreiben

Eine Szene aus einem Training für Manager im Scrum-Kontext. Auf der Themenliste aus der konkreten Führungspraxis stand der Satz: Wie motiviere ich mein überlastetes und gestresstes Team?

Im Fallgespräch erzählt der Teamleiter, der mit seinen vier Mitarbeitern für die Qualitätssicherung im Unternehmen zuständig ist, dass seine Mitarbeiter von den ständigen Unterbrechungen bei ihren täglichen Vorhaben genervt und immer mehr demotiviert sind. “Kaum eine Aufgabe können wir kontinuierlich zu Ende führen, immer gibt es höhere Prioritäten, durch Kunden, Management oder den Product Owner. Die Tage sind zerrissen durch spontane, unvorhergesehene Situationen, die es uns schwer machen, gute Arbeit abzuliefern. Der Druck ist groß und die Ressourcen sind knapp. Veränderungen aus dem Umfeld sind in absehbarer Zeit keine möglich. Und so quälen wir uns über die Runden und sehen irgendwie kein Land. Trotzdem machen wir immer noch einen guten Job, aber wie lange noch? Wie halte ich in so einer Situation meine qualifizierten und guten Leute bei der Stange, wie motiviere ich sie?“

Während er mir und den anderen Teilnehmern seine Geschichte erzählt, wirkt auch der Teamleiter selbst gestresst, hilflos und deprimiert. Mehrere Kollegen kennen das Erzählte aus ihrer Praxis und bestätigen ihn verständnisvoll in seiner Not.

Ein Bild sagt mehr als tausend Worte

Ich fordere ihn auf, sich mal ein Bild, eine Metapher für sich und sein Team zu überlegen. Er braucht nicht lange und bringt als sein Teambild den Notarzt. Er beschreibt das Bild: „Wie wir muss der Notarzt permanent ohne Vorwarnung zum Einsatz. Manchmal von einem direkt zum anderen. Er hat immer Probleme vor sich, wenn er ausrücken muss. Trotz hoher Kompetenz sterben ihm oft die Leute unter den Händen weg, weil er nicht genug Zeit hat. Oder sie sterben trotz aller Bemühungen später im Krankenhaus. Irgendwie ist seine Arbeit doch meist Stückwerk. Dann muss er auch noch ellenlange Berichte schreiben und ist im schlimmsten Fall an allem Schuld. Das ist doch deprimierend und total unbefriedigend und genauso geht es uns“.

Immer noch ist er deutlich wahrnehmbar in seinem Defizitzustand, es geht ihm nicht gut, er wirkt ratlos und resignativ.

Ich bitte ihn nun, sich doch mal ein positives Bild zu seinem Team und der Arbeitssituation zu machen. Er überlegt lange hin und her, es arbeitet in ihm, aber er kann keine positive Bildmetapher entwickeln. „Mit fällt da wirklich nichts ein, ich bin völlig blockiert. Da gibts anscheinend einfach nichts Gutes bei uns“, ist sein Fazit.

Nun frage ich ihn, ob ich ihm ein positives Bild anbieten darf, das aus meiner Sicht auch eine Möglichkeit sein könnte seine Teamsituation zu betrachten und einzuordnen. Er stimmt, leicht skeptisch, zu.

Ich entwickle folgendes Bild für den Teamleiter:

„Stell Dir vor, Dein Team ist eine hochprofessionelle Bergführermannschaft, deren tägliche Aufgabe es ist, Menschen aller Art sicher auf hohe, steile, ja auch gefährliche Bergriesen aller Höhengrade zu begleiten. Alle Deine Spezialisten beherrschen ihr „Handwerk“ perfekt, sind optimal als Team aufeinander eingespielt und kennen ihren Job genau. Ihr liebt eure Aufgabe und eure Kunden. Gut vorbereitet und hoch motiviert beginnt ihr den Aufstieg. Ihr kennt die Routen genau und arbeitet routiniert. Trotzdem ereignet sich immer wieder Unvorhergesehenes. Das Wetter wechselt plötzlich und zwingt zum Biwak, gefährliche Gerölllawinen erfordern Routenwechsel, Kunden verletzen sich und müssen ins Tal zurückgebracht werden, oder sie geraten in Panik, sind unzufrieden und belasten die Gruppe, usw. Die geplanten Zeiten können nicht immer eingehalten werden. Manchmal kommt es zum Abbruch und es muss ganz neu gestartet werden. Dein Bergführerteam löst die Probleme kompetent und gelassen unter Deiner engagierten Leitung. Bei allen Hindernissen erreichst Du mit Deinem Team und den Kunden (fast) immer die Gipfel. Dann genießt ihr den „Sieg“, freut Euch über die Anerkennung der Kunden und seid immer aufs Neue begeistert vom herrlichen Ausblick auf all die Gipfel, die ihr in Zukunft noch bezwingen werdet. Ihr wisst, dass es kaum eine Situation gibt, die ihr nicht engagiert angehen und lösen könnt, wenn es darauf ankommt. Das zeichnet Euch als Spezialteam aus, das ist Eure Mission und darauf seid ihr auch richtig stolz. Ihr freut Euch auf die nächsten, sicher nicht einfacheren Aufgaben und gebt Euch untereinander Feedback, was läuft und was man verbessern könnte, um Euch als Team zu optimieren.”

Schon bei den letzten Worten meiner Bildbeschreibung wirkt der Teamleiter deutlich entspannter und kommt aus seiner negativen Haltung heraus. Folgender Dialog entsteht (leicht gekürzt):

Frage: „Wie ist das jetzt im Moment für Dich“?

Antwort (mit fester Stimme): „Das klingt ganz  gut, so kann man mein Team und seine Arbeitssituation tatsächlich auch sehen. Und vieles stimmt tatsächlich, wenn ich es genau betrachte.”

Frage: “Wie geht es Dir denn jetzt mit dem neuen Bild?”

Antwort: „Prima, ich fühle mich optimistischer und gestärkt, irgendwie ein ganz positives Gefühl.“

Frage: „Stell Dir vor, Du gehst mit diesem positiven „Bildgefühl“ an Deine Arbeit, was würde evtl. anders sein als vorher?“

Antwort: „Das hätte sicher einen gute Wirkung auf meine Mannschaft, ich lass mich immer wieder zu sehr runterziehen.

Frage: „Nimmst Du das Bild mit, und probierst mal aus, ob Deine neue Haltung tatsächlich seine Wirkung tut?“

Antwort: „Ganz sicher, ich denke ich hab was begriffen, was für mich als Führungskraft ganz wichtig ist. Und ich werde mir ein tolles „Bergbild“ als Merker besorgen.”

Innere Bilder – das sind all die Vorstellungen und Szenen, die wir biographisch (von Kindheit an) gespeichert haben und die unser Denken, Fühlen und bewusstes/unbewusstes Handeln in hohem Maße mitbestimmen. Wenn sich Menschen bildlich etwas vorstellen, sind die gleichen Hirnbereiche aktiv, wie wenn sie es tatsächlich tun. Im Sport wird das seit langem erfolgreich be- und genutzt. Innere Bilder sind im Gehirn abgespeicherte Muster, die wir meist unbewusst benutzen, um uns zu orientieren, Situationen zu analysieren, zu bewerten und unsere Handlungsimpulse danach auszurichten. Je länger sich Menschen z.B. in für sie negativen Bildervorstellungen aufhalten, umso mehr verfestigt sich dieses Bild und seine Auswirkung auf Denken, Fühlen und Handeln. Innere Bilder können uns blockieren, oder aktivieren, können uns ängstigen oder Mut machen und motivieren. Bilderprozesse sind auf alle Fälle eine wesentliche menschliche Ressource, um das Leben und seine Anforderungen zu gestalten.

In Anlehnung an einen Blogbeitrag von Boris Gloger vom 18. Februar 2013 kann gesagt werden: „Führungskräfte sind konstruktiv, nicht destruktiv.” Sie müssen um ihre besondere Wirkung auf ihr Team wissen und durch Selbstwahrnehmung, Selbstreflexion und ihre mentale Einstellung ihren Mitarbeitern gute, positive, stärkende „Bilder“ vermitteln, auch wenn es manchmal schwer fällt. Den Einfluss, den die mentale Verfassung von Führung auf Teams hat, wird in der Regel unterschätzt. Für Motivation, Engagement und Arbeitszufriedenheit, besonders in schwierigen Situationen, ist dies zweifellos oft entscheidend. Dieser Beitrag soll Mut machen, „das eigene Bild“ einer schwierigen Situation zu erkunden, dessen evtl. kritische Wirkung wahrzunehmen und sich ein neues, unterstützendes Bild zu gestalten und den Unterschied zu testen.

Übrigens: Der Teamleiter überlegte zum Ende des Trainings, dieses Bild mit seinem Team im nächsten Meeting zu besprechen. Er kann sich gut vorstellen, dass auch seine Kollegen eine neue Perspektive gewinnen und so mit einer anderen, lockeren Einstellung an die Arbeit herangehen.

Tipp: An der eigenen Einstellung arbeiten und mit dem Team zu neuen Erfolgen aufbrechen – Scrum Supplements sind die Krafttrainings für die Veränderungsarbeit mit Scrum. Nähere Infos und alle Termine gibt es hier.

Related posts:

1. Führung in Scrum | der Manager | Verhalten | Teil 2
2. Führung in Scrum | Manager | Teil 4
3. Einzelkämpfer ScrumMaster? Herausforderungen als ScrumMaster Team gemeinsam meistern Teil 4

Wisst ihr was Parabeln  sind? Ich musste selbst nachschlagen und habe das dazu gefunden:

Die Parabel ist

„eine lehrhafte und kurze Erzählung. Sie wirft Fragen über die Moral und ethische Grundsätze auf, welche durch Übertragung in einen anderen Vorstellungsbereich begreifbar werden. Das im Vordergrund stehende Geschehen (Bildebene) hat eine symbolische Bedeutung für den Leser. Die Parabel bringt den Leser zum Nachdenken und zum Erkennen eines richtigen Lebens durch die Herleitung des gemeinten Allgemeinen (Sachebene). Eine Parabel enthält meist zwei Lehren: Zum einen eine im engeren Sinn, zum anderen eine Lehre im weiteren Sinn. Sie kann sowohl explizit als auch implizit enthalten sein.“ (Wikipedia)

Beim Lesen eines wunderbaren Buches von Stefanie Widmann und Andreas Wenzlau bin ich auf eine Parabel gestoßen, die jeder ScrumMaster kennen sollte und deren Lehren fester Bestandteil im Handlungsportfolio eines Change Agents sein sollten. Ich möchte euch den wirklich lehrreichen, inspirierenden Text nicht vorenthalten. Sinngemäß geht die Parabel so (vgl. Widmann und Wenzlau, 2008, S. 47):

Ein Teammitglied, das die nicht enden wollenden Diskussionen und Streitereien mit einem seiner Teammitglieder nicht länger aushielt, bat seinen ScrumMaster um Rat und erzählte ihm von seinem Kummer:

„Kaum macht einer von uns einen Kommentar, wird er vom anderen schon unterbrochen. Es reicht ein falsches Wort und wir streiten wieder miteinander. Danach ist jeder schlecht gelaunt und überträgt die miese Stimmung auf den Rest des Teams. Eigentlich kann ich ihn doch ganz gut leiden und er ist ein wirklich toller Entwickler. Ich weiß einfach nicht mehr weiter. Was soll ich deiner Meinung nach machen?“

Der ScrumMaster antwortete ruhig:

„Du musst lernen, ihm zuzuhören. Und wenn du denkst, dass du dir ganz sicher bist, dass du das kannst, dann komm wieder zu mir.“

Nach zwei Sprints sprach das Teammitglied wieder mit dem ScrumMaster. Der junge Mann berichtete, dass er sich sicher sei gelernt zu haben, auf jedes Wort zu hören, das sein Teamkollege zu ihm sagte.

„Prima“, sagte der ScrumMaster lächelnd. „Wenn du jetzt dafür sorgen möchtest, dass ihr miteinander auskommt, euch respektiert und eine gemeinsame Sprache findet, musst du jetzt noch lernen, auf jedes der Worte zu hören, die dein Kollege nicht sagt.“

Das Spannende steht zwischen den Zeilen

Die gesprochene Sprache ist und bleibt nur ein Element unserer Kommunikation bzw. des gegenseitigen Verständnisses und der damit einhergehenden Zusammenarbeit. Sie dominiert unser Tun, weil sie vordergründig das ist, was unserem Bewusstsein klar ist. Man kann es sehen, man kann es hören. Unser Fokus beschränkt sich hierauf. Dinge, die nicht gesagt werden, sind ein wichtiger Bestandteil, um zu verstehen und verstanden zu werden. Nonverbale Kommunikation (z.B. Gestik, Körpersprache) ist nur ein Aspekt, der aus einem einfach ”Ja, ich verstehe dich” (und gleichzeitig geht beispielsweise der Blickkontakt verloren oder es ist ein kaum wahrnehmbares Kopfschütteln zu bemerken) eine ganz andere Reaktion werden lässt. Auch unser Mienenspiel, sogenannte Mimikexpressionen (=kurze Veränderungen in unserem Gesicht aufgrund einer Gefühlslage), verraten dem guten Zuhörer oder in diesem Fall Beobachter, dass es nicht nur auf die gehörten Worte ankommt, sondern auf ebenso auf das, was zwischen den Zeilen steht. Wir können nun mal keine Gedanken lesen. Das ist Fakt. Nichtsdestotrotz sind wir mit Fähigkeiten in uns ausgestattet, die uns mehr erlauben, als nur zu hören, was ein Gegenüber sagt. Es bedarf hierzu auch ein anderen (inneren) Haltung. Empathie (=Einfühlvermögen) ist nicht genetisch bedingt. Es ist Übungssache und es hat etwas mit einer Fähigkeit zu tun, die wir zwar in uns tragen, die wir aber aufgrund von unserer Getriebenheit im Alltag nur mangelhaft zum Einsatz bringen: der Neugierde.

Seid neugierig auf das, was ihr hört und seid noch neugieriger auf das, was ihr nicht hört, meint zu verstehen und hinterfragt es – beim anderen, aber auch bei euch selbst, wenn ihr einfach mal euer Bauchgefühl “sprechen” lasst.

 Die Definition, was eine Parabel ist, beinhaltet, dass es meist zwei Lehren in ihr gibt – eine implizite und eine explizite. Was sind eure Lehren aus dieser Parabel?

Literatur

Widmann, S. & Wenzlau, A. (2008). Moderne Parabeln. Eine Fundgrube für Trainer, Coachs und Manager. Publics.

Übrigens: Haltet in den nächsten Wochen die Augen offen. Vielleicht bekommt ihr bald die Gelegenheit, richtig gute Zwischenzeilenleserinnen und -leser zu werden!

Related posts:

1. Prioritäten | Product Owners Tools
2. Scrum Alliance mal wieder führungslos – Donna Farmer geht
3. Schuldzuweisungen verhindern Lernen

Wozu Scrum? Die Antwort auf diese Frage variiert von Unternehmen zu Unternehmen – und dennoch geht es meistens um schnellere Auslieferungen, bessere Qualität, stärkere Kundeneinbindung, zufriedene Mitarbeiter.

All das ist wichtig und gut, doch beantwortet es nicht die Frage nach dem Wozu. Denn ich kann großartigen Code schreiben, alle zwei Wochen releasen, meine Kunden ständig dabeihaben und immer noch nicht wissen, welchen Zweck ich damit verfolge. Solange die Geschäftszahlen stimmen, mag das nicht weiter schlimm erscheinen. Gewinn ist ein täuschend echter Unternehmenszweck.

Verändern sich aber die Marktbedingungen (und das ist heute eher die Regel als die Ausnahme), ist die eigene Ausrichtung zu überprüfen: Ist das, was sich bisher blendend verkauft hat, auch heute noch das Richtige? Und spätestens da stellt sich die Frage nach dem Wozu. Um sie zu beantworten, muss ich erstmal verstehen, wie mein Produkt aussehen könnte und was es zum Produkt macht. Wir haben dafür eine eigene Rolle in Scrum: Den Product Owner. Ohne die Frage nach dem “Wozu” wären Product Owner überflüssig: Die Entwicklungsteams könnten direkt mit Kunden und Benutzer sprechen, seine Anforderungen aufnehmen und dann umsetzen.

Was ist das denn: ein Produkt?

Laut Wikipedia ist es das Ergebnis eines vom Menschen bewirkten Transformationsprozesses, in dem Produktionsfaktoren wie Güter und Dienstleistungen in einen Output umgewandelt werden. Das ist sicher nicht falsch, aber es zieht am Wesentlichen vorbei.

Ein Produkt ist für mich so etwas wie ein Leuchtturm in der Beziehung des Menschen zu seiner Umwelt. Ein Anker, eine feste Referenz, die unser Leben besser, schöner, einfacher, anspruchsvoller macht.

Ein Kunstwerk, ein Schlüssel, ein Zug, ein Studium, ein Hut, eine Tasse Kaffee. Das alles sind Produkte – feste Bestandteile des menschlichen Lebens, milliardenfach produziert und in Anspruch genommen, weil sie nützlich sind.

Ein gutes Produkt fügt sich ungezwungen in die Interaktion zwischen Mensch und Umwelt. Es wird nicht als Last oder Hindernis, sondern als Stärkung empfunden. Als etwas, das man gerne in die Hand nimmt, trägt, bedient, in Anspruch nimmt.

In der Softwareentwicklung fällt der Bau guter Produkte nicht leicht. Mit Software lässt sich sehr viel sehr schnell bauen. Diese Fülle an Möglichkeiten, die ja die Kraft von Software ausmacht, ist zugleich ihre Achillesferse. Benutzer wollen einfache, intuitiv bedienbare, gut aussehende und zugleich leistungsstarke Software. Zu oft fühlen sie sich jedoch überfordert und frustriert, haben eine vorbelastete Beziehung zu Software und würden am liebsten ohne sie auskommen, wenn sie die Wahl hätten. Da sie diese Wahl nicht haben, werden sie bisweilen stiefmütterlich behandelt. Es sollte niemanden verwundern, wenn die gleichen Benutzer bei der erstbesten Gelegenheit dem Konkurrenten in die Arme laufen und dem alten Produkt keine Träne nachweinen.

An welchem Produkt arbeitest du mit? Was macht es stark? Wie beeinflusst es die Interaktion zwischen Mensch und Umwelt? Wer sind diese Menschen? Die Antwort auf diese Fragen nennen wir Produktvision. Es lohnt sich, Zeit dafür zu investieren. Denn nur die Produktvision kann die Frage nach dem Wozu beantworten. Software wird nicht entwickelt, um fehlerlos zu laufen. Oder um möglichst viel Abfragen in möglichst geringer Zeit zu bearbeiten. Sie ist da, um Spuren im Alltag der Menschen zu hinterlassen. Du kannst bei dem, was du entwickelst, beim besten Willen keine Produkteigenschaften feststellen? Dann versuche es mit folgenden Fragen:

• Wer sind deine Kunden? Was haben sie davon, dass es euch gibt?
• Welcher Bedarf deines Kunden wird durch euer Produkt erfüllt?
• Welche sind die vier bis fünf kritischen Funktionalitäten, die den Erfolg des Produktes ausmachen?
• Wie wird das Unternehmen vom Produkt profitieren?

Nimm dir zum Schluss noch zehn Minuten, um deine Erkenntnisse in einen “Elevator Pitch” zusammenzufassen – einem Statement, das so knapp und prägnant ist, dass während einer Fahrt im Aufzug die Vision kommuniziert werden kann.

Unsere Produktvision bei bor!sgloger lautet übrigens wie folgt: Nach ihrem Arbeitstag sollen unsere Kunden nach Hause gehen und dorthin die Energie und Zufriedenheit mitnehmen, um mit ihren Kindern zu spielen.

Related posts:

1. Scrum Essentials: Die sieben Fragen der User Story
2. Warum wir eigentlich alle Freelancer sind
3. ScrumMaster vs. ScrumMasterin

Stephanie G.: Having discussed Sprint Planning 2, let us continue with your experiences and advice for the Sprint Review. Would you say that the meeting becomes more complicated the more locations are involved?

Hélène V.: It does indeed get more complicated if the Customers live in different timezones. It would be truly inhumane to ask one of the Customers to get out of bed at 4am in order to participate at the Review. If that‘s the case, I would simply have more than one Review meeting. After all, Reviews are usually culturally pretty different anyway – for example, an Australian thinks differently than an Austrian. If you hold more than one Review, I think it would suffice to have one Dev.Team member and the Product Owner present. Of course, the Dev.Team member should vary.

Christof B.: I don‘t necessarily think that it becomes more complicated the more locations are involved. The thing is, even co-located Teams sometimes have international Customers, so the question of handling international Reviews is of interest to most Scrum Teams. The meeting very much depends on the kind of software that is presented – for example, it is more difficult to show a mobile app than a browser. However, generally one can say that it‘s simply a matter of having the right tool – Webex or TeamViewer are good options. If a telephone connection is unavailable, feedback via chat is also possible.

Bernd K.: I agree – from a technological point of view, the Review is quite easy. My Team members used to present all Stories by using Desktop Sharing and Skype.

Kristina K.: True! You can always send the product increment to the Customer in advance via a preview platform and then watch one of the Users click around via video conference. However, as Christof has already stated, this depends on the type of product. I also think it would be a good idea for the Product Owner and a Dev.Team member to fly to the Customer every now and again. Alternatively, a proxy User can be found in each location – a colleague, for example – who can try out the product increment. I usually vary these options – alternating internal and external Reviews. If the distance allows it, I would also recommend the whole Team coming together for every second Sprint change.

Hélène V.: On top of Kristina’s input, if you decide to hold a Sprint Review for each Customer, I would take the feedback from one Customer to the next. Meaning that I would ask whether the Australian is of the same opinion as the Austrian that i.e. there‘s a button missing in the upper left corner. If the budget allows it, I would even recommend to fly in the Customer directly every now and again.

Deborah W.: We never had any Customers present at our Sprint Reviews. Instead, we did what Kristina’s just mentioned and asked people from other departments to step in for them. It was very pragmatic – we had one person with an iPad who filmed the proxy User while handling the application and clicking around. The webcam also filmed what was shown on the screen, so that all locations could get the idea.

Bernd K.: Deborah, it was similar with my Team. Before I arrived as the new ScrumMaster, the User or Customer had never actually seen the product. It seemed that there was a real culture of criticism in the relationship between the Customer and the company. After three Sprints, we had a large Review to which I invited Managers and Customers. It was strange, because the fear in the air was truly tangible. In the end, only the Management and other interested people turned up. That was really nice, as the Team felt in a safe environment to present their work. If I could do it again, I would first address and work on the feedback culture before inviting the Customer.

Stephanie G.: Ina, what do you think?! Did you have a similar experience?

Ina K.: I find it rather funny that I‘m the only one here who found the Review to be one of the more difficult meetings with internationally distributed Teams. I always had these questions running through my head: How can you get the Customer or User properly involved if they‘re on a different continent?! Does using a person from an internal department suffice as a proxy for them? I love the fact that Scrum provides us with the Sprint Review, as it gives all parties concerned the opportunity to get involved in the making of the product. As a Manager, I can try out product increments that are ready to be delivered – how cool is that?! Even people who are not very technologically talented can participate. The Review enables the Scrum Team to interact with the Customer by way of feedback and arouse his interest in the product. When working with co-located Teams, I really enjoy turning the Review into a marketplace together with other Scrum Teams, where all stakeholders can try out different elements at the same time. I find that to be much more fun than simple presentations with frontal speakers. However, organising a marketplace is more complicated when working with internationally distributed Teams.

Bernd K.: Ina, you‘re not the only one who found it quite difficult. There really are certain aspects that need to be addressed when talking about Reviews and distributed Teams. For example, some of my Team members found it pretty stressful to present without knowing what the audience looks like or how they are reacting. They were also pretty scared of negative feedback. So we made sure that we had webcams pointing at the audience, so that the presenters would become more relaxed. As ScrumMaster, I began introducing a culture of positive feedback and of pushing performance into the foreground. After a while, even the Product Owner praised the Team during the Reviews.

Stephanie G.: Anything else that you would advise to keep an eye out for?!

Ina K.: The preparation is the most important element of the Sprint Review, as it is always better when different Team members from various locations present. This should become part of the routine. At the actual meeting, as a ScrumMaster, you should make sure that everyone is involved – always ask whether there are any more questions concerning a certain feature and make sure that the guests know how important it is for them to be involved.

Bernd K.: Particularly during the Sprint Review, I find it super embarrassing if the technological connection does not start. Keeping Murphy’s Law in mind, I would really recommend arriving even earlier than you normally would for a meeting in order to make sure that everything is up and running before the guests arrive.

Stephanie G.: True, Bernd. I‘m glad you mentioned the topic of preparation, as I can only second the importance of that! So summing up your points, one should consider the following when holding a Sprint Review with a distributed Scrum Team:

• Make sure that the technological set-up and the Team members are prepared 
• Make sure that the right tools are available for allowing the Customer to try out the product increments and filming it
• Vary the Review meeting: 
  • have more than one Review, but share the feedback across Review meetings i.e. different time zones, different Customers
  • PO and 1 varying Dev.Team member fly to the Customer
  • fly in the Customer or
  • ask colleagues or potential End Users at each location to try out the product increment as proxy Customers
• Work on a positive feedback culture

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. Should internationally distributed Teams be avoided?

Unlängst schilderte mir ein guter Bekannter, ein Unternehmensberater, dass er eine Führungskraft zu unterschiedlichen Ausprägungen ihrer Kompetenz befragte. Er wollte mit der betreffenden Person gemeinsam Handlungsfelder identifizieren, in denen diese sich entwickeln könnte. Es kam allerdings heraus, dass die Führungskraft mit dem Stand ihrer Entwicklung vollends zufrieden war und dass aus ihrer Sicht derzeit kein wirklicher Handlungsbedarf bestand. Etwas irritiert erzählte mir der Bekannte, dass er sich über die vollkommen übersteigerte Selbsteinschätzung dieser Führungskraft ärgerte und er gar nicht verstehen könne, dass die Diskrepanz zwischen seiner Meinung und der der Führungskraft so groß war. Er begründete seinen Ärger mit den Worten: „Das ist so typisch. Sie (die Führungskraft) denkt tatsächlich, dass sie schon alles weiß. Es gäbe so viel zu verbessern. Ich habe die Arroganz und Ablehnung in ihrem Gesicht gesehen. Wie kann man nur so von sich überzeugt sein!“ Ich stutzte, sah meinen klagenden Bekannten mit einem Schmunzeln an und erwiderte: „Du hörst dich an wie Othello.“ Fragend sah er mich an: „Othello? Was hat der denn damit zu tun?“

Der Othello-Effekt

Othello, Feldherr in der Republik Venedig und mit der wunderschönen Desdemona verheiratet, wurde das Opfer einer Intrige. Ihm wurde der schreckliche Floh ins Ohr gesetzt, dass Desdemona eine Affäre mit seinem bestem Freund Cassio hätte. Der voreingenommene und rasend eifersüchtige Othello konfrontierte seine Ehefrau mit dieser Anschuldigung, forderte sie auf zu gestehen und beging dabei den Fehler, ihren unter Tränen vorgebrachten Unschuldsbeteuerungen keinen Glauben zu schenken. Rasend vor Eifersucht erwürgte er sie, nachdem er zuvor bereits ihren angeblichen Geliebten getötet hatte. Othello sah, dass Desdemona offensichtlich Angst hatte, als er sie zur Rede stellte. Als sie dann auch noch zu weinen begann, nachdem sie von Cassios gewaltsamen Tod durch die Hand ihres Mannes erfahren hatte, fühlte sich Othello zusätzlich bestätigt. Für die Tränen seiner Frau auf die Nachricht vom Tod ihres Geliebten und für die Angst in ihrem Gesicht konnte es nur eine Erklärung geben: Sie musste schuldig sein. Desdemonas Angst war für Othello ein Schuldbekenntnis des Ehebruchs, der ans Licht gekommen war.

Othello hatte Desdemona leider – wie sich später herausstellen sollte – zu Unrecht getötet und zwar ohne anderen Ursachen für die Angst und Pein seiner Ehefrau Raum zu geben: Dass nämlich Desdemonas Angst die Reaktion einer unschuldigen Frau sein könnte, die wusste, dass ihr von Eifersucht geblendeter Ehemann im Begriff war sie umzubringen. Und sie hatte ja keinerlei Möglichkeit mehr, ihre Unschuld zu beweisen, weil der Einzige, der es hätte bestätigen können, bereits tot war.

Emotion verrät uns nichts über ihren Ursprung

Emotionale Signale, wie z.B. Ärger, Überraschung oder in Othellos Fall Angst, verraten uns nie etwas über ihren Ursprung oder anders ausgedrückt (vgl. Ekman, 2011, S. 80ff):  Wenn ich das Was kenne, weiß ich noch lange nichts über das Warum. Wollen wir den Othello-Effekt vermeiden, müssen wir daher der Versuchung widerstehen, zu rasche und einseitige Schlüsse zu ziehen. Dies gelingt uns nur, wenn wir uns darum bemühen, neben der für uns offensichtlichsten, also der erstbesten Ursache für ein Gefühl, mindestens eine Erklärungsalternative zuzulassen.

Wenden wir uns mit dieser Erkenntnis erneut meinem Bekannten zu. Die Führungskraft reagierte auf sein Weiterentwicklungsangebot mit arroganter Ablehnung. Die offensichtlichste Ursache lag für meinen Bekannten auf der Hand: Die Führungskraft erkannte keinen Handlungsbedarf für sich. Diese ablehnende Haltung wurde durch die Erwartungshaltung meines Bekannten verstärkt, der aus seiner Sicht Handlungspotentiale identifiziert hatte und daher mit einer ganz anderen Reaktion gerechnet hatte. Fremd- und Selbsteinschätzung gingen vollkommen auseinander. Mit freundlichen Grüßen, Othello.

Welche weiteren Ursachen könnte das ablehnende Verhalten der Führungskraft gehabt haben? Antworten finden sich, wenn wir uns Fragen nach alternativen Ursachen stellen:

• Welche Erfahrungen hatte die Führungskraft in der Vergangenheit mit Weiterentwicklung gesammelt?
• Welchen Anteil hatte der Berater und die Art und Weise seines Angebots, dass die Reaktion so ausgefallen war?
• Wie würden der Vorgesetzte der Führungsraft oder das Team reagieren, wenn sie wüssten, dass diese noch Handlungsbedarf in punkto Führung hat?
• Was wohl andere Führungskräfte über mögliche Defizite dieser Führungskraft denken?

Wie ihr seht, eröffnen die Fragen mehrere, alternative Zugänge auf Ursachen für die Reaktion bzw. Emotion der Führungskraft. Der Othello-Effekt ist in unserem Alltag allgegenwärtig und handlungsleitend. Achtet darauf und nehmt euch Zeit dafür, Ursachen zu erforschen. Wenn ihr bei eurem Gegenüber eine Emotion wahrnehmt, dann bewertet sie nicht gleich. Oder, wenn ihr das tut, dann denkt an Othello und gebt einer zweiten Meinung zu eurer Bewertung eine echte Chance.

Und in Teil 2 von ScrumMaster sind Meister der Effekte und Illusionen geht es um den Halo-Effekt und seinen Einfluss auf die Teamleistung und die Teamkommunikation.

Literatur

Ekman, P. (2011). Gefühle lesen. Wie Sie Emotionen erkennen und richtig interpretieren. Spektrum.

Related posts:

1. Der ScrumMaster ist eine Versicherung (Mike Beedle)
2. Über das Schreiben | Schreibblockaden
3. Über das Schreiben | Leidenschaft

Auch in der Produktentwicklung werden gerne Ziele gesetzt. Bis Ende des Jahres soll der Gewinn um dreißig Prozent steigen, der Wartungsaufwand halbiert werden und die Anzahl zufriedener Kunden signifikant wachsen. Alles schön und gut.

Aber: Was passiert mit uns, wenn wir uns solche Ziele setzen? Wir bauen Brücken, um sie zu erreichen. Mary und Tom Poppendieck zählen drei Möglichkeiten auf, ein Ziel zu erreichen:

• Die Arbeit umgestalten
• Das System verzerren
• Tricksen

Gibt es eine Abkürzung zur Veränderung?

Ziele können also auch über Abkürzungen erreicht werden. Wir biegen dann die Verhältnisse so lange zurecht, bis sie auf das Ziel passen. Eine wirkliche Veränderung erreichen wir damit nicht – sondern bewirken mitunter etwas ganz anderes. Deshalb dürfen wir Ziele nicht mit Zwecken verwechseln: Mein Ziel ist, 100 Meter in 11 Sekunden zu laufen. Dabei verfolge ich den Zweck, etwas für meine Gesundheit und mein Selbstbewusstsein zu tun. Wenn ich dazu eine Abkürzung nehme und zu leistungssteigernde Drogen greife, mag ich mein Ziel zwar erreichen – den Zweck verfehle ich aber oder handle sogar konträr dazu.

Mary und Tom Poppendieck raten aus solchen Gründen davon ab, Ziele zu setzen. Und sie liefern ein weiteres Argument: Wer anderen Ziele setzt, bringt ein Defizit zum Ausdruck. Du bist noch nicht schnell genug. Das Unternehmen generiert noch zu wenig Gewinn. Das kann zu einer negativen Stimmung führen.

Sollen wir also besser gar keine Ziele setzen? Ich sehe das anders. Ziele haben einen großen Vorteil: Sie sind prinzipiell erreichbar. Das macht uns stark. Denn wir können auf sie hinarbeiten, uns ihnen Schritt für Schritt nähern. Und am Ende stolz sagen: Ich habs geschafft.

Sie zeigen, wo man gerade steht und was noch zu erreichen ist. Sie dürfen nicht utopisch sein, sondern müssen den Möglichkeiten des Systems entsprechen. Ich kann 100 Meter in 11 Sekunden laufen – 10 Sekunden sind für mich außer Reichweite. Unter dem Stichwort SMART verbergen sich fünf Eigenschaften guter Ziele: Spezifisch, messbar, erreichbar, relevant, zeitlich terminiert.

Und: Ziele dürfen nie isoliert formuliert werden. Sie ergeben nur dann Sinn, wenn sie mit einem Wozu, mit dem Zweck verbunden sind. Wer seinen Gewinn steigern möchte, um seine Quartalsziele nicht zu verfehlen, der mag mit Bilanzkosmetik genau das Richtige tun. Wer es aber tut, um die Produktivität zu erhöhen, der wird um Veränderungen in der Organisation nicht umhinkommen. Dabei sind Ziele nur Wegmarken, wie die Leuchtfeuer am Boden vor der Landepiste. Umso wichtiger ist es, ein scharfes Bild vom dem zu haben, was man erreichen möchte. Wir nennen das Vision. Erst eine gute Vision macht Ziele attraktiv, gibt ihnen Anziehungskraft. So kann aus dem mühsamen Abrackern eine spannende Herausforderung werden. John F. Kennedy hat es mit seiner Vision zur Mondlandung geschafft, die ganze Welt bei der Zielerreichung mitfiebern zu lassen.

Wie sieht es in deiner Organisation, in deinem Leben aus? Hast du Ziele, für deren Erreichung du arbeitest? Machen sie Sinn, steckt dahinter ein Zweck? Und welches Bild, welche Vision verbindest du damit?

Mary und Tom Poppendieck: Leading Lean Software Development: Results Are Not the Point. Addison-Wesley.

Related posts:

1. Was hat Fußball mit Zielen zu tun – und das alles mit Scrum?
2. Utopie – Quo Vadis?
3. Eine Erleuchtung: Scrum als Coaching-Tool!

Deine Kollegen sagen nicht nein, aber vor Begeisterung sprühen sie auch nicht gerade. Und schon während der erste Sprint anläuft, merkst du: Verdammt. Wir bleiben im Sand stecken. Zu viele Kompromisse werden eingegangen, auf zu Vieles wird gleich von Anfang an verzichtet. Das Daily findet nicht täglich statt und dauert dann gleich eine halbe Stunde. Im Planning werden komplett neue Backlog Items vorgestellt. Das Team weiß nicht so recht, worauf es sich committen soll. Es ist selten zusammen zu sehen, weil jeder anderen Projekten nachlaufen muss. Und bei der Retro zur Scrum-Einführung heißt es dann: Scrum ist grundsätzlich gut, aber wohl nichts für unser Unternehmen. Wir brauchen einen weniger strengen Ansatz, der sich mit unserer Wirklichkeit besser verträgt.

So viel Respekt vor Scrum ist merkwürdig. Ich kann gar nicht oft genug betonen, dass Scrum nur ein Rahmenwerk zur Entwicklung von Produkten ist. Vieles, sehr vieles wird in Scrum offen gelassen – zur Enttäuschung all jener, die eine Schritt-für-Schritt-Anleitung erwarten.

Diese Offenheit hat einen großen Vorteil. Denn der Scrum Flow, so wie wir ihn kennen, ist hinreichend formal, um Vielfalt zuzulassen. Im Vergleich zu anderen Methoden wie beispielsweise dem RUP (Rational Unified Process) kommt Scrum mit einer handvoll Regeln und Rollen aus. Und selbst die Meetings, die gerne als Zeitfresser dargestellt werden, nehmen zusammen gerade einmal 12% der Gesamtzeit eines Sprints ein (zumal Scrum dafür sorgt, dass die restlichen 88% dann wirklich für die Produktentwicklung frei bleiben).

Scrum deckt auf – für manche zuviel

Nehmen wir zum Beispiel das Daily: Ich vergleiche es gerne mit einem gemeinsamen Frühstück am Familientisch. Man sitzt zusammen, um sich für den Tag vorzubereiten. Wer bringt die Kinder zur Schule, wer holt sie ab? Wer geht einkaufen? Was steht auf der Liste? Wann kommt der Babysitter? Wann ist Abfahrt für das Konzert am Abend? Am Ende eines solchen Dailies sollte jeder den Fahrplan für den Tag im Kopf haben und entsprechend koordiniert starten können.

Schreibt ein solches Daily der Familie vor, wie sie zu leben hat? Nein. Es schreibt inhaltlich rein gar nichts vor. Alles, was sich verändert hat, ist der Rahmen: Man verabredet eine feste Zeit und einen festen Treffpunkt. Man versieht das Treffen mit einem Zweck: dem der Synchronisation und Kooperation.

Vielleicht geht man sogar etwas weiter und bittet die Familie, das Frühstück im Stehen abzuhalten, damit alle mit Augen und Ohren dabei sind. Und – Achtung: Jetzt wird’s radikal! Man drückt jedem Familienmitglied einen Stapel gelber Post-Its in die Hand, verbunden mit der Bitte, die jeweiligen Aktivitäten schriftlich festzuhalten und für alle sichtbar an die Kühlschrankwand zu pinnen.

Is that too much to ask for? Für manche Familien sicherlich schon. Die empfinden ein solches Meeting als eine Zumutung und klagen, dass einmal täglich viel zu oft ist. Aber eine solche Überforderungssituation stellt nicht die Tauglichkeit von Scrum, sondern die Kommunikationsstruktur der Familie in Frage. Denn entweder ist die Familie schon so gut aufeinander abgestimmt, dass ein formales Treffen gar nicht mehr nötig ist. Das kann durchaus vorkommen – so wie es auch extrem gute Teams gibt, die sogar eine Retrospektive entbehren können, weil sie den Veränderungsprozess laufend gestalten und in die Alltagspraxis integriert gaben.

Oder aber – und das ist der weitaus häufigere Fall – die Familie hat schlicht und einfach keine Lust mehr, zu kommunizieren. Und auch das mag eine legitime Entscheidung sein, die es zu respektieren gilt. Allerdings ist es dann blauäugig, das Rahmenwerk (Scrum) für das Scheitern verantwortlich zu machen und zu behaupten: Scrum passt hier einfach nicht zu uns. Ehrlicherweise müsste die Antwort lauten: Wir möchten uns nicht so oft ins Gesicht schauen müssen.

Related posts:

1. Eine Erleuchtung: Scrum als Coaching-Tool!
2. Ich bin aus jenem Holze
3. 10 gute Gründe, warum Sie € 99.- und einen interessanten Tag in Ihre Zukunft investieren sollten

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