Der Stare down, das Blickduell, ein spektakuläres Ritual. Zwei Boxer stehen sich Tage vor ihrem Kampf für ein paar Augenblicke gegenüber. Auge um Auge. Kein Ausweichen. Elektrisierende Spannung. Regloses Anstarren, keine Miene verziehen. Wer den Blick senkt, hat sich eine Blöße gegeben und gilt als der Schwächere. Über dem anderen stehen, ihn im Status überragen, ihm zu verstehen geben, dass man überlegen, besser, mehr ist und bereit, den Kampf jederzeit aufzunehmen.

Das Thema “Status” (= Stand, Stellung in einer Gruppe oder Gesellschaft) und im wahrsten Sinne des Wortes seinen Mann oder seine Frau stehen, spielt ähnlich wie in dem Beispiel oben auch im beruflichen Alltag eine tragende Rolle. Fragen wie “Wer steht über wem?”, “Wie viel bin ich, wenn ich wie viel Menschen führe oder plötzlich nur noch halb so viele?”, “Hab ich einen eigenen Firmenparkplatz?”, “Ist mein Bürostuhl in meinem Einzelbüro mit Lehne ausgestattet oder noch ohne?” Petra Klapps umschreibt “Status” in ihrem Buch “Das Kolibri-Prinzip – leicht und spielerisch Ressourcen stärken“ als ”soziales Niveau. Das ist die Art und Weise, in der wir unseren eigenen Wert zu anderen Menschen in Beziehung setzen. Status ist immer von Werten und Spielregeln einer Gruppe oder einer Kultur abhängig. Nicht nur im Berufsleben, auch im Alltag stellen wir zu Menschen unbewusst oder auch sehr gezielt ein Statusverhältnis her. Dieses Verhältnis beeinflusst gravierend, wie wir (…) uns zueinander verhalten. Wir platzieren uns ständig auf einer Werteskala im Verhältnis zu unserer Umgebung. Wir nehmen keinen festen Platz ein auf dieser Werteskala, sondern wir wechseln unseren Status und unser Sozialverhalten (…). Jeder Mensch verhält sich anderen Leuten gegenüber entsprechend seinem eigenen Status. Wir signalisieren die ganze Zeit über unseren Platz in der Hierarchie, indem wir anderen gegenüber einen höheren oder einen niedrigeren Status einnehmen” (a.a.O., S. 136). Klapps postuliert, dass beinahe jede Kommunikation mit unserem Gegenüber etwas mit Konkurrenz zu tun hat und der Klärung der Frage, die einem (Status-)Kampf gleich kommt: Wer wird wen verändern?

Verhaltensweisen, die Status sichtbar machen können – ein Must für gute ScrumMaster

Ich halte es für eine herausragende Fähigkeit, Statusverhalten wahrzunehmen. Gerade ScrumMaster in ihrer besonderen Rolle als Servant Leader, als Führungskraft ohne Anspruch auf Autorität, brauchen hierfür äußerst sensible Antennen. Wie wirke ich in der Rolle als ScrumMaster? Wie sehen mich andere? Was verschafft mir meinen Status im Team, gegenüber anderen ScrumMastern, gegenüber dem Linienmanagement? Es gibt eine Vielzahl von Informationsquellen, die sich ein ScrumMaster zunutze machen kann, wenn er herausfinden möchte, welchen Status er in einer Interaktion gerade einnimmt. Dazu sollte er den Fokus seiner Wahrnehmung in erster Linie auf sich richten und überprüfen, was seinen Status wirklich ausmacht. Alles hat und zeigt eine Wirkung und kommt beim Gegenüber an.

So logisch das klingt, so wichtig ist es, es sich bewusst zu machen. Dabei geht es auch weniger darum, ob man mit seinen Verhaltensweisen richtig liegt. In erster Linie zählt die Selbstwahrnehmung und die mögliche Wirkung auf andere. Ich verstehe dabei insbesondere die Wahrnehmung des eigenen Handelns als echten Quantensprung. Wie ist mein Gang? Wer berührt wen (Körpernähe – oftmals ist nur der Person mit dem höheren Status gestattet, berühren zu dürfen)? Wer nimmt mehr Raum ein (Sitzposition, Redeanteil, etc.)? Wie wird mit dem Thema Zeit verfahren (wer lässt wen warten, werde Zeiten eingehalten, wer überschreitet die Timebox)? Wie ist der Tonfall in einem Gespräch, wie ist die Wortwahl, gibt es Unterbrechungen und wer unterbricht wen? Wie stehe ich im Raum (über anderen, weit entfernt)?

Wie ist nun mein Standing im Team? Welchen Status genieße ich als ScrumMaster? Informationen gewinnt man darüber am besten, indem man konsequent und ehrlich hinterfragt, mit welcher Haltung man anderen Menschen begegnet und wie die Art und Weise von Kommunikation gesehen wird. Man unterschiedet hierbei

• einen positiven/natürlichen Hochstatus, mit dem man Begriffe verbindet wie Freundlichkeit, Klarheit, Einfühlvermögen, Bescheidenheit, Kompetenz, Vertrauenswürdigkeit oder Geduld. Vereinen sich viele dieser Attribute in der inneren Haltung und der Art und Weise der Kommunikation, dann wird diesen Menschen oftmals Anerkennung, Wertschätzung und Respekt von ihren Interaktionspartnern entgegen gebracht.

• einen negativen Hochstatus, mit dem man Attribute wie Egoismus, Eitelkeit, Arroganz, Ungeduld oder Launenhaftigkeit verknüpft, erzeugen eher Widerwillen und (versteckte) Aggressionen beim Gegenüber.

• einen positiven Niedrigstatus, der sich in Hilfsbereitschaft, Flexibilität, Zuverlässigkeit oder Kreativität wiederfindet oder
• einen negativen Niedrigstatus, der das Ergebnis von Unzuverlässigkeit, Gleichgültigkeit, Widerwillen, Unnachgiebigkeit oder Sturheit ist.

Natürlich stehen diese vier Statuserläuterungen und die beschrieben Typologien nicht für stereotype Definitionen und kommen darüber hinaus fast immer in Mischformen vor bzw. sind ebenso situationsabhängig. Es sind dennoch Orientierungspunkte, die eine Idee vermitteln sollen, welchen Einfluss Verhalten auf den Status innerhalb einer Gruppe, einem Team haben kann. Wer nun einen Vorgeschmack darüber erhalten möchte, welches Standing Teammitglieder untereinander oder aber ein ScrumMaster im Team hat, vielleicht auch, welches Standing man selbst genießt, dem empfehle ich als Startpunkt die nachfolgende Übung.

Wie ist mein Standing? 

Teilnehmerzahl: je mehr umso besser

Vorbereitung: Es braucht eine kleine Freifläche, die als Bühne genutzt werden kann. In der Mitte der Bühne wird ein X auf dem Boden markiert. Alle Teilnehmer sitzen mit Blick zur Bühne (Kinobestuhlung). Neben der “Bühne” ist eine Sitzgelegenheit (Warteposition). Darüber hinaus braucht es einen Moderator.

Material: Kreppband für Markierung, Kinobestuhlung

Ziel: Die Teilnehmer

Ablauf: Der erste Teilnehmer betritt die Bühne und nimmt auf dem Stuhl neben der Bühne (Warteposition) Platz. Wenn er/sie für sich selbst entschieden hat, bereit zu sein, tritt der Teilnehmer auf die Bühne und stellt sich auf das markierte X. Er nimmt mit seinem Blick Kontakt zum Publikum auf und steht dort solange bis der Moderator nach 30 bis 40 Sekunden zu dem Teilnehmer gewandt sagt: “Ja, bitte?” Der Teilnehmer nennt seinen Namen. Im Anschluss daran applaudiert das Publikum und der Teilnehmer nimmt wieder auf dem Stuhl neben der Bühne Platz.

Das Publikum gibt dem Teilnehmer zu seinem Auftritt bzw. “Standing” Feedback. Das Feedback sollte wertschätzend sein und keine Negationen enthalten (z.B. du sollst nicht mehr). Sprecht euer Feedback in Ich-Form aus (z.B. ich habe beobachtet/wahrgenommen, dass…).

Das Wichtigste kommt meist zu kurz: das Debriefing in sechs Schritten

Die Übung soll natürlich nicht für sich alleine stehen, sondern einen gewinnbringenden Abschluss haben. Auf der Bühne stehen ist das eine, ein Feedback erhalten inkl. Debriefing das andere und ebenso Wichtige (= die gemeinsame Beschreibung der Erfahrungen, die das Team in der Übung gemacht hat. Dies beinhaltet ebenso die Auseinandersetzung mit deren Gedanken, Gefühlen und Reflexionen zur Umsetzung ins Business). Häufig kommt genau das in Übungen viel zu kurz. Eine Übung sollte nie für sich alleine stehen.

Eine gute Struktur für ein aufschlussreiches Debriefing kann so aussehen:

Schritt 1: Wie hast du dich gefühlt? (Beschreibung der Emotionen während der Übung. Es wird deutlich, wie unterschiedlich die gleiche Situation empfunden und/oder bewertet werden kann)

Schritt 2: Was ist geschehen? (Austausch von Wahrnehmungen und Beobachtungen)

Schritt 3: Was hast du gelernt? (Identifikation der Erkenntnisse und Schlussfolgerungen)

Schritt 4: Wie hängen die Übung und die Realität zusammen? (Transfer zwischen Übung und Realität. Achtung! Unterscheidung, ob das Verhalten aus der Übung zufällig oder einmalig war oder in Beziehung zur Realität und dortigen Handlungsmustern steht)

Schritt 5: Was wäre gewesen, wenn? (hypothetische Szenarien – optionaler Schritt: Spekulation über hypothetische Szenarien)

Schritt 6: Wie geht es nun weiter und was mache ich mit den neuen Erkenntnissen? (Festlegung von eindeutigen, machbaren, messbaren Zielen und Maßnahmen für das zukünftige Verhalten inkl. Mechanismen für Feedback und/oder Follow ups)

Viel Spaß beim Ausprobieren. Eure Kommentare zum “Standing”, wenn ihr euch mal in eurem Team ausprobiert habt, würden mich brennend interessieren.

Literatur

Klapps, P. (2012). Das Kolibri-Prinzip. Leicht & spielerisch Ressourcen stärken. Kreuz

Related posts:

1. Und gib uns unseren täglichen Status…
2. Der ScrumMaster: Status, Position, Rolle
3. Nein! Es gibt keine BI-Projekte!

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“

Ja, der gute Product Owner hat eine ganze Menge zu tun: Er soll möglichst nah an seinem Team sein, mit dem Kunden im ständigen Kontakt stehen, und darüber hinaus die gestalterische Gewalt über das Produkt haben. Für manchen klassischen Projektleiter bedeutet das ein deutliches Mehr an Aufgaben und an Verantwortung. Auch der ScrumMaster ist, wenn er für sein Team da sein und Scrum in die Organisation tragen soll, gut ausgelastet.

Am Ende eines langen Tages stellt sich dann der Frust über die vielen Stunden ein, die man wieder mit Meetings und Abstimmungen verbracht hat. Spannenderweise beziehen sich die Klagen, die mir zu Ohren kommen, fast immer auf die Quantität. Dabei scheint es eine fest verankerte Vorstellung von “Normalität” zu geben: Der Achtstundentag gilt als das gesunde Maß aller Dinge. Neun Stunden werden noch toleriert, zehn gelten vielerorts schon als grenzwertig – und bei allem, was darüber liegt, erntet man besorgte Blicke und gilt als ernstzunehmender Burnout-Kandidat.

Tomas Chamorro-Premuzic hat im Harvard Business Review einen wunderbar provokanten Text geschrieben, der genau diese Korrelation zwischen Dauer und Last in Frage stellt. Seine Behauptung: Überarbeitung ist nur dann möglich, wenn du keinen Spaß bei der Arbeit hast (http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html):

“Work is just like a relationship: Spending one week on a job you hate is as dreadful as spending a week with a person you don’t like. But when you find the right job, or the right person, no amount of time is enough. Do what you love and you will love what you do, which will also make you love working harder and longer. And if you don’t love what you are doing right now, you should try something else — it is never too late for a career change.”

Nehmen wir das Zitat ernst, sollten wir am Ende eines langen Tages Rückschau halten und für uns prüfen: Was habe ich heute alles gemacht? Was davon hat mir Spaß gemacht, was hat mich herausgefordert, wo ist die Zeit schnell vergangen? Und wo habe ich mich herumgequält, wo war es einfach nur mühsam und frustrierend? Am Ende eines ganztägigen Trainings bin ich manchmal so kaputt, dass ich kaum noch aufräumen und packen kann. Und trotzdem schwebe ich einen halben Zentimeter über dem Boden, halb euphorisiert und halb benommen von den vielen Eindrücken und Erlebnissen des Tages. Die Belastung eines solchen Tages ist enorm, aber sie macht mich nicht fertig. Es ist dann wie ein langer, langer Lauf, an dessen Ende man glücklich auf dem Rasen sitzt und keuchend grinst.

Wenn wir mit Scrum erreichen möchten, dass Menschen anders miteinander arbeiten und daran wachsen, dann können wir nicht einfach weitermachen. Wir müssen uns vielmehr überlegen, was von der bisherigen Arbeitsweise noch Sinn macht, und was komplett gestrichen werden muss.

Drei Vorschläge:

• Meetings auf maximal dreißig Minuten reduzieren und dadurch auf das wirklich Wichtige begrenzen. Eine gut vorbereitete Agenda, ein Moderator (der nur moderiert) und strenge Einhaltung der Timebox.
• In der Mitte des Meetings einen Energizer einbauen (ein kurzes Bewegungsspiel oder etwas mit Humor). So kommt einem die Zeit nur halb so lang vor, eine andere Hirnregion wird aktiviert, man kommt auf andere Gedanken und das Schwere wird etwas leichter.
• Meetings komplett abschaffen. Stattdessen ein Daily zur Synchronisation und dann Open Spaces: Jeder, der ein Anliegen hat, wirbt im Daily dafür, nennt Zeit und Ort. Und jeder, der mit dabei sein möchte, gesellt sich dann einfach dazu. Klingt radikal, ist aber einfach nur eine Umkehrung der Verhältnisse: Wer zuvor über einen “zugemüllten” Terminkalender geklagt hat, der ihm noch den letzten Atemraum genommen hat, darf nun den Luxus eines unbeschriebenen Blatts genießen, das er selber gestalten darf, indem er sich die Themen für den Tag aussucht. Auch das ist mehr Verantwortung, aber es macht den Getriebenen wieder zum Handelnden. Und das kann dazu führen, dass der Job wieder Spaß macht und die Zeit wie im Flug vergeht.

Tomas Chamorro-Premuzic: Embrace Work-Life Imbalance. HBR Blog Network. http://blogs.hbr.org/cs/2013/02/embrace_work-life_imbalan.html

Principles behind the Agile Manifesto: http://agilemanifesto.org/principles.html

Related posts:

1. Der ScrumMaster als Dienstleister
2. Volles Scrum ist gefragt!
3. Sie können abschalten, wir haben die Vision

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

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

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?