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

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

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.

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).

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)

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)

Vielleicht fragt ihr euch, wie ich auf dieses Thema gekommen bin. Dieser Beitrag ist entstanden, weil mir vor ein paar Tagen eine solche kleine Freude am eigenen Leib zuteil wurde. Nach zweiwöchiger Abwesenheit kam ich an den Arbeitsplatz, der mir bei einem meiner Kunden zur Verfügung gestellt wird. Auf meinem Schreibtisch fand ich diese Nachricht vor:

Das Ergebnis war echt erlebte Freude. Kann ein Arbeitstag wertschätzender starten? Ich bin für diesen einen Moment, meinen Moment, nicht mehr aus dem Strahlen gekommen:

Take a smile

Eine schöne und bemerkenswerte Variante zu dem Willkommen-Post-it, die ich immer wieder gerne nutze, um für eine kleine Freude, ein Schmunzeln, zu sorgen, ist das Take a smile-Post it.

Mögliche „Einsatzgebiete“? Es kann den bzw. die Empfänger beispielsweise über einen ganzen Sprint begleiten (jeden Tag ein Lächeln). Es kann aber auch für ein Lächeln pro Teammitglied stehen. Take a smile ist genauso einsetzbar für ein einzelnes Teammitglied, dem es vielleicht gerade nicht so gut geht. Vielleicht verteilt ihr es an eure Besucher im Daily oder im Review. Wenn ihr aber die Wirkung erstmal einfach so ausprobieren wollt, dann hängt ein Post-it an die Eingangstür, die zum Teamraum führt. Ich garantiere euch, dass ihr Abnehmer finden werdet und denen ihr unter Garantie mindestens ein Schmunzeln entlocken werdet.

Der Briefwechsel

Wer als ScrumMaster einen erinnerungswürdigen Moment von Freude, gemischt mit einem gerührten Innehalten erzeugen möchte, sollte sein Team zu einem „Briefwechsel“ bewegen. Der Zeitaufwand ist im Verhältnis zur Wirkung verschwindend gering und ein Zusammenrücken im Team ist nahezu garantiert. Der Briefwechsel kann als Separator in einer Retrospektive zum Einsatz kommen, aber auch als möglicher Wochenabschluss in ein erholsames Wochenende einleiten. Was habt ihr zu tun? Sorgt für eine lockere, aber störungsfreie Atmosphäre im Teamraum (z.B. lockerer Stuhlkreis, wenn das räumlich möglich ist; jedes Teammitglied kann aber auch an seinem Arbeitsplatz sitzen, sofern das Team in einem Raum ist und nicht verteilt). Jeder bekommt einen Stift. einen Briefbogen und einen Briefumschlag. Ich empfehle euch, echtes Briefpapier zu nehmen. Das sieht einfach schöner aus und macht den Briefwechsel authentischer. Eure Teammitglieder sollen ihren Namen gut lesbar in eine Ecke des vor ihnen liegenden Briefpapiers schreiben. Bei der Überschrift für den Briefwechsel seid ihr nun frei. Wählt ein Motto in Form eines Satzanfanges, der dann jeweils vervollständigt werden soll: z.B. Es ist schön, mit dir in einem Team arbeiten zu dürfen, weil … oder Ich möchte dir heute ein Kompliment machen, weil… Hat jedes Teammitglied seinen Namen und die Überschrift auf seinen Brief geschrieben, wird der Briefbogen im Uhrzeigersinn an den Nächsten weitergegeben. Dieser widmet nun dem Briefbesitzer (Name steht auf dem Briefbogen) seine persönlichen Worte durch die Vervollständigung des Satzanfangs (siehe oben). Und weiter geht es. Der Brief wird an das nächste Teammitglied übergeben. Dieser Ablauf findet solange seine Fortsetzung, bis der Briefbesitzer beim nächsten Briefwechsel überreicht werden würde. Ist der Satz formuliert, wird der Brief gefaltet und kommt in den Briefumschlag. Schreibt den Namen des Empfängers nun auf den Umschlag und übergebt den Brief an seinen Empfänger.

Der Briefwechsel – auf einen Blick

Zutaten: 1 Briefbogen, 1 Briefumschlag, 1 Stift (alles je Teammitglied)

Zeitlicher Aufwand: Teammitglieder mal zwei in Minuten

Sinn und Zweck: Wir schenken uns Freude

Räumliche Bedingungen: störungsfreie Teamatmosphäre

Anlass: Separator in einer Retrospektive, Wochenabschluss, für gute Laune zwischendurch

ScrumMaster, nehmt meinen Blog zum Anlass, verteilt kleine Freuden mit Scrum und schaut, was ihr bei den Menschen auslöst und bewegt. Denkt daran, dass die Wahrheit uns allen ins Gesicht geschrieben steht. Wer sich übrigens wirklich sicher sein möchte, ob er bei seinem Gegenüber „echt erlebte Freude“ (1) produziert hat, möge sich nicht allein auf hochgezogene Mundwinkel konzentrieren. Die Basisemotion der Freude, wenn sie echt erlebt und nicht nur sozial erwünscht geäußert wird, tritt zweifelsfrei nur in Kombination mit der Muskelkontraktion des Wangenhebers (musculus orbicularis occuli) auf. Wangenheber? Nein, ihr habt euch nicht verlesen und nein, ich meinte nicht Wagenheber. Den braucht es hoffentlich nicht für diesen Muskeleinsatz. Die Kontraktion des Wangenhebers kann leicht ausfindig gemacht werden. An den Außenseiten der Augen werden die sogenannten „Krähenfüßchen“ sichtbar, die natürlich auf meinem Freude-Foto kaum zu erkennen sind :-).

Und jetzt los. Verschenkt Freude. Ich bin mir sicher, dass ihr dankbare Abnehmer finden werdet.

Literatur

(1) P. Ekman (2012). Emotionen lesen.

Related posts:

1. What’s so funny about bugs?
2. Scrum4All
3. Warum wir eigentlich alle Freelancer sind

Synchronisation

Der Sprint dient der Synchronisation für die Priorisierung und Lieferung. Hierbei besteht die gleiche Kadenz für Priorisierung und Lieferung. Die gleiche Kadenz heißt, es wird zu Anfang des Sprints festgelegt, was in die freien Slots kommt, die im nächsten Sprint frei sind und es wird festgelegt, wann das Scrum-Team die nächsten Ergebnisse liefert. Sobald man in Scrum das Sprinten startet, legt man den Rahmen, die Kadenz automatisch fest. Man legt Synchronisationspunkte fest und die damit verbundenen Transaktionskosten.

Die Transaktionskosten der Koordination minimiert man bei einer regelmäßigen Priorisierung. Es ist klar, wann wer zusammenkommen muss und jeder kennt den Rhythmus.

Transaktionskosten für die Lieferung hängen von mehreren Faktoren ab: Wie aufwendig sind Koordination und Integration, wie hoch ist der Grad der Automatisierung und wie schnell kann, wie schnell muss man Geschäftswert für den Endnutzer bereitstellen.

Die Automatisierung hat heutzutage noch viel mit Professionalisierung der Software-Entwicklung zu tun. Unternehmen, bei denen bisher wenig automatisiert ist, haben meist hohe Transaktionskosten. Solche Kosten sind oftmals auf manuelle Qualitätssicherung und hohe Koordinationskosten für Integration und Releases zurückzuführen. Meist führen gerade solche langen Lieferzeiten jedoch zu einem Teufelskreis: Da die Transaktionskosten hoch sind, meiden Unternehmen kurze Zyklen. Lange Zyklen beinhalten immer ein höheres Risiko an Fehlern. Kombiniert man nun lange Zyklen mit der Angst vor Fehlern in der Praxis, stellen sich nochmals höhere Transaktionskosten durch ausgeprägte Testphasen ein. Da man zum einen mehr testet, zum anderen fehlerhafte Funktionen länger in der Praxis hat, verlängert sich der Zeitraum des fehlenden Geschäftswerts. Derweil sitzt der Kunde noch mit Praxisfehlern auf der langen Bank. Wartet der Kunde auf der Bank, dann führt das häufig zu Mitnahmeeffekten durch Wettbewerber.

WIP-Limit

“Limit work in progress” – so richtig wichtig, leider oft so richtig wenig verstanden. Überlast in Unternehmen führt nicht nur dazu, dass alles lange dauert und keiner mehr Lust hat. Es führt vor allem dazu, dass fast nichts mehr geht. Menschen betankt man nicht wie Maschinen, die dann bis auf eine gewisse Grundwartung mit einer geringen Fehlerquote arbeiten. Wann geht fast nichts mehr? Wenn alles aufeinander wartet und gemeinsame Synchronisationspunkte zu selten oder unkoordiniert stattfinden. Dann ergeben sich Abhängigkeiten, die nur noch so ungefähr aus der Vogelperspektive erfasst werden können. Wenn die Vogelperspektive hier helfen würde, dann wäre das schön, meiner Erfahrung nach zählen allerdings vor allem die Details.

Im Sprint limitiert das Entwicklungsteam die eigene Auslastung. Das Entwicklungsteam zieht sich die eigene Auslastung, manchmal auch die eigene Überlastung. Dadurch entsteht für den Zeitraum des Sprints ein limitiertes System, ähnlich einem Währungssystem, es entsteht eine Knappheit. Mit dieser Knappheit kann man arbeiten. Indem ich ausweise, dass im nächsten Zeitraum nicht mehr geht, zeige ich deutlich auf, was geliefert wird. Meine Lieferung rückt in den Fokus.

Des Weiteren kann bei Blockaden nicht auf etwas weniger Wichtiges ausgewichen werden, sondern es muss genau an dem gearbeitet werden, was wichtig ist. Trifft man auf Blockaden, so sind sie zu lösen. Ist das System nicht limitiert, so wäre die natürliche Reaktion, sich mit etwas anderem zu beschäftigten. Das führt in vielen Organisationen dazu, dass Blockaden selten oder nie gelöst werden und man sich mit ihnen abfindet. In einem knappen System geht das nicht. Es muss etwas getan werden, der Fokus auf den Wert bleibt erhalten und man reduziert deutlich die Parallelität und damit den Auslöser für das heutzutage vielmals gescheiterte Multiprojektmanagement.

Wichtig ist, die so erzeugte Knappheit im System aufrechtzuerhalten: Wird das System ständig gestört z. B. durch Incidents, dann werden schnell die Vorteile eines solchen Systems obsolet (stabile Transaktionskosten für Priorisierung, Lieferung, konsequentes Auflösen von Hindernissen, etc.).

Störungsfreies Arbeiten

Wer kennt es nicht: Manager hetzen stundenweise von Termin zu Termin. Stimmen sich ab, tauschen sich aus und tragen all die neuen Erkenntnisse überall dorthin, wo sie aktuell noch gar nicht sein müssten – ins Entwicklungsteam. Auf der anderen Seite sitzen im Entwicklungsteam Menschen, die Zeit benötigen, sich in ihre Arbeit zu vertiefen.

Ich beschreibe Software-Entwicklung meist so: Du sitzt da vor deinem PC und über dir schwebt ein stetig wachsendes Konstrukt von Beziehungen, Abläufen und Strukturen. Es ist wie ein kleines Wolkenschloss, dass mit jeder Zeile Code, die du liest, wächst. Immer mehr Gedankenblasen steigen vor dir auf bis dann… ja dann klingelt das Telefon, es kommt jemand herein, spricht dich an und du siehst weit am Horizont die letzte Gedankenblase zerplatzen und dein Wolkenschloss ist vom Winde verweht. Um ein solches Konstrukt zu erzeugen benötigt es Zeit, es ist aufwendig und anstrengend.

Wenn wir die Zeitpläne eines Managers mit dem eines Entwicklungsteams vergleichen, dann sehen wir kleine Zeiteinheiten über den Tag verteilt beim Manager und große Zeiteinheiten beim Entwickler. Jetzt würde manch einer sagen, dass es jede Menge Entwickler gibt, die auch einen zerstückelten Zeitplan mit sich herumtragen. Hier stelle ich die Frage: “Wie viel wird von demjenigen dann noch entwickelt und wie viel managt er schon?”

Paul Graham nannte 2009 die unterschiedlichen Zeitpläne “Maker’s schedule, manager’s schedule“. Er bringt dort zum Ausdruck, dass diese beiden Zeitpläne konträr zueinander stehen und so wenig wie möglich aufeinandertreffen sollten, damit die Produktivität der Macher (Entwickler) möglichst wenig beeinträchtigt wird. Im Umkehrschluss schlägt er vor, dass beide Zeitpläne voneinander entkoppelt werden sollten. Spannenderweise findet dieses Prinzip sich im Agilen im Allgemeinen und bei Scrum im Speziellen wieder. In Scrum entkoppeln die Sprints die beiden unterschiedlichen Zeitpläne voneinander. Im Sprint sorgt der ScrumMaster für störungsfreies Arbeiten und gibt seinem Entwicklungsteam den Freiraum und die Zeit, möglichst autonom und produktiv zu arbeiten. Zum anderen entkoppeln die Rollen Product Owner und ScrumMaster die Zeitpläne. Das geschieht dadurch, dass beide für das Scrum-Team zwischen den Zeitplänen vermitteln, indem sie selbst als Puffer und Filter agieren. Ein weiterer Vorteil ist, dass sich das Entwicklungsteam gegenüber Störungen ausgehend von den beiden Rollen auch durchsetzen kann, da weder ScrumMaster noch Product Owner disziplinarische Vorgesetzte des Teams sind.

Zieleinlauf

Der Sprint isoliert die hektische Welt des Managements vom Zeitplan eines Entwicklers. Entwickler können sich so fokussieren und gedankenintensive Arbeit leichter abschließen. Der Sprint fördert stabile Bedingungen, die zu niedrigeren und stabilen Transaktionskosten führen und ermöglicht Professionalisierung aufgrund von kleinen Lieferungen. Als knappes System führt der Sprint dazu, dass Blockaden gelöst werden müssen und zukünftig nicht auch anderen Arbeiten im Weg stehen. “Wenn Sie mich fragen: Ich mag ihn, den Sprint!”

Related posts:

1. Warum wir eigentlich alle Freelancer sind
2. Scrum – und wir machen doch was wir wollen
3. Dr. Scrum – antwortet

Jeder kennt die Situation, dass er etwas verändern möchte, dass er ziemlich genau weiß, wie es nicht sein sollte, eine vage Vorstellung davon hat, wo er hin möchte, wie er handeln müsste. Aber an der Umsetzung hapert es immer wieder. Man fühlt sich blockiert, ja sogar hilflos, bei manchen Themen über eine lange Zeit. Diese Situation kannte auch der große Cäsar, als er mit seinen Truppen am Rubikon, einem Fluss nördlich von Florenz stand und überlegte, ob er den römischen Senat in Rom angreifen und ihm damit den Krieg erklären sollte oder nicht. Sicher machte es sich Caesar nicht leicht mit seiner Entscheidung. Letztlich aber kam er ins Handeln, machte sich nach Rom auf und überschritt mit den berühmten Worten “alea iacta est”, “Der Würfel ist gefallen”, mit seinen Legionen den Rubikon in Richtung Süden. Dieser Ausspruch steht heute noch für Entscheidungen, die ein ganz bewusstes und konsequentes Handeln nach sich ziehen.

Das Rubikonmodell nach Grawe (Grawe, 1998, S. 71) gilt heute als wichtiges und funktionales Selbstmanagementmodell, das die Entstehung einer inneren Struktur von den Bedürfnissen bis hin zum konkreten Handeln aufzeigt und helfen kann, schwierige Entscheidungssituationen handlungsreif zu machen.

Bedürfnis: Unbewusste, vorbewusste Impulse

Motiv: Erfassen, bewusst werden, erkennen, wünschen, wägen

Intention: Bewusstes Wollen, Handlungsziel entwickeln, gezielte Entscheidung treffen

Präaktionale Vorbereitung: Planen, Ressourcen und Möglichkeiten eruieren

Handeln: Umsetzen, üben, sichern durch Wiederholen bis die Handlung stabilisiert ist

In der ersten Phase spürt man als Führungskraft oft ein meist noch unklares Bedürfnis im Hinblick auf eine Veränderung, zum Beispiel mit einem „schwierigen“ Mitarbeiter zu reden oder für die Meetings mehr Disziplin im Team zu fordern. Oft ist das Bedürfnis in dieser Phase noch nicht ganz klar oder auch noch nicht richtig bewusst.

Erst mit der Zeit bildet sich in der zweiten Phase daraus ein konkretes Motiv, z.B. ich will mehr Führung zeigen, eine nicht akzeptable Situation in Ordnung bringen. Oft weiß man aber in dieser Phase noch nicht, was genau man tun möchte. Außerdem gibt es immer mehrere Motive, die sich manchmal gegenseitig auszuschließen scheinen. Da stehen z.B. Motive wie Harmonie, die Mitarbeiter nicht zu demotivieren, Konflikten aus dem Weg zu gehen, im inneren Spannungsfeld. In dieser zweiten Phase sind die Menschen sehr mit dem Abwägen aller Motive beschäftigt. Mit Kopf und Bauch versucht man eine Entscheidung herbeizuführen. Manchmal dauert das Abwägen lange, aber irgendwann sind die Prioritäten dann klarer und es entsteht idealerweise ein Gefühl und eine Bewusstheit der Entschlossenheit: Ich tue jetzt etwas für mich und meine Führungsrolle und auch für die Verbesserung von Disziplin im Team und damit für eine bessere Teamleistung.

Dies ist der eigentliche Schritt über den Rubikon. Nach diesem Schritt liegt in der Phase drei das, was der Mensch gern tun möchte, in einem neuen Reifestadium vor, als Intention. Es wird nun ein konkretes Handlungsziel definiert. Jetzt wird nicht mehr abgewogen, sondern es wird nach einer Lösung und nach Maßnahmen gesucht: Wie, wann und wo kann ich mit dem Mitarbeiter Klartext reden? Wie bringe ich das Disziplinthema in mein Team ein?

In der vierten Phase geht es dann um „präaktionale Vorbereitung“ und die Entwicklung von konkreten Ausführungsmöglichkeiten: Ich werde einen Gesprächstermin mit dem Mitarbeiter in meinem Büro vorgeben und von Anfang an die Gesprächsregeln festlegen. Ich werde deutlich sagen, dass ich hier nicht als Kollege, sondern als Führungskraft rede. Ich achte bewusst darauf, dass ich die Steuerung des Gesprächs in meinen Händen behalte. Ich atme vor dem Gespräch tief durch und mache mir bewusst, dass es in Ordnung ist, das Gespräch so zu führen. Ich werde das Thema Disziplin ganz oben auf die Prioritätenliste des nächsten Meetings setzen. Ich werde die Zeit nehmen, die es braucht, damit alle sich äußern können und verstehen, worum es mir geht. Ich behalte die Moderation in meiner Hand und achte auf Regeln und Zeitmanagement. Ich werde konkrete Commitments am Flip Chart visualisieren.

Nun geht es an die gut vorbereitete, bewusste und gezielte Umsetzung, sprich konkrete Handlung, des Selbstmanagementvorhabens im Umgang mit dem Mitarbeiter oder dem Team. Je grundlegender ein Thema für das persönliche Selbstmanagement ist, z.B. eben mit schwierigen Personen oder Führungsautoritäten ist (siehe Beispiele), um so öfter ergeben sich Möglichkeiten, die gezeigten Handlungen auf andere Situationen zu übertragen und den Rubikon immer leichter zu überschreiten. Übung macht auch hier den Meister.

Der Rubikonprozess als Selbstmanagementtool unterstützt den bewussten Umgang mit sich selbst und den Situationen und Herausforderungen die oft scheinbar schwer zu bewältigen sind. Es ist immer auch gerade dann hilfreich, wenn es um Themen wie Unsicherheit, Souveränität, Auftreten, Durchsetzungsvermögen, Setzen von Prioritäten, Grenzen setzen, Verändern persönlicher hinderlicher Muster wie „Ich muss immer perfekt sein“ etc. geht. Im Sinne von Selbstcoaching ist die Reflektion des Rubikonmodells eine Chance, die persönliche Weiterentwicklung anzugehen. Caesar hats ja auch genutzt.

Grawe K. (1998) Psychologische Psychotherapie, Hogrefe: Göttingen

Related posts:

1. Einzelkämpfer ScrumMaster? Herausforderungen als ScrumMaster Team gemeinsam meistern / Teil 2
2. Lernen ist Arbeitszeit – vom Erlernen der Scrum Praxis
3. Die bor!sgloger Methode

Katja Lüdtke, seit einem Jahr ScrumMaster beim E-Postbrief, versteht diesen Anspruch auf ihre ganz eigene Art und Weise und sagt: „Yin und Yang. Weich und hart. Stark und schwach. Nichts ist absolut. Die Eigenschaften definieren sich immer im Vergleich. Also, es ist wichtig, nach draußen zu gehen und sich auch andere Welten anzuschauen, um relativieren zu können, um neue Erkenntnisse zu gewinnen und daraus zu lernen.“  Und Katja nahm sich selbst beim Wort und ging nach „draußen“, zur ESG nach Wolfsburg. Im Rahmen einer Weiterbildung von bor!sgloger consulting, die von ihrem Chef, Dr. Oliver Zeiler (Mitglied des Bereichsvorstands BRIEF GB 32), möglich gemacht wurde, implementierte sie dort in einem gerade neu aufgestellten Team Scrum. Drei Sprints (sechs Wochen) lang durfte sie dort als ScrumMaster und ScrumCoach ihren Blick über den Tellerrand nicht nur schweifen lassen, sondern auf besondere Weise schärfen.

Über ihre Erlebnisse, die vielen Erkenntnisse und kleinen Geschichten möchte ich heute mit Katja reden.

D.: Hallo Katja, du bist zurück von deiner kleinen Reise. Wie ist es dir ergangen?

K.: Es war besonders. Es stimmt, was Mike Cohn sagt: Scrum ist anders. Ich würde dies aber gerne ergänzen wollen: Scrum ist woanders anders.

D.: Wie meinst du das?

K: Es war wie Sprinten auf einem anderen Planeten. Ich durfte Scrum und mich als ScrumMaster und Coach in einer völlig neuen Umgebung, auf einem fremden Planeten erleben. Von drei meiner wichtigsten Beobachtungen und Erkenntnisse möchte ich gern berichten.

D.: Dann leg mal los. Du machst mich neugierig.

Beobachtung 1: Kleine Teams sind tatsächlich dynamischer als größere

Die „Fremdlinge“ haben sich für die agile Entwicklung eines neuen Produkts in kleinen Teams von vier bis fünf Personen organisiert. Das war neu für mich, da ich als ScrumMaster bislang nur die Arbeit mit Teams von acht bis zehn Personen kannte und diese Größe für mich selbstverständlich war. Nun beobachtete ich gespannt die Auswirkungen einer noch kleineren Organisationseinheit und stellte fest, dass die Teammitglieder häufiger zu Wort kommen als in einer größeren und das persönliche Kennenlernen begünstigt ist. Klingt erst mal logisch, hat aber in letzter Konsequenz große Auswirkungen. Die Phasen der Teamentwicklung sind im Vergleich mit einem Team, das aus mehr als acht Personen besteht, kürzer. Im Team werden die Ideen schneller besprochen, die Aufgaben rotieren zügiger, bei Problemen finden sich fast automatisch Partner, um diese  lösen zu können. Als Teammitglied ist man stärker gefordert und kann sich weder verstecken, noch geht man in der Anonymität unter, weil man vielleicht zu leise ist. Es ist in jedem Moment offensichtlich, wie die zugesicherte Eigenverantwortung gelebt wird – nicht zuletzt, weil man irgendwie muss, aber dadurch auch will. Das bedeutet, dass die persönliche Motivation, das Ziel zu erreichen, höher ist, da gute Ergebnisse viel schneller sichtbar sind und zur Anerkennung führen.

Weitere Vorteile eines kleineren Teams ergeben sich aus der Arbeit des ScrumMasters: Die Timeboxes für Meetings sind, ohne das Team zu überfordern, leichter einhaltbar – weniger Köpfe, weniger Kontroversen. Für die Verbesserung der Persönlichkeits- und Team-Entwicklung bleibt somit auch mehr Raum, was sich natürlich direkt in der Arbeitseffektivität widerspiegelt – die Velocity steigt, die Qualität bleibt hoch. Folge: Der ScrumMaster kann sich mehr und nachhaltiger um die Lösung von Impediments kümmern.

Beobachtung 2: Ein ScrumMaster schützt das Team, aber er hat keine Schützlinge

Kennt ihr das Bild der Glucke mit ihren kleinen Küken, die ihr nahezu blind folgen, wenn sie gemeinsam zum Spazieren gehen? Die Glucke unternimmt alles, damit ihre Zöglinge vor allem und jedem geschützt werden. Manchmal verhalten sich ScrumMaster genau so, wenn sie seit vielen Sprints mit dem gleichen Entwicklungsteam zusammen sind. Natürlich ist es absolut menschlich, dass sich mit der Zeit Freundschaften zwischen dem ScrumMaster und den Teammitgliedern bilden, Menschen wachsen sich ans Herz oder gewöhnen sich einfach aneinander. Und dann? Neigen wir dann nicht dazu, Schwächen nicht mehr so konsequent und bedingungslos anzusprechen, das Gegenüber zu schonen und Missstände sogar zu ignorieren? Interessant: Auf dem fremden „Planeten“ zeigten die „Außerirdischen“ sehr ähnliche Symptome. Sie haben allerdings ziemlich schnell eine Lösung gefunden: eine ScrumMaster-Rotation!

Es wurde erkannt und angewendet, dass jeder ScrumMaster seinen eigenen Stil und seine Stärken hat, die auf unterschiedliche Weise eine Performance-Steigerung im Team bewirken können. Erst gute und gemeinsame Emotionen lassen ein Gefühl für Gemeinschaft und Vertraulichkeit entstehen. Das ist anzustreben, um konzentriert arbeiten zu können. Aber ein regelmäßiger Teamwechsel ist eine Chance für den ScrumMaster und für das Entwicklungsteam: Der eine vermeidet die Fallen der Routine und das Team profitiert von den Fähigkeiten anderer ScrumMaster.

Beobachtung 3: Eine wirkungsvollen Vision unterstützt die Veränderung

Mut zu signifikanten Veränderungen in der Organisation haben, ist ein agiler Wert (Courage). Zu wenig davon kann teuer für ein Unternehmen sein, das auf dem Weg zur Agilisierung ist. Änderungen sind bekanntlich unbequem und schmerzhaft, können Angst und Widerstand erzeugen. Grund genug, um diese unter Vorwand nicht umzusetzen oder zu verschieben.

Auf dem „Planeten“, den ich besuchte, haben dessen “Bewohner“ im Rahmen der Entwicklung neuer Produkte einen Weg gefunden, mit den Veränderungsängsten umzugehen: Sie stellen sich ein sehr klares Bild einer gemeinsamen gewünschten Zukunft vor. Das tun sie so lange, bis dieses Bild so vielversprechend, klar und schön ist, dass es eine große Anziehungskraft entwickelt, für alle! Sie beginnen die Zukunft mit dem neuen Produkt zu lieben! Danach fällt es allen leichter, die Kraft und die Entschlossenheit für die Bewältigung der Schwierigkeiten auf dem Weg dahin zu finden.

Ich bin jetzt von der Reise zurück, fest entschlossen das zu nutzen, einzusetzen und anderen zurückzugeben, was ich für mich erkannt, herausgefunden, erlebt habe.

Hier mein Aufruf an die vielen ScrumMaster, die sicher ständig ihre neugierigen Blicke als Change Agent schweifen lassen:

• Formt kleine Teams
• Wendet die richtige Mischung persönlicher Bindung und Team-Förderung an
• Sorgt für Inspiration im Team durch den Product Owner

Ich bin seit meiner Rückkehr von diesem gar nicht mehr so fremden Planeten überzeugt, dass wenn ihr schon einen der drei Punkte verfolgt, viele Erfolgsstories auch auf euren Heimatplaneten entstehen.

Related posts:

1. 10 Things about ScrumMasters
2. Führung in Scrum | Manager | Teil 4
3. Der ScrumMaster – Wirklich ein Weichei?

Seit mehr als einem Jahr setzt der E-Postbrief Scrum ein, verteilt auf die zwei Standorte Bonn und Berlin. Ich spreche heute mit Jens. Jens hat nach einem Jahr als ScrumMaster die Rolle des CompanyScrumMasters am Standort Bonn übernommen. Er steht uns gerne für die Schilderungen seiner Erfahrungen mit Scrum zur Verfügung, bevor es wieder heißt: Sagen Sie jetzt nichts.

Hallo Jens, wie ist es dazu gekommen, dass du die Rolle des Company ScrumMasters ausführst?

Als die Rolle durch den Weggang eines Kollegen frei wurde, war mir zunächst nur klar, dass jemand aus dem Kreis der ScrumMaster diese Rolle nachbesetzen sollte. Dann wurde ich mir allmählich der großartigen Möglichkeiten bewusst, die die Rolle bietet, und wollte selbst Company ScrumMaster werden.

Was sind deine Verantwortungen als Company ScrumMaster?

Ich fühle mich für ein funktionierendes ScrumMaster-Team und eine sich stetig verbessernde agile Produktentwicklung verantwortlich.

Warum braucht es überhaupt einen Company ScrumMaster?

So wie ein Team von einem ScrumMaster profitiert, der unterstützt und beschützt, moderiert und hilft, die Produktivität zu verbessern, so kann eine Scrum-Organisation auch von einem Company ScrumMaster profitieren.

Nehmen dich die Menschen anders wahr, seitdem du Company ScrumMaster bist? Und wenn ja, wie und woran machst du das fest?

Ja, ich habe den Eindruck anders wahrgenommen zu werden. Scherzhaft sieht man das zum Beispiel an der einen oder andere Andeutung eines militärischen Grußes auf unseren Fluren. Ich wurde auch in Reviews schon mit Adelstiteln und Vergleichbarem begrüßt. Auf der ernsten Seite stelle ich aber auch fest, dass mich die Kollegen in der neuen Rolle mehr in Anspruch nehmen und bereits angefangen haben, mich beispielsweise als Schnittstelle zu begreifen.

Wie nimmst du dich selber seither wahr? Hat sich in deinem Denken und Handeln etwas verändert?

Meine Wahrnehmung und mein Gesamtblick haben sich geweitet. Ich spüre eine größere Verantwortung für die Entwicklung unserer Organisation. Es geht mir immer noch darum, dass das Team Performance abliefert und sich stetig verbessert. Aber “das Team” ist jetzt das ScrumMaster-Team und somit geht es mir nun auch um die gesamte agile Produktentwicklung.

Was ist grundsätzlich anders als vorher als ScrumMaster? Musst du jetzt z. B. länger/kürzer arbeiten?

Ich arbeite länger, weil es soooo viel zu tun gibt. Bisher habe ich aber auch noch ein Scrum-Team betreut – was ein schlechter Kompromiss zu Lasten des Scrum-Teams war. Fortan wird sich ein anderer Kollege um das Team kümmern, sodass ich mich vollends der neuen Rolle und somit dem ScrumMaster-Team sowie der Verbesserung der agilen Organisation widmen kann. Zusammen mit der reifenden Klarheit über meine Handlungsfelder und Prioritäten will ich auf diesem Wege wieder zu verträglichen Arbeitszeiten zurückkehren.

Was ist dein derzeit größtes Impediment?

Ein ScrumMaster-Team, das auf zwei Standorte verteilt und noch kein echtes Team ist. Ich habe den Eindruck, dass wir uns in der Kommunikation untereinander schwer tun und unsere Diversität noch nicht nutzbringend einsetzen.

Was hat dir besser gefallen: ScrumMaster sein oder Company ScrumMaster sein?

Am ScrumMaster-Dasein gefielen mir die Nähe zum Team und die kurzen Feedbackzyklen, die schnell zeigten, ob etwas funktioniert oder nicht. Als Company ScrumMaster hingegen haben sich nun Team, Aufgaben und damit Verantwortungen signifikant verändert. Der Einflussbereich ist größer geworden und der Feedbackzyklus wurde dadurch auch (zumindest gefühlt) länger. Aber die neuen Möglichkeiten, die ich nun habe und die Dinge, die ich dazulernen kann, begeistern mich auf jeden Fall noch mehr.

Was kannst du durch deine neue Rolle jetzt besser beeinflussen, um die Organisation besser, produktiver, agiler zu machen?

Ich kann die Meinung und Ansichten des ScrumMaster-Teams in Gremien vertreten, die nicht gewohnt oder in der Lage sind, mit einem Team von Change Agents zusammenzuarbeiten. Kollegen, die eher mit hierarchischen Strukturen vertraut sind, kann ich als “Chef” der ScrumMaster besser erreichen, auch wenn ich gar kein Chef bin. Durch diese Schnittstellenfunktion kann ich auch meine ScrumMaster-Kollegen entlasten.

Wo siehst du bei dir die größten Potentiale auf dem Weg noch besser zu werden?

Ich strebe danach, dass es mir noch besser gelingt, einen Status Quo zu hinterfragen und eine Gruppe so zu Verbesserungen anzuregen. Dabei wünsche ich mir auch eine bessere Fähigkeit, durch Moderation Gruppen schnell zu guten Ergebnissen zu führen.

Als Company ScrumMaster bist du fester Bestandteil des ScrumMaster-Teams. Du führst es. Wie machst du das? Wie führst du? Bist du so etwas wie ein „Primus inter pares“ (Erster unter Gleichen)?

Da wir ein Team von Kollegen mit zum Teil sehr unterschiedlichen Hintergründen und Erfahrung sind, fokussiere ich mich darauf, die Kommunikation untereinander zu fördern und gemeinsame Sichten auf Dinge herzustellen. Dabei versuche ich meine Ansichten so oft wie möglich als Gleicher unter Gleichen einzubringen.

Quis custodiet custodes – wer bewacht die Wächter? Wachst du über die ScrumMaster? Und wer bewacht dich?

Ich hoffe, dass ich von allen Kollegen um mich herum offenes und ehrliches Feedback zu meiner Arbeit erhalte, das mich dann in die Lage versetzt, mein Handeln auch mit Hilfe externer Eindrücke zu reflektieren, zu verändern und hoffentlich dann auch im Sinne der Organisation zu verbessern.

Angenommen, du hättest einen Wunsch frei für dein Tun als Company ScrumMaster? Was wünschst du dir am allermeisten?

Ich wünsche mir mehr Geschlossenheit und Einigkeit im ScrumMaster-Team, sodass man uns auch als die wirkungsvolle Einheit wahrnimmt, die wir sein wollen. Damit meine ich nicht die Einigkeit mit totalitären Zügen, die man von einer kommunistischen Partei erwartet, sondern regen und offenen Austausch untereinander und die Bildung einer Teammeinung zu Themen, die uns umtreiben.

1. Company ScrumMaster sein: Ist das stressig?

2. Deine Antwort auf: “Früher war alles besser!”

3. Scrum finde ich …

4. Der E-Postbrief ist …

5. Wenn du einen Company ScrumMaster malen müsstest, wie würde er aussehen?

6. Dein Anti-Stress-Rezept?

Related posts:

1. Der ScrumMaster: Status, Position, Rolle
2. Einzelkämpfer ScrumMaster? Herausforderungen als ScrumMaster-Team gemeinsam meistern / Teil 1 / Dieter Rösner
3. “How long does it take to become excellent?” — “A minute!”