Hut auf reicht nicht!

…nun bist du also ScrumMaster. In einem neuen Team, in einem für dich neuen Unternehmen, in einer neuen Branche. Quasi in der Fremde. Du betrittst das Glatteis. Es fühlt sich wackelig an. Und dennoch ist da der Reiz des Neuen, des Unbekannten. Eine unsichtbare Kraft motiviert dich wieder mal aufs Neue, einen guten Job zu machen. Aber, nur weil du nun den Hut des ScrumMasters, des latenten Teamleads auf dem Kopf trägst, bist du noch nicht von allen unumstritten und akzeptiert in deiner Rolle. Das klingt hart, ist jedoch die Realität, so wie ich sie in vielen Fällen erlebt habe, wenn ich die Führung neuer Teams übernahm. Dennoch kein Grund zum Pessimismus, solange man sich vor Augen führt, dass es nun zu liefern gilt. Sprich, Taten spürbar und transparent für das Team folgen zu lassen. Was also tun? Ich möchte einige Beispiele beleuchten, die einem auch als Branchenneuling helfen, von einem gestandenen Team akzeptiert zu werden.

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

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

Taten sagen mehr als 1000 Worte!

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

Schaffe Transparenz!

Ganz egal, ob als ScrumMaster, Manager, Führungskraft … Man steht im Fokus. Gewollt oder nicht. Die Berechtigung den „Hut“ zu tragen, der uns zum ScrumMaster macht, müssen wir uns immer wieder durch Taten verdienen. Hier hilft uns die Transparenz. Häufig ist die Arbeit eines ScrumMasters nicht so sehr sichtbar. Wir hacken nicht den halben Tag in unseren Computer. Wir sind häufig nicht zu sehen, da wir in irgendwelchen Meetings stecken und abends können wir keine Verkaufszahlen präsentieren. Machen wir doch also einfach transparent, was wir den Tag über so tun. Machen wir es sichtbar. Wir brechen uns keinen Zacken aus der Krone. Und, ich finde es geht die Teammitglieder sehr wohl etwas an, was ich für sie und unser Team den lieben langen Tag so tue. Das funktioniert sehr gut über ein persönliches Taskboard, das in Papierform (Flipchart) an unserem Platz hängt, sowie ein ebenso sichtbares Impediment Backlog. Unsere Aufgabe ist es schließlich, Impediments aufzuspüren und aus dem Weg zu räumen. Das darf gerne sichtbar sein. Erledigte Impediments oder Tasks wandern über unser Board. Ein Gradmesser für unsere Leistung. Für uns und unsere Teamkollegen. Letztlich möchte ich mich noch dafür aussprechen ebenso transparent zu machen, wo ich mich befinde. Auch das kann man am persönlichen Taskboard ersichtlich machen. „Im Meeting/Raum xyz oder auch „in der Mittagspause“ sind mögliche Varianten, dem Team zu zeigen, dass ich es respektiere.
Die Beispiele, die ich heute beschrieben habe, sind sehr leicht umzusetzen, haben jedoch große Wirkung. Denn häufig scheitert es einfach im Kleinen und in der Häufung dieser Kleinigkeiten. Wer kennt es nicht?! „Mein Chef sagt mir nie Guten Morgen“ oder „…nie werde ich gelobt“. Diese und andere Aussagen haben wir alle schon gehört oder vielleicht sogar gemacht. Gehen wir also mit positivem Beispiel voran und sorgen für eine gute Stimmung. Lieferung, Qualität, Produktivität und Profitabilität sind zwar die klaren Erwartungen und Ziele, die ein Scrum-Team verfolgt und erfolgreich macht. Das, was uns letztlich jedoch glücklich macht neben unseren Erfolgen, ist eines: Stimmung.
Abschließend möchte ich eine Frage zum Nachdenken stellen:
„Ob groß oder klein. Begeisterung ist nichts anderes als übertroffene Erwartung. Was tue ich dafür?“

Der Sin Obelisk oder die Tücken der Teamdynamik

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.

Am Ende eines langen Tages

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:

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

Zählen ist doch ganz einfach, oder?

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!

ScrumMaster sind Meister der Effekte und Illusionen (Teil 2) – der Halo-Effekt

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

Führung selbstorganisierter Teams: alte Theorie vs. Scrum (Teil 2)

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.

Das Haar in der Suppe oder was ScrumMaster gegen negative Denkmuster tun können

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:

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

ScrumMaster schenken kleine Freuden mit Scrum

Es sind die kleinen Freuden des Lebens, die unser Tun manchmal besonders machen. Sie passieren spontan, überraschend oder auch unvorbereitet. Genau darin steckt ihre tiefgreifende Kraft. Man rechnet nicht mit ihnen. Und plötzlich sind sie da. Sie lösen einen vollwertigen Cocktail an Gefühlen in uns aus. Ein wahres Fest für jeden Neurobiologen. Ein kleines Feuerwerk aus Endorphinen.
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.

Der Sprint – ein Zeitplan für Macher

Wer beim Sprinten ins Stolpern kommt, wird meist von etwas abgelenkt. Das gilt zumindest in den Sprints, die im Büro stattfinden. Den Sprint in Scrum gibt es aus vielen Gründen: Er dient der Synchronisation, stellt eine Grenze gegen Überlast dar (WIP-Limit) und sorgt für störungsfreies Arbeiten.

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

Cäsars Entscheidung oder wie aus Wünschen erfolgreiche Handlungen werden

Nur wer sich selbst gut managen kann, kann auch andere gut managen. Folgt man diesem Satz, ist es nachvollziehbar, dass das Thema Selbstmanagement Hochkonjunktur hat, vor allem im Kontext von Führung. Ein spannendes Element im Selbstmanagement ist die Frage, wie man von seinen Bedürfnissen und Wünschen ins Handeln kommt.
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