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“

Kennt ihr ihn auch? Den ausgepowerten Product Owner, der vor lauter Terminen seinen Tag doppelt bis dreifach verplant hat? Oder den eifrigen ScrumMaster, der noch abends im leeren Teamraum sitzt und die Retro für den nächsten Tag akribisch vorbereitet? Manche sagen dann: “Das kann nicht gut sein.” Und zitieren das Agile Manifest, das von “nachhaltiger Entwicklung” und von einem “gleichmäßigen Tempo” erzählt, das “auf unbegrenzte Zeit” haltbar sein soll. Häufig geistert dann noch dieses eine Wort herum: Burnout.

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

Why firing brilliant assholes is required to build a great engineering culture

 

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

„Wir wollen das Scrum of Scrums (SoS) anders gestalten – und zwar grundlegend. So, wie es jetzt gerade läuft, funktioniert es nicht.“

Mit diesen Worten begrüßte mich vor einiger Zeit ein Company ScrumMaster, den ich zurzeit coache. Er berichtete, dass das Scrum of Scrums seit einigen Wochen bei den Teams in der Kritik stehen würde, weil die dort besprochenen Inhalte den Teams wenig Mehrwert brächten und die dort investierten 15 Minuten Zeitverschwendung seien. Es sei vor allem herausgekommen, dass nicht jedes Team jedem anderen Team etwas zu sagen habe – und schon gar nicht jeden Tag. Vielmehr gäbe es Teams, die immer mit den gleichen Teams kommunizieren und genau das müsse man verstärken und statt einer großen Plattform mehrere kleinere Gelegenheiten schaffen, bei denen diese Themenverwandtschaften besprochen werden können. Man habe sogar schon einen Namen für diese neue Form der Zusammenarbeit gefunden: Meta-Scrums. Die ScrumMaster haben sich nach Rücksprache mit ihren Teams entschieden, das SoS- Setting mit „Meta-Scrums“ zu revolutionieren.

Ich lobte meinen Coachee für diese tolle Idee und unterstütze seine Ausführungen, indem ich auf seinen nachhaltigen Inspect-and-Adapt-Drang verwies. Ich schloss mein Lob mit einem nachdenklichen Seufzer. Leicht verunsicherte fragte mich der Company ScrumMaster, ob ich mit der Entscheidung nicht zufrieden sei.

Ich antwortete: „Ja und nein.“ Ich bestärkte ihn erneut darin, immer auf der Suche nach Verbesserungen bzw. Veränderungen zu bleiben und die Teams weiter als Meinungs- und Stimmungsbarometer zu nutzen (Ask the team). Ich erläuterte ihm aber, worin ich ein Problem erkannt habe. Meines Erachtens wäre eine Big-Bang-Lösung das falsche Signal an die Teams und würde der Reputation der ScrumMaster eher schaden. Warum? Der ScrumMaster hat die Verantwortung, den Scrum-Prozess zu bewahren und alles dafür zu tun, um die Produktivität seines Teams zu steigern. Mit der Meeting-Revolution würde jedoch der Prozess in Frage gestellt werden.

Wurde wirklich alles unternommen, um das kritikbehaftete SoS zu etablieren? Nein. Auf die Frage, ob alle ScrumMaster dafür gesorgt hätten, dass der Sinn des Scrum of Scrums in den Teams verstanden wurde und damit die (Selbst-) Verantwortung der einzelnen Teammitglieder geklärt sei, musste der Company ScrumMaster sich eingestehen, dass das „interne Marketing“ für das SoS Lücken aufwies. Seine Entscheidung für einen vollständig neu aufgesetzten Prozess kam noch stärker ins Wanken, als ich ihn bat, sich nochmal vollständig von seiner gefundenen Lösung zu entfernen und meine Fragen zu beantworten: Was war gut am alten SoS-Prozess? Was hatte das SoS bislang erfolgreich gemacht? Warum sollte man das SoS unbedingt behalten? Ich intensivierte meine Lösungsfokussierung, indem ich dem Company ScrumMaster riet, auch sein ScrumMaster-Team mit dieser Denkrichtung zu konfrontieren.

Alles anders

Gesagt, getan. Zwei Wochen später wurde ich bei meinem nächsten Besuch Zeuge eines lebhaften, gut besuchten, produktiven Scrum of Scrums. Am Ende gab es sogar Applaus! Die Teams applaudierten ihrer eigenen Performance. Verrückte Welt! Was ging hier vor sich? Wurde ich gerade Zeuge des ersten Scrum-Bestechungsskandals? Wurde verdeckt körperliche Gewalt an den Teams geübt?

Nein! Natürlich nicht. Aber wie war dann diese (Ver-)Wandlung zu erklären? Es klingt fast zu simpel, aber das ScrumMaster-Team hatte lediglich zwei klein(st)e Veränderungen vorgenommen:

• 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

"Es sind nicht die Dinge, die uns beunruhigen, sondern unsere Sicht auf die Dinge." Seneca

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

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum
Part 6: How internationally distributed Teams can improve their Sprint Planning 1
Part 7: How internationally distributed Teams can improve their Sprint Planning 2

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?

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 7)

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Part 4: The Pros and Cons of Electronic and/or Physical Taskboards
Part 5: How internationally distributed Teams can improve their Daily Scrum
Part 6: How internationally distributed Teams can improve their Sprint Planning 1

Stephanie G.: Having discussed Sprint Planning 1, let us continue with your tipps & tricks for Sprint Planning 2. How would you conduct this design meeting?

Ina K.: I would actually say that it‘s quite similar to Sprint Planning 1, apart from the Product Owner not being present. Sometimes the meeting is off to a slow start. If that‘s the case, the ScrumMaster should get involved and start filming people (see Christof’s answer in How internationally distributed Teams can improve their Sprint Planning 1) as well as make sure that the Team members who document the meeting rotate. Once the Team members properly get going, the ScrumMaster can retreat  and remain in a position of observation. Watch the Team – are they interacting enough? Do they seem to have a common understanding? Is everyone adding to the conversation? It‘s important to keep an eye out for such things, as the DevTeam members usually don‘t. Once they actually start looking out for it by themselves, the ScrumMaster has achieved wonders.

Hélène V.: The most important aspect of Sprint Planning 2 is that the common design solution that the Team has agreed upon is visualized and can be seen by all Team members. Only if this has happened, can the distributing of Tasks on a cross-location basis begin. Some Teams think that they do not need any visualisation … all I can say is that distributed Teams who believe this myth have a much higher chance of forgetting important aspects to their design.

Kristina K.: My Team had this issue. The fact that they typed up the Tasks into an electronic tool didn‘t help either, since it sometimes seemed that only the one who did the typing also did the thinking. The fact that the know-how was so unevenly distributed was an impediment in Sprint Planning 2, too. The lack of drawing meant that there was no real common Team understanding of the design – they didn‘t talk about how to implement the User Stories, but rather talked about what singular steps were necessary to implement them.

Bernd K.: We didn‘t really have what you can call a design session either. Sometimes the Team members used the flip charts for drawing, but then I had to take a picture (since the quality of our webcam was not good enough) and send it to the other Team members. This alone would take 5 minutes, by which time the moment for entering in the design discussion was over.

Generally, I did not enjoy Sprint Planning 2 – it often stretched out over three to four hours, which is two hours longer than a Sprint Planning for a two-week sprint should be. The problem was that our electronic tool did not have a word limit for Tasks, meaning that the Team often spent ages on writing them. This did not help to bridge the geographical gap either: the Team members in Romania were rather pragmatic, while the ones in Germany could be called the „philosophers“ – wishing to specify their Tasks and over-thinking the why what, when and where. While the Team dynamic of a co-located Team would have quickly eliminated this discrepancy with smiles or a nervous look, the Romanians were hidden behind a microphone and nobody knew what they were thinking.

Kristina K.: Oh dear, that sounds quite irritating. What I started implementing after a while was to ask the various locations to prepare several design options and to then challenge each other during Sprint Planning 2. In the end, we used the best idea out of all of them and wrote Tasks for it. This ensured that everyone on the Team had actually thought about the Stories, even if they‘re no expert.

Hélène V.: Yes, that‘s what I would recommend, too. After Sprint Planning 1, the Team should do a short mapping of the areas and topics that need discussing. You could then divide up the topics for each location i.e. location A takes the module on the database approach, location B focusses on another solution etc.

Christof B.: I agree with both of you, but I think that the decision of splitting up a Team for or in preparation of Sprint Planning 2 really depends on the Team constellation. If all roles are represented at all locations, I do think that the Sprint Planning 2 can be conducted as group work – meaning that each location grabs its own User Story, does its own mini-Sprint Planning 2 and then presents it to the rest of the Team after 30 minutes. After reviewing the outcome, the entire Team writes the Tasks together. However, this is only possible if both front-end and back-end are present at all locations. This option is not possible if i.e. testers and developers are in different locations.

Stephanie G.: It is so interesting that you all recommend splitting up the meeting, since I actually used to do the same. Only I did not split it in the way of one Story in each location, but rather one person from each location formed a Team, which would together work on one Story (see Pre-SP2 Design Sessions or How to use your Time during a Sprint Change?).

Christof B.: Sprint Planning 2 should not be underestimated. It is certainly not trivial, as it can be chaotic due to the necessary interaction between the Team members. After all, it is not only a meeting, but a creative process, design thinking, architectural brain-storming etc. A lot happens during SP2. I don‘t believe that its doable over the phone. It‘s even nearly impossible to do via video conference. I really think it‘s best if each location works on its own concept during Sprint Planning 2, which is only interrupted by SoS-like coordination meetings where the whole Team gets together again. For example, a design session for 30-45 minutes, followed by 10-15mins of presentation by each location including feedback.

Deborah W.: Funny. I never had any difficulties with Sprint Planning 2, meaning that I could always really enjoy this meeting. I thought it was one of the simpler ones when dealing with distributed Teams. Maybe it was an exception, but my Team members got really involved – even across locations. It was easier than SP1, since there was always less to show. Yes, we did draw a few diagrams and design the architecture, but not for too long. The topic was pretty clear to everyone, so the meeting was concise and short.

Stephanie G.: I love it when opinions diverge as much as yours right now. So before you all get jealous of Deborah‘s Team, let me quickly sum up the main points of advice:

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

 

Related posts:

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

Im Psychologiestudium war die Wahrnehmungspsychologie eines meiner Lieblingsfächer. Ich kann mich noch gut daran erinnern, wie mein Professor zwei Fotos zweier Männer mittleren Alters nebeneinander hinlegte: Der eine im teuren Armani-Anzug, frisch rasiert, wie aus dem Ei gepellt. Der andere im Freizeitlook, Drei-Tage-Bart. Der Professor fragte uns: “Bei welchem der beiden Herren würden Sie eher eine Lebensversicherung  kaufen?” Interessanterweise entschieden sich fast alle Studenten für den Anzugträger und wurden damit Opfer des Halo-Effekts (vom Griechischen hàlos = Lichthof). Der Halo-Effekt (oder Hofeffekt) ist einer der am häufigsten auftretenden Beurteilungs- bzw. Wahrnehmungsfehler. Er besagt, dass die Dominanz einzelner Eigenschaften bzw. Attribute den Gesamteindruck einer Person bestimmt und auf diese Weise die Wahrnehmung weiterer Eigenschaften überstrahlt. So können Äußerlichkeiten wie das Aussehen, die Kleidung oder gar die Körpergröße den Ausschlag dafür geben, ob man z.B. kompetent oder freundlich wahrgenommen wird. Das Märchen “Des Kaisers neue Kleider” von Hans Christian Andersen ist ein schönes Beispiel für die kritische Auseinandersetzung mit den Auswirkungen des Halo-Effekts.

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

Wenn das Team halo-ziniert

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

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

Literatur

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

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

Related posts:

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

Eines der faszinierendsten Elemente von Scrum als Modell ist die Tatsache, dass hier neue, innovative Rollen im beruflichen Kontext kreiert werden und klassischen Rollen prägnantere Funktionen (z.B. dem Manager) zugeordnet sind. Die Funktionen von ScrumMaster und Product Owner sind in der Projektwelt ohne Beispiel. Daher ist das  Verständnis über ihre Aufgaben und Instrumente mitunter noch diffus und schwer einzuordnen. Was genau sind ihre Wirkungsfelder, was sind die dazugehörigen Kompetenzen, welche Methoden und Techniken stehen zur Verfügung, was sind die Einflussbereiche, was genau ihre Aufgaben und Funktionen, etc.? Und wie grenzen sie sich zu anderen Rollen wie Team- oder Projektleiter ab?

Rollen müssen sich legitimieren

In sozialen Systemen sind Rollen zentrale Elemente, denen spezifische Aufgaben und Verantwortungsbereiche zugeordnet sind. Mit ihrem Handeln sollen sie zum Erfolg des Systems beitragen, sie haben eine definierte Legitimation, eine von außen vorgegebene Struktur und sind mit spezifischen Erwartungen an den Rollenträger in punkto Verhalten, Einstellungen, Werte, Know-how usw. verbunden. Es gibt aber immer auch einen eigenen Gestaltungsraum, in dem der Rollenträger seine Aufgaben individuell interpretieren und ausüben kann. in der Arbeitswelt gibt es relativ einfache, unkomplizierte Rollen, aber immer mehr solche, die hoch komplex und herausfordernd sind. Zu den letzteren gehören ganz sicher Rollen wie jene des ScrumMasters und des Product Owners. Neue Rollen brauchen in der Regel Zeit, um sich etablieren zu können und akzeptiert zu werden. Ihr Sinn und Nutzen für das System zeigt sich erst im Laufe der Zeit. Der Rollenträger hat darauf großen Einfluss: Schließlich trägt er mit seinem kompetenten Handeln dazu bei, wie seine Rolle im beruflichen Umfeld wahrgenommen und eingeordnet wird. Dafür braucht man bestimmte Fähigkeiten und Fertigkeiten, aber auch ein entsprechendes Handwerkszeug. Genauso muss die neue Rolle in ihrem Umfeld, besonders an den Schnittstellen, auf Offenheit und Verständnis stoßen, damit der Nutzen tatsächlich wahrgenommen werden kann. Was dabei auf jeden Fall notwendig ist, ist die eindeutige Legitimation durch das Management.

In der Scrum Praxis machen viele die Erfahrung, dass eine Grundausbildung zum ScrumMaster oder Product Owner für die ganze Komplexität dieser Aufgaben nicht ausreicht. Im Alltag wird schnell deutlich, wie zentral der sorgsame Umgang mit Menschen ist. Es müssen vielfältige Kommunikationsprozesse gesteuert werden, in der Veränderungsdynamik muss die laterale Führungskraft die Ruhe bewahren, manchmal auf Konfrontationskurs mit dem Management gehen usw. usw. Kurzgesagt lautet das, was diese Rollen so besonders macht: Change, Change und nochmal Change!

Neue Rollen sind Stützen der Veränderung

Wer an Change denkt, denkt meist zuerst an das Neugestalten von Strukturen und Prozessen im Unternehmen. Als prozesshafte Struktur tut das Scrum natürlich. Ein ScrumMaster denkt aber weit darüber hinaus: Er denkt an die betroffenen Menschen und an die tradierte Unternehmenskultur. Ihm ist bewusst, dass er die Menschen einbinden muss, wenn die Kultur des Systems neu gestaltet werden soll, denn die Menschen sind die Kultur. Sowohl ScrumMaster als auch Product Owner (ggf. auch Team- oder Projektleiter) werden zu wertvollen Stützen eines agilen Unternehmens, wenn sie in ihrem Change-Repertoire sattelfest sind und es zum richtigen Zeitpunkt einsetzen. Damit helfen sie auch dem Management, Veränderungsprozesse über Scrum hinaus anzustoßen. Natürlich gibt es Schattenseiten, wenn diese Rollen schlecht ausgefüllt werden: Frustration, Demotivation, Resignation bei den betroffenen Mitarbeitern. So werden nicht selten die wertvollsten Mitarbeiter „verbrannt“.

Der Scrum ChangeManager als multifunktionale Rolle

 

Was sind die Lernfelder für diese multifunktionalen Rollen? Laterales Führungswissen, die Kompetenz der professionellen Kommunikation, Umgang mit Konflikten, Moderation und Workshopgestaltung, die Kunst des Coachings, systemisches Know-how zum Change Management und zur Teamentwicklung haben zentrale Bedeutung. Ebenso muss die eigene Persönlichkeit durch gezieltes Selbstmanagement weiterentwickelt werden. Für einen solchen „Knochenjob“, bei dem manchmal der Widerstand um die Ohren pfeift,  braucht man Selbstsicherheit und Standing, Klarheit über die eigenen Ziele und Ressourcen, Mut zu Innovation und Kreativität und den bewussten Umgang mit Herausforderungen und Stress. Gerade neue, noch nicht umfassend etablierte Rollen brauchen Zeit um zu lernen, Erfahrungen zu sammeln und Feedback zu bekommen, um sich ihren Status zu erarbeiten.

Zukünftige Rollenträger, Management und Personalentwicklung tun also gut daran, sich schon zu Beginn einer Scrum-Implementierung um die Ausstattung mit den nötigen Fertigkeiten zu kümmern. Der zertifizierte Scrum ChangeManger als Vertiefungs- und Erweiterungskonzept ist ein sinnvoller Weg dazu. Er bleibt nicht beim Verändern vom Vorgehensweisen stehen, sondern sieht das Ganze, die Menschen in einer neuen Situation. Und daher verändert und entwickelt er zu allererst: sich selbst.

Tipp

Wie fülle ich meine Rolle erfolgreich aus? Mit unseren Scrum Supplements stärken Sie Ihr souveränes Auftreten als Change Agent: Konflikte regeln, Impediments lösen, Teams entwickeln, Workshops gestalten, Gespräche zielorientiert führen – all das mit der richtigen Dosis Selbstbewusstsein.

Related posts:

1. Der klassische Projektmanager in Scrum
2. Scrum – Erfolgsfaktor Personalmanagement
3. Die drei weiteren Rollen in Scrum

Platons Zitat “Pánta chorei kaì oudèn ménei” ist die knappste Formulierung der Flusslehre Heraklits, die besagt: Alles fließt und nichts bleibt. Es gibt nur ein ewiges Werden und Wandeln. Sie ist eine Metapher für die Prozessualität der Welt. Das Sein ist das Werden des Ganzen. Das Sein ist demnach nicht statisch, sondern als ewiger Wandel dynamisch zu erfassen. (Wikipedia)

Das Leben ist Wandel, das wussten also schon die alten Griechen. Und wir sind im Flow, hier und jetzt, am besten. So besagt es die Theorie. Wir sind in unserer Energie und erschöpfen uns nicht.

Doch die Realität sieht meistens anders, zumindest meine sah anders aus.

Stunden um Stunden habe ich mit Budget-, Projekt- und Personalplanungen verbracht. Für nächste Woche, für nächsten Monat  – was ja noch gerade so geht. Fürs nächste Jahr – was eigentlich gar nicht geht. In einem Projektlaufzettel (ein hochoffizielles Dokument) habe ich tatsächlich den Begriff Glaskugelschätzung gefunden! Ich denke, da erübrigt sich jeder Kommentar. Und da Leben das ist, was geschieht, während man es plant, war ein Großteil der Planung innerhalb kürzester Zeit obsolet. Projekte kamen gar nicht, dafür fielen ganz neue vom Himmel, Budgets wurden gekürzt, Mitarbeiter kamen und gingen. Diese Art der Planung war für mich in höchstem Maße Zeitverschwendung, Geldverschwendung, sinnlos. Es war eine Verwaltung von Zukunftängsten, die nur dazu diente, eine gefühlte Sicherheit herzustellen, mühselig und erschöpfend. Geht es euch auch so wie mir damals?

Und dann kam Scrum.

Keine tapetenrollenlangen MS Projektpläne, die mich schon allein optisch überforderten. Stattdessen eine Vision entwickeln. Alle Ideen, Stories, Anforderungen in einem Backlog sammeln und priorisieren, aber nur noch drei Sprints im Voraus planen. Wow, schon das allein war eine Erleichterung

Keine stundenlange Kapazitäten-Planung für die nächste Woche mit den Projektleitern, die am Ende der Woche doch nicht gemacht hatten, was sie geplant hatten und jeder hatte tausend gute Gründe dafür. Dafür im Sprint Planning zu Anfang des Sprints mit dem Product Owner und dem Team den Umfang des nächsten Sprints besprechen, sich gemeinsam auf ein Sprintziel comitten. Kontinuierliche Fortschrittskontrolle im Daily und mit Hilfe des Burn Down Charts. Jeden Tag sehen können, wo wir gerade stehen. Kontinuierliche Planung statt Glaskugelschätzung.

Keine Jour Fixes mehr, kein Status, nur noch die Review Meetings mit den Teams. Wenn ich wissen wollte, wie der tagesaktuelle Status war, musste ich mich nicht mehr durch 50-seitige Power-Point-Berichte graben (kein Scherz!) und diverse Jour fixe mit Projektleitern einstellen. Ich bin still ins Daily gegangen, einen Blick auf Task Board und Burn Down Chart werfen und ich wusste innerhalb von 15 Minuten, wo das Team, das Projekt stand. Das ist übrigens mein Geheimtipp fürs Management: Einfach mal still das Daily verfolgen! Besser und effektiver kann man nicht mitbekommen, was im Team läuft und wie die Stimmung im Team ist. 15 Minuten pro Team jeden Tag. Mehr braucht man nicht.

Das Leben und Arbeiten machte plötzlich wieder Spaß. Die Ausrichtung auf ein gemeinsamen Ziel setzt ungeahnte Energien frei und gibt der Arbeit Sinn. Meine Teams und ich konnten jetzt Visionen entwickeln  UND umsetzen. Ganz entspannt im Hier und Jetzt. Go with the (Scrum-) Flow!

Related posts:

1. Schätzen vs. Planen?
2. First things first
3. Ferien und Sprints

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

Als Management Consultant bekomme ich regelmäßig die Möglichkeit, die Scrum-Implementierung in den unterschiedlichsten Branchen und Unternehmen zu beobachten bzw. zu begleiten. Interessanterweise ähnelt in der Auslegung von Scrum kaum ein Unternehmen dem Nächsten – nicht einmal, wenn es um die Abhaltung der Scrum-Meetings geht. Selbst das kürzeste Meeting im Scrum Flow, das Daily Scrum, sieht stets anders aus. Vor allem bei Scrum-Neulingen habe ich die Erfahrung gemacht, dass ein gewisser, vorher gemeinsam mit dem Coach geübter Ablauf dem neuen ScrumMaster etwas Sicherheit bietet. Mein Vorschlag sieht meist so aus:

Zweck

Synchronisation innerhalb des Dev-Teams, um das Sprintziel und somit das Release zu schaffen.

Ziel

Als Team wissen wir, was erledigt werden muss, damit die committeten Stories auf Done gesetzt werden können.

Ablauf

1. Das Dev-Team trifft sich im Halbkreis vor dem Taskboard. Der ScrumMaster steht seitlich ca. einen halben Schritt außerhalb dieses Halbkreises. Gäste stehen komplett außerhalb des Halbkreises.
2. Begrüßung durch den ScrumMaster – ein “Guten Morgen” reicht aus. Hier ist ein motiviertes Auftreten wichtig: Wenn der ScrumMaster als Coach des Teams schon keinen Bock hat, wie soll das Team dann erst Lust bekommen? Der ScrumMaster startet mit einer Begrüßung und macht auf die geplanten Termine für den Tag aufmerksam.
3. Falls jemand im Dev-Team noch keine Vorstellung hat, welche Arbeit er an diesem Tag leisten kann/ möchte/wird, sollte er sich gleich anfangs zu Wort melden, damit das restliche Team ihn für potenzielle Aufgaben in Erwägung ziehen kann.
4. Nacheinander erzählt jedes Teammitglied seinen Kollegen Folgendes:
   1. Was habe ich seit dem letzten Daily umgesetzt? (falls fertig, wird der Task von Work In Progress in Done gehängt) Falls die Aufgabe wider Erwarten innerhalb des letzten Tages nicht fertiggestellt werden konnte, erklärt das Teammitglied kurz, wodurch die Aufgabe behindert wird. Dann wird ein Punkt auf das Post-It gemacht. Ggf. wird diese Störung am Impediment Backlog, auf dem Task bzw. an der Story visualisiert.
   2. Was werde ich heute tun? Hier zieht sich das Teammitglied eine Aufgabe aus der To Do Spalte der höchstpriorisierten User Story und hängt sie in Work In Progress. Falls möglich, plant das Teammitglied gleich Pair Programming mit einem Teamkollegen bzw. Unterstützung, die er in Anspruch nehmen möchte.
   3. Was behindert mich in meiner derzeitigen Arbeit? (Visualisierung nicht vergessen…)
   4. Wo benötige ich Hilfe?
   5. Meine heutige Verfügbarkeit
   6. Das nächste Teammitglied übernimmt und beantwortet dieselben Fragen gegenüber dem restlichen Team. Dies passiert reihum, bis das Team seine Arbeit synchronisiert hat und jeder weiß, was er heute mit wem bearbeiten soll.
   7. Ist eines der Teammitglieder nicht da, übernimmt ein anwesendes Teammitglied die Punkte des abwesenden Kollegen und hängt die jeweiligen Aufgaben auf dem Taskboard für ihn um.
5. Der ScrumMaster fasst abschließend folgende Punkte zusammen:
   1. Neue Impediments, die in diesem Daily ans Tageslicht gekommen sind und um die er bzw. jemand im Team sich kümmern wird
   2. Inwieweit sind aktuelle Impediments schon gelöst bzw. ist dafür die Hilfe des Dev-Teams nötig?
   3. Neue Termine, falls ein detaillierter Abstimmungsbedarf zwischen Teammitgliedern sichtbar geworden ist
   4. Die eigene heutige Verfügbarkeit, ggf. einer Vertretung
   5. Falls der Product Owner anwesend ist: Spätestens jetzt noch fragen, ob er weitere  Anmerkungen hat
6. Das Burn-Down Chart wird von einem Teammitglied aktualisiert.

Alles was man für dieses kurze Stand-Up benötigt, sind ein ScrumMaster, ein Dev-Team, ein Taskboard und ein Burn-Down Chart. Gäste, vor allem der PO, sind immer herzlich willkommen. Die Rahmenbedingungen von max. 15 Minuten, täglich, stehend, selber Ort, selbe Zeit dürfen deshalb aber nicht außer Acht gelassen werden.

Was haltet ihr von diesem kleinen “How-To”? Wie sieht der Ablauf des Daily Scrums bei euch aus?!

Related posts:

1. Christbaumschmücken Advanced
2. Erfolgreiches Nichtwollen
3. 10 Things about ScrumMasters

Was macht jemand, der sich verändern möchte? Er setzt sich ein Ziel. Der Raucher will in einem Monat von einer Packung auf drei Zigaretten runtergehen. Ich will bis zum Sommer hundert Meter in 11 Sekunden laufen können.

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!

Wenn wir davon ausgehen, dass Produktentwicklung zu jedem Start mit Erwartungen, Annahmen, Befindlichkeiten und schlichtweg Vermutungen konfrontiert ist, dann Reden wir von Hypothesen. Wie prüft man Hypothesen? Richtig, durch Experimente, und das möglichst schnell und kostengünstig – denn man erkennt das Wichtigste erst nach dem Start.

Was machen wir in Unternehmen, vor allem im Enterprise? Da wird versucht, die Kosten von Hypothesen im Vorfeld möglichst genau einzugrenzen, um die möglichen Experimente gegeneinander abzuwägen. Diese Unternehmen agieren also meist risikoavers. Da in der Software-Entwicklung schmerzlich gelernt wurde, was es heißt, falsche Schätzungen abzugeben, entstehen für Schätzungen teilweise enorme Kosten. Die Kosten entstehen, weil genau eruiert wird, was alles sein könnte, und dafür benötigt man viele Details, die später selten noch etwas wert sind. Es wird Eindeutigkeit provoziert und geschätzt und zwar genau dort, wo Mehrdeutigkeit im Spiel ist. Die Dinge, die geschätzt werden, haben selten etwas mit dem zu tun, was letztlich später umgesetzt und noch später akzeptiert wird. Ein weiteres Problem, das damit einhergeht: Die Anforderer lassen jeden Gedankenblitz von der Software-Entwicklung schätzen, stören so die Menschen und halten sie von ihrer eigentlichen Arbeit ab.

Warum ticken Unternehmen so risikoavers? Meine These: Es fehlt an Vertrauen, Fachkenntnis und Mut zu klaren Entscheidungen. Klar sind die Themen auch komplex, allerdings entzerrt man Komplexität nicht durch das Denken alleine, sondern vielmehr durch das Tun und Anschauen – zu viel mehr taugt unser Verstand auch nicht. So ist es auch leichter, Verantwortung abzuwälzen und anderen Schuld in die Schuhe zu schieben. Schließlich hat sich ja die Software-Entwicklung verschätzt und nicht etwa der Vertrieb oder das Marketing entschieden, dass das Feature sinnvoll und wichtig ist.

Schätzungen sind teilweise wichtig, das möchte ich nicht anzweifeln, aber klar einschränken. Wenn ich für mein Produkt den gesetzlichen Termin kenne, wenn ich weiß, dass ich nur ein gewisses Zeitfenster für mein Produkt habe, wenn ich schnell etwas auf dem Markt ausprobieren möchte, dann benötige ich selten eine genaue Schätzung. Dann mache ich es, oder unterlasse ich es – je nach Konsequenz.

Was ist nun mit der anderen Sachlage, z. B. bei zwei ähnlich wichtigen Features oder Produkten, die ich auf den Markt bringen könnte? Warum sollte ich hier auf eine Schätzung verzichten? Zum einen weil ich meine Entwicklung ausbremse, indem ich sie störe und ihr Gedanken wie Flöhe in den Kopf setze. Zum anderen hilft viel Information nicht viel, sondern erschwert die Entscheidung. Zudem ist die Zeit der großen Produkte ziemlich vorbei und es ist wesentlich wichtiger geworden, schnell auf dem Markt zu sein und seine Ideen zu testen, als fertig ausgereifte und vollends fertige Produkte nach Jahren auf den Markt zu werfen. Auch hier werden die risikobereiten Unternehmen mehr und mehr belohnt. Unternehmensstrategien stehen auf dem Kopf und so macht Agile das.

Warum kann ich auf Schätzungen und Details verzichten und wie mache ich das?

Zuerst: “Warum kann ich auf auf Schätzungen und Details verzichten?” Weil die Bauchentscheidung oftmals die bessere Wahl ist. Wenn ich Sie frage, welche der zwei Features oder Produkte Sie als Nächstes haben möchten, dann haben Sie sich, unabhängig von Schätzungen und ROI-Geschichten, von Business-Value-Berechnungen und strategischen Gesichtspunkten, höchstwahrscheinlich bereits entschieden und das ist gut so. Nahezu jeder, der sein Geschäft gut kennt, kann abwägen, kann aus dem Bauch heraus entscheiden, was er für das Unternehmen als wichtiger betrachtet. Wichtig ist das Zeitfenster und die Reihenfolge, in der das Feature zum Zug kommt.

Gehen wir einmal davon aus, dass Sie die durchschnittliche Durchlaufzeit von Features oder Produkten in ihrem Unternehmen kennen. Also kennen Sie die Anzahl der benötigten Tage von der Idee bis zur Fertigstellung. Im nächsten Schritt begrenzen Sie die Anzahl der gleichzeitig laufenden Entwicklungen. Als nächstes bestimmen Sie einen wiederkehrenden Zeitpunkt, einen Rhythmus, um die nächsten Themen zu priorisieren und an die Entwicklung zu übergeben. Letztlich geben Sie klare Regeln aus, wie priorisiert wird, bspw. durch genau eine Person, einen Kreis von Experten oder rotierende und gewichtete Verteilung nach Bereichen – viel ist möglich, fair und transparent sollte es sein.

Jetzt priorisieren Sie zu den bekannten Zeitpunkten nach Ihrem Regelwerk die nächsten Produkte oder Features und übergeben genau so viele an die Entwicklung, wie Plätze in der Entwicklung frei sind (Limit work in progress).

Was hat das mit Scrum zu tun?

Erstmal viel! Scrum begrenzt das System, vermeidet Überlast durch den Sprint und anhand des Commitments des Teams. Der Sprint stellt den Rhythmus dar und gibt klar vor, wann geliefert wird und wann neue Features und Produkte an die Entwicklung übergeben werden. Der Product Owner entscheidet autonom über die Priorisierung der nächsten Features und arrangiert so die Reihenfolge der Features/Produkte, die als Nächste zu entwickeln sind.

Einsprüche

Höre ich da ein fernes Schreien, ein: “Nein, dann sind wir nicht ausgelastet und wir verschwenden Kapazitäten!” Tja, dann ist das so. Jetzt stellt sich die Frage, wovon lassen Sie sich lieber steuern: Von dem, was sie haben oder von dem, was Sie brauchen und möchten? Ich schätze, das ist Ihre Entscheidung. Das eine ist die eigene Aufstellung zum Selbstzweck, das andere die Ausrichtung am Kunden als Zweck des Unternehmens.

Höre ich da ein nahes Schreien, ein: “Wir benötigen doch Klarheit für den ROI!” Tja, dann ist das so. Jetzt stellt sich die Frage, für welchen ROI: Aus all unseren Priorisierungskosten versuchen wir rational eine Beurteilung herauszufiltern, die Folgendes erzeugt: Zu viel Informationen zum zu frühen Zeitpunkt, falsche Zahlen und ein falsches Gefühl von Sicherheit. Wir priorisieren anhand des Verstandes mit Hilfe von Hypothesen, die teils aus echten Fakten hergeleitet werden, teils aus Nonsens und beides vermischt sich, unteilbar, nicht unterscheidbar. Von der Idee hin zum Ergebnis haben unsere Gedanken das zuerst Gedachte mehrfach verändert und das bei jeder involvierten Person. Wäre das der ROI, den Sie berechnen möchten? Ist das der ROI, den Sie berechnen?

Related posts:

1. Scrum History | Ken´s Talk über Qualität
2. Case Study, we are sorry
3. Certified Product Owner – How to ESTIMATE Business Value – Relative Weight

Im ersten Teil des Blogs habe ich mich auf die Abbildung der relativ betagten theoretischen Grundlage des gruppeninternen Führungsverhaltens auf die ScrumMaster Rolle bzw. Prozessverankerung in Scrum konzentriert. Heute steht die Führung an der Grenze zwischen Gruppe und Organisation im Mittelpunkt.

Manz/Sims (1986, S. 148ff.) sehen als Grenzverhalten einer externen Führungskraft die Kommunikation zu dem und von dem Management (1), die Funktion als Bindeglied zwischen Arbeits-Teams in Bezug auf Kommunikation (2) und Unterstützung des Produktionsflusses (3), Training unerfahrener Teammitglieder (4), das Bereitstellen von Arbeitsmaterial (5), die Ermutigung zum Übernehmen anfallender (fremder) Aufgaben (6) und die Abstimmung mit anderen Teamleitern (7).

Aufgaben eines Teamleiters eines selbstorganisierten Teams nach Manz/Sims (1986, S. 148ff.) Aufgaben des ScrumMasters 1) Der Teamleiter informiert das Team über Entscheidungen oder Standpunkte des Managements und stellt sicher, dass das Management über die Bedürfnisse und Standpunkte des Teams informiert ist. Dieser Informationsfluss – ermöglicht durch den Teamleiter – sorgt dafür, dass sich Team und Arbeitssystem besser aneinander anpassen können. Der ScrumMaster als Change Agent sorgt dafür, dass das Management die Rahmenbedingungen für das Team ständig optimiert. Außerdem nimmt er dem Team die Diskussion oder den ggf. zeitintensiven Informationsaustausch mit dem Management ab. 2) Die Verbindung von Teams über den Teamleiter sehen Manz/Sims besonders in Organisationen, in denen aufgrund der Technologie starke Abhängigkeiten zwischen den Teams bestehen, als wichtig an. Zumindest sorgen die ScrumMaster im ScrumMaster-Team dafür, dass übergreifende Kommunikation sichergestellt ist und auch der skalierte Scrum Prozess den Austausch zwischen den Teams ermöglicht. Abhängigkeiten sollten jedoch durch Team und Produktschnitt so weit als möglich vermieden werden. Ist das zu Beginn noch nicht so, ist es Aufgabe der SM, darauf hinzuarbeiten oder die Organisation trotz Abhängigkeiten zu befähigen, zu funktionieren und zu liefern. 3) Hierunter könnte in Ergänzung zu 2 und 5 z.B. die Weitergabe von Output des einen an das andere Team oder die Optimierung dieses Prozesses verstanden werden. In Scrum ist das keine Aufgabe des ScrumMasters. Entweder stellen die Product Owner dies durch die Releaseplanung und Abstimmung der Produktinkremente sicher oder die Teams können untereinander dafür sorgen. 4) Das Training eines unerfahrenen Teammitgliedes durch den Teamleiter (nicht wie oben beschrieben durch das Team) kann nach Manz/Sims zur besseren Leistung des Teams beitragen, da die Teammitglieder die Teamaufgaben besser erledigen können. Training im Sinne des Scrum Frameworks und der agilen Prinzipien liegt beim ScrumMaster. Alles Fachliche kann in der Regel jedoch nicht vom SM abgedeckt werden. Hier würde der ScrumMaster dafür sorgen, dass das Team (siehe Blog Teil 1 zu dem Thema) oder evtl. externe Schulungen dafür sorgen, dass das neue Teammitglied arbeitsfähig wird. 5) Bereitstellung von Arbeitsmaterial Nicht der ScrumMaster, sondern der Product Owner sorgt dafür, dass das Team mit Arbeit versorgt ist. Er/sie liefert User Stories und somit den Input für den Produktionsprozess. Arbeitsmaterial wie Infrastruktur, Berechtigungen, Lizenzen, Schulungen und alles weitere, was das Team braucht, um den Input tatsächlich verarbeiten zu können, muss aber der ScrumMaster beschaffen. Die Bereitstellung im Sinne von Finanzierung ist jedoch eher an das Management geknüpft. Auch muss nicht der ScrumMaster alleine rausfinden, welche Arbeitsmittel benötigt werden – das Team kann und muss sich genauso beteiligen. 6) Teammitglieder sollten nach Manz/Sims durch den Teamleiter ermutigt werden, auch anfallende Tätigkeiten zu übernehmen, die nicht (genau) ihrem eigentlichen Profil entsprechen. Bingo! Der ScrumMaster sorgt dafür, dass das Wissen zumindest im Team verteilt wird und/oder dass Teammitglieder sich Wissen aneignen, das sie zum Übernehmen fremder Aufgaben befähigt. “Anfallende Tätigkeiten” passt daher so gut, weil zur Umsetzung der Prio 1 Story mit dem höchsten Business Value bestimmte Skills gerade nicht benötigt werden. Genau dann sollte der ScrumMaster dafür sorgen, dass die Teammitglieder nicht darauf warten, bis wieder eine “passende Aufgabe” kommt oder niedriger priorisierte Aufgaben vorziehen. Sie sollten neben ihrer Spezialisierung Skills aufbauen, die sie auch bei anderen Schwerpunkten nutzen können. 7) Dass die Teamleiter ihre Anstrengungen abstimmen und koordinieren, sollte zur Ergänzung und somit mehr Effektivität führen. Das ScrumMaster-Team sollte übergreifende Impediments oder Muster der Teams identifizieren und ihnen damit helfen, effektiver zu werden. Obwohl diese übergreifende Aufgabe nicht gänzlich auf die ScrumMaster verlagert werden sollte, sollte das ScrumMaster-Team die Anstrengungen bündeln und z.B. Vorschläge zur Optimierung machen. Außerdem sollten die ScrumMaster nicht getrennt voneinander bzw. in Unwissenheit die gleichen Anstrengungen unternehmen.

So weit, so gut. Es findet sich also eine Menge Theorie in Scrum und eine Menge Führungstheorie selbstorganisierter Teams in der Rolle des ScrumMasters wieder. Dem gerecht zu werden, ist in der Hektik und vor allem bei der Umstellung auf Scrum nicht immer einfach. Nichtsdestotrotz sollte es immer wieder die Richtschnur sein, an der die Tätigkeiten der ScrumMaster ausgerichtet und priorisiert werden. Viel von den Bereichen ist durch den Scrum Prozess berücksichtigt – wir müssen also “nur” darauf achten, dass es richtig gelebt wird und vor allem darauf vertrauen, dass es funktioniert. Der Weg zu Selbstorganisation auf einem hohen Level ist jedoch nur durch das Commitment aller, mit Konzentration, Zeit und Inspect and Adapt möglich.

Related posts:

1. 15 Minuten sind 15 Minuten
2. Der ScrumMaster: Status, Position, Rolle
3. Scrum – eine Revolution (4)

Du bist von Scrum überzeugt und versuchst, dein Umfeld dafür zu begeistern. Du willst deine Kollegen dazu bewegen, es mal für drei Sprints auszuprobieren – mit allem, was dazugehört: Backlog, Taskboard, Product Owner, ScrumMaster, DevTeam.

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

Scrum bedeutet Veränderung und Veränderungen, ob kleine oder große, sind schmerzhaft – zumindest solange, bis die Veränderung vollzogen ist. Ein routiniertes Verhalten abzulegen und gegen ein anderes einzutauschen, wird von uns Menschen überwiegend als Risiko wahrgenommen und löst Gefühle wie Unsicherheit oder sogar Angst aus. David Rock, Autor von “Brain at work”, drückt das mit den treffenden Worten aus: “Uncertainty is poison to thought. We want to know what will happen next.“

Die Folge dieser Unvorhersehbarkeit des Unbekannten ist, dass wir in eine Position der Ablehnung gehen und jeden Sinn für Neutralität und Offenheit verlieren. Alles, was darauf hindeutet, dass etwas anders werden wird, wird nicht nur einfach in Frage gestellt, sondern zumeist wie eine Bedrohung erlebt. Und damit nicht genug. Wir finden in anderen Menschen oftmals Gleichgesinnte und ziehen uns gegenseitig runter, weil wir im Pessimismus eine Gemeinsamkeit gefunden haben: „Das kann nicht funktionieren!“ Die Argumente, die für eine Veränderung sprechen, reichen einfach nicht aus. Sie sind immer zu schwach, weil wir gemeinsam (relatedness) an dem festhalten, was uns in dieser Unsicherheit gewiss (certainty) zu sein scheint: eine Veränderung kann nur schief gehen und bringt nichts Gutes. Der Fokus geht ausschließlich in Richtung des Problems: Was wird alles nicht funktionieren? Was könnte alles schief laufen? Was würden wir verlieren, wenn wir uns für die Veränderung entscheiden?

In meinen Trainings erlebe ich bei einer simplen Übung eine ähnliche Denkart. Ich schreibe vier einfache Rechenaufgaben auf:

18 + 4 = 22     //     23 – 8 = 15     //     6 x 4 = 20     //     25 : 5 = 5

Was fällt euch auf? Stimmt. Eine (die dritte) Rechnung ist falsch (6 x 4 = 24). Das Gleiche stellen die Trainingsteilnehmer auch fest. Immer. Es war noch nie anders. Kein einziges Mal habe ich erlebt, dass die erste Reaktion lautete: Drei Rechnungen sind richtig, nur eine ist falsch. Stattdessen wird das Haar in der Suppe gesucht und gefunden. Das Schlechte oder in diesem Fall Falsche fällt uns schneller ins Auge, nicht zuletzt, weil ein Misserfolg immer emotional stärker erlebt wird, als ein Erfolg. Daraus entsteht eine Art Schutzhaltung, die ihre Kraft darauf ausrichtet, sich durch eine pessimistische Grundhaltung gegen ein Negativerlebnis zu wappnen: klappt etwas gut, dann bin ich überrascht und erleichtert, klappt etwas nicht, dann fühle ich mich bestätigt, weil ich es ja schon vorher gesagt hatte. Die Folge sind negative Denkmuster, die unsere Denkkanäle einseitig prägen und wie eine Abwärtsspirale wirken. Sogenannte negative Denkmuster gehen von einer Unveränderbarkeit der aktuellen (Problem-)Situation aus und versperren damit jeden Weg auf eine andere, neue, optimistische, lösungsorientierte Perspektive. Die Dominanz von Verallgemeinerungen (z.B. Scrum passt nicht zur Branche X), blockierenden Annahmen (z.B. So kann das doch nichts werden) oder selbsterfüllenden Prophezeihungen (z.B. Ich konnte noch nie gut mit anderen kommunizieren) überdecken auf diese Weise jede Möglichkeit des anders Denken.

Eine der drei integralen Verantwortungen des ScrumMasters ist, dass dieser sein Team schützen soll. Natürlich ist hiermit in erster Linie gemeint, dass keine Anforderungen außerhalb eines Commitments zur Verpflichtung werden, damit das Team störungsfrei arbeiten kann. Ein ScrumMaster schützt aber ebenso gegen die Verbreitung negativer Denkmuster. Als Change Agent gehört es zu seiner Aufgabe, das agile Mindset zu schärfen, indem der Fokus auf die Lösung (weg vom Problem) gerichtet wird. Steve de Shazer, Begründer der lösungsfokussierten Kurzzeittherapie, wirbt für eine solche Form der  Umdeutung (Reframing), indem er sagt: Wenn etwas nicht funktioniert, dann probier etwas anderes.

Worte, die unser Denken verändern können

Ihr fragt euch nun sicher, was ihr jetzt tun könnt? Natürlich ist das Ablegen von Handlungsroutinen nichts, was per Knopfdruck geschieht. Es ist aber möglich. Wenn mir Menschen von Problemsituationen erzählen, dann konzentrieren sich die Schilderungen auf zwei Aspekte: Wie schlimm und aussichtslos die Situation ist und was alles nicht funktioniert bzw. was derjenige alles nicht tut. Würdigt und lobt, was ihr bereits unternommen habt, sorgt ab diesem Moment für einen Kurswechsel und fragt:

Was machst du stattdessen?

Es ist nur ein Wort. Ich kann euch aber empfehlen, euer Gegenüber zu beobachten, wenn ihr eure Frage mit der Lösungsformel „stattdessen“ stellt. Es passiert nichts. Stimmt. Euer Gegenüber schweigt. Und er oder sie schweigt, weil er oder sie nachdenkt. Und das ist ein gutes Zeichen. Ihr habt ins Schwarze getroffen. Ich empfehle euch, nicht locker zu lassen. Immer wieder wird euer Gegenüber versuchen, gedanklich und mit seinen Argumenten dorthin zu „flüchten“, wo er oder sie sich auskennt – ins Problem. Das ist leicht zu erkennen an einem Aber, Negationen oder dem Konjunktiv. Bleibt am Ball und lasst den Problemwälzer auf die Suche nach positiven Ausnahmen (= ein klitzekleines Anzeichen, wann/wo das Problem weniger war) gehen oder konfrontiert ihn mit Fragen, mit denen er nicht rechnet:

• Was an dem Problem möchtest du unbedingt behalten?
• Was war das Beste an deinem Problem?
• Woran merkst du, dass das Problem nicht mehr da ist und was ist dann anders?

Übrigens: Solltet ihr feststellen, dass euer Gegenüber plötzlich mitmacht und Gefallen daran findet, an seinem Lösungsbild zu arbeiten, dann verweise ich gern ein zweites Mal auf de Shazer: „Wenn etwas gut funktioniert, dann mach mehr davon!“

Related posts:

1. Scrum – eine Revolution (4)
2. Definition of Done: Die harte Schule
3. Value Based | Nutzen Schaffen (3)