Mit den Scrum-Werten durch die Woche – ein Selbstversuch

Als Berater bekommt man so einige Unternehmen zu sehen. Und eines haben diese fast alle gemeinsam: plakative Unternehmenswerte, Leitbilder und Richtlinien als Grundlage für ein erfolgreiches Miteinander – am liebsten auf bunten Postern gut sichtbar in jedem Büro angebracht.
Gerade der Generation Y wird immer wieder nachgesagt, dass sie sich ihren zukünftigen Arbeitgeber nicht anhand von Prestige oder Status aussuche, sondern vor allem auf die vom Arbeitgeber vermittelten Werte schaue.

Auch Scrum fußt auf fünf Werten, die neben den 12 Prinzipien das Fundament für die agile Zusammenarbeit in Teams bilden: Offenheit, Fokus, Mut, Respekt und Commitment. Diese fünf Werte scheinen leicht verständlich, doch was bedeuten sie im Alltag und wie können sie gelebt werden? Um diese Frage zu beantworten, habe ich mir für jeden Tag der Arbeitswoche einen Wert ausgesucht und diesen bewusst gelebt. Natürlich kann man diese fünf Werte in der Praxis nicht isoliert voneinander betrachten, daher soll die Aufteilung auf verschiedene Wochentage hier eher der Veranschaulichung dienen.

Montag – Offenheit

Eine neue Woche startet bei uns im Projekt und ich als ScrumMaster habe ein neues Team übernommen. Neben der klassischen Übergabe bekomme ich von meinem Vorgänger auch ein paar inoffizielle Informationen mit auf den Weg, zum Beispiel, wer im Team gerne mal Diskussionen torpediert. Offenheit bedeutet im agilen Kontext unter anderem, sich auf neue Themen, Arbeitsweisen und neues Gedankengut einzulassen. An diesem Montag heißt Offenheit also für mich, meinem neuen Team ohne vorgeformte Meinung zu begegnen.

Als Menschen denken wir gerne in Schubladen, weil diese es uns erleichtern, Dinge und Situationen in das persönliche Erfahrungsnetz einzuordnen. Im Alltag kann das durchaus effizient sein. Wir können nicht jede Einzelheit in allen Facetten beleuchten, sondern müssen auf vorhandene Denkmuster zurückgreifen. Beim agilen Arbeiten ist es jedoch zum Teil wichtig, mit diesen Mustern bewusst zu brechen, um das tatsächliche Potenzial der Mitarbeiterinnen und Mitarbeiter zu identifizieren. Ohne Offenheit würde ich dazu tendieren, die Teammitglieder in Schubladen zu stecken.

Hier nehme ich gerne eins der Modelle aus dem Schulz von Thun Institut für Kommunikation zur Hand, um Klarheit über (Kommunikations-) Strukturen innerhalb des Teams zu gewinnen und diesem mit Verständnis anstatt Schubladendenken entgegenzutreten. Auch bei mir selbst wende ich z. B. das Kommunikationsquadrat gerne an, insbesondere in stressigen Situationen. Es hilft mir, kurz innezuhalten und mich zu erinnern, auf „welchem Ohr“ ich gerade auf Empfang geschaltet habe.

Dienstag – Fokus

Diese Woche steht der Sprintwechsel an und damit zunächst zwei wichtige Meetings, um den vorherigen Sprint abzuschließen: das Review und die Retrospektive. Die Struktur von Scrum und die regelmäßigen Meetings unterstützen das Team nicht nur darin, einen gemeinsamen (Arbeits-)Rhythmus zu finden, sondern helfen auch dabei, das Augenmerk auf bestimmte Themen zu lenken. Da meine Hauptaufgabe als ScrumMaster darin besteht, das Team zu befähigen, so schnell wie möglich zu liefern, ist die Gestaltung der Meetings ein wichtiger Teil auf diesem Weg. Wenn ich als Moderator mein Team durch die Meetings (wie z. B. ein Sprint Planning) führe, heißt das für mich: genau hinschauen, das Ziel im Auge behalten und aufpassen, dass sich das Team nicht in kleinen Diskussionen verliert.

Mittwoch – Mut

Im agilen Kontext bedeutet Mut, sich den Veränderungen und Herausforderungen zu stellen, die das Arbeitsumfeld mit sich bringt, und dann auch die Konsequenzen unserer Entscheidungen zu tragen. Wie eingangs erwähnt, habe ich diese Woche ein neues Team übernommen. Mein Vorgänger hat das Team ein gutes Jahr lang geführt und das Team hat sich an seinen Stil gewöhnt. Nun liegt es an mir, Wege zu finden, mich mit dem Team einzuschwingen. Das bedeutet, in den Meetings verschiedene Formate auszuprobieren, um zu sehen, welches für das Team das aktuell ertragreichste ist. Dabei kann es auch durchaus passieren, dass das Team ein bestimmtes Format nicht annimmt – mit dem Mut, verschiedene Herangehensweisen auszuprobieren und damit auch Rückschläge in Kauf zu nehmen, kann ich lernen, was für mein Team am besten passt.

Donnerstag – Respekt

Am Donnerstag steht im Team eine Diskussion zur Weiterentwicklung unserer Ziele und der Aufgaben auf dem Weg dorthin auf der Agenda. Durch verschiedene Kommunikationsstile und Persönlichkeiten, die aufeinandertreffen, können hierbei hitzige Diskussionen entstehen. Da fällt es manchmal schwer, durchzuatmen und den jeweils unterschiedlichen Standpunkt des anderen zu akzeptieren. Was mir dabei hilft: mir und meinem Team immer wieder klarzumachen, dass unterschiedliche Standpunkte gewinnbringend zu neuen Einsichten führen können.

Freitag – Commitment

Das Wort Commitment hat verschiedene Übersetzungen im Deutschen, weshalb oft die englische Variante gewählt wird, um seiner Bedeutung gerecht zu werden: Selbstverpflichtung und freiwillige Bindung. Im Klartext bedeutet Commitment, einen Beitrag für das eigene Team und das Unternehmen leisten zu wollen und diesem Willen auch Taten folgen zu lassen.

Am Freitag habe ich mir im Rahmen eines Meetings eine Aufgabe gezogen, deren erfolgreiche Erfüllung nun in meiner Verantwortung liegt. Ich habe mich entsprechend meiner aktuellen Kapazitäten freiwillig für diese Aufgabe entschieden und bin damit auch eine Verpflichtung eingegangen, die ich nach bestem Gewissen einhalte. In meinem Team habe ich beobachten können, dass gelebtes Commitment dazu führt, dass Aufgaben gewissenhafter erledigt werden: Wenn sich die Teammitglieder freiwillig für eine Aufgabe entschieden haben (anstatt diese zugeteilt zu bekommen), waren ihre Motivation und das Verantwortungsgefühl für die qualitative und pünktliche Lieferung größer. Zusätzlich entsteht eine positive Gruppendynamik: Wenn transparent ist, wer welche Aufgaben hat, und diese Ergebnisse regelmäßig im Plenum gezeigt werden, möchte man selbst nicht ohne Aufgabe und Ergebnis dastehen.

Ist der Selbstversuch geglückt?

Eine Woche mit einem agilen Wert pro Tag liegt hinter mir. Und in dieser Woche ist es mir leichtgefallen, die Werte in meinem Alltag zu leben. Dennoch sind wir Menschen – es kann mitunter eine große Herausforderung sein, sich im Alltag jederzeit aller Werte bewusst zu sein und vor allem auch danach zu handeln. Indem ich mir als Teil eines agil arbeitenden Teams regelmäßig vor Augen führe, dass ich durch das Leben dieser Werte wesentlich erfolgreicher bin, erscheinen diese fünf großen Worte auf einmal viel nahbarer.

Als ScrumMaster oder Agile Coach arbeite ich nicht nur mit diesen Werten, sondern repräsentiere sie. Darum muss ich immer wieder prüfen, ob ich selbst das lebe, was ich in meinen Teams verankern möchte.

Die Rolle des ScrumMasters und seine Fähigkeiten – ein Eisbergmodell

Erst kürzlich hatte ich eine Unterhaltung, in der mir mein Gesprächspartner stolz erzählte: „Ich habe jetzt auch endlich eine Ausbildung als ScrumMaster absolviert. Probleme in Teams zu beheben, machte mir schließlich schon immer Spaß. Und für die Moderation von Meetings habe ich eine Weiterbildung gemacht. Das kann ich auch neben meinen eigentlichen Aufgaben erledigen.“

Und so werden Heerscharen von ScrumMaster ausgebildet, die in ihre Teams gehen, um Meetings zu moderieren und Impediments zu lösen. Denn das ist schließlich unsere Aufgabe, oder nicht?

Die Spitze des Eisbergs

Ja, natürlich fallen diese Aufgaben in den Verantwortungsbereich eines ScrumMasters. Aber für mich als passionierte ScrumMasterin ist das nur die Spitze des Eisbergs. Der eigentliche Sinn dieser Rolle geht viel tiefer.

Was tut also ein guter ScrumMaster? Er führt eine Methode ein und stellt die Produktivität des Teams sicher, doch auch das greift meiner Meinung nach noch zu kurz. Denn die Methode Scrum ist ein Impuls für etwas Größeres, für den Kulturwandel im gesamten Unternehmen. Aus der Methode heraus ergeben sich neue Werte und Prinzipien, eine neue Einstellung der MitarbeiterInnen und dadurch das Potential, die Unternehmenskultur nachhaltig zu verändern.

Der ScrumMaster ist also auch ein Change Agent. Er muss sein Team und die Organisation durch den Wandel führen. Diese Führungsrolle lebt er aber nicht als disziplinarischer Vorgesetzter mit entsprechender Weisungsbefugnis aus, sondern bewegt die Teams und das Management durch seine laterale Führung. Er verkörpert eine neue Kultur und das für viele Kollegen und Kolleginnen ganz neue, agile Mindset. Er geht mit gutem Vorbild voran, lebt die Scrum-Werte und -Prinzipien jeden Tag, sodass die Teammitglieder diese nach und nach verinnerlichen.

Der ScrumMaster muss ins kalte Wasser tauchen

Viele Menschen entscheiden sich für eine Ausbildung als ScrumMaster, weil sie mit einzelnen Teilaufgaben dieser Rolle liebäugeln. Sie stürzen sich voller Motivation auf ausgewählte Aspekte und vergessen dabei, dass 85 % der eigentlichen Themenfelder gut verborgen unter der Oberfläche zu suchen sind. Vielleicht ist manchen bewusst, dass sie auf ihrem Weg als ScrumMaster noch weitaus anspruchsvollere Aufgaben vor sich haben, als den zeitlichen Rahmen in Meetings einzuhalten. Meiner Erfahrung nach rechnen sie jedoch oft nicht damit, dass sie ins eiskalte Wasser eintauchen müssen, sobald sie auf eines der etwas tiefer gehenden Themen treffen. ScrumMaster brauchen also die Bereitschaft, immer und immer wieder unbekannte Dinge auszuprobieren, Fehler zu machen, Neues dazuzulernen und an sich selbst zu wachsen.

Betrachtet man insbesondere die Aufgaben als Change Agent, der den Wandel vorantreibt, dann sind Ausdauer und Durchhaltevermögen ebenso wie der Mut gefragt, den Status quo in den Teams immer und immer wieder herauszufordern. Darüber hinaus braucht es Offenheit, um die agilen Werte und Prinzipien in der Organisation und den Teams zu verankern und dadurch den Kulturwandel zu forcieren – ebenso wie Offenheit gegenüber der Geschwindigkeit der Teams. Deshalb ist ein hohes Maß an Anpassungsfähigkeit und Selbstreflexion notwendig. Denn man muss immer wieder hinterfragen, ob man die vorgesehenen Veränderungen einleiten konnte und – falls nicht – was man in der Umsetzung anpassen kann, um den Change anzustoßen.

Welche Eigenschaften solltest du als ScrumMaster mitbringen?

Ein guter ScrumMaster ist jederzeit bereit, über sich selbst hinauszuwachsen. Ich habe im Folgenden ein paar Fähigkeiten gesammelt, auf die es meiner Erfahrung nach im agilen Arbeitsalltag ankommt:

Es ist natürlich noch kein Meister vom Himmel gefallen und ich weiß, dass es viele wirklich begnadete Eis-Schwimmer gibt. Meine Anregung ist jedoch: Bitte seid ehrlich mit euch selbst und hinterfragt kritisch, ob ihr die richtigen Fähigkeiten für die Rolle des ScrumMasters habt und die Offenheit mitbringt, Neues zu lernen und auch in Aufgaben einzutauchen, die euch vielleicht nicht so sehr liegen. Denn ihr werdet den Wandel im Unternehmen kontinuierlich vorantreiben und habt damit eine zentrale Rolle, zu der ihr euch bewusst committen solltet.

Selbstorganisation der Teams fördern: Ask the team!

Die Wahrscheinlichkeit ist sehr hoch, dass Sie während Ihrer Ausbildung zur agilen Expertin, zum agilen Experten oder beim Durchwälzen der Fachliteratur auf den Ausspruch “Ask the team!” gestoßen sind. Was genau steckt dahinter?

Die Grundannahme hinter diesem Prinzip ist, dass die Teammitglieder alle Fähigkeiten besitzen, um selbst zu einer Lösung zu kommen. Oder man formuliert es noch stärker: Als crossfunktionales Expertenteam können nur sie zur besten Lösung für ihre fachspezifische Fragestellung kommen. Wenn sich die Teammitglieder ihres Wissens und ihrer eigenen Handlungsfähigkeit bewusst sind, steht der Selbstorganisation nichts mehr im Weg. Aber wie schafft man es, das Team in diese Richtung weiterzuentwickeln?

Ein Beispiel, das viele aus der Praxis kennen

Stellen Sie sich vor, Sie haben mit Ihren Teams als agile Begleiterin oder agiler Begleiter ein Arbeitsmodell erstellt, das iteratives Arbeiten inkl. Reflexionsschleifen ermöglicht. Wohlwollend stellen Sie Terminserien ein, moderieren die Meetings wie bspw. die Retro oder Dailys und beinahe automatisch verbringen Sie sehr viel Zeit mit einer Hand am Flipchart und frontal vor dem Team. Sie erklären vieles, schaffen Transparenz über Themen und Zusammenhänge etc.

Nun frieren Sie diese Szene ein, zoomen aus der Situation heraus und betrachten diese mit einiger Entfernung. Was können Sie aus der Metaperspektive beobachten?

Vielleicht erkennen Sie Folgendes:

  1. Ein Team, das eine Kultur des „Command & Control“ gewohnt ist und Selbstverantwortung nur aus dem Duden kennt.
  2. Eine ehemalige Teamleitung / Teilprojektleitung, welche die alte Rolle noch nicht ganz loslassen konnte und wie gewohnt Aufgaben zuweist und Ansagen macht.
  3. Einen Agile Coach, der die Selbstorganisation des Teams stärken möchte und das dem Team sogar offenlegt, der aber gleichzeitig stark steuert und die Entwicklung der Autonomie im Team unbewusst zurückhält – durch das frontale Stehen und seinen hohen Redeanteil. Alles in der guten Absicht, das Meeting bestmöglich zu gestalten und das Team zu unterstützen.
  4. Ein Team, das alles abnickt und Anweisungen einfach befolgt – den Blick stets brav auf die moderierende Person oder die ehemalige Teamleitung gerichtet.

Wege zur Selbstorganisation

Wie können Sie die Selbstorganisation in Ihrer Rolle als agile Begleiterin oder agiler Begleiter fördern? Oder anders formuliert: Wie können Sie dem Team eine gewichtige Stimme zuteilwerden lassen? Folgende Maßnahmen haben sich in der Praxis als hilfreich erwiesen:

  1. Stellen Sie sich nicht direkt an das Flipchart! Meetings sind die Bühne der Teams, in denen Sie eine Nebenrolle spielen: Sie achten auf die Akustik, die Beleuchtung, das Bühnenbild und vieles mehr, damit die Hauptdarsteller ungehindert auf der Bühne performen können. Mit einer Ausnahme: Sie machen die Einführung und den Abschluss eines Meetings. Experimentieren Sie ruhig ein wenig, welche Position im Raum sich für Sie und das Team gut anfühlt.
  2. Achten Sie darauf, dass Ihr Redeanteil hauptsächlich aus Fragen besteht. Fragen Sie interessiert nach. Fragen Sie, wen das Team noch involvieren könnte, ob es noch etwas zu ergänzen gibt. Und fragen Sie, ob das Team noch weitere Lösungsansätze kennt. Was passiert durch das Fragen? Es regt die Synapsen der Teammitglieder an, die Systemlandschaft, in der sie sich bewegen, gedanklich nach Handlungsmöglichkeiten abzufahren. Was vermeiden Sie dadurch? Die Teammitglieder bekommen keine Lösungen auf dem Servierteller präsentiert und sind aktive Gestalter statt nur Befehlsempfänger.
  3. Setzen Sie sich anfangs ein Ziel, wie viele Fragen Sie an einem Tag stellen wollen, um das Fragenstellen zu trainieren. Es mag Ihnen eingangs etwas roboterartig vorkommen. Bald werden Sie das als Selbstverständlichkeit betrachten.
  4. Und ein zusätzlicher Tipp: Widerstehen Sie dem Drang, einfach drauflos zu sprechen, wenn Sie das Gefühl haben, das Team stockt. Nehmen Sie sich ruhig gelegentlich Zeit, das Team einfach zu beobachten. Diese Beobachterrolle ermöglicht Ihnen, bewusster wahrzunehmen, was im Meeting geschieht. Achten Sie darauf, wer eine führende Rolle einnimmt, wer sich zurückhält und welche Dynamiken entstehen. Erkennen Sie immer wiederkehrende Muster? Wandert der Blick Hilfe suchend zu Ihnen? Spielen Sie den Ball zurück ans Team, auch wenn es manchmal zwei bis drei Anläufe braucht. Die Teams kommen selbst auf Lösungen.

Was Sie dadurch bewirken

Wenn Sie die Teams fleißig mit Fragen gefüttert und die Teammitglieder erlebt haben, dass dadurch wertvolle Informationen offengelegt werden, beginnen diese selbst, mehr Fragen zu stellen. Sie werden sehen, dass sie sich zu Beginn an Ihren häufig gestellten Fragen orientieren. Parallel dazu beginnen die Teammitglieder automatisch, mehr Informationen zu liefern, weil sie

  1. lernen, dass sie wertvoll sind und
  2. erkennen, dass eine Frage ohnehin gestellt wird, wenn sie diese nicht schon von sich aus im Vorhinein beantworten.

Fazit

Besonders zu Beginn, wenn die Rolle als ScrumMaster oder Agile Coach aufgenommen wird, ist es eine große Herausforderung, die Teams nicht zu stark durch die Meetings zu steuern und zu viel Präsenz in altbekannten Mustern zu zeigen. Erinnern Sie sich an die Weisheit, die man aus vielen Managementseminaren kennt: „Wer fragt, der führt.“ Oder übertragen auf den agilen Kontext: Ask the team!

Warum die Rollenfindung Teamsache sein sollte

„Wir wollen agil werden“ – so oder so ähnlich lautet die Maßgabe in vielen Unternehmen. Bei der Einführung von Scrum braucht es dazu unterschiedliche Rollen wie den ScrumMaster und Product Owner. Den Führungskräften ist oft schon im Vorfeld klar, wer diese Rollen im späteren Verlauf ausführen soll. Dabei vergisst man aber häufig, auch das Team zu fragen, wen es in dieser Rolle sieht. Aufgrund hierarchischer Machtverhältnisse und Weisungsbefugnissen werden neue Rollen einfach zugewiesen, ohne auf die Anforderungen und Befähigung der Erwählten einzugehen. Auch wie die Bedingungen innerhalb des Teams aufgestellt sind, spielt tendenziell eine eher untergeordnete Rolle.

Aber wie kann man das besser machen? Meiner Meinung nach ist zunächst die Unterscheidung von Macht und Status essenziell für die Etablierung und Akzeptanz der neu geschaffenen Rollen. Denn Macht bekommt man manchmal geschenkt, Status muss man sich erarbeiten.

Status vs. Macht

Sozialer Status zeichnet sich durch Respekt und Wertschätzung aus, die einer Person von anderen entgegengebracht werden. Er entsteht somit durch die Beurteilung von Außenstehenden und bezieht sich auf den Wert, den sich eine Person in einem sozialen System erarbeitet hat. In weiterer Folge heißt das, dass man sich Status nicht selbst verleihen kann, sondern das soziale Umfeld diesen zuschreibt.

Genau darin unterscheidet sich der Status auch im Wesentlichen von der Macht. Sie kennzeichnet sich vor allem durch die Fähigkeit, eigene Interessen durchzusetzen, auch wenn das Umfeld anderer Meinung ist. Die Art und Weise, wie Macht schließlich ausgeübt wird, kann dabei völlig unterschiedlich sein – sei es durch den alleinigen Zugang zu Wissen oder durch eine höhere soziale Stellung.

Aus diesen unterschiedlichen Konzepten von Status und Macht lassen sich allgemein drei mögliche Szenarien ableiten:

  1. Macht ohne Status
    Fehlt der Status, so kann Macht alleine immer noch ausreichen, um seine eigenen Vorstellungen auch gegen den Willen oder die Interessen anderer durchzusetzen. Allerdings macht man sich dabei oft keine Freunde, da man zwar Autorität besitzt, die anderen aber nur kontrolliert.
  2. Status ohne Macht
    Auch ohne Macht kann man als Führungsperson fungieren, wenn der Status, also der Respekt und das Ansehen im sozialen Umfeld stimmen.
  3. Macht gepaart mit Status
    Wer sowohl über Macht als auch über Status verfügt, kann beide nutzen, um seinen Einfluss geltend zu machen. Entweder kann man sich auf seine Macht berufen und seine Ansichten durchsetzen oder seinen Status einbringen, um andere zu überzeugen.

Was bedeutet das beispielhaft für die ScrumMaster-Rolle?

Übertragen auf die Besetzung eines ScrumMasters können sich folgende Szenarien ergeben:

  1. Klassisch besetzt der Teamleiter die Rolle des ScrumMasters im neu etablierten Scrum-Team. Dadurch besitzt die Rolle zwar die notwendige Rückendeckung, um Entscheidungen im Sinne des Teams zu treffen (technische Voraussetzungen, Anschaffungen, Entwicklungsmaßnahmen für Teammitglieder etc.). Jedoch fehlt die notwendige Akzeptanz der Rolle im Team, wodurch die Entscheidungen nicht immer auch vom Team mitgetragen werden.
  2. Der ScrumMaster wird als Teil des Teams akzeptiert und ist in der Lage zu wirken, kann aber in der Beseitigung von Impediments durch organisationale Hürden ausgebremst werden.
  3. Der ScrumMaster wurde gemeinsam im Team gewählt, akzeptiert und genießt die Rückendeckung seines hierarchisch Vorgesetzten bei der Lösung von Impediments.

Um in dieser Rolle im agilen Umfeld tatsächlich wirksam werden zu können, braucht es sowohl Macht wie auch Status. Szenario 3 stellt für mich daher die optimale Ausprägung dar.

Das Team weiß, was es braucht

Zur Förderung dieser Entscheidung aus dem Team heraus hat sich folgende Herangehensweise als praktikabel erwiesen:

  1. Klare Darstellung der Rollenanforderung und Erwartung
  2. Selbstwahrnehmung der beteiligten Personen zur dargelegten Rolle
  3. Fremdwahrnehmung der einzelnen Gruppenmitglieder: Wen kann ich mir in der dargestellten Rolle vorstellen?
  4. Reflexion in der Gruppe zur Teamaufstellung
  5. Gemeinsames Commitment

Festzuhalten bleibt: An vielen Stellen bedarf es keiner klassischen Rollenbesetzung, da die Teammitglieder durchaus in der Lage sind, eine objektive Aussage darüber zu treffen, wer die beste Rollenpassung aufweist. Und wem ich das Vertrauen schenke, die Rolle auszufüllen. In der Praxis sieht das oft aber leider noch ganz anders aus. Beim Entscheidungsverhalten wie auch bei der Rollenfindung hält man noch stark am klassischen Verständnis fest und schreibt die Verantwortung für diese Bereiche einer hierarchisch vorgesetzten Person zu. Meiner Meinung nach sollte sich das Verständnis wandeln, um mit der sich verändernden Arbeitswelt Schritt halten zu können.

Pfläging¹ zeigte auf, dass man viel schneller auf die Marktbedürfnisse reagieren kann, wenn die Entscheidungsmacht aus dem Zentrum in die Peripherie, also an die marktnächste Instanz gegeben wird, wo die entsprechenden Informationen vorhanden sind. Äquivalent dazu sollte es sich mit der Rollenfindung verhalten – nur eben in die andere Richtung. Die Information bzw. das Wissen liegen hierbei im Kern, also im Team. Dementsprechend sinnvoller ist es, dass auch das Team die Rollenfindung innehat.

 


Literaturhinweis:

¹Nils Pfläging: Komplexithoden: Clevere Wege zur (Wieder)Belebung von Unternehmen und Arbeit in Komplexität. Redline Verlag 2015.

Mysterium Motivation – so motiviere ich mein Scrum-Team

Kürzlich stellte einer unserer Trainingsteilnehmer am Ende des Trainings folgende Frage: „Wie schaffe ich es als ScrumMaster, alle Leute in meinem Team für Scrum zu begeistern oder überhaupt zu motivieren, Teil dieses Teams zu sein?“ Mit dieser Frage ist er nicht alleine. In fast jedem Team begegnen wir der Problematik, dass nicht alle von Anfang an mitziehen und die agile Transformation unterstützen. Was tun?

Das Motivations-Tagebuch

Als ScrumMaster sollten Sie auch Widerstände als Chancen betrachten, weil darin Optimierungspotential sichtbar wird. Ich empfehle ScrumMastern, ein Motivations-Tagebuch zu führen, in dem konkrete, motivierende und kurzfristig umsetzbare Maßnahmen aus den Beobachtungen des Tages abgeleitet werden. Welche Einträge ins Tagebuch kommen und wie diese aussehen können, schauen wir uns in diesem Blog-Artikel gemeinsam an. Begleiten Sie unseren fiktiven ScrumMaster durch seinen Sprint. Er macht sich zu jeder Situation Notizen und hält konkrete To-dos zur Motivation und Weiterentwicklung seines Teams fest.

Montag, 09:00 Uhr – Verantwortung übertragen

Der ScrumMaster steht mit seinem neuen Team vor dem Taskboard. Er ist seit zwei Wochen im neuen Projekt unterwegs, es gibt viel zu tun. Jeder nimmt sich reihum Tasks und schreibt sein Kürzel auf die einzelnen Aufgaben. Es sind immer die gleichen Personen, die sich die gleichen Tasks ziehen. Und es gibt ein Teammitglied, das scheinbar an derselben Aufgabe arbeitet wie in der Woche zuvor. Das Worst-Case-Szenario: Am Ende werden die User Storys bis zum Review am Freitag nicht fertig. Es gibt kein Feedback vom User und der Product Owner sieht die abgeschlossenen User Storys im Review zum ersten Mal. Eine Konsequenz, wenn nicht geliefert wird? Fehlanzeige.

Hier braucht es dringend einen aktiven ScrumMaster. Das Team muss lernen, Verantwortung für die Qualität der Lieferungen zu übernehmen, und braucht echtes Feedback von einem Endanwender sowie ausreichend Support vom Product Owner.

Der ScrumMaster erstellt eine Liste mit konkreten To-dos für den Tag und versucht, diese direkt umzusetzen: 

Dienstag, 10:00 Uhr – Wertschätzung fördern

Eine sehr knifflige User Story ist endlich fertig geworden. Zwei Teammitglieder bekommen kräftigen Applaus vom gesamten Team. Der ScrumMaster klatscht am Anfang noch am lautesten. Zur Abnahme der Story bringt der Product Owner zwei seiner selbstgebackenen Muffins vorbei. Ein Teammitglied steht halb abgewandt zum Taskboard und betrachtet diese Zeremonie skeptisch: „Mit so einer billigen Nummer kriegt ihr mich nicht“, denkt er sich. Es waren seine Lieblingsmuffins.

Die Scrum-Master-Notiz am Dienstag: 

Mittwoch, 14:00 Uhr – Fokus setzen

Der ScrumMaster hat drei neue Teammitglieder. Einer der drei Kollegen scheint sich mit Scrum auszukennen. Er hält sich sehr bedeckt. Der ScrumMaster ist nun nicht mehr der einzige Verfechter der Methode und sieht die Chance, etwas zu verändern. Er bittet den Kollegen, mit ihm gemeinsam einen Workshop zum Thema „User Storys schreiben“ durchzuführen. Im gemeinsamen Austausch berichtet der Mitarbeiter, dass ihm einige Dinge aufgefallen sind, die er gerne ändern würde – z. B. könnte man das Taskboard anpassen. Es sprudelt nur so aus ihm heraus. Er hat bereits in zwei erfolgreichen Teams gearbeitet und möchte sein Wissen weitergeben.

Der ScrumMaster notiert in seiner Liste:

Donnerstag, 12:30 Uhr – Wissen vermitteln

Der ScrumMaster hat ein gemeinsames Mittagessen organisiert. Einen Teamraum gibt es nicht, daher sieht sich das junge Team bis auf die Meetings nicht so häufig. Im gemeinsamen Austausch kommen unterschiedlichste Themen auf, welche die Teammitglieder noch nicht verstanden haben. Scrum sei doch sehr kompliziert. Ein Kollege erzählt, dass er gerade gemeinsam mit dem ScrumMaster einen User-Story-Workshop plant. Die anderen Teammitglieder machen Vorschläge, welche Themen sich noch eignen würden.

Weitere Vermerke kommen auf die Liste:

Freitag, 15:00 Uhr – mit Begeisterung anstecken

Das Review beginnt. Sechs von sieben Storys sind fertig geworden. Nur sechs Storys werden gezeigt. Hier gibt es Verbesserungspotential, aber für die nächsten 90 Minuten widmet sich der ScrumMaster vor allem dem Erfolg des Teams. Ein neues Gesicht ist in der Runde. Eine Mitarbeiterin aus dem Vertrieb ist vorbeigekommen, um sich anzusehen, was das Team entwickelt hat. Sie hat einen Tipp bekommen und wollte sich das nicht entgehen lassen. Sie kann die Endanwender zwar nicht ersetzen, ist aber ziemlich nahe dran. Der PO hält sich zurück und das gesamte Team präsentiert. Die Mitarbeiterin ist begeistert. Sie hat zwar ein paar Anmerkungen, ist aber sonst sehr zufrieden. Das nächste Mal bringt sie einen weiteren Kollegen mit. Vielleicht kann sie sogar mal einen richtigen User organisieren. Den Applaus erhalten am Ende alle. Auch der eine Kollege, der etwas abseits von der Gruppe steht. Überzeugt ist er (noch) nicht, aber ein Lächeln konnten wir ihm abgewinnen.

Der letzte Eintrag diese Woche: 

Sie kennen alle Tipps und Tricks zum Thema Motivation von Scrum-Teams und lassen nichts unversucht, um Ihre Teams zu motivieren? Dann sind wir gespannt auf Ihre Erfolgsgeschichte.

 

Feedback oder die Kunst der Anerkennung

Wir Menschen streben nach Anerkennung. Unsere Motivation steigt, wenn unsere Arbeit „erkannt“ und wertgeschätzt wird. Diese Wertschätzung können wir durch unser Umfeld, also Kollegen, Freunde oder Familie erhalten, aber auch durch uns selbst. Und doch passiert beides immer noch viel zu selten.

Konstruktives und wertschätzendes Feedback kann das Bedürfnis nach Anerkennung der eigenen Arbeit bedienen. Es kann dabei helfen, die eigenen Ressourcen besser einzusetzen, produktiver zu werden und Erfolgspotentiale weiterzuentwickeln. Nicht zuletzt bietet es die Chance, aus Fehlern zu lernen und blinde Flecken aufzudecken. Halten wir uns bei der Arbeit mit Feedback zurück, bringen wir uns selbst und vielleicht auch unser Team oder ein ganzes Unternehmen um den Erfolg.

Die Devise heißt also: Schwächen abbauen und Stärken aufbauen. Doch leider ist Feedback oft eine Mogelpackung, wenn es falsch formuliert ist und dadurch verletzend wird. Wissenschaftliche Erkenntnisse beweisen, dass es entscheidend ist, wie man etwas sagt.

Wie formuliert und gibt man Feedback?

Die Kunst ist also, Feedback wertschätzend zu formulieren. Es sollte beschreibend sein und nicht bewertend. Es sollte sich auf eine erlebte Situation und ein konkretes Beispiel beziehen und am besten sofort im Anschluss gegeben werden. So, dass man über veränderbares Verhalten spricht – konkret und nicht allgemein gehalten, mit klar formulierten Aussagen. Besonders positive Wahrnehmungen und Gefühle können und sollen mitgeteilt werden. Wichtig ist dabei, stets aus eigener Perspektive für sich zu sprechen. Gut wäre es, eine Gesprächsatmosphäre so zu kreieren, die nicht unter Zeitdruck und in der Öffentlichkeit geschieht, sodass der Feedbacknehmer auch die Zeit hat, das Feedback in Ruhe zu verarbeiten.

Um das Feedback zu entschärfen und nicht als verletzende Waffe einzusetzen, sollten Sie sich im Voraus über die folgenden Punkte klar werden:

Feedback geben in drei Schritten

Wenn Sie diese grundlegenden Fragen geklärt haben, hilft es, das Feedback in drei Schritte zu gliedern:

  1. Klären Sie zunächst den Sachverhalt und stellen Sie sich die Frage: „Was ist geschehen?“
  2. Danach folgt eine Offenbarung bzw. Beschreibung der Gefühle: „Wie geht es mir damit?“
  3. Die konstruktive Komponente ist schließlich entscheidend für die Umsetzung: „Wie kann für die Zukunft eine Verbesserung herbeigeführt werden?“ Wichtig dabei ist, dass Sie realistische Maßnahmen vorschlagen, die auch umgesetzt werden können.

Fakt ist, dass Selbst- und Fremdeinschätzung meistens voneinander abweichen. Des Weiteren ist jedes abgegebene Feedback zu einer Person anders, weil jedes Individuum andere Dinge an der beobachteten Person wahrnimmt. Die Gefahr ist daher groß, missverstanden oder überhaupt nicht verstanden zu werden. Deshalb seien Sie offen, hören Sie beim Feedback nehmen aktiv zu und fragen Sie bei Unklarheiten beim Gesprächspartner nach. Nur so können beide Seiten sichergehen, dass Ihre Botschaften auch ankommen.

Auf den Punkt gebracht

Feedback erlaubt uns, das eigene Verhalten aus der Perspektive des Gegenübers zu betrachten und es damit auf den Prüfstand zu stellen. Somit haben wir die Chance uns weiterzuentwickeln und in dem was wir tun noch besser zu werden. Für den Feedbackgeber ist die Kunst, die konstruktive Kritik wertschätzend zu formulieren, damit der Empfänger das Feedback auch annehmen kann und nicht in eine abwehrende Haltung gezwungen wird. Fragen Sie den Empfänger ruhig vorher, ob Sie Feedback geben dürfen. Als Empfänger lohnt es sich bei Unklarheiten oder nicht nachvollziehbaren Beispielen nachzufragen, was gemeint ist und in den Dialog zu treten. Denn nur so profitieren Sie und damit Ihr Unternehmen davon.

Von Löwen und dem Mut, sich auf Scrum einzulassen

Verschränkte Arme, kritischer Blick und einen spöttischen Zug um den Mund – so steht er mal wieder in unserem Sprint Planning 2. Manchmal lauert er auch wie ein Löwe, lauert auf die nächste Gelegenheit zum Angriff. Er ist schon sehr lange dabei. Er weiß, wie der Laden läuft und er ist Experte auf seinem Gebiet. Stolz wie ein Löwe nutzt er nur zu gerne jede Gelegenheit, um zu präsentieren, wie bisher alles gemacht wurde und welche Erfolge er dabei verzeichnen konnte. Wozu er jetzt mich – diesen sogenannten ScrumMaster – brauchen sollte, der ihm sagt, wie er noch effizienter arbeiten kann, versteht er nicht. Warum er ständig an diesen Meetings teilnehmen muss und transparent machen soll, woran er gerade arbeitet, versteht er noch weniger. Und was ist eigentlich dieses Scrum? Wer hat sich das schon wieder ausgedacht? Er beobachtet argwöhnisch jeden meiner Schritte und gibt mir zu verstehen, dass ich ein Eindringling in seinem Herrschaftsgebiet bin.
Jeder kennt sie, diese Art von Kollegen. Veränderung fällt ihnen schwer. Sie können sich nicht so leicht wie die anderen darauf einlassen. Eine neue Methode wie Scrum in den Arbeitsalltag zu integrieren, ist eine solche Veränderung. Manche Menschen können damit umgehen, manche nicht. Was man dabei immer im Hinterkopf behalten sollte: Jede Veränderung bringt auch einen größeren oder kleineren Verlust mit sich. Und jeder Mensch begegnet diesem Verlust unterschiedlich.

Verlust verstehen mit den fünf Phasen der Trauer

Mir hat die Beschreibung der fünf Phasen der Trauer von Elisabeth Kübler-Ross – Verleugnung, Verärgerung, Verhandlung, Depression und Akzeptanz – dabei geholfen, die möglichen Reaktionen auf Verlust und damit die unterschiedlichen Reaktionen von Menschen auf Veränderungen besser zu verstehen. [vgl. Kübler-Ross, Kessler 2005, S. 7-24] Das Leugnen der Veränderung hilft uns durch den ersten Schockzustand, indem wir uns nur so weit auf die Realität einlassen, wie wir es im Moment aushalten können. Der Ärger, den wir fühlen, sobald wir das gesamte Ausmaß der Veränderung realisieren, kann auf ganz unterschiedliche Ziele gerichtet sein: Kollegen, Management oder auch die Familie. Manchmal versuchen wir, über die Folgen der Veränderung zu verhandeln, um einen Ausweg aus der Situation zu finden. Eine typische Frage, die für mich die Unsicherheit in der Depressionsphase deutlich macht, lautet: „Warum soll ich mich denn überhaupt noch anstrengen, ergibt das noch Sinn?“ Und irgendwann gelangen wir an den Punkt, an dem wir die Veränderung Stück für Stück akzeptieren können und lernen, mit ihr zu leben.
Anzunehmen, dass jede einzelne Phase linear durchlaufen wird und Wochen ja vielleicht sogar Monate fortwährt, ist falsch. Wir reagieren in diesen Phasen auf Gefühle, die Stunden oder auch nur Minuten andauern und sich an keine vorgeschriebene, rationale Abfolge halten!

Wie ScrumMaster durch den Verlust führen können

Doch zurück zu unserem Löwen. Wie helfe ich ihm als guter ScrumMaster jetzt durch diese Situation? Mein erster Impuls bei einer solchen ablehnenden Haltung ist immer, den Kollegen darauf anzusprechen. Ich möchte verstehen, was das Problem ist, es aus der Welt schaffen und ihn dazu befähigen, sich auf diese Reise in die Agilität einzulassen. Doch genau das ist es, worauf der Löwe wartet: Wertschätzung im Sinne von Aufmerksamkeit zu erhalten und dadurch in seiner ablehnenden Haltung bestärkt zu werden.
Wieso also sollte ich ihm genau das geben, was er möchte und ihn wertschätzen, wo er sich doch dem ganzen Team gegenüber respektlos benimmt? Deshalb konzentriere ich mich auf die Teammitglieder, deren motiviertes und offenes Verhalten zum Erfolg des Projekts beiträgt. Getreu dem Motto: Ich konzentriere mich auf die Einstellung, von der ich mehr möchte. Ich ignoriere den Löwen auf der anderen Seite des Raums und schenke dem restlichen Team meine Aufmerksamkeit. Ich bestärke die Haltung des Löwen nicht und signalisiere ihm, dass er die Phasen der Trauer weiter durchlaufen muss. Dadurch versuche ich, ihn dazu zu bringen, über sein Verhalten zu reflektieren und er lernt, dass nur jene Teammitglieder eine Belohnung in Form von Aufmerksamkeit bekommen, die mir und der Methode offen begegnen und respektvoll miteinander umgehen. Jedoch achte ich wachsam darauf, wann er sich der Methode und dem Team gegenüber öffnet. Dann bin ich da, um ihm dabei zu helfen, wieder zum Team aufzuschließen – inhaltlich, aber auch emotional. Ich beantworte seine Frage und nehme ihn mit auf unsere Reise. Und dabei ist mir stets bewusst, dass man einen wilden Löwen nie ganz zähmen kann.

[Kübler-Ross, Kessler 2005]
Kübler-Ross, Elisabeth; Kessler, David: On Grief and Grieving: Finding the Meaning of Grief Through the Five Stages of Loss. Simon and Schuster 2005.
Foto: CC0 Creative Commons – pixabay, IanZA

Regeln und Prozesse im agilen Umfeld? Nein! Doch! Oh!

In vielen selbstorganisierten Umfeldern gibt es zwei böse Wörter: das R-Wort und das P-Wort. Benutzt man diese Worte, kann man sich auf einen wilden Mob und viel Widerstand einstellen. Wild ist der Mob vielleicht nicht, aber er ist bereit, sich mit allen Mitteln gegen die Regeln und Prozesse zu wehren. Denn die vielen Freigeister fühlen sich durch das R-Wort auf einmal eingeengt und ihrer Freiheit beraubt. Meiner Meinung nach brauchen wir aber Regeln und Prozesse. Ein selbstorganisiertes System endet schnell im Chaos, wenn es keine Regeln und Prozesse gibt. Die Effizienz sinkt und die Produktivität geht in den Keller. Aus unternehmerischer Sicht ein Desaster.
Vorweg sei also gesagt: Auch in der agilen Welt brauchen wir Regeln und Prozesse. Es kommt aber darauf an, um welche Regeln und Prozesse es sich handelt und wie viele es davon gibt. Hier greift ein bekannter Satz: So wenig wie möglich, aber so viel wie nötig! Der Inhalt ist wichtiger als die Menge. Jede Organisation sollte daher ihre eigenen Regeln und Prozesse genau analysieren und auf folgende vier Aspekte untersuchen:

  1. Nutzen: Eine Regel, die keinen Nutzen stiftet, ist eine schlechte Regel. Beschützt die Regel etwas, was beschützt werden muss? Ja – super, diese Regel behalten wir! Nein – diese Regel kann weg. So einfach können Sie Ihre Regeln aussortieren.
  2. Nachvollziehbar: Eine Regel muss nachvollziehbar sein. Was bringt mir eine Regel, die von den Mitarbeitern nicht verstanden wird? Sie bringt Widerstand. Besonders in selbstorganisierten Organisationen kann dieser groß werden. Die Kollegen werden die Regel hinterfragen und sich zur Wehr setzen, also gestalten Sie die Regel transparent und kommunizieren sie den Nutzen (s.o.), damit der Angestellte sie verstehen und vor allem akzeptieren kann.
  3. Effizienz: Eine Regel oder ein Prozess muss effizienzsteigernd sein. Was bringt mir ein Nutzengewinn durch einen Prozess, wenn ich diesen wesentlich schlanker gestalten könnte und somit effizienter arbeiten könnte? Genau, er bringt Opportunitätskosten mit sich und einen Effizienzverlust! Übrigens: Ist ein Prozess nicht effizient, wird er in der Regel nicht akzeptiert, weil er nur bedingt nachvollziehbar ist!
  4. Flexibel: Eine Regel oder ein Prozess muss agil sein. Ist diese(-r) nicht anpassbar, werden alle drei Punkte zuvor nicht erfüllt. In einem dynamischen Umfeld ist es also unabdingbar, sich regelmäßig mit seinen Regeln und Prozessen auseinanderzusetzen.

Das Wichtigste, was Sie über Regeln wissen müssen, ist die folgende Regel: Reden Sie im Unternehmen regelmäßig über Ihre Regeln. Sorgen sie für Verständnis, stellen Sie den Effizienzgewinn dar und passen Sie dann bei Bedarf ihre Regeln an. Kommunizieren Sie ständig und immer weiter Ihre Regeln. Es muss deutlich werden, dass diese Regeln nicht da sind, um den Freigeistern Ihre Freiheit wegzunehmen, sondern um sie zu schützen oder um ihre Produktivität zu erhöhen. Nur durch Kommunikation kann ein harmonisches und effizientes Miteinander in einer Selbstorganisation mit Regeln und Prozessen garantiert werden.
Ein relevantes und aktuelles Beispiel gefällig? Bitte sehr: Auch wir bei borisgloger consulting haben Regeln und Prozesse, an die sich meine Kollegen und ich halten müssen. Gerade aber neue Kollegen verstehen die Regeln nicht immer und wollen sie in Frage stellen. Was passierte also speziell bei uns? Einige Kollegen versuchten eine Regel zu umgehen, weil sie sich um Teile ihrer Freiheit beraubt fühlten. Sie sahen in dieser Regel vor allem eine Hürde, bedachten aber gleichzeitig nicht, dass die Regel einen tieferen Grund hatte. Dieses Nichtwissen kann man ihnen gewiss nicht vorwerfen, denn der Grund der Regel wurde ihnen nie wirklich nahegebracht. Was dann aber passierte, ist unserer lebendigen Diskussionskultur zu verdanken. Regelaverse und regelfreudige Kollegen diskutierten miteinander. Das Ergebnis: eine Anpassung der Regel und vor allem eine klare Kommunikation der Regel. Gut, dass wir darüber gesprochen haben!

Foto: CC0 Creative Commons – pixabay, taniadimas

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Als ScrumMaster werde ich in Unternehmen geholt, um zur Produktivitätssteigerung Scrum „einzuführen“. Relativ schnell begegne ich dabei folgendem Umstand: Viele Product Owner haben nicht im Blick, was ihr Team eigentlich genau liefern soll. Jedenfalls beantworten sie diese Frage selten aus Kundensicht. Meistens treffe ich auf Product Owner, die durch ihre lange Erfahrung und ihr umfangreiches Wissen zwar Experten für ihre Produktsparte geworden sind, aber ihr Blick hängt am eigenen Tun und Denken fest. Letzteres ist folglich zu wenig nach draußen gerichtet, in die Erlebniswelt des Kunden und des Nutzers. Für mich als ScrumMaster bedeutet das, den Product Owner und das Entwicklungsteam zu dieser Sicht- und Denkweise hinzuführen, was viel umfassendere Implikationen hat, als einfach mal eine neue Methode „einzuführen“. Genau genommen sprechen wir von der Entwicklung hin zu einer kundenorientierten Organisation, und das wirkt sich gleich auf mehreren Ebenen aus:
Ein wichtiger erster Schritt ist, eine agile Produktentwicklung zu etablieren. Das heißt im Idealfall, dem Scrum-Team beizubringen, wie man iterativ ein MVP (Minimum Viable Product) entwickelt und es dem Markt bzw. den Usern aussetzt – bis ein Produkt gefunden wird, das es sich in allen Details fertig zu bauen lohnt.
In diesem Prozess stellt man wiederum fest, wo es im Team an Skills mangelt, und in der Regel tut es das. Die nächste Aufgabe wäre also, diese Skills zu entwickeln. In der Softwareentwicklung hat sich für den Aufbau und den Austausch von Wissen das Mob bzw. Pair Programming etabliert, das Prinzip lässt sich aber auf andere Arbeitsbereiche anwenden. Fehlen bestimmte Skills zur Gänze, muss man sich diese zusätzliche Kompetenz ins Team holen.
Auf der Ebene der Infrastruktur stößt man schnell an Grenzen, die aufgelöst werden wollen: Hat das Team überhaupt geeignete Räume, in denen die Zusammenarbeit möglich ist? Sind Kommunikationsmittel im Einsatz, mit denen die Teamarbeit strukturell überhaupt abgebildet werden kann („Pull“-basierte Tools wie Slack oder Microsoft Teams können das), oder läuft die schriftliche Kommunikation des Teams hauptsächlich über E-Mail? Gibt es Arbeitsmaterialien wie Flipcharts, Whiteboards etc. erstens in ausreichender Menge und zweitens in guter Qualität?
Bleibt noch die Ebene der Architektur, auf die man einen Blick werfen sollte. Wie ist das Unternehmen organisiert und passt diese Organisationsstruktur überhaupt zu dem Produkt, das sich die Kunden und Anwender wünschen? Eng verbunden damit ist die Frage der Führungskultur in der Organisation: Sind Selbstorganisation, Freiwilligkeit und Commitment erlaubt und werden sie belohnt?
Was bedeutet das für die Arbeit als ScrumMaster oder Agile Coach? Ich muss einerseits die genannten Ebenen im Blick behalten und gleichzeitig meine Rolle mit Konsequenz leben. Das bedeutet, die agilen Werte und Prinzipien mit Bestimmtheit zu vertreten. Das bedeutet zum Beispiel, den nötigen langen Atem mitzubringen und dem Management so lange auf den Nerv zu gehen, bis die Lizenz für das geeignete Kommunikationstool gekauft wurde. Müsste ich das Handeln des ScrumMasters auf einen Aspekt reduzieren: immer wieder transparent machen, wo es hängt – auf allen Ebenen. Nur so komme ich überhaupt an die entscheidenden Punkte heran, die eine Organisation in ihrer Produktivität behindern.

ScrumMaster in Aktion: Das Feiern von Erfolgen

Es ist 9.00 Uhr. Wir haben uns vor dem Taskboard versammelt. Es ist alles noch ganz frisch, wir lernen noch, ein Hauch Unsicherheit liegt in der Luft. Der erste Kollege beginnt und hängt seine Tasks um. Die Kollegin folgt. Der erste Task wird auf „Done“ gesetzt. Die erste Aufgabe ist geschafft. Ich lade zum Feiern ein, strahle die Kollegin an. Ich empfinde die erste erledigte Aufgabe als große Genugtuung. Grund genug, um kurz innezuhalten und den Moment wirken zu lassen. Einziger Haken daran: um mich herum nur verdutzte Gesichter, die Kollegin ist verunsichert. Lob für eine solche „Kleinigkeit“ ist sie nicht gewohnt. Sie mache doch nur ihren Job. Auch der Product Owner ist verwirrt: Sollte das hier nicht selbstverständlich sein? Warum also ist der ScrumMaster so begeistert?
Ich merke schnell: Das Problem liegt tiefer. Lob und positive Rückmeldungen gehen hier allen schwer von den Lippen. Aus der Psychologie ist bekannt, dass Belohnung der positiven Verstärkung dient. Damit soll die Wahrscheinlichkeit erhöht werden, dass sich ein gewünschtes Verhalten wiederholt. Situationsgebundene Belohnung kann also durch Loben erfolgen. Dies sollte allerdings nicht zu freigiebig eingesetzt werden, da es sonst unverdient erscheint. Bewiesenermaßen wird das Belohnungssystem jedoch gezielt durch die Wertschätzung unserer Mitmenschen angesprochen – das steigert die Ausschüttung des Glückshormons Dopamin.

Den kleinen Dingen Aufmerksamkeit schenken

Meistens sind es ja die kleinen Dinge, die als selbstverständlich hingenommen werden, und es erscheint uns deshalb nicht nötig, diese wertzuschätzen. Es liegt uns fern, die kleinen Dinge zu sehen, die in Summe zum Gesamterfolg beitragen. Gerade im Prozess der Veränderung ist es jedoch sehr wichtig, diese kleinen positiven Fortschritte zu erkennen und hervorzuheben. Dopamin ist dafür verantwortlich, dass wir Erfahrungen als wohltuend empfinden, in Zukunft werden wir uns an dieses Gefühl erinnern können. So werden diese aktiv unterstützt und in Zukunft höchstwahrscheinlich wiederholt werden. Noch wichtiger als das Lob durch den ScrumMaster und den Product Owner ist das Lob untereinander. Kollegen, die sich gegenseitig zu ihren einzelnen Leistungen wertschätzend äußern, steigern die produktive Zusammenarbeit und den Zusammenhalt im Team.

Das Team mit Freiheiten belohnen

Das Team kann neben diesen kleinen Wertschätzungen auch durch Freiheiten belohnt werden. Vertrauen, das dem Team beispielsweise vom Product Owner entgegengebracht wird, ist eine wertschätzende Handlung, die dazu führen kann, dass das Team bemüht ist, beim nächsten Mal die Erwartungen des Product Owners zu übertreffen. Es wird dadurch selbstbewusster und beginnt, sich selbst mehr zuzutrauen. Damit ist die Grundlage für innovativere und kreativere Lösungen gelegt und das Team wächst noch mehr zusammen. Zugestandene Freiheit wirkt durch ihren wertschätzenden Charakter also ebenfalls als positive Verstärkung und steigert die Produktivität im Scrum-Team.

Gold Cards

Die gleiche Wirkung haben sogenannte Gold Cards, die der Product Owner an die Teammitglieder vergibt. Mit diesen Cards können Mitarbeiter innerhalb eines gewissen Zeitraums einen Teil ihrer Arbeitszeit in etwas investieren, das sie interessiert. Dies kann eine Fortbildung, persönliche Weiterbildung oder Zeit sein, um an eigenen Ideen zu arbeiten. Der Vorteil an dieser Variante ist, dass dem einzelnen Mitarbeiter gegenüber Interesse ausgedrückt wird, nicht nur an der Leistung des Teams.

Eine Release-Party schmeißen

Im skalierten Umfeld gibt es eine weitere mächtige Möglichkeit, das gesamte Team oder sogar mehrere Teams für ihre erbrachten Leistungen zu belohnen. Wie wäre es beispielsweise mit einer Release-Party? Die Teams haben durchgehalten, gekämpft und geliefert. Warum also nicht den Release gebührend mit allen Beteiligten feiern? So kann sogar das Angenehme mit dem Nützlichen verbunden werden: Die Teams können ihre Leistungen bei einer Präsentation von den Stakeholdern und dem gesamten Umfeld anerkennen lassen und anschließend kann sich das Team gebührend selbst feiern.
Zurück zum Geschehen: Ich wiederhole meine Aufforderung, den ersten Task auf „Done“ zu feiern. Peinlich berührt versucht sich die Kollegin aus dem Mittelpunkt zu stehlen. Wir haben noch einen langen Weg vor uns, aber ich werde nicht aufgeben, denn: Gerade am Anfang sind es die kleinen Erfolge, die aus einer Gruppe von Menschen ein Team machen.

Foto: CC0 Creative Commons – pixabay, pexels

Interview: Was macht ein ScrumMaster?

Meine Kolleginnen und Kollegen unterstützen unter anderem als ScrumMaster die Teams von Kunden. Worum sich ein ScrumMaster gerade kümmern sollte, hängt von der Phase ab, in der sich ein Team befindet – und zum Team gehört auch der Product Owner. Wie sich die Rolle des ScrumMasters im Laufe der Zeit verändert, erzählt Christoph Schmiedinger anhand seiner eigenen Erfahrung.

Agil trotz Überlastung: Wie man die Freiwilligkeit rettet

Die folgende Situation kommt Ihnen eventuell bekannt vor: Der Product Owner oder das Management haben das Prinzip der Agilität noch nicht vollständig verinnerlicht und überladen die Teams mit Aufgaben, die ihre Kapazität um das Doppelte übersteigen. Die Folge sind unzählige Meetings, lange Abende und wenig Motivation für alles, was den ständig wachsenden Stapel auf dem Schreibtisch nicht direkt verkleinert. Dazu gehören auch die morgendlichen Dailys, lange Sprint Plannings und ganz beliebt: die vermeintlich überflüssige Retrospektive. Gerade Letztere erzeugt selten einen sofort messbaren Mehrwert, weswegen sie gerne einmal gekippt wird, wenn ein Team zu ausgelastet ist. Was also tun, um dem Team zu helfen, Agilität zu verstehen, seine eigene Effizienz zu steigern und Zeit dafür zu finden? Und wie kann man den Weg dorthin auch noch auf dem Prinzip der Freiwilligkeit beruhen lassen?

  1. Freiwilligkeit betonen. Ich handhabe dies gerne, indem ich das Gesetz der zwei Füße anbringe und zum Standard in allen Meetings erhebe. Freiwilligkeit zu betonen und vor allem zu leben, ist von enormer Bedeutung, da das Team lernen soll, selbstbestimmt zu arbeiten. Langfristig wird es eine intrinsische Motivation für Agilität aufbauen, wenn es den Mehrwert darin erkennt.
  2. Mehrwert schaffen. Nichts überzeugt mehr als Mehrwert. Wenn jedes Teammitglied nach einem Meeting das Gefühl hat, dass die Zeit gut investiert war, fällt es leichter, auch am nächsten Meeting teilzunehmen und sich langfristig auf Agilität einzulassen. Mehrwert zu schaffen, liegt in der Verantwortung des ScrumMasters.
  3. Meetings koppeln. Was aber, wenn die Teammitglieder aufgrund ihrer Auslastung zum Beispiel nicht einmal zur ersten Retrospektive zu bewegen sind? Hier hat es sich für mich bewährt, Kombinationsmeetings anzubieten. Statt zu einer Stunde Backlog Refinement und einer Stunde Retrospektive einzuladen, lade ich einfach zu zwei Stunden Refinement und Retro in einem Termin ein. Klingt simpel? Ist es auch. Sind die Teammitglieder erst einmal an einem Ort und gestaltet der ScrumMaster einen guten Übergang, hat die Retro schon voll begonnen, bevor das Team merkt, dass es bereits die Axt schärft. Tipp: Zu Beginn kann das Kombinationsmeeting auf eineinhalb Stunden angesetzt werden, um die Hemmschwelle zu senken.
  4. Brokkolimethode einsetzen. Als Kind mochte ich, heute unverständlicherweise, keinen Brokkoli. Meine Oma fragte mich dann am Mittagstisch, mit der Kelle Brokkoli bereits in der Hand, ob ich denn zwei oder drei Stücke Brokkoli möchte. Ich nahm natürlich zwei Stück und aß sie brav auf, da ich das Gefühl hatte, die Entscheidung selbst getroffen zu haben. Wie wohl meine Antwort ausgefallen wäre, wenn meine Oma gefragt hätte: „Möchtest du Brokkoli? Ja oder nein?“ Übertragen wir die Methode meiner Oma auf ein Meeting: „Wollt ihr die Retrospektive lieber um 14.00 Uhr oder um 16.00 Uhr machen?“ Ask the team. Danke Oma!
  5. Jedes Zweiglein greifen. Ein guter ScrumMaster hört zu. Jederzeit und mitdenkend. So fallen ihm auch Zweiglein auf, die das Team fallen lässt und die er aufheben muss, um die Arbeit des Teams zu verbessern. Beispielsweise ließ in einem Sprint Planning ein Tester den Kommentar fallen, wie schade es sei, dass niemand im Team Wissen zu einer bestimmten Datenbank hatte. Nach fünfminütiger Diskussion war klar, dass drei Teammitglieder dieses Wissen sehr wohl hatten und der besagte Tester dies erst jetzt, sechs Wochen nach Projektstart und unzähligen Abstimmungsschwierigkeiten, erfahren hatte. Das Zweiglein greifend, stellte sich heraus, dass es alle gut fänden zu wissen, welche Fertigkeiten und Wissen die anderen Teammitglieder hatten (welch Überraschung). Einmal zu dieser Erkenntnis gekommen, fiel es nicht schwer, einen Skills-Workshop auf die Beine zu stellen: Einerseits wurden die Skills der Teammitglieder samt selbstorganisierter Fortbildungsmaßnahmen entwickelt und andererseits wurde mein Arbeitsmodell für das Projekt gefüllt. Also mein Tipp: Hört genau zu, fragt nach und nutzt die mäeutische Methode von Sokrates.

Zusammenfassend gibt es aus meiner Sicht mehrere Möglichkeiten, die Effizienz eines Teams zu steigern und das Prinzip der Freiwilligkeit zu leben und zu fördern, auch wenn das Team stark ausgelastet ist. Das bedeutet zu Beginn viel Aufwand, Motivationsarbeit und den einen oder anderen Kniff. Dabei sollte nie vergessen werden, das Prinzip der Freiwilligkeit zwar explizit zu erwähnen, es jedoch ab und zu durch aktives Nachdenken direkt erkennbar werden zu lassen.

Visualisierung: Behübschung oder Mehrwert für den Scrum Flow?

Überall dort, wo Menschen aufeinandertreffen, um miteinander Dinge zu erarbeiten, zu besprechen und zu planen, ist Visualisierung sinnvoll – zum Beispiel bei Meetings, Tagungen, Konferenzen, Seminaren, Trainings und Workshops. Obwohl es unzählige Möglichkeiten gibt, verstehen viele unter „Visualisierung“ noch immer nur PowerPoint-Präsentationen und vergeben sich damit die Chance auf einen nachhaltigen Eindruck. Was bleibt nach der x-ten PowerPoint-Präsentation in Erinnerung? Endlose Folienschlangen, dicht bepackt mit Zahlen, Daten und Fakten – kaum etwas davon bleibt erwiesenermaßen im Gedächtnis der Zuhörerschaft hängen.
Auch die Wissenschaft zeigt: Visuals schaffen es deutlich besser, die Zuhörer und Zuschauer zu binden. Laut einer Studie der Universität von Minnesota gemeinsam mit der 3M Corporation, die den Einfluss visueller Hilfen im Präsentationssetting untersuchte, kann das menschliche Gehirn Visualisierungen bis zu 60.000 mal schneller verarbeiten als reine Textinhalte. Da 90 Prozent der vom Gehirn absorbierten Informationen visueller Natur sind, können im Anschluss visualisierte Inhalte wesentlich besser abrufen werden.

Visualisierung

Beispiel einer unterstützenden Visualisierung zum Thema “Methodenevolution” während einer interaktiven Meetingform

Das ist ideal für den agilen Kontext, der von der Interaktion, der Freiwilligkeit und Bereitschaft im Team lebt, gemeinsam an Produktlieferungen zu arbeiten. Visualisierungstechniken schaffen es, die Menschen in Arbeitssitzungen und Lernumgebung stärker zu aktivieren. Als Visual Facilitator kann ich hier komplexe Inhalte und unterschiedliche Perspektiven sichtbar machen, dem Team Impulse für den Dialog geben, Gedanken strukturieren und schließlich wichtige Ergebnisse sichern. Neben den zahlreichen Vorzügen zeigen sich in der Unternehmenspraxis allerdings auch einige Herausforderungen, die man beachten sollte, wenn man die Vorzüge der Visualisierung im agilen Kontext nutzen will:

  1. Halten Sie eine lebendige Präsentation. Gehen Sie nicht mit vorgefertigten Flipcharts in eine Präsentation. Als Live-Zeichner sollten Sie die Darstellung im Laufe der Präsentation entwickeln, um die Zuhörer abzuholen, den Erinnerungswert zu steigern und Publikumsfeedback direkt einfließen lassen zu können. Der Zuhörer und Betrachter wird dadurch zweifach kognitiv stimuliert – der Erinnerungswert steigt.
  2. Vermeiden Sie die Ornamentierung von Scrum. Auch wenn Prozess, Inhalte und Ergebnisse in visueller Sprache, d.h. in Kombinationen von Text, Bild und Containern gut sichtbar gemacht werden können, schlägt im Zweifel der Inhalt die Form. Konzentrieren Sie sich auf die Präsentation und nutzen Sie Visualisierungshilfen nur zur Unterstützung Ihrer Kernaussagen.
  3. Lassen Sie sich als ScrumMaster nicht auf die Rolle des Facilitators reduzieren – ein mit bunten Visuals geschmückter Scrum-Meeting-Raum ist keine Garantie für einen funktionierenden Change Prozess. Dem Team und den Stakeholdern hilft die Transparenz, die durch Visualisierungen in Meetings, von Artefakten und auf Boards entsteht. Übernehmen Sie aber nicht alle zeichnerischen Leistungen, sonst werden Sie schnell auf die Rolle des Visual Facilitators reduziert – als ScrumMaster haben Sie noch wesentlich wichtigere Aufgaben!

Nicht nur, aber besonders im agilen Umfeld bieten ausdrucksstarke Visualisierungen die Möglichkeit, den Wert und die Wichtigkeit von Aussagen zu unterstreichen und klarer zu machen. Vom Teammeeting bis zur Großgruppenveranstaltung mit mehreren Hundert Teilnehmern haben Sie ein kraftvolles Tool in der Hand, wenn Sie die damit verbundenen Herausforderungen ernst nehmen.

Foto: CC0 Creative Commons – pixabay, AlexanderStein

The Role of the ScrumMaster

There are many misconceptions about which key tasks are included in the role of a ScrumMaster. In this video, I illustrate the different functions which a ScrumMaster must fulfill. However, it is important that a ScrumMaster does not get sidetracked by his many tasks, but remains focused on his most important function. 
Do you want to find out more? Watch my video about the role of a ScrumMaster! 

Was die Position des Scrum-Teams vor dem Taskboard über das Team aussagt

„Leistet mein Team gute Arbeit?“ Eine Frage, die viele Führungskräfte in Unternehmen umtreibt, wie zahlreiche Anfragen nach Projektbesuchen und Assessments beweisen. Doch braucht es Fragebögen, Interviews oder stundenlange Post-Mortems, um eine Antwort zu finden? Die Frage lässt sich häufig mit einer scheinbar einfachen Methode beantworten: durchs Beobachten.
Wenn ich zum ersten Mal ein Team besuche, das bereits agile Arbeitsweisen wie Scrum oder Kanban nutzt, achte ich bewusst und unbewusst auf viele kleine Hinweise, um eine Hypothese über den Teamerfolg und das Verhalten des Teams und des Unternehmens zu bilden. Ich versuche bewusst, nicht in Aktionismus zu verfallen und sofort alles auf links zu drehen. Denn es gibt Gründe, warum die Menschen so arbeiten, wie sie es gerade tun. Es geht also nicht darum, nach wenigen Tagen einen detaillierten 12-Punkte-Aktionsplan zu haben, sondern ein tiefes Verständnis für die Arbeitsweise der Menschen im Unternehmen zu entwickeln.
Erfahrungsgemäß ist die Stehung, das Catch Up, Stand Up oder Heads Up, oder wie auch immer Sie das tägliche kurze gegenseitige Update im Team, also das Daily Scrum, bezeichnen, eine tolle erste Möglichkeit, um diese Beobachtung durchzuführen. Neben dem üblichen Teilnehmerkreis, der Dauer und der Häufigkeit des Dailys sagt die Position der Teammitglieder vor dem Taskboard sehr viel über die Kultur und den Teamspirit aus.
In den zahlreichen Unternehmen und Projekten, die ich gesehen habe, zeichneten sich einige Muster immer wieder ab. 12 davon zeige ich Ihnen hier. Zur Erklärung: Der orange Kreis ist der ScrumMaster, Gelb symbolisiert die Teammitglieder, in Grün sehen sie den Product Owner und blau ist der Manager.

Muster 1 – das einsame Taskboard


Niemand kommt zum Daily. Man hat sich zwar die Mühe gemacht, die Arbeit sichtbar zu machen, doch das Hilfsmittel wird nicht genutzt. Wahrscheinlich wird das Taskboard nicht als hilfreich erachtet. Offensichtlich sind Zusammenarbeit und Koordination in diesem Team nicht notwendig.

Muster 2 – die Leere


Kein Taskboard, keine Gespräche, kein Treffen. Ob das besser oder schlechter ist, als das „einsame Taskboard“ sei mal dahingestellt.

 

Muster 3 – kein Taskboard


Das Team unterhält sich mehr oder weniger strukturiert. Das ist ein guter Anfang. Der Hauptzweck des Meetings – die kurze, zielgerichtete Unterhaltung zwischen den Teammitgliedern funktioniert. Ein Taskboard kann helfen, diesen Austausch zu fokussieren und zu strukturieren.

Muster 4 – das Zentrum

Die Teammitglieder berichten an den ScrumMaster. Der ScrumMaster steht viel zu sehr im Fokus und verhindert, dass sich die Teammitglieder offen und ehrlich austauschen. Das Team hat den Nutzen des Dailys für sich selbst wahrscheinlich noch nicht erkannt. In besonders schlimmen Fällen fragt der ScrumMaster die Teammitglieder einzeln ab und verlangt eine Rechtfertigung, wenn etwas nicht klappt. Selbstorganisation muss hier noch beigebracht werden.

Muster 5 – das alternative Zentrum


Die Teammitglieder berichten an den Product Owner. Ein Wort – Micromanagement. Anscheinend vertraut der Product Owner dem Team nicht ausreichend. Der ScrumMaster scheint auch schwach zu sein.

Muster 6 – die spanische Inquisition


Product Owner und ScrumMaster sitzen hinter einem Schreibtisch vor dem Taskboard und erwarten den Bericht der Teammitglieder. So ziemlich das Schlimmste, was einem Team passieren kann. Noch schlimmer wäre es nur mehr, wenn die Teammitglieder mit verbundenen Augen vor einer Wand stünden.

Muster 7 – das Meeting


Offensichtlich ist die alte Meetingkultur noch tief verankert. Die Teammitglieder sitzen an den Tischen. Im „Idealfall“ klappt jeder noch seinen Laptop vor sich auch und tippt wild vor sich hin. Es geht um Anwesenheit, nicht um Ergebnisse. Langeweile ist vorprogrammiert, Leidenschaft werden wir in so einem Meeting vergeblich suchen. Kann noch gesteigert werden durch das nächste Muster.

Muster 8 – das Klassenzimmer


Ähnlich wie „Das Meeting“, zusätzlich können sich die Teammitglieder jetzt nicht mehr in die Augen schauen. Auch hier arbeiten eher Fachexperten in einer Arbeitsgruppe. Zusammenarbeit gibt es hier wahrscheinlich nicht.

Muster 9 – der Experte


Das Daily findet ausschließlich mit dem ScrumMaster und dem „einzigen Teammitglied, das sich wirklich auskennt“ statt. Ab und zu gibt es auch mehrere Experten, die jedoch getrennt voneinander befragt werden. Die restlichen Teammitglieder werden ignoriert. Teamzusammenarbeit und Austausch wird man in diesem Team vergeblich suchen.

Muster 10 – noch ein alternatives Zentrum


Die Teammitglieder berichten an den Manager – Micromanagement in Vollendung. Der Product Owner ist entweder entmachtet oder nicht da.

 Muster 11 – der Lonesome Rider


Der ScrumMaster macht das Daily mit sich alleine, weil er das Team nicht braucht, um Transparenz zu stiften. Er weiß Bescheid (oder meint Bescheid zu wissen), was im Team gerade läuft. Hat den Sinn des Dailys komplett verfehlt. Offensichtlich hat der ScrumMaster auch wenig Respekt vor den Fähigkeiten der Teammitglieder. Eine alternative Interpretation ist, dass keines der Teammitglieder zum Daily kommt, weil sie den Mehrwert und Sinn nicht sehen. Vergleichbar mit Muster 1 und 2.

Muster 12 – der Reporter


Der ScrumMaster berichtet direkt an den Manager. Teammitglieder werden komplett außen vor gelassen – entweder, weil der ScrumMaster die Teammitglieder als nicht fähig genug einstuft oder diese keine Lust auf das Meeting haben. Vertrauen und Identifikation mit dem Produkt, das entwickelt wird, wird man hier vergeblich suchen.

Die Kraft des Taskboards nutzen: Wie macht man es besser?

Idealerweise stehen alle Scrum-Teammitglieder – also Entwicklungsteam, Product Owner und ScrumMaster – gleichberechtigt vor dem Board. Die Teammitglieder erzählen sich gegenseitig von ihrem Fortschritt, der ScrumMaster moderiert, achtet in den Ausführungen des Teams auf Hindernisse und erzählt auch selbst von den Themen, an denen er arbeitet. Der Product Owner interessiert sich auch für den Fortschritt des Teams und berichtet von den Themen, die bei ihm passiert sind. So gefällt mir das.

Starten Sie an dieser Stelle ein kleines Experiment. Beobachten Sie bei nächster Gelegenheit das Verhalten Ihres Teams. Überprüfen Sie, ob sich der aus der Beobachtung ableitbare Zweck mit der Funktion deckt, die das Team erfüllen soll. Passt das Gesagte mit dem sichtbaren Verhalten zusammen? Damit wird die Beobachtung auch zur Strategiearbeit: Was haben wir uns vorgenommen zu tun und was tun wir tatsächlich? Beobachtung als bewusste Führungsaufgabe benötigt etwas Zeit und Kontakt ins Team, kann aber zur Rekalibrierung des Veränderungsbedarfs führen und zur Steuerung genutzt werden. Konkret könnte das bedeuten, die Beobachtung zu teilen und zusammen mit dem Team in Bezug auf den angestrebten Zweck zu reflektieren.
Kennt ihr noch weitere Muster? Ich freue mich über eure Kommentare.

ScrumMaster in a nutshell

Wenn wir uns in unseren Trainings der Rolle des ScrumMasters widmen, taucht in den Gesichtern der Teilnehmer meistens ein Ausdruck auf, der so viel sagt wie: „Das ist ja ziemlich klar“ oder „Diese Rolle kenne ich doch am besten, ich bin ja selbst jeden Tag ScrumMaster“. Doch bei der Diskussion über die umfassenden Aufgaben des ScrumMasters fällt auf: Das tägliche Doing in Worte zu fassen, ist gar nicht so leicht. Ein wirklich tiefes Verständnis seitens unserer Trainingsteilnehmer oder Projektmitglieder zu schaffen, ist aber eine wichtige Aufgabe. Auch wir Berater schärfen die Rolle des ScrumMasters durch unser tägliches Handeln nach und erfahren dabei selbst immer wieder aufs Neue, welche Herausforderungen diese Rolle mit sich bringt.
Die oberflächlichen Begriffe zu nennen, ist simpel: Ein ScrumMaster ist Leader, Facilitator, er ist Team Coach, Change Agent und Trainer. Er ist für die Produktivität des Teams zuständig. Diese Aspekte gehen weit tiefer als die Begrifflichkeiten – das liegt auf der Hand. Aber was bedeutet das konkret für den Alltag? Was muss ein ScrumMaster können? Was steckt hinter den Rollen?

Leader

Eine Rolle, die der ScrumMaster einnimmt, ist die laterale Führung des Teams. Selbstorganisierte Teams brauchen Führung, ganz besonders zu Beginn der Arbeit mit agilen Management-Frameworks. Dabei geht es konkret um das Verständnis verschiedener Führungsansätze: Es wird zum Beispiel zwischen Leadership im Sinne von „das Team befähigen und inspirieren“ (transformationale Führung) und „Führen mit Anreizsystemen und klaren Ansagen an das Team“ (transaktionale Führung) unterschieden. Ein ScrumMaster muss diese Führungsansätze kennen, verstehen und in der jeweiligen Situation richtig anwenden können. Er muss auch wissen, dass Laissez-faire keine Art der Führung ist. Wichtig in diesem Zusammenhang ist, zu Beginn des Auftrags zu klären, unter welchen Bedingungen der ScrumMaster an das Team herantritt und mit ihm arbeitet. Dazu gehört eben auch, dem Team gewisse Dinge vorzugeben, in denen der ScrumMaster in diesem Fall der Experte ist.

Team Trainer

Als Trainer vermittelt der ScrumMaster seinem Team die theoretischen Grundlagen. Er muss aber nicht nur die Methode kennen, er versteht auch die Probleme seiner Kunden und deren Branche. Er besitzt das nötige Domänenwissen und kann mit seinem Know-how über die Branche neue Lösungswege aufzeigen. Das bedeutet auch, dass er dem Kunden mit seinem Wissen immer eine Nasenlänge voraus ist. Er muss nicht besser entwickeln können als ein Entwickler, aber er muss wissen, wie entwickelt wird und was die Herausforderungen dabei sind.

Team Coach

In der Rolle des Team Coaches bringt der ScrumMaster das Team durch geschickte Fragestellungen von A nach B. Als Team Coach liegt sein Hauptfokus darauf, die Gesamtleistung bzw. das Können des Teams zu verbessern. Er erkennt und fördert Potentiale des Teams. Dabei können sowohl Stärken als auch Schwächen und Defizite im Team aufgedeckt werden, an denen gearbeitet werden muss.

Facilitator

Als Facilitator begleitet er das Team durch den Prozess und bringt eine Vielfalt an Methoden mit, mit der er Veränderung initiiert, begleitet, unterstützt und fördert. Die Moderationsskills an sich sowie Facilitation-Methoden wie Open Space, Appreciative Inquiry, The Circle Way oder Dynamic Facilitation sind dem ScrumMaster ebenfalls bekannt. Darüber hinaus muss er einige Soft Skills besitzen, um in seiner Rolle wirksam zu werden. Die Haltung, andere Sichtweisen zu akzeptieren und hinzunehmen sowie Authentizität auszustrahlen und das Team begeisternd durch den Prozess zu führen, zählt ebenso dazu, wie die ständige eigene Weiterentwicklung.

Change Agent

Und schließlich ist der ScrumMaster ein Change Agent im Unternehmen. Er trägt den Change ins Unternehmen und sorgt für Verständnis auf Seiten der Organisation (z.B. auch beim Betriebsrat und HR). Die große Herausforderung, neben seinen bisher genannten Fähigkeiten, noch die Grundsätze und Modelle des Change-Management-Ansatzes zu verstehen und je nach Situation einordnen zu können, vollendet das Bild dieser komplexen und anspruchsvollen Rolle, die eine hohe Kompetenz und Flexibilität zur ständigen Weiterentwicklung abverlangt.
Auch wenn die Ansprüche an die Rolle des ScrumMasters in allen Facetten wohl unmöglich zu jedem Zeitpunkt ausgefüllt werden können, bringt dies zugleich die Herausforderung mit sich, ständig weiter an sich selbst zu arbeiten. Die unterschiedlichen Tools und Methoden sind ein Handwerk. Und ein Handwerk kann man bekanntlich lernen. Für mich heißt das ganz konkret, dass die Rolle des ScrumMasters nicht nur für die betreffende Person selbst, sondern für die Organisationen in ihrer Gesamtheit ein unglaubliches Entwicklungspotential bereithält.

Foto: CC0 Creative Commons – pixabay, ulleo

Skalierte agile Organisation: Das übergreifende Arbeitsmodell als Führungsinstrument

Im klassischen Führungsparadigma soll eine Führungskraft vermitteln, was wie zu tun ist, um ein definiertes Ziel zu erreichen. Damit verbunden ist die Kontrolle: Erledigen meine Mitarbeiter die vorgegebenen Aufgaben? Demgegenüber liegt dem agilen Führungsverständnis die Annahme zugrunde, dass sich die Organisation automatisch in die „richtige“ Richtung bewegen wird, wenn das Management durch den Sinn – die Vision, das „Warum“ – eine grobe Richtung vermittelt und die Rahmenbedingungen (die Constraints) vorgibt.
Obwohl die Forderung nach einer Vision banal klingt, haben Unternehmenslenker große Mühe, sich auf dieses neue Führungsverständnis einzulassen. Bereits die Definition einer Vision ist eine Herausforderung. Die Frage, weshalb das „Warum“ so wichtig ist (allen voran Simon Sinek) und wie eine Vision entsteht („Geheimnisse einer wirklich guten Vision“) wurde in den entsprechenden Diskussionen hinlänglich bearbeitet. Anders sieht es beim Setzen der Rahmenbedingungen aus: Wie gelingt es dem Management, einen Rahmen vorzugeben, innerhalb dessen die Organisation die Lieferfähigkeit erhöhen und gleichzeitig ein hohes Maß an Transparenz schaffen kann?
Die erste Hürde ist, sich von einem nach wie vor weit verbreiteten Irrglauben zu verabschieden: Agilität bedeutet nicht, Teams ohne Kontrolle und Vorgaben einfach machen zu lassen, in der Hoffnung, es werde schon etwas Gutes dabei herauskommen (Video: Agilität – das Managen von Unsicherheiten). Sicherlich gibt es hoch performante agile Teams, bei denen es genügt, eine Vision zu kommunizieren. Gerade beim Change in einer klassischen Organisation ist es jedoch umso wichtiger, neben einer griffigen Vision auch klare Rahmenbedingungen zu definieren. Demnach bedeutet Agilität nicht, die Freiheit zu haben alles zu tun, sondern vielmehr, die Freiheit zu haben, sich innerhalb der gesetzten Rahmenbedingungen in Bezug auf die Vision selbst zu organisieren.
Der Entwurf eines Arbeitsmodells ist ein bewährtes Mittel, um Teams in die Selbstorganisation zu führen.

Was ist ein Arbeitsmodell?

Ein Arbeitsmodell an sich ist nicht mehr als die Beschreibung der in einem Unternehmen gelebten Scrum-Rollen, -Meetings und -Artefakte. Scrum selbst gibt diese zwar vor, jedes Unternehmen lebt die Rollen, deren Skalierung, die Meetings und Artefakte allerdings anders. Meetings finden in unterschiedlichen Taktungen mit unterschiedlichen Teilnehmerkreisen und Formaten statt. Während in dem einen Unternehmen als Artefakt lediglich ein Taskboard existiert, schwören andere Unternehmen auf einen Releaseplan und ein übergreifendes Unternehmensbacklog, während andere pflichtbewusst alle Artefakte anwenden, die Scrum definiert.
Ein übergreifendes Arbeitsmodell ist die Sammlung und Konsolidierung der bestehenden Rollen, Meetings und Artefakte, um daraus Best Practices abzuleiten. Das Arbeitsmodell ist ein lebendes und somit lernendes Artefakt, das veränder- und anpassbar ist und auf neue Erkenntnisse im Sinne einer verbesserten Zusammenarbeit reagiert und diese abbildet.
Unsere Erfahrung ist, dass idealerweise ein Scrum-of-ScrumMaster die Verantwortung für die Erstellung des Arbeitsmodells übernimmt. Er erhält durch die Arbeitsmodelle der einzelnen Teams, die von seinen ScrumMastern erstellt werden, einen Einblick in die Arbeitsweise der Teams und ist somit in der Lage, daraus ein übergeordnetes Arbeitsmodell zu erstellen.

Wozu dient das Arbeitsmodell?

Das Arbeitsmodell unterstützt dabei, Transparenz, Einheitlichkeit und eine Meetingkultur zu schaffen sowie den Prozessframework kontinuierlich zu optimieren.

Gleichzeitig ist das Arbeitsmodell ein lebendes Dokument, das auf Veränderungen und neue Erkenntnisse in der Arbeitsorganisation reagieren kann und diese abbildet. Es dient den ScrumMastern zur Reflexion und ist somit selbst Gegenstand der kontinuierlichen Verbesserung.
Das Arbeitsmodell kann also zu einem wichtigen Instrument des Change werden, indem es Orientierung gibt und die übergreifende Zusammenarbeit der ScrumMaster fördert. Es bietet eine Alternative zu Hierarchien, da es dem Unternehmen eine Arbeitsorganisation auf Teamebene anbietet, die nicht auf der Ableitung von Führungsebenen beruht.
Im Idealfall erzeugt ein Arbeitsmodell einen Rhythmus, der das iterative Arbeiten unterstützt und eine Art Taktung für das Unternehmen erzeugt.

Foto: CC0 Creative Commons – pixabay, Michael Gaida

Die User Story als Einladung zu einer Diskussion

Viele meiner Kunden fragen, wie viele Anforderungen eine User Story beinhalten sollte und wo denn die „anderen“ Anforderungen abgespeichert werden sollen.
Diese Frage ist meiner Meinung nach ein Widerspruch in sich. Denn eine User Story besteht ja nicht nur aus dem berühmten Satz „Als <Rolle> möchte ich <Funktion>, um <Nutzen> zu haben“, sondern enthält einiges mehr an Informationen.
Zunächst mal: Was braucht man, um ein Produkt zu entwickeln? Natürlich das Wissen darüber, wie dieses Produkt am Ende aussehen soll. Was *braucht* der User? Was *will* der User? Was sind die Rahmenbedingungen (Budget/Ressourcen, Gesetze etc.)?
Um all diese Fragen zu beantworten, sollte also eine User Story diese Informationen beinhalten:

Wie umfassend soll diese „Dokumentation“ sein? Ich beobachte, wie lange mein Team beim Refinement darüber geredet hat – das ist mein Richtwert. Denn das ist genau das, was in diesem Meeting passieren soll: darüber reden. So lange bis jeder weiß, was diese Funktionalität können muss.
Jetzt werden viele sagen: „Wir arbeiten ja nur mit Kärtchen, da passt das alles nicht drauf.“ Das ist schon richtig. Es spricht allerdings nichts dagegen, zusätzlich zum Kärtchen auch andere Medien zu verwenden, die separat geführt werden. Ein Flipchart reicht oft völlig aus.
Wie sieht bei Ihnen eine User Story aus?

Scrum – eigentlich so einfach wie kochen

Einzelne Teams, inzwischen aber auch ganze Unternehmen stellen sich die Frage: Wie können wir uns angesichts sich ständig verändernder Marktbedingungen so aufstellen, dass wir unsere Anpassungsfähigkeit erhöhen und gleichzeitig schneller in der Umsetzung werden? Sicher: Auf diese Frage gibt es viele mögliche Antworten und ganz sicher gibt es nicht das eine Rezept. Eine Antwort ist, die Haltung und Methoden von Scrum für sich zu entdecken und anzuwenden.
Oft erleben wir viele Hemmungen, wenn Menschen zum ersten Mal von Scrum hören und es für sich und ihren Kontext anwenden sollen. Deshalb wollen wir das Thema einmal aus einer anderen Perspektive betrachten und es mit dem Kochen vergleichen. Stellt euch vor, ein Familienmitglied hat Geburtstag. Ihr wollt diesen Geburtstag bei euch Zuhause feiern und ein Festmahl zubereiten. So ähnlich ist es, wenn man den Scrum Flow für sich entdeckt und seinen Projekt-/Arbeitsalltag mit Leben füllt.

Mit Offenheit kocht es sich leichter

Eine wichtige Voraussetzung ist aus unserer Sicht die Haltung, beispielsweise die Offenheit für Experimente. Bezogen auf unser Menü bedeutet das, nicht zu lange zu überlegen, sondern bereit zu sein, einfach loszulegen. Sich darauf einzulassen, dass das Menü während des Kochens weiter Form annimmt. Natürlich kann man beliebig viel Zeit investieren, ein besonders kreatives Menü zusammenzustellen, doch lasst uns einfach mal damit beginnen!
Auf den Kontext der Organisation übertragen, bedeutet das eine neue Haltung in der Führung: sich beispielsweise gemeinsam mit den Mitköchen zu überlegen, was traue ich mir und meinen Mitköchen zu, die Aufgaben aufzuteilen und dann loszulassen. Es bedeutet, in die Selbstorganisationsfähigkeit des Teams zu vertrauen, in die Kollaboration über horizontale und vertikale Grenzen hinweg, damit das Essen gemeinsam gelingt. Welche Zutaten tragen wesentlich zum Gelingen bei?

Die Vision: Pasta oder Schweinshaxe?

Um den Geburtstag gebührend zu feiern, wollen wir unsere liebe Familie und die Freunde bekochen. Natürlich soll es etwas Besonderes geben. Wir haben es geradezu vor Augen: Das größte Festmahl aller Zeiten soll es werden! Ein rauschendes Fest, wie es die Welt noch nicht gesehen hat. Mit einem Leuchten in den Augen erzählen wir bei der Einladung von unserem Plan und sehen, wie geradezu der Funke überspringt. Alle freuen sich auf das anstehende Fest und bieten ihre Unterstützung an. Im Scrum-Kontext ist es der Product Owner, der diese Vision in ein Produkt verwandelt und emotional kommuniziert und dadurch das Team motiviert, voller Energie an der Umsetzung mitzuwirken.

Die Constraints: der Blick in den Kühlschrank

Wir stehen also in der Küche und haben die Vision eines opulenten Festmahls vor Augen. Ein Blick in den Kühlschrank holt uns zurück auf den Boden der Tatsachen. Er ist ziemlich leer. Es ist Monatsende und das Konto zeigt überdeutlich, dass ein Großeinkauf heute nicht mehr drin ist. Es gibt aber noch ein paar Dosen geschälte Tomaten und in der Vorratskammer findet sich eine Packung Nudeln. Etwas Knoblauch ist auch noch da, frische Chili-Schoten und Olivenöl. Leider ist der Backofen seit Wochen defekt, aber immerhin funktionieren die Herdplatten, im Schrank finden sich ein Topf und eine Pfanne. Mit diesen Rahmenbedingungen lässt sich zwar kein 10-Gänge-Menü zaubern, für eine große Portion Penne Arrabbiata dürfte es aber reichen. Zusammen mit der letzten Flasche von dem guten Rotwein ergibt es das bestmöglichste Gericht.
So ambitioniert eine Vision auch sein mag, kein Produkt und kein noch so leckeres Gericht ist frei von Einschränkungen und Rahmenbedingungen, eben den sogenannten „Constraints“. Im Kontext einer Produktentwicklung geben diese Rahmenbedingungen vor, wie die Vision umgesetzt werden kann. Wie groß ist das Budget? Wie viele Mitarbeiter können an einem Projekt arbeiten? Welche gesetzlichen Vorschriften müssen eingehalten werden? Was ist technisch überhaupt machbar?

Die Rollen: Verantwortung teilen – kochen im Team

Wie auch im Scrum Flow gibt es beim gemeinsamen Kochen zugewiesene Rollen. Diese Rollen sind klar voneinander abgegrenzt: Jeder der mitkocht, übernimmt eine bestimmte Arbeit. Im Scrum Flow gibt es die drei Kernrollen Scrum Master, Product Owner und Entwicklungsteam. In drei weiteren Rollen kommen noch Kunde, User und Management ins Spiel. Auch hier sind die Rollen klar voneinander abgegrenzt: Der Product Owner weiß genau, was er oder sie am Schluss vor sich stehen haben möchte. Er organisiert das Menü und ist dafür verantwortlich, dass jeder Koch im Team die benötigten Fähigkeiten hat, um das beste Menü auf den Tisch zu zaubern. Seine „Vision“ gibt er an die Mitköche weiter, die das Entwicklungsteam bilden. Sie kochen das Menü „tatsächlich“ und bringen es in eine Form. Ohne sie würde der Product Owner das Gericht nicht rechtzeitig zur Feier fertigbekommen.
Die Rolle des Scrum Masters kann in der Küche mit jemandem verglichen werden, der sich darum kümmert, dass jeder die Zutaten hat, um seine Arbeit schnellstmöglich auszuführen. Der Scrum Master sorgt auch dafür, dass das Team ohne Probleme und Einschränkungen kochen kann, indem zum Beispiel Geschirr abgewaschen oder Abfälle entsorgt werden. Um den Scrum Flow zu vollenden, benötigen wir noch Kunde, User und Management. Im unserem Fall ist das Geburtstagskind Kunde und User. Es gibt im Vorfeld an, welche Wünsche es hat (oder das Kochteam weiß das aus vergangenen Beobachtungen), und genießt das Mahl im Anschluss an die Zubereitung. Der Manager finanziert das Geburtstagsessen, er hat nichts mit der Küche und dem Kochen zu tun. In unserem Fall könnte das der Vater des Geburtstagskindes sein.

Kochen und abschmecken: Selbstreflexion und Feedback-Loops

Lasst uns nun kochen. Um das Rezept bestmöglich umzusetzen, bietet sich ein gewisses Vorgehen an. Die taktische Ebene des Scrum Flow umfasst alle Meetings und ist mit den Anleitungen in einem Rezept vergleichbar. In diesen Anleitungen steht genau beschrieben, welche Schritte und welche Zutaten wann eingesetzt werden.
Starten wir mit dem Sprint Planning 1: In diesem Meeting überlegen wir uns, was das Festmahl beinhalten soll. Eventuell möchten wir mehrere Gänge zubereiten und entscheiden uns dafür, dass Kartoffelsuppe das Beste für den ersten Gang sei. Nachdem alle zugestimmt haben, überlegen wir uns, wie wir unseren ersten Gang umsetzen werden – vergleichbar mit dem Sprint Planning 2. Jeder Koch hat seine Aufgabe zugeteilt bekommen: Der eine wäscht die Kartoffeln, der andere schält die Kartoffeln, der Dritte schneidet sie klein und so weiter.
Nun ist das Vorgehen klar und alle Köche kommen ins Tun. Während der Zubereitung kann es Rücksprachen geben – im Scrum Flow spiegelt sich das in den Dailys wider. In diesem täglichen, rund 15 Minuten dauernden Standup-Meeting halten alle Köche kurze Rücksprachen zu den einzelnen Aufgaben. Ist die Suppe fertig, wird der Product Owner in die Küche gerufen, um zu probieren. Gefällt ihm die Kartoffelsuppe, wird sie an den Tisch gebracht und kann vom Geburtstagskind und den Gästen probiert und bewertet werden. Sind die Gäste und vor allem das Geburtstagskind zufrieden, hat die Kartoffelsuppe bestanden. Sollte es jemandem nicht schmecken, wird zum Beispiel mit weiteren Gewürzen nachgebessert – das geschieht im Rahmen des Scrum Flow mit Produkten nach dem Review. Nachdem die Kartoffelsuppe von den Genießern „abgenommen“ wurde, trifft sich das Team in der Küche und reflektiert die Zusammenarbeit, wie in einer Retrospektive.
Die Prinzipien und Vorgehensweisen von Scrum sind also eigentlich nichts Neues – sie werden in anderen Kontexten täglich praktiziert. Was vielleicht ungewohnt ist, ist die Anwendung dieser Prinzipien auf die Wissensarbeit. Fangen Sie doch einfach genau so an, wie wir es hier beschrieben haben: Legen Sie einfach los, machen Sie sich den Spaß und bereiten Sie mit Freunden ein Essen nach dem Ablauf des Scrum Flow zu. Guten Appetit!

Diesen Artikel haben Mara Ambs, Michael Gissler und Miruna Sachse im Mob-Writing gemeinsam verfasst.

ScrumMaster: Schaff wieder Raum für Begeisterung!

Vor Kurzem habe ich im Rahmen eines Trainings zu Selbstorganisation und Führung das folgende, kurze Video von Gerald Hüther gezeigt: “Wie Lernen am besten gelingt”.  [Bitte zuerst das Video ansehen, dann weiterlesen].
Was Hüther beschreibt und was bei Kindern beobachtbar ist, entspricht in etwa dem Zugang, den jene dynamischen, erfolgreichen Scrum Teams hatten und haben, die ich kenne. Sie sind mit Neugierde an das Scrum Framework herangegangen, haben ausprobiert, damit freudig gespielt und gelernt. Sie haben Erfahrungen gesammelt und sie haben gelernt. Es ist diese Perspektive „Die Welt ist voller Möglichkeiten für mich – es gibt viel zu entdecken“, die diesen Teams zu eigen war. Eine der grundlegenden Motivationen in der Entstehung der agilen Bewegung war: wieder Freude an dem zu empfinden, was man macht – gemeinsam mit den Menschen, mit denen man arbeitet. Jeff Sutherland rät deswegen nicht ohne Grund: „Macht Scrum mit Teams, die Scrum machen wollen.“
Aus der agilen Bewegung, die Ende der 1990er und Anfang 2000er Fahrt aufgenommen hat, ist inzwischen aber sowas wie „Corporate Agile“ geworden. Vor allem die letzten drei Jahre haben die Bewegung nachhaltig verändert – sie wurde in die Industrie inkorporiert. Damit geht einher, dass mitunter, vielleicht sogar sehr oft, Teams zur zielgerichteten Selbstorganisation verpflichtet werden. Kurzer Reality-Check: Bitte schau Dir jetzt das Video von Gerald Hüther nochmal an.
Selten befinden sich Teams in diesem „Flow“. Macht nichts. Ist halt gerade nicht der Fall. Aber vielleicht möchtest du das wieder erleben und mit deinem Team, deinen KollegInnen und MitarbeiterInnen zurück in den Flow? Vielleicht weil ihr gerade eine Restrukturierung, eine Transition to Agile oder Ähnliches durchlebt? Dann lade ich dich auf eine Entdeckungsreise ein.

Wie du den Flow zurückholst

Zuallererst nimm einen Stift und Papier zur Hand und reise gedanklich durch dein Leben – zu jenen Momenten, in denen du genau dieses Gefühl und diese Neugier gespürt hast. Wo und wann hast du dich im Privaten und/oder im Beruf schon mal so gefühlt? Verweile kurz in Gedanken dort und hole dir dieses Gefühl bewusst ins Gedächtnis. Schreibe ein Stichwort auf und reise weiter. Wenn du einen zweiten solchen (oder auch mehrere findest), notiere auch diese. Verbinde die Worte miteinander, so entsteht eine Stationenkarte deiner besonderen Momente. Mein inneres Bild dazu:

Für mich heißt das: Ich habe zumindest drei Referenzpunkte in meinem Leben, die ich nachfühlen kann. Und an diese Orte meiner Geschichte reise ich, wenn ich mich darauf vorbereite, mit meinem Team oder Kunden etwas Neues anzugehen.
Nimm dir ein paar Minuten Zeit, deine besonderen Momente der Neugier und der kompletten Potentialorientierung aufzuspüren, aufzuschreiben und miteinander zu verbinden.
Gratuliere! Präge dir die Stationen und Gefühle gut ein, das ist dein Wegweiser zum Flow. Vielleicht ist dir ja das eine oder andere aufgefallen, das dir auf deiner Reise dieses Gefühl des Flow gegeben hat.

Bist du begeistert genug, um zu führen?

Bevor Du nun zu Deinem Team zurückgehst, prüfe dich. Bist du bereit, dein Team zu führen? Trägst du die Begeisterung, die du bei deinen KollegInnen sehen möchtest, in dir? Wenn nicht, dann reise zu den Stationen, wo du schon mal begeistert warst und gelernt hast. Frage dich: „Was möchte ich heute in der Zusammenarbeit mit meinem Team lernen? Was könnte für mich drin sein?“
„Mache Scrum mit Teams, die Scrum machen möchten“ bedeutet auch und vor allem: Mache Scrum mit deinem Team, wenn du selbst es erleben und agil arbeiten möchtest (nicht nur anleiten und vermitteln). Als ScrumMaster bist du Teil des Scrum-Teams. Deine Rolle ist halt eine, die auch Methodisches vermittelt. Vorrangig bist du aber ein Teammitglied auf einer gemeinsamen Erkundungsreise mit deinen Teammates.
Eine Kundin, Kommunikations- und Change-Expertin aus der Strategieabteilung einer Konzern-IT, hat vor einigen Jahren im Zuge der Einführung von Agilität nach wenigen Wochen Zusammenarbeit das vielleicht aufschlussreichste Statement gemacht: „Agile kann man nicht managen, das muss man (er)leben.“
Dem habe ich nichts hinzuzufügen. Verwalte als ScrumMaster nicht die Agilität, sondern bleib dabei, sie zu leben und mit deinen Teammates jeden Tag aufs Neue zu erkunden. Bleib neugierig. Auch wenn es bedeutet, mal die Regeln zu verletzen und Scrum oder andere agile Frameworks nicht „richtig“ zu machen.
Und wenn du dich mit deiner Rolle und Aufgabenstellung in „Corporate Agile“ gefangen fühlst, dann bring wieder Bewegung rein. Mach es für dich und dein Team wieder zur agilen Bewegung. Und Bewegung heißt ja: sich bewegen. Ganz nach diesem Motto wünsche ich dir viel Freude, Neugier und Begeisterung in der lateralen (Aus-)Führung. Eine Inspiration, wie es zurück in die Bewegung gehen kann, bietet dieses Video.

Die Retrospektive: Maßnahmen einfach tracken

Donnerstagnachmittag, Retrospektive bei einem Automotive-Kunden. Der Gong schlägt, die Timebox ist vorbei. Ich blicke überrascht auf die Resultate: Viele Vorschläge, aber keine wirklich konkrete Maßnahme. Vor allem keine, die man in einem Sprint umsetzen könnte.
Was nun? Klassische Frage: Halte ich die Timebox? Nach dem Prinzip: „Schade, schön wäre es gewesen. Learning fürs nächste Mal.“ Oder fokussiere ich mich auf den Zweck des Meetings: Wir wollen unseren Prozess verbessern. Ich entscheide mich für den Zweck und gebe uns noch einmal 10 Minuten.
10 Minuten später.
Nachdem wir kurz in eine offene Diskussion zurückgefallen sind, haben wir zwei konkrete Maßnahmen abgeleitet. Ich lasse das Meeting abschließend bewerten und beende es. So weit so gut, das Meeting war erfolgreich. Wie geht es nun weiter?

Leichen vergraben?

Ich habe mir vorgenommen, alles gut zu dokumentieren. Auch wenn das Fotoprotokoll wahrscheinlich eine Leiche im SharePoint bleibt. Was mich eher beschäftigt ist: „Was waren eigentlich die Maßnahmen der Retrospektive einen Sprint zuvor?“ Ich kann mich nicht daran erinnern und noch schlimmer, eine Abfrage hat es auch nicht gegeben. Das muss besser werden, denke ich mir. Diesmal tracke ich die Maßnahmen effektiv.

Noch ein Board?

Ich dachte erst an Continuous Improvement Board (CIB). Klasse Idee, oder? Ich verhandle mit mir selbst: „Viel Platz für viele Maßnahmen. Werden die auch alle umgesetzt in einem Sprint? Naja vielleicht brauchen sie ja mehrere Sprints. Aber dann sind die Maßnahmen einfach nicht konkret genug. Ein weiteres Problem beim CIB: Es ist ein weiteres Artefakt. Ich hänge es gleich neben die wenig beachtete Definition of Ready und die kaum benutzte „Waste-Wall“.

Oder einfach nur ein Task?

Die besten Lösungen sind die einfachsten. In einem früheren Team hatte ich am Taskboard eine eigene Swimlane mit dem Namen „Kaizen“. Das war gut, aber ich suche die Herausforderung: Geht es noch einfacher? Ohne Verlust von Effektivität? Ich entscheide mich dafür, Tasks zu erstellen. Simpel, nachvollziehbar und transparent. Weiterer Vorteil: Die Maßnahmen werden nun täglich im Daily mitverfolgt, und zwar instinktiv.
Mein Learning: Die einfache Lösung ist oft weniger intuitiv, aber durchdachter als die komplexe.

Never give up your own claim!

Viele ScrumMaster sind satt. Sie bauen die schönsten Taskboards und halten die tollsten Meetings. Sie zeichnen die schönsten Definitions of Done und Happiness-Metriken. Sie bringen Kekse zum Meeting mit.
Aber ihre Teams liefern nicht.
Genau das ist das Problem: Wir halten uns ewig mit den richtigen Methoden auf. Wir quetschen alle Retromaten der Welt aus, um unseren Teams Scrum als Leckerli mit Zuckerguss präsentieren zu können. Vielleicht, um uns auch ein bisschen selbst zu verwirklichen. Doch wenn Teams nicht den Spirit leben, wenn Artefakte und „Make things visible“ nur zu Deko werden, wird der agile Grundgedanke verfehlt.
In Scrum geht es am Ende immer ums Liefern, nicht zwangsweise darum, dabei schön auszusehen.
Was bringt Ihrem Unternehmen auf lange Sicht mehr: Ein schöner Teamraum, wo alles ordentlich ist, oder ein ScrumMaster, der mutig und schonungslos alles transparent macht, was sein Team behindert? Nach einem anfänglichen Tal der Tränen sind viele ScrumMaster satt. Sie werden ruhiger und kämpfen nicht mehr für ihr Team. Das Impediment kann auch noch morgen gelöst werden. Den Workshop kann ich auch noch nächste Woche halten. Nein! Es geht darum, alles für sein Team zu geben.
Teams müssen liefern.
Das, und nur das ist die Aufgabe des ScrumMasters. Es ist eine verdammt schwere und unangenehme. Ein ScrumMaster ist dabei so etwas wie der beste Freund. Er hört zu, er lacht mit, er leitet dich in schwierigen Situationen, aber haut auch auf den Tisch und scheut nicht vor klarem Feedback zurück. Dafür gibt es vor allem die Retro oder das Review, aber auch One-on-One-Gespräche. Er kümmert sich um seine Mannschaft. Er kümmert sich um das agile Management.
Als ScrumMaster sollte man immer wieder überprüfen, wie man sich weiterentwickeln kann. Das ist eine Auswahl an Fragen, die mir geholfen haben, mich als ScrumMaster weiterzuentwickeln:

Vielleicht helfen diese Fragen dabei, den Spirit (wieder) zu finden, den die Arbeit als „Schäferhund“ ausmacht. Er ist bissiger und fürsorglicher zugleich.

Wie man als ScrumMaster besser mit Widersprüchen umgehen kann

 
Wer sagt, die Anforderungen an den ScrumMaster seien vielfältig, sagt zwar nichts Neues, aber es stimmt natürlich. Ich sehe es als ScrumMaster an mir selbst jeden Tag beim Bestreben, Teams produktiver zu machen. Angesichts der vielen Herausforderungen, die einen manchmal zur Verzweiflung treiben, stelle ich mir dann die Frage: Wie kann ich besser damit umgehen?
Uns ScrumMastern begegnet häufig noch eine sehr mechanistische Weltsicht, die versucht, jedes einzelne Detail zu verstehen und dadurch alles widerspruchsfrei zu erklären: Führungskräfte und Product Owner wehren sich reflexartig gegen die User Story „als eine Einladung zur Konversation“, da sie nicht so detailliert wie die alten Lastenhefte ist und Informationen verloren gehen könnten. Prozesse sind heilig und müssen eingehalten werden – dass ein Produkt deshalb sechs Wochen später live geht, interessiert nicht. Dailys werden zu Kontrolltribunalen des Managements, das Team soll Rechenschaft ablegen.
Wenn ein ScrumMaster immer wieder gegen solche Windmühlen kämpft, kann man es ihm manchmal nicht verübeln, dass er das Handtuch werfen und „Macht doch, was ihr wollt!“ rufen will. Dabei ist es doch seine Aufgabe, mit Komplexität umgehen zu können. Mit Widersprüchen leben zu können, die auftreten, wenn eine Organisation sich gerade transformiert – was Jahre dauern kann.

Nimm’s leicht mit der systemischen Sicht

Um manches für sich zu klären und innere Ruhe finden zu können, kann dem ScrumMaster ein anderer Blick auf das Unternehmen helfen: Er kann damit beginnen, Unternehmen als soziale Systeme zu begreifen. Das bedeutet, dass Unternehmen ein Konstrukt aus Individuen und verschiedenen Teilsystemen sind. Warum besteht ein System überhaupt? Sein Sinn ergibt sich immer aus der nächsthöheren Ebene, in dem System, das es umschließt. So wie sich der Sinn eines Lenkrads immer nur im Kontext des Autos erschließt. Diese Individuen und Teilsysteme wirken nicht kausal aufeinander: Ich kann ein privates Unglück erleiden, wirke aber total ausgeglichen, weil ich beruflich aufblühe und erfolgreich bin. Der umgekehrte Fall ist genauso denkbar. Jeder Mensch lebt in unterschiedlichen Systemen: Als Elternteil, Fachexperte, Visionär, Marathonläufer… Die unterschiedlichen Wechselwirkungen lassen sich dabei nicht immer aufdröseln. Russell Ackoff – einer der einflussreichsten Systemtheoretiker – hat dieses Denken in Systemen und die Operations Research als Grundlagen der heutigen Organisationstheorie etabliert. Seine wesentlichen Grundgedanken fasst er leicht verständlich noch einmal in dieser Rede zusammen.
Die systemische Sicht hilft, Widersprüche als Normalität anzunehmen. Es ist zum Beispiel nicht immer erklärbar, warum auf einmal ein Teammitglied nicht mehr zum Daily kommt. Sieht das Teammitglied andere Arbeit gerade als relevanter an? Zieht die Führungskraft das Teammitglied zurück in die Linie? Gab es einen familiären Zwischenfall? Am Ende können viele Gründe zutreffen, die sich nicht immer aufschlüsseln lassen und sich nicht immer von einem ScrumMaster auflösen lassen müssen.
Welche Implikationen lässt das zu?

Ja, unser Unternehmen ist komplex

Lösen wir uns von der Vorstellung, dass Systeme wie Maschinen funktionieren: Ich lasse das Fließband schneller laufen, sie werden es schon schaffen. Ich sage „mach das“, und der Mitarbeiter tut es. Diese Haltung funktioniert immer seltener. Damit werden wir im Wissenszeitalter nicht wettbewerbsfähiger.

Der systemische Ansatz führt aus der Hilflosigkeit der mechanistischen Welt und schafft eine Erleichterung, wenn es darum geht, Organisationen zu verändern. Das kann gerade für das Management sehr beruhigend wirken. Mit diesem Ansatz kann ein ScrumMaster die Organisation der Zukunft gestalten. Denn das ist seine Vision: Er ist ein Change Agent, der Unternehmen in turbulenten Zeiten den Weg weist.
Die Antwort auf die Frage „Wie kann ich besser mit dieser Komplexität umgehen?“ ist damit nicht einfach, aber kann uns doch in einer gewissen Weise Orientierung geben: Wir werden unsere Arbeitsrealität nicht einfacher gestalten können. Doch wir können lernen, zu akzeptieren, dass es Mehrdeutigkeit gibt und diese sich auch nicht wegrationalisieren lässt. Der Kunde wünscht sich Sicherheit in dieser Welt. Was können wir ihm sagen? Statt alles erklären zu wollen, sollten wir offen dafür sein, genau diesen Drang zu verlernen.
 

Wer committet sich in Scrum eigentlich?

 
Das Entwicklungsteam committet sich für den nächsten Sprint. Generationen von ScrumMastern sind mit dieser Vorstellung groß geworden. Immer und immer liest man das in Büchern. Stopp, Moment. Nur das Entwicklungsteam? Wenn man das so handhabt, bringt man Scrum um eines seiner wichtigsten Prinzipien, die das Framework letztlich so verlässlich machen: die Verantwortung. Ohne Verantwortung kann man Scrum auf dem Papier machen, doch es wird nicht geliefert.
Wenn das Team nicht die Verantwortung für professionelles Entwickeln übernimmt, gibt es keine erfolgreiche Lieferung. Wenn der Product Owner keine Zusage gibt, dem Team immer fachlich zur Seite zu stehen, wird das Produkt nicht annähernd einen so hohen Return on Investment (ROI) für das Unternehmen bringen, wie es könnte.
Genauso viel Einfluss hat das Commitment des ScrumMasters. Der Glaube “Ich unterstütze das Entwicklungsteam bei seinem Commitment” birgt einen Trugschluss in sich, der die Lieferung und ihre Qualität entscheidend beeinflussen kann. Als ScrumMaster ist meine Arbeit mit dem Commitment nicht getan. Alle haben sich geeinigt, sie wissen, worum es geht. Nein, im Gegenteil: Gerade jetzt schaue ich besonders darauf, dass ich meinen Job voll und ganz übernehme; ich werde alle Hindernisse aus dem Weg räumen, die Entwickler oder den Product Owner daran hindern, effektiv zu arbeiten. Ich werde alles dafür tun, dass UNSER Commitment eingehalten wird. Dass der Product Owner verfügbar ist. Dass er Fragen beantwortet. Dass er im Review anwesend ist und weiß, welche Features als nächste umgesetzt werden sollen. Dass das Entwicklungsteam ungestört arbeiten und alle Features umsetzen kann. Dass alle notwendigen Informationen zwischen den richtigen Teammitgliedern ungehindert fließen, Missverständnisse ausgeräumt werden und Disziplin in der Arbeitsweise eingehalten wird.
Als ScrumMaster schütze ich das Team – das gesamte Team. Ich bin so für das Team da, wie es mich gerade braucht. Als bester Freund, als Führungskraft, als guter Hirte im Tal der Tränen, als Provokateur, wenn etwas zu selbstverständlich aussieht. Eben das, was es braucht, damit wir das schaffen, wofür wir alle zuständig sind: die Lieferung. Die Produktivität ist die Aufgabe des ScrumMasters. Die Produktivität des ganzen Teams. Denn vom ihm hängt die Lieferung ab. Wenn wir nicht alle Hand in Hand arbeiten, ist unser Ziel gefährdet. Nicht die Entwickler sagen, dass sie das Sprintziel umsetzen können. Jeder im Team tut es.
Aber wie führe ich als ScrumMaster? Es ist meine Verantwortung, dem Team einen Weg zu zeigen. Ja, es ist mein Ziel als ScrumMaster, Teams auf dem Weg zur Selbstorganisation zu unterstützen, wenn sie noch nicht so weit sind. Es ist meine Aufgabe, ihnen das Wichtigste zuerst beizubringen: pünktlich sein, zielorientiert liefern, sich selbst und die Gruppe managen können, kurz: die agilen Werte zu verankern.
Die Verantwortung des ScrumMasters ist eine Führung im Spannungsfeld:
Ich schreibe keine Aufgaben vor, aber setze Regeln.
Ich werde keine Anweisungen geben, aber immer wieder unbequem sein.
Ich bin Teil des Teams und verantworte seine Produktivität – nicht durch Command und Control, sondern durch den Umgang auf Augenhöhe. Das heißt auch für mich: ein Commitment geben. Für jede Minute des Sprints.
 

ScrumMaster: Wie setze ich ein gutes Scrum-Team auf?


Derzeit arbeite ich als Agile Coach und unterstütze meinen Kunden in der täglichen Arbeit mit Scrum, d.h.: Rollencoaching der ScrumMaster und Product Owner, Ausbildung der internen agile Coaches und Durchführung eines Intensivcoachingprogramms für neu startende Scrum-Teams. Ähnlich wie in dem Comic oben kommen bei meinen neuen ScrumMastern zwei Fragen auf:

  1. Was mache ich jetzt als ScrumMaster?
  2. Wie setze ich mein Team auf?

Auf die erste Frage möchte ich nur kurz eingehen, denn was ein ScrumMaster machen sollte, ist euch wahrscheinlich hinlänglich bekannt und wird in anderen Quellen ausgiebig behandelt: Der ScrumMaster ist verantwortlich für den reibungslosen organisatorischen Ablauf inner- und außerhalb seines Scrum-Teams. Er löst Impediments und agiert als Coach für seinen Product Owner und sein Development-Team. Zu guter Letzt arbeitet er als Change Agent mit anderen ScrumMastern in seiner Organisation daran, diese bei der Transformation zu einer agilen Organisation zu unterstützen.
Mehr Informationen zu den Aufgaben eines ScrumMasters findest du in diesem Blogbeitrag und Video von Boris Gloger oder in der 5. Auflage von Scrum – Produkte zuverlässig und schnell entwickeln.
Hier und heute ist mir die Antwort auf die zweite Frage besonders wichtig.

Das Team aufsetzen

Idealerweise ist das Scrum-Team crossfunktional aufgesetzt und besteht aus T-Shaped Professionals. Dabei bedeutet Crossfunktionalität, dass ein Team alle Skills besitzt, die es zur Produktentwicklung und –umsetzung benötigt. Ein crossfunktionales Team kann beispielsweise aus zwei bis drei Entwicklern, einem Tester und einem Testautomatisierer, einem Architekten und einem UX-Designer bestehen. Somit sind die Voraussetzungen für eine End-to-End-Entwicklung des Produkts im Team geschaffen.
T-Shaped Professionals besitzen tiefergehende Fähigkeiten in einer Disziplin und sind gleichzeitig in der Lage, sich aus angrenzenden Tätigkeitsbereichen Wissen anzueignen und innerhalb des Teams anzuwenden. Beispielsweise kann ein Tester nicht nur Testfälle schreiben und testen, er versteht auch einfache Codestellen der Entwickler und kann so simple Codefragmente selbst schreiben. Ebenso verhält es sich mit dem Architekten. Die Vision jedes Scrum-Teams sollte es sein, so viel Wissen wie möglich auf die einzelnen Köpfe zu verteilen. In absehbarer Zeit kann beispielsweise die Entwicklung der Architektur vom Dev-Team übernommen und  vorangetrieben werden.
Ein Team sollte nicht mehr als 7 bis 9 Mitglieder haben. Ist das Team größer, sollte man das Team wenn möglich (sinnvoll) teilen.

Und in der Unternehmenspraxis?

In den meisten Unternehmen, die mit Scrum starten, ist es nicht möglich, die ersten Scrum-Teams von Anfang an crossfunktional und t-shaped aufzusetzen. Das liegt meistens daran, dass einerseits die Mitarbeiter in mehreren Projekten gleichzeitig eingesetzt sind und ihnen die Zeit fehlt, sich bewusst und engagiert im Team einzubringen. Andererseits wird erst mit der Einführung von Scrum aufgedeckt, welche Skillprofile das Unternehmen wirklich braucht. Meistens müssen die passenden Mitarbeiter erst am Markt gefunden werden. Scrum startet allerdings nur selten auf der grünen Wiese. Daher sollte man zunächst einmal mit den vorhandenen Ressourcen und gegebenen Constraints arbeiten. Das Management sollte von Anfang an einbezogen werden, etwa in kurzen Meetings, in denen der ScrumMaster immer wieder die beschriebenen Impediments transparent aufzeigt. Mit der notwendigen Portion Geduld wird sich stückweise etwas ändern und das Team wird sich zu einem High-Performance-Team entwickeln. Immer wieder werden faule Kompromisse eingegangen, zum Beispiel wird ein Tester für drei Scrum-Teams eingesetzt. Für die fokussierte Arbeit in einem Team ist das nicht förderlich, trotzdem ist es gängige Praxis. Auch hier gilt wieder: Das Management einbinden und gemeinsam nach Lösungen suchen.
Hat eine Organisation einen höheren agilen Reifegrad erreicht, startet ein erfahrener ScrumMaster erst dann mit seinem Team, wenn ein Großteil der Mitglieder mindestens zu 60-70 % für das Scrum-Team verfügbar ist. Außerdem wird er darauf achten, so bald wie möglich einen Tester zu 100 % im Team zu integrieren. Innerhalb des Scrum-Teams fördert er den Wissenstransfer, damit auf eine End-to-End-Entwicklung hingearbeitet wird. Entweder braucht das Scrum-Team im Idealfall keinen eigenen Architekten mehr oder das Dev-Team ist in der Lage, mit dem Architekten gemeinsam die Softwarearchitektur weiterzuentwickeln.
Ein weiteres gängiges Modell aus der Praxis sind verteilte Teams. Die Teammitglieder befinden sich nicht an einem, sondern an mehreren Standorten. Manche Unternehmen sind in dieser Situation besonders kreativ, wie ein Beispiel aus meiner eigenen Erfahrung zeigt:

Es ist möglich, auch als verteiltes Team gute Ergebnisse zu erzielen. Dazu braucht es einen ScrumMaster, der vor allem in der Anfangsphase darauf achtet, dass das Team mindestens 3 Tage pro Woche gemeinsam vor Ort verbringt und entwickelt. Nur so können sich die Teammitglieder gegenseitig kennenlernen und ein Wir-Gefühl entwickeln. Die Sprintwechsel werden selbstverständlich auch gemeinsam durchgeführt. Hierbei empfehle ich, den Sprintwechsel auf zwei Tage zu legen. Am ersten Tag Anreise, Review und Retro, abends kann das Sprintende mit allen gefeiert werden. Am nächsten Tag finden im Laufe des Vormittages Sprint Planning I & II statt. Anschließend kann das Team gemeinsam starten, bevor sich alle wieder auf den Weg nach Hause machen. Bei einem Kunden beispielsweise legten die auf vier Standorte verteilten Teammitglieder in Summe 600 km pro Woche zurück, um die Meetings und den Sprintwechsel gemeinsam an einem Ort durchzuführen.

 
Wende dich als ScrumMaster beim Aufsetzen deines Teams beispielsweise an den unternehmenseigenen Agile Coach oder an andere ScrumMaster und bitte das Management sowie HR um Unterstützung. Oder wende dich an uns 🙂
 

Video: Der ScrumMaster II

Warum heißt der ScrumMaster eigentlich ScrumMaster? Ich habe dafür eine Erklärung mit einem Augenzwinkern und erkläre in diesem Video: Was macht den erfolgreichen ScrumMaster aus? Dass er die Regeln befolgt, die er in Scrum-Büchern findet? Oder dass er lange darüber nachdenkt, ob das Taskboard richtig aufgesetzt ist? Macht es ihn erfolgreich, dass er Scrum studiert hat, also ein Certified ScrumMaster ist, oder weil er unheimlich gut über Scrum reden kann?
In diesem Video findet ihr meine ganz persönlichen Antworten auf diese Fragen.
Viel Spaß beim Schauen – Boris

Übrigens: Ich bin gerade in Rio de Janeiro und mache das Studium zum GEMBA (Global Executive MBA) – bin dann also auch bald was 😃

Video: Der ScrumMaster

Der ScrumMaster ist eine Management-Rolle. Sie oder er hat eine Vielzahl von Funktionen zu erfüllen, um ein Scrum-Team produktiv zu machen. Aus meiner Sicht war der ScrumMaster die erste Verkörperung der modernen lateralen Führungskraft: Er war der erste agile Manager. Seine Aufgabe ist extrem wichtig und jedes Scrum-Team braucht diese Führungskraft. Woher der ScrumMaster kommt, ob er aus den Reihen des Entwicklungsteams stammt, ob er oder sie aus der Fachabteilung gestellt wird, ob es – wie bei unseren Implementierung – oft der externe Consultant ist, ist unerheblich. Wichtig ist, dass er die Verantwortung für das Gelingen der Arbeit des Teams übernimmt. Er macht Scrum-Teams erfolgreich.
In diesem Video erzähle ich euch mehr über meine Auffassung zur Rolle des ScrumMasters.
Viel Freude beim Anschauen! — Boris

The ScrumMaster's 6 duties in self-organisation

“The ScrumMaster role cannot fill a person’s working day!” Most managers and even most ScrumMasters believe this is true. However, it’s not even near the truth. The ScrumMaster has a very hard job to do. In my ScrumMaster Advanced Pro training I use Dieter Rösner’s framework “The glorious six of self-organisation” (see his postings on this blog here) to highlight and explain all the duties. In short, self-organisation is framed and supported by six elements which lateral leadership roles should take into account when doing their job: the common problem, structure, voluntariness, synchronisation, know-how and development.
boris_6
So let´s have a look at the ScrumMaster’s job from the position of Dieter’s framework:

  1. Leadership/common problem: A ScrumMaster leads people. He is not a “boss” or a “manager in a traditional sense, nevertheless he leads his people and gives them orientation by helping them to see the “the common or mutual problem”. Every organisation – and a team is an organisation – derives its purpose from the problem it is trying to solve. It´s the job of the ScrumMaster to make sure that there is a problem addressed and that he has established a team that wants to solve this problem. Usually, the problem is defined by the Product Owner but the ScrumMaster makes sure that everyone moves in that direction. In this regard, the ScrumMaster is a leader or shows leadership.
    a. His task is to lead people,
    b. therefore he has the responsibility to do so, and
    c. he needs to gain the skills to do so.
  2. Facilitation/structure: Dieter mentioned that self-organisation needs boundaries (structure). Scrum demands a certain structure and it is always a ScrumMaster’s job to create a structure which allows people to perform. ScrumMasters build this structure on different levels, e.g.:
    a. Team-level: Using Scrum as a framework for creating structure.
    b. Meeting-level: By facilitating meetings and all other communication processes he ensures a clear structure in which team members can perform their tasks.
  3. Voluntariness/change agent: For me, the most interesting aspect of agile leadership has always been voluntariness and its corresponding commitment. Acting as a change agent, I created a believe system and a culture of voluntariness within my own company. It is the ScrumMaster’s job to establish a culture that fosters contribution and the willingness to commit.
  4. Synchronisation/management: Teams, departments and our whole society functions because we are able to synchronise activities of individuals. Ensuring synchronisation has always been the management’s job. So, nothing changes for the ScrumMaster. He acts as a manager to establish communication processes so that everybody involved is able to contribute as productively as possible.
  5. Skills (know-how)/trainer: Someone needs to make sure that team members have all necessary skills for performing a task. In most cases team members take care about it themselves. However, from a meta position it is sometimes easier to assess if a team lacks certain skills (“you do not know that you do not know”). The job of a ScrumMaster is to ensure that a team becomes aware of its own limitations and consequently supports it in gaining new skills by offering/organising … training. As a “head trainer” the ScrumMaster might not be able to train others himself in every occasion, but he is responsible for coordinating all training activities.
  6. Development/coach of a team: It is one part of the ScrumMaster’s duties to provide skills and knowledge as a trainer. However, a team also needs a coach. Someone who works with the team on its development as a team. I am not talking about skills but about mindset, behavior and motivation – we can also call it personal growth. The ScrumMaster sets thought-out measures to let a team grow.

In this short blog post I tried to transfer Dieter’s framework onto the role of the ScrumMaster. Please note that I only focused on the “what” not on the “how”. If you want to know how to do all this … read our free book “Selforganisation needs Leadership” on Gitbook. It is a translation of my best selling book: “Selbstorganisation braucht Führung”.

A model for management helps to understand ScrumMaster duties

The Scrum world mostly focuses on leading agile teams. In this community we constantly discuss how to treat team members and whether the Product Owner is a part of the team or not. We question the role of management and are still not sure if the ScrumMaster is a leader. Several times the agile world tried to dismiss managers as not being useful anymore. In his famous article “First, let’s fire all the managers” Gary Hamel even treated the manager’s position as a tax rather than a value creating function (Hamel 2011). Most people on the operational level (primarily those who produce something) consider managers as not creating value. Management is something bad whereas no management is something good. Sometimes, agilists believe that only leadership is necessary and people are able to manage themselves.
I have never been sure whether this simplistic approach to distinction between management and leadership is really useful. And I am still struggling with the idea that large corporations like Daimler, General Motors, Apple or Google shall exist without having a “management”. Of course I know that Buurtzorg for example doesn’t have a distinctive management level, neither has Spotify. Being aware of that, I wanted to know more and went back to university. I enrolled in a Global Executive Master of Business Administration Program at St. Gallen University (HSG). Within the first week of the program I was shown that the professors thought like the protagonists of the agile world but they don’t try to simplify things in the same way as we sometimes tend to do within the agile community.
It might be useful for the agile community to understand the deep implications of seeing management as a “reflexive design praxis” as the St. Gallen Management Model (SGMM) suggests (I will talk about the SGMM in another article). One “translation” of the SGMM into practical terms is described by a model, that I do not claim having understood correctly in detail yet but I would like to share a piece with you which helped me understand the difference between the logical levels of vision and strategy. Looks pretty obvious when you see this model, but not having clear this distinction before had confused my thinking. We got this depiction from HSG Professor Dr. Wolfgang Jenewein who specializes in High Performance Teams (he has also written a book about it, see Jenewein and Heidbrink 2008). He coaches large organizations as well as football teams – and it seems to me that he is very successful in doing so.
jenewein2
You can see the model he introduced and which is used at HSG by many professors in the picture. Please note that this is not the St. Gallen Management Model itself (Rüegg-Stürm and Grand, 2015) which I will try to describe in another article. The model explained by Jenewein operates on three levels – normative, strategic and operational – and five different aspects of management (give a vision, create a strategy, build an organization, form a culture and lead your people) which comprise “Leadership” as one necessary function of management. Let’s have a look at the three levels:

  1. The normative level represents the settings put in place by managers or e.g. the board of directors. One function of the normative level is to determine the vision of the company or the team. A vision offers the “Why?” (see Sinek 2011). The normative level is located above the strategic level, so the strategy of a company or team is not part of the vision but it can influence the vision of course.
  2. Most of the time, the strategic level consists of a set of processes to determine and guide the actions of a company or team. On this level we need to answer all the questions which help guiding the company. We need to deliver:
    a. Focus
    b. The positioning of the company/team = the differentiation to other teams or companies
    c. Customer segments and the respective customer needs
    d. We need to consider potentials and risks of our strategy
    e. And it is all about the FUTURE!
  3. The operational level is the most important according to the agile community as the “real” work is done on this level:
    a. Set up of processes to organize the organization. That means also to set targets and goals for the organization.
    b. Working on and building the culture
    c. “Leadership” is a day to day activity which is shaped by the context you are working in. If you are the head of department, you will need to set up visions that are different from those visions you would set up if you were the ScrumMaster of a cross-functional development team.

I believe this model helps us to understand which aspects of management need to be taken care of in order to structure an organization, a department, a project and even a team. As the ScrumMaster is the one who works on raising the productivity of the organization, he is also in charge (on his level) of making this happen.
The ScrumMaster has to make sure that there is a vision, a strategy, a clear set of rules that guides the organization and he needs to build the culture. He or she does this by applying modern leadership tools as I described in “Selforganization needs Leadership”(available online here)
If you understand leadership as an activity then you can also learn it. You can learn how to help your team by working on all three levels using the appropriate “transfers”, f.e. the company vision becomes the product vision, the strategy might become your product roadmap and so on. Using an approach that lets team members grow in their personality, work attitude and ability of self organization.
 
Hamel, G. (2011). First, let’s fire all the managers. Harvard Business Review, 89(12), 48-60.
Jenewein, W., Heidbrink, M. (2008). High-Performance-Teams: Die fünf Erfolgsprinzipien für Führung und Zusammenarbeit. Stuttgart: Schäffer-Poeschel.
Rüegg-Stürm, J., Grand, S. (2015). The St. Gallen Management Model. English translation of the fourth generation of the German text. Bern: Haupt Verlag.

Real life tips: Do's and Don'ts for Scrum implementations – the ScrumMaster

Do

Have a full-time ScrumMaster for each of your teams. Why? Because, as the name suggests, if you are doing Scrum you need someone who masters all the aspects of it: Protecting the team from outside disturbances, making the team more productive, collecting data and defining KPIs on the team’s performance in order to define where the team stands and where it wants/needs to be next. Every team has a lot of contact points with stakeholders/other departments within a company – all of these contacts need to be managed and scheduled. Furthermore, the ScrumMaster is the change agent of your organization. If Marketing is still wondering, why they are getting invited to those “review meetings” every second week, you need someone to explain the Why, the How and the What.
For a ScrumMaster to be effective it has to be clear that she assumes a lateral leadership role. Protecting the team, removing impediments and constantly challenging the status quo can only be done if you stop treating the ScrumMaster role as an add-on but start treating it as a prerequisite for starting with Scrum. Here are 3 things you can do right now, to ensure the legitimacy of your ScrumMaster:

Scrum is about continuous learning and continuous improvement – if you want to take full advantage of it, the ScrumMaster is a full time job!

Auch ScrumMaster machen mal Urlaub

ScrumMaster zu sein ist eine ziemlich fordernde Sache. Neben den langfristigen Zielen, die man für sich selbst und gemeinsam mit dem Team verfolgt, tauchen jeden Tag Impediments auf, die mehr oder weniger sofort analysiert und gelöst werden wollen. Ja, hin und wieder ist dann auch der ScrumMaster urlaubsreif. Es ist nicht vorherzusehen, wann Impediments auftreten und wie sie sich entwickeln – und meistens lösen sie sich während des Urlaubs nicht in Luft auf. Wenn wir von unseren Projekten länger abwesend sind, lassen wir uns also gerne von Kollegen vertreten. Irgendwie logisch.

“Oh mein Gott, ein neuer ScrumMaster!”

Da wir als Team sehr gut vernetzt sind und das Übernehmen von Teams regelmäßiger Teil unserer Aufgabe ist, ist es für uns als Consultants – vom Einarbeitungsaufwand abgesehen – ein routinierter Prozess. Für die unmittelbar Beteiligten, also in erster Linie für das restliche Scrum-Team und das Management, bedeutet das aber, sich sehr schnell und nur für einen relativ kurzen Zeitraum auf ein neues Gesicht einstellen zu müssen. Der oder die Neue steigt flugs in hausinterne Prozesse ein und hat aufgrund einer sauberen Übergabe durch den urlaubenden Kollegen auch noch ziemlich schnell seinen Daumen in offenen Wunden. Das muss man erst einmal verdauen.
Die Reaktionen, die einem ScrumMaster dabei entgegenschlagen, können weitreichend sein. Veränderung erzeugt nun einmal Widerstand. Zugegeben, eine Projektübergabe bedeutet in unserem Kontext nicht, dass wir dem vertretenden Kollegen jeden Handgriff erklären müssen und es kann sein, dass gewisse, für das Team selbstverständliche Spezifika nochmals hinterfragt werden. Unterm Strich machen wir aber alle zusammen das Gleiche: Scrum. Und das im Rahmen eines standardisierten Frameworks.

Die Chance eines neuen Mindsets

Um personenbezogene Impediments zu lösen, sind kontinuierliche Zusammenarbeit und Vertrauen nötig. Als Change Agents sehen wir in dem frischen Wind zwischendurch aber in erster Linie eines: eine Chance! Jeder Consultant bringt eine andere Spezialisierung, andere Erfahrungen und persönliche Zugänge zur Problemlösung ein. Als T-shaped-Team nutzen wir unsere unterschiedlichen Fähigkeiten gerne, um Spezialisten in das Projekt zu holen. Stefan Willuda zum Beispiel ist unser Spezialist für agiles Monitoring und Reporting; Karl Bredemeyer hat unglaubliche Skills in der Visualisierung und ist Mastermind hinter unseren Visual Scrum Trainings. T-shaped heißt in unserem Verständnis, dass Karl genauso rechnen und Stefan zeichnen kann. Ebenso verhält es sich mit unserem gemeinsamen Verständnis von Scrum: Das Toolkit ist das gleiche, jeder von uns nutzt die Tools aber auf seine eigene Art.

Mehrwert durch ein zweites Augenpaar

Insgesamt verhält es sich dabei wie beim Mob Programming: Durch ein zweites Augenpaar, einen externen Blick und ein frisches Mindset können Synergien geschaffen werden. Ich sehe es als Urlaubsvertretung gerade selbst, habe diese Vorteile aber auch schon auf eigenen Projekten erleben können, wenn ein Kollege mit einem Sonderthema oder einem speziellen Workshop für ein paar Tage eine neue Sicht auf ein Thema eingebracht hat. Sehen Sie das als Chance! Wenn ihr ScrumMaster das nächste Mal auf Urlaub gehen möchte, fürchten Sie sich nicht – fragen Sie ihn lieber, ob er sich vertreten lassen will!

Das andere Ende der Leitung: Scrum in verteilten Teams

Verteilte Teams passieren nicht. Sie entstehen, weil das Management festgestellt hat, dass erforderliches KnowHow nicht an einem Ort versammelt ist oder an einem anderen Standort günstiger zu bekommen ist. Wir müssen unser Team also dezentral organisieren. Nachdem wir uns im ersten Schritt mit der Kommunikation in verteilten Teams befasst haben, können wir uns nun daran machen, das Projektmanagement zu organisieren.

Warum bietet sich Scrum für die Organisation verteilter Teams an?

Am Ende jedes erfolgreichen Teambuilding-Prozesses steht ein gemeinsam geteiltes und verinnerlichtes Ziel. Im Scrum-Umfeld verbinden wir dieses gemeinsame Ziel in erster Linie mit dem Artefakt der Vision und mit dem agilen Wert des Commitments. Die Vision sollte bereits auf strategischer Ebende schnell, klar und deutlich verbreitet und laufend erneuert werden. Auf Sprint-Ebene ist das Commitment zu einem gemeinsamen Ziel das erste integrative Element. Es hilft dem Team, sich auf die Aufgaben des kommenden Sprints zu konzentrieren.
Scrum setzt auch im Verlauf des Sprints auf mehrere integrative Effekte. Wie bereits erwähnt ist das Peer Working ein effektiver Weg der Zusammenarbeit. Hier geht es aber nicht nur um den angesprochenen Vertrauensaustausch. Wenn es den Teamspirit stärkt, Checklisten abzuhaken hilft es uns erst recht, dieses Erfolgserlebnis zu teilen. Apropos: (Miss-)Erfolg ist der abschließende integrative Teil unserer Arbeit. Das Erreichen eines gemeinsamen Ziels kann uns als Team bestärken, Lohn für unsere Mühen sein. Ebenso kann gemeinsamer Leidensdruck Auslöser für Veränderung und Verbesserung sein.

Be part of it!

Spätestens wenn Sie versuchen, Magic Estimation mit einem verteilten Team zu spielen, werden Sie herausfinden, dass die Integration von Menschen, die sich nicht in einem Raum befinden, recht kompliziert sein kann. Hier gibt es verschiedenste Lösungsansätze, die je nach Teamsetting umgesetzt werden können. Zum Beispiel

Spätestens, wenn Sie ein großteils verteiltes Team betreuen, müssen Sie sich als ScrumMaster über eine vollkommen digital spielbare Variante der Magic Estimation Gedanken machen. Egal, um welches Meeting oder welchen Arbeitsschritt es sich handelt, die zwei wichtigsten Anforderungen sind dabei, dass

Remote. Ein Problem, das wir letzten Endes alle kennen.

Ihr Scrum-Team ist an einem Standort zusammengefasst? Herzlichen Glückwunsch! Sie werden sich im Rahmen der Zusammenarbeit gewisse Abstimmungsarbeit sparen. Das bedeutet aber nicht, dass Sie die oben genannten Grundsätze nicht beachten sollten. Irgendwie ist nämlich jedes Team verteilt. Wenn wir von Scrum sprechen, meinen wir die kontrollierte Zusammenarbeit von verschiedenen (Interessen-)Gruppen, den Rollen. Ich habe schon verschiedenste Unternehmen und Teams gesehen: Eine Konstellation, in der der operative Kern, externe Zulieferer, Management, Kunden und User nicht verteilt waren, habe ich dabei noch nie beobachtet. Die zugrundeliegenden Probleme können dabei durchaus die gleichen sein wie bei einem verteilten Scrum-Team. Somit betrifft uns das Problem des verteilten Teams doch irgendwie alle. Machen wir uns das bewusst und agieren wir dementsprechend. So können wir uns wieder ein klein wenig verbessern.

Das andere Ende der Leitung: Kommunikation in verteilten Teams

Remote-Arbeit ist heute gang und gäbe – auch in Scrum-Umgebungen. Ich bin selbst Teil mehrerer Remote-Konstellationen: Aktuell betreue ich als Interim ScrumMaster im Rahmen eines Kundenprojekts ein verteiltes Team. Es gehört zu meiner Aufgabe, Remote-Kollegen bestmöglich in das Team zu integrieren. Darüber hinaus gehöre ich als Consultant zum verteilten Team von Boris Gloger Consulting und tausche mich regelmäßig mit meinen Kollegen zu aktuellen Fragen und Problemstellungen aus; ich erlebe also die andere Seite, jene des Teammitgliedes. Zwei unterschiedliche Perspektiven mit interessanten Erfahrungen, aus denen ich viele Schlüsse über die Arbeit in verteilten Teams ziehen kann. Ich will hier nicht auf die allgemeinen Rahmenbedingungen verteilter Teams eingehen. Ein Blick in die Praxis beweist, dass sie in vielen Fällen nicht vorhanden sind. Ich möchte nur die wichtigsten zwei Rahmenbedingungen kurz zusammenfassen:

Die Remote-Aufgaben des ScrumMasters

Wie kann ein ScrumMaster nun die Remote-Kollegen einbinden? Oft höre ich, dass die Position des ScrumMasters nicht remote besetzt werden darf. Für meinen beruflichen Schwerpunkt als Interim ScrumMaster, der meist in existierende Organisationen kommt, ist das grundsätzlich richtig; aber nicht bedingungslos. Als Remote-Einzelkämpfer ist man oft schlechter ins Team integriert. Sei es, weil es sich um externe Arbeitskräfte handelt, die später zum Team stoßen, weil die persönliche Anbindung anders ist als im unmittelbaren Kreis des Teams, oder weil es bei der technischen Verbindung hakt. Es gibt viele Gründe, wieso Remote-Kollegen sich scheuen, Verbindungsprobleme auszusprechen oder es schlichtweg aufgeben. Aus den Augen heißt in dem Fall aber nicht aus dem Sinn. Um sich ein eigenes Bild zu verschaffen, sollte man sich auch einmal an das andere Ende der Leitung setzen, sobald man Remote-Kollegen hat, die diesen Platz besetzen.
Wurden die Rahmenbedingungen für die Arbeit in einem verteilten Team durch die Organisation geschaffen, können wir damit beginnen, unser Team aufzusetzen. Auch verteilte Teams durchlaufen die klassischen Teambuilding-Phasen, es sind aber noch zusätzliche Erfolgsfaktoren zu beachten. Beginnen wir mit dem, was da sein muss, bevor es losgeht: das Vertrauen. Vertrauen wir in die Ehrlichkeit der Remote-Kollegen? Oder geht es uns in erster Linie um das Vertrauen in ihre fachliche Qualifikation? Ist Kontrolle nicht besser? Das eine gegen das andere aufzuwiegen, ist nicht nötig – aus zwei Gründen:

Beachten Sie als ScrumMaster vor allem auch die Kunst, aneinander vorbei zu reden. Man benötigt keinen Abschluss in Kommunikationswissenschaften, um zu erkennen, dass Menschen Sprache unterschiedlich nutzen und interpretieren. Das kann nicht zuletzt eine Frage des Kulturkreises oder der Generation sein, Stichwort „Digital Natives“. Remote-Kommunikation verliert an Gestik, Mimik, manchmal auch Tonalität. Achten Sie beim Forming eines Remote-Teams also noch stärker darauf, dass der Empfänger morgen noch weiß, wie es der Sender gemeint hat.
Hoch entwickelte Teams können davon ungeachtet auch komplett remote problemlos kommunizieren. Meine Erfahrung als Berater zeigt mir aber, dass persönlicher Austausch in unserem Kulturkreis immer noch ein Grundbedürfnis jedes Teams ist. Sorgen Sie also dafür, dass sich die Teammitglieder in regelmäßigen Abständen persönlich treffen!
Der erste wichtige Schritt zur Arbeit in verteilten Teams ist gesetzt: die Kommunikation funktioniert. In einem zweiten Schritt können wir nun überlegen, wie Scrum mit der Problematik umgeht.
 
Fortsetzung folgt

5 Punkte für ein effektives Daily

Scrum ist ein hocheffizientes Rahmenwerk für die Produktentwicklung, sofern es richtig gelebt wird. Leider erleben wir zu oft das Gegenteil. Die Scrum Meetings werden prozessual etabliert, aber es fehlt am qualitativen Mehrwert, der durch die Meetings entstehen sollte.
Immer wieder sehen wir Dailys, in denen der ScrumMaster vor dem Board steht, als gelte es sein Heiligtum zu bewachen. Das Team hat im weiten Bogen um ihn herum Aufstellung bezogen und jede Person sagt einen Satz, ohne dass sich die Kärtchen am Taskboard bewegen. Fast alle Storys hängen in der WIP-Spalte und die Tasks bekommen trotz Bewegungsfaulheit keinen Punkt dafür. Der Product Owner vergibt bei Gelegenheit noch Aufgaben an einzelne Teammitglieder und fährt anderen Teammitgliedern über den Mund.
Ein so oder so ähnlich durchgeführtes Daily ist leider ein sehr ineffizientes Daily. Gut, immerhin ist das Daily als Meeting etabliert. Es wäre weitaus schlimmer, wenn das Meeting überhaupt nicht stattfinden würde. Da es stattfindet und das auf eine transparente Art und Weise, können wir anfangen, es in eine effektive Richtung zu lenken.

1. Daily als Ort der Kommunikation

Das Daily ist KEIN Statusreport für den Product Owner und auch nicht für den ScrumMaster. Das Daily ist da, damit sich das Dev-Team austauschen und koordinieren kann. Die Mitglieder des Dev-Teams sprechen miteinander und erklären sich gegenseitig, was sie machen, wo sie bei der jeweiligen Story noch Hilfe brauchen bzw. wo es sinnvoll ist, im Pairing zu arbeiten. Der ScrumMaster achtet darauf, dass das Ganze im zeitlichen wie auch menschlichen Rahmen bleibt und ist hellhörig bezüglich Impediments. Der Product Owner steht für Rückfragen zu den Akzeptanzkriterien zur Verfügung oder kann sich einbringen, wenn er das Gefühl hat, dass das Dev-Team über das Ziel der Akzeptanzkriterien hinausschießt.
Umsetzung: Der SM fordert die Teammitglieder auf, vor dem Taskboard zu stehen und stellt sich selbst mit den Product Owner in den Hintergrund. Wenn der ScrumMaster oder der Product Owner in den Mittelpunkt der Kommunikation rutschen, erklärt der ScrumMaster wiederholt, dass das Daily nicht dazu da ist, um ihn oder den Product Owner auf den neuesten Stand zu bringen. Das Daily dient dem Informationsaustausch zwischen den Teammitgliedern. Der ScrumMaster hält bei Bedarf wiederholte Mini-Workshops ab, um den Sinn eines Dailys zu erläutern und coacht bei Bedarf den Product Owner in seiner Rolle.

2. Das Herz des Dailys – Aufbau des Tasksboards

Ein Taskboard besteht aus drei Spalten: To do, Work in Progress (WIP) und Done – nicht mehr und nicht weniger. Die horizontalen Zeilen ergeben sich aus den Storys, wo die Tasks zugeordnet sind.
Umsetzung: Der ScrumMaster baut ein Taskboard auf. Unsere beliebtesten Hilfsmittel sind: Pinnwände oder Metaplanwände, die mit Kreppband oder Garn und Stecknadeln in die Bereiche aufgeteilt werden. Moderationskarten sind optimal für die Spaltenüberschriften und die Storys, während verschiedenfarbige Post-its und Stifte das tägliche Aktionsmaterial sind.

3. Die Fragen für das Daily

Man orientiert sich an den 4 Fragen:

Diesbezüglich gibt es mehrere Optionen. Entweder man geht diese Fragen pro Teammitglied oder pro Story durch. Ich persönlich präferiere letzteres: Letztendlich geht es darum, zu sehen, ob die Storys fertiggestellt werden können und nicht darum, dass alle Teammitglieder ausgelastet sind. Wer etwas Neues ausprobieren will, geht einen Schritt weiter und lässt die Teammitglieder herzeigen, was Sie bereits produziert haben, sodass jedes Daily zum Mini-Review wird.
Umsetzung: Der ScrumMaster achtet darauf, dass zu jeder Story/Person die Fragen beantwortet werden. Wenn etwas vergessen wird, erinnert er daran. Die Fragen auf Moderationskarten neben dem Taskboard aufzuschreiben, ist eine einfache und gute Erinnerungsstütze. Beim Mini-Review sorgt der ScrumMaster dafür, dass die Teammitglieder zwischen den Präsentationen zum Taskboard zurückzugehen, um es auf den neuesten Stand zu bringen. Der ScrumMaster sorgt dafür, dass die Timebox von 15 Minuten eingehalten wird, indem er die Leute daran erinnert, sich kurz zu halten bzw. eine Uhr mitlaufen lässt, die alle daran erinnert, wie viel Zeit noch übrig ist. Tipp: Es gibt Timebox-Uhren mit kleiner werdendem Zeitbereich zu kaufen.

4. Das Team bewegt sich, nicht der ScrumMaster

Das Team bewegt die Tasks über das Taskboard. Wenn ein Task done ist, sollte er auch wirklich done sein und nicht mehr zurückkommen. Dabei hat jeder Task ein Namenskürzel. Auch wenn wir Consultants als ScrumMaster arbeiten, können wir uns nicht immer merken, wer von uns welchen Task erstellt hat – mit Namenskürzel auf dem Task hat man aber immer eine Anlaufstelle, wenn man sich über Sinn und Zweck eines Tasks im Unklaren ist. Sollte sich ein Task nicht in die nächste Spalte bewegen, bekommt er jeden Tag einen Punkt und zwar von den Teammitgliedern. Der ScrumMaster achtet auf diese Tasks und fragt während oder nach dem Daily, ob es ein bestimmtes Impediment gibt, das die Fertigstellung des Tasks behindert, oder ob der Task einfach nur zu groß ist.
Umsetzung: Der ScrumMaster bittet die Leute, selbst die Tasks zu schreiben und zu bewegen und reicht dabei auch gerne die Stifte. Auch wenn es sich am Anfang unangenehm anfühlt: Der ScrumMaster bittet die Leute wiederholt höflich (oder auch direkter), die Tasks selbst zu schreiben, zu bewegen und Punkte zu machen. Irgendwann wird er es nicht mehr tun müssen, weil es die Leute selbst tun werden.

5. Flow

Es wird immer daran gearbeitet, so wenige Storys wie möglich offen zu halten und so wenige Tasks wie möglich in progress zu haben. Im Allgemeinen gilt es, sich immer in die Richtung des Optimums einer offenen Story zu bewegen und eine Taskanzahl in progress zu haben, die geringer oder gleich der Anzahl der Teammitglieder ist. Wir wissen alle, dass Multitasking ineffizient ist und wir wollen einen schnellen Feedback-Loop mit dem Product Owner erzeugen. Sobald eine Story abgeschlossen ist, nimmt der Product Owner sie ab bzw. gibt Feedback, warum sie nicht abgenommen werden kann.
Umsetzung: Der Scrum Master vereinbart mit dem Team ein WIP-Limit auf Story-Ebene oder gibt eines vor. Er sorgt dafür, dass das WIP-Limit eingehalten wird, indem er es nicht zulässt, dass weitere Storys eröffnet werden. Sobald eine Story fertig ist, sorgt er oder sorgen die Teammitglieder dafür, dass der Product Owner davon erfährt. Der ScrumMaster sorgt dafür, dass es bald Feedback gibt, ob die Story abgenommen wird oder was die Abnahme verhindert.
 
Es gäbe noch viel mehr dazu zu sagen, aber diese fünf Punkte sind für mich die Basis für jede weitere Aktion – sie erschaffen im Kern eine gesunde Daily-Kultur. Dabei ist es wirklich schwierig, diese Punkte alle im Kopf zu behalten und kontinuierlich zu kontrollieren. Es ist ein Idealbild, dem man sich im im Laufe der Zeit annähern kann. Im Laufe der Entwicklung des Scrum-Prozesses wird der ScrumMaster immer mehr seiner Verantwortung an die Teammitglieder abgeben, sobald er sieht, dass sie das Konzept verinnerlicht haben. Am Anfang jedoch muss er durch Vorzeigen, Vorleben und häufiges Erklären die Grundlage und das Verständnis für die Vorgänge schaffen, die für langfristige Produktivität sorgen.

Was braucht eigentlich ein ScrumMaster?

Haben wir als ScrumMaster eigentlich Bedürfnisse? Im agilen Umfeld liegt der Fokus ja darauf, dass ein Scrum-Team liefert und allfällige Impediments beseitigt werden. Der Kunde steht dabei im Mittelpunkt der Aufmerksamkeit. Das Entwicklungsteam und der Product Owner versuchen stetig, seine Bedürfnisse zu erkennen und zu befriedigen. Wir ScrumMaster haben dabei die Aufgabe, Hürden oder Lücken in diesem Prozess jeden Tag aufs Neue zu erheben und zu beseitigen. Als Feuerlöscher oder Boje im Sturm stellen wir sicher, dass das Team ungestört neue Produkte entwickeln kann und wir haben ein offenes Ohr für alle, die an diesem Prozess beteiligt sind: für den Product Owner, das Entwicklungsteam, den Kunden, aber auch für das Management. Wir sind Seelsorger, Superhelden, Innovatoren, Beschützer, Sekretäre, Strategen, Anpacker, Künstler, Freunde, Sprachrohre, Motivatoren, Coaches und Clowns zugleich. Wir versuchen in unserer täglichen Arbeit, die Schmerzen und Blockaden zu lösen, damit ein reibungsloser Arbeitsflow entstehen kann, aber auch die Stärken und Freuden zu fassen und sie am Leben zu halten. Im Grunde dienen wir als Servant Leader unseren Teams und ihrem Umfeld und sind stets bemüht, ihre Bedürfnisse zu stillen. Aber wer stillt unsere Bedürfnisse? Wir selbst? Das Management? Oder im Gegenzug unser Team?
Und wir ScrumMaster? Sollten wir nicht Motivation und Freude aus unserer Arbeit ziehen, indem wir den Prozess am Laufen halten und den Menschen um uns herum die Verantwortung für die und Freude an der Arbeit schenken? Sollten wir nicht so bescheiden sein, dass wir Kraft und Anerkennung aus den kleinen Veränderungen schöpfen, die wir vollbringen? Sollten wir nicht unsere Befriedigung aus der Freude und Dankbarkeit unseres Teams ziehen?
Da liegt meiner Meinung nach der große Knackpunkt. Ein Prozess lässt sich nicht von heute auf morgen verändern, eine Denkweise nicht von jetzt auf gleich bereichern und schon gar nicht trägt eine Veränderung sofort Früchte. Also sind wir ScrumMaster erst einmal diejenigen, die alles aufreißen, kaputt machen und in Frage stellen, was allen Beteiligten Schmerzen bereitet, unangenehm ist und teilweise nicht verstanden wird. Die Freude unserer Teams und aller, die sie umgeben, fällt eher mager aus und damit auch die Befriedigung unserer Bedürfnisse als ScrumMaster. Jetzt könnten alle ScrumMaster aufspringen und sagen: “Ja! Revolution! Seht endlich ein, dass wir nicht eure Gegner sind, sondern eure Partner!” Aber nein, bescheiden wie wir sind, halten wir uns zurück, genießen im Stillen und hoffen auf den einen oder anderen guten Zuspruch in irgendeiner näheren oder fernen Zukunft. Ein paar Methoden helfen uns dabei, nicht den Mut und den Antrieb zu verlieren:
 

Was ist ein Change Agent ohne die Legitimation, einen Change auch durchführen und implementieren zu können? Was ist ein ScrumMaster ohne das Vertrauen des eigenen Teams? Und was können wir bewegen im Unternehmen, wenn das Management uns nicht hört und weiter die alten Wege geht? Nur wenn wir die Möglichkeit haben, Änderungen auch bis zum Schluss verfolgen und umsetzen zu können, haben wir die Möglichkeit, unsere Bedürfnisse zu stillen. Nur wenn wir die Erlaubnis aller im Team haben, mit ihnen gemeinsam den Weg gehen zu dürfen, können wir Arbeits- und Denkweisen verändern. Und somit ist das unser elementarstes Bedürfnis: die Freiheit und Legitimation, endlich unseren Job machen zu dürfen.

Wie sieht der Arbeitsplatz eines ScrumMasters aus?

Jede Form von Veränderung erzeugt in uns den Wunsch nach Orientierung. Das gilt selbstverständlich auch, wenn man in einem neuen Arbeitsumfeld oder durch einen neu eingeführten Prozess plötzlich mit Scrum konfrontiert wird. Dieser Wunsch nach Orientierung manifestiert sich unter anderem in dem Bestreben, den eigenen Arbeitsplatz möglichst funktional und ansprechend einzurichten – das reicht von  Zimmerpflanzen über Fotos bis hin zur Frage, welche Icons man auf seinen Desktop legt. Am Anfang meiner Beratertätigkeit verfolgte ich ein ähnliches Ziel. Zum Glück hatte ich in meinen ersten Woche die Möglichkeit, mir bei Projektbesuchen einige Details von meinen Kollegen abschauen zu können. In der Hoffnung auf Tipps und Tricks zur Gestaltung meines Arbeitsbereiches, fand ich mich bald mit einer wesentlichen Frage konfrontiert:
Wo ist eigentlich der Arbeitsplatz eines Scrum Masters?
Meine Kollegen und ich sind externe Consultants, die ihre Kunden oft tageweise besuchen. Da liegt die Antwort nahe, dass unser Arbeitsplatz dort ist, wo wir unseren Laptop parken. Freies LAN-Kabel = Arbeitsplatz!? Weit gefehlt. Keiner meiner Kollegen, die ich dazu befragt habe, hat auch nur annähernd an den Laptop gedacht. Eine Kollegin zeigte mir, dass ein fehlender Netzwerkzugang eigentlich das kleinste Hindernis ist, um mit der Arbeit zu beginnen. Zur Verwunderung mancher Auftraggeber finden wir uns, obwohl am Puls der Zeit lebend, mit einfachen Mitteln wie Markern und Post-Its für den Anfang sehr gut zurecht. Mit der Feststellung, dass der Arbeitsplatz des ScrumMasters nicht an den Computer gebunden ist, endet die Liste der Übereinstimmungen aber auch schon. Von fünf Kollegen, die ich nach dem „wo“ gefragt hatte, bekam ich fünf  unterschiedliche Antworten: von „vor dem Impediment-Backlog“ bis hin zu „unter Menschen“.

Pixabay Public Domain, CC0

Pixabay Public Domain, CC0


 
Wenn es also schon keinen eindeutigen Platz gibt, könnte man versuchen, den gesamten Arbeitsbereich des ScrumMasters zu beschreiben. Hier bietet sich eine Beschreibung über die Artefakte an. Einerseits ist der ScrumMaster für die Visualisierung einer Reihe von Artefakten verantwortlich, andererseits bestimmen diese aufgrund ihrer Großflächigkeit das Gesamtbild des Arbeitsbereichs wesentlich. Um die Frage nach dem optimalen Arbeitsumfeld zu beantworten, müssen wir uns noch eine Zwischenfrage stellen:
Wie viele Artefakte kennen wir?
Selbstverständlich liefert uns die Theorie eine Reihe von Artefakten, die ein Scrum-Team einsetzt. Als Berater gehen wir während einer Scrum-Implementierung in der Regel aber eher pragmatisch als dogmatisch vor. Unsere Arbeit wird nicht besser oder schneller erledigt, wenn wir ein Team mit der vollen Bandbreite an Charts, Definitionen und anderen Artefakten überfahren, ganz im Gegenteil. Sollte Ihnen diese Erkenntnis für die Gestaltung Ihres Team-Raumes zu minimalistisch erscheinen, möchte ich eine besondere Wahrnehmung teilen, die mir bei einer Kollegin aufgefallen ist: Haben Sie schon einmal von einer ‚Peer-Programming-Matrix’ gehört? Ein einfaches Flipchart mit einer Matrix gibt Auskunft darüber, wer mit wem bereits gemeinsam programmiert hat – dazu braucht es keine ausschweifende Beschreibung oder einen ausgefallenen Bauplan. Sollten Sie in Ihrer Organisation der ScrumMaster of ScrumMasters sein, hilft Ihnen vielleicht die Adaption zu einer „Peer-Working-Matrix“. So einfach die Idee ist, so hilfreich kann sie im richtigen Umfeld sein: In diesem Fall hat es die ScrumMasterin mit einfachen Mitteln geschafft, ihren Arbeitsplatz so zu gestalten, dass ein von ihr gesetztes Ziel im Raum steht. Nein, in ihrem Raum hängt keine Definition of Ready, denn sie hat entschieden, dass Peer Programming ein zumutbarer nächster Schritt ist, der ihr Team produktiver machen kann.
Darin versteckt sich aber auch die Antwort auf die ursprüngliche Frage: Ein guter ScrumMaster gestaltet seinen Arbeitsplatz individuell, den Bedürfnissen seines Teams entsprechend – wo auch immer dieser Arbeitsplatz ist. Und dafür gibt es endlos viele Möglichkeiten.

Warum ScrumMaster eskalieren müssen

Worum geht es eigentlich wirklich beim ScrumMaster-Dasein? Dazu gibt es so viele unterschiedliche Ideen wie ScrumMaster. Letztendlich geht es um die Performance des Teams und damit verbunden um die Lösung von Impediments. Wieder so weitläufige Begriffe – was bedeutet das konkret? Vielleicht bin ich einer der Facetten schon mal näher gekommen. Vor kurzem wurde in unserem internen Company Review in der Retrospektive die folgende Frage gestellt: Was hat uns im letzten Sprint produktiv gemacht?
Eine meiner ScrumMaster-Kolleginnen meinte, es seien vor allem die Eskalationen gewesen. Ihr Mentor habe einmal gesagt: “Jede Eskalation bewirkt etwas Gutes.” Sie habe es am Anfang nicht geglaubt, aber in der letzten Zeit habe sie ohne Ende eskalieren müssen und die Aussage habe sich bewahrheitet.
Für mich ein AHA-Moment. Vor allem deshalb, weil es Situationen gab, in denen ich – retrospektiv betrachtet – hätte eskalieren müssen und es nicht gemacht habe. Als ich diese Aussage meiner Kollegin hörte, wurde mir klar, wieso es so wichtig ist zu eskalieren und was passiert, wenn wir es nicht tun.

Es geht um das Team 

Bei der Eskalation geht es in Wirklichkeit darum, für das Team einzustehen (und falls es diesbezüglich Unklarheiten geben sollte: Das Team besteht aus den Entwicklern UND dem PO). Es geht darum, dem Team eine Stimme zu geben und sich vor das Team zu stellen. Damit üben wir nicht nur eine Schutzfunktion aus, wir zeigen dem Team auch, dass es so nicht geht. Wir zeigen den Teams, dass wir sie hören – wir hören die Stimme des Teams und verleihen ihr zusätzliche Kraft. Wir zeigen damit, dass sie nicht allein sind mit den Impediments, die ihre Produktivität behindern. Das wir nicht schon wieder Leute mit irgendwelchen wirren Ideen sind, die nicht hinter diesen Ideen stehen. Wir zeigen, dass wir bereit sind, für das Team und seine Anliegen mit unserer Person einzustehen. Nicht nur das, wir werden damit auch zum Vorbild und geben unseren Teams wieder die Kraft und den Glauben an sich selbst. Simon Sinek würde sagen, wir stellen den Circle of Safety wieder her und erfüllen als wahre Leader unsere ursprünglichste Aufgabe: Wir schützen die Herde.

Keine Angst vor dem Säbelzahntiger

Aber damit die edlen Gefühle nicht die Wahrheit verschleiern: Etwas zu eskalieren braucht eine Menge Courage. Wenn wir Pech haben, berührt der Gang zum Management die Angst, danach keine Stelle mehr zu haben. Und so archaisch und seltsam es in der heutigen Zeit anmutet, können wir uns manchmal noch immer so fühlen, als würden wir vor einem Säbelzahntiger stehen. Sich gegen jemanden zu wenden, der eine höhere hierarchische Position einnimmt oder die Macht hat, unser Projekt zu beenden, kann anscheinend noch immer unseren urzeitlichen Überlebensinstinkt triggern, der sagt: “Raus hier, nur raus!” Das ist insofern seltsam, als dass ich das Management in vielen Fällen aufgeschlossen und unterstützend erlebt habe. Letztendlich geht es darum, gemeinsam etwas zu bewegen und das geht bei größeren Impediments nur als Gesamtorganisation.
Gerade deswegen ist es aber auch die Aufgabe der ScrumMaster, zu eskalieren. Nicht nur weil wir dem Team eine Stimme geben (und gehört zu werden ist eines der Urbedürfnisse jedes Menschen), sondern auch um im Sinne des Scrum-Wertes „Mut” zu handeln. Denn Mut gibt uns die Kraft, die Dinge anzugehen, die uns wirklich im Weg stehen. Genauso wie es den Wert der Offenheit braucht, um  Impediments mit dem Management gemeinsam zu klären und eine bessere Situation zu erschaffen.
In diesem Sinne: Wenn Ihr Bauchgefühl nach einer Eskalation schreit – tun Sie es! Es ist auf jeden Fall mein Anspruch an mich selbst, auf diese Stimme zukünftig stärker zu hören und die Eskalationen durchzuführen, die mein Team braucht, damit es seinen Job noch besser ausführen und mehr für den Gesamterfolg seiner Firma beitragen kann als jemals zuvor.

Der Gewinner: Das mittlere Management

Letzte Woche hatte ich sie wieder: Die Diskussion darüber, dass Scrum und Kanban im Management noch immer als Methode der Softwareentwicklung oder des Projektmanagements angesehen werden. Den einen oder anderen Manager dieser Sorte gibt es sicher noch. Es ist sicher auch richtig, dass es den einen oder anderen Consultant gibt, der das, was in den funktionierenden Frameworks Scrum/Kanban ohnehin drinsteckt, wieder neu verpackt und als die neueste Managementmethode zu verkaufen versucht. All das ist vollkommen okay. Wo es einen Markt gibt, da wird es auch immer einen Anbieter geben.
Aber was können wir tun, damit das Management, oder besser gesagt die heutigen Führungskräfte, Scrum nicht als Bedrohung oder ein neues Übel sehen, das ihnen die Existenz abspricht? Niels Pfläging sagte in einem kürzlich auf InfoQ erschienenen Interview:

“The whole idea of command-and-control is wrong, and it is inseparable from management, the social technology. Management is command-and-control. It is at the heart of what organizations have to overcome to make transformation happen. Let me be clear: Management as invented by Frederick Taylor and his peers, with its explicit division between thinkers and doers, served us well during the industrial age. It was a brilliant idea 100 years ago! But the world has changed, and the Alpha way of organizing became a zombie technology. Management, quite simply, belongs onto the garbage heap of history.”

Das ist nicht hilfreich – es verschreckt. Denn wir brauchen Menschen, die andere führen. Wenn Organisationen größer werden als sieben Personen, dann werden die Dynamiken so komplex, dass Strukturen entstehen. Hier benötigen wir Menschen, die sich darum kümmern, dass die anderen sinnvoll und effizient miteinander arbeiten können. Das können wir Management nennen oder wie immer wir das wollen. Auch Morning Star, das Lieblingskind der Leute, die über selbstorganisierte Firmen schreiben, hat Manager – nämlich jeden einzelnen Mitarbeiter! Jeder ist dort ein Manager und es gibt bei Morning Star auch klare Regeln, die von den Menschen in dieser Organisation aufgestellt wurden. Eines ist jedoch klar: Das gegenwärtige, das so oft anzutreffende Management, das sich vom Geschehen in den Firmen entfernt hat, das Kreativität mit Bürokratie erstickt, das sich trotz Status, Boni und Dienstwagen langweilt und in den Burnout-Sinnkrisen versinkt: Dieses Management ist nicht hilfreich und wir müssen es befreien.

Auch Manager brauchen mal Anleitung

Marx zeigt mir jetzt sicher den Vogel: Die herrschende Klasse “befreien”? Ja! Denn sie sind es, die, ob wir es wollen oder nicht, derzeit die Regeln machen und sich wenig bis gar nicht gegen sinnlose Dinge auflehnen. In “Selbstorganisation braucht Führung” zeigen Dieter Rösner und ich, wie man als Manager wieder Spaß daran haben kann, sein Team zu führen. Doch reicht das aus? Ich glaube, wir brauchen eine ganz neue Diskussion, eine Diskussion, die dem Management zeigt, wie es seine Ziele, die es dank des Topmanagements erreichen muss, erreicht: Wie sie als Manager produktiver werden und dabei dennoch weniger arbeiten. Wie sie mit vielleicht vier Stunden Arbeit am Tag ihre Teams so steuern können, dass diese doppelt so produktiv werden. Wie sie mit dem Umstand des Skalierens von heutigen Projektgrößen so umgehen können, dass sie sich selbst als erfolgreich empfinden. Dann werden sie agil arbeiten und anfangen, daran mitzuarbeiten, die Gräben zwischen den Teams und sich selbst zu überwinden.
Wie man das macht? Indem ScrumMaster aufhören, ihre orginäre Aufgabe darin zu sehen, ein Team aus Softwareentwicklern zu steuern. Nach spätestens sechs Monaten sollte das Team (aus POs und Dev-Team) doch die meisten Aktivitäten selbst übernehmen können. Dann haben sich die ScrumMaster freigeschaufelt und können mit dem Management arbeiten. Behutsam. Wenn Ihr ScrumMaster seid: Zeigt ihnen, wie man mit dem Team arbeitet, wie man die Führung wieder übernimmt, anstatt sie an die ScrumMaster auszulagern. Vielleicht wollen die Führungskräfte dann selbst wieder einmal im Team mitarbeiten.
Wir müssen Managern zeigen, was sie selbst davon haben, agil zu werden. Dann werden sie es werden. Davon bin ich fest überzeugt.

Woran ScrumMaster ihre Effektivität erkennen

Jeder ScrumMaster stellt sich irgendwann diese Fragen:

Gibt es auf diese Fragen überhaupt eine auf messbaren Kriterien beruhende Antwort? Sehen wir uns die Fragen mal aus unterschiedlichen Blickwinkeln an. Setzen wir zunächst die Brille des einzelnen ScrumMasters auf, der in einem Entwicklungsteam arbeitet. Es gibt nur wenige absolut eindeutige und messbare Ergebnisse, die auf ein produktives Team und somit die effektive Arbeit des ScrumMasters schließen lassen:
Das Scrum-Team liefert!
Kontinuierlich produziert das Team in kurzen Iterationen Produktinkremente und liefert sie unabhängig aus. An den regelmäßigen Releases in kurzen Abständen wird dieser Rhythmus ersichtlich. Die Kunden erhalten meist schon nach zwei Wochen neue Funktionalitäten, die sie bereits nutzen können.
Geliefert wird auf hohem Qualitätsniveau
Das gesamte Team ist für eine hohe und beständige Qualität verantwortlich. Die hohe Kundenzufriedenheit lässt auf eine gute Zusammenarbeit und eine qualitativ hochwertige Produktentwicklung schließen. Ein sicheres Zeichen für eine gute Arbeit des Entwicklungsteams ist es auch, wenn der Kunde nur wenige Fehler zurückmeldet – insgesamt ist ist das auch ein Verdienst der effektiven Arbeit des ScrumMasters.

Pixabay CC0

Pixabay CC0


Neben diesen zwei direkten Anzeichen guter ScrumMaster-Arbeit gibt es einige indirekte Indikatoren, die eine hohe Effektivität in der Vorgehensweise vermuten lassen:
Das Team erkennt Impediments eigenständig
Das Aufdecken von Hürden und Blockaden im Team trägt zu einem besseren Verständnis darüber bei, was die Arbeit eines Entwicklers erschwert. Genau so wichtig ist es aber, für alle Beteiligten transparent zu machen, wie diese Hürden bearbeitet und gelöst werden. So wird das Team für das Erkennen aufkommender Impediments sensibilisiert und im besten Fall lernt es sogar, Impediments selbst zu thematisieren und zu lösen.
Das Team verbessert sich kontinuierlich
In den Retrospektiven hilft der ScrumMaster dem Team, über die eigene Arbeit zu reflektieren. Sind positive und verbesserungswürdige Punkte erst einmal identifiziert, lassen sich Maßnahmen ableiten. Auch hier arbeitet der ScrumMaster aktiv mit dem Team zusammen und versucht, das Commitment jedes Teammitgliedes zu wecken, sich selbst und somit die Teamleistung zu verbessern. Wenn der ScrumMaster das schafft, macht es sich teilweise als höhere Produktivität bemerkbar – wieder ein messbares Ergebnis.
Das Team vertraut seinem ScrumMaster
Feedback wird offen gegeben, angehört und auch angenommen. Dass das Feedback außerdem die Leistung und nicht die Person betrifft, ist ein Zeichen dafür, dass im Team Sicherheit, Respekt und Vertrauen herrschen. Das Team steht füreinander ein und sieht in jedem Mitglied den Mehrwert, den es für das Gesamtprojekt leistet. Diese Stimmung aus gegenseitiger Unterstützung, gemeinsamer Verantwortung und Austausch untereinander zu schaffen, ist eine der wesentlichsten Aufgaben eines ScrumMasters und damit ein guter Gradmesser für wirksame Arbeit.
Der ScrumMaster reflektiert und erkennt Verbesserungsmöglichkeiten an sich selbst
Ein ScrumMaster ist auf Dauer nur dann eine Bereicherung für sein Team, wenn er auch die Verbesserungspotenziale an sich selbst erkennt und nutzt. Durch ständige Reflexion der eigenen Tätigkeit versucht der ScrumMaster, sich selbst und somit seinen Mehrwert für das Team zu identifizieren und gegebenenfalls zu erhöhen.
Bewegen wir uns von der Perspektive des einzelnen ScrumMasters auf die skalierte Ebene und nehmen wir die Rolle des ScrumMasters of ScrumMaster (SoS) ein. Natürlich möchte auch er seinen Wert für die Organisation messen und bewerten können. Woran könnte er die Effektivität seiner Arbeit festmachen?
Die einzelnen Scrum-Teams liefern
Ein SoS hat seine Aufgabe erfüllt und somit einen guten Job gemacht, wenn die einzelnen ScrumMaster die Impediments ihrer Teams lösen und ihnen so beim Liefern helfen. Die Unterstützung in der Bearbeitung von Impediments gewährleistet, dass die Projekte des Unternehmens vorankommen und abgeschlossen werden können.
Teamübergreifende Impediments werden gelöst
Betrifft ein Hindernis mehr als ein Entwicklungsteam, sollten die ScrumMaster sinnvollerweise gemeinsam an einer Lösung arbeiten – der SoS unterstützt sie dabei tatkräftig. Er ermutigt seine ScrumMaster, mit offenen Augen an die Arbeit zu gehen, damit auch verdeckte Hürden aufgezeigt und beseitigt werden können.
Das ScrumMaster-Team hat eine vielfältige Methodenkompetenz
Jeder ScrumMaster sollte mehrere unterschiedliche Moderations-, Arbeits- und Führungstechniken beherrschen, um sein Team effektiv bei der Arbeit unterstützen. Der SoS sorgt für Wissensaustausch, Dokumentation und die Ausbildung solcher Kompetenzen. Somit kann er seine Effektivität an der Vielfalt der Methoden bzw. ihrer Wirksamkeit in der Umsetzung messen.
Als Team sind wir stark!
ScrumMaster haben meistens ähnliche Schwierigkeiten in ihren Teams. Umso wichtiger ist die Unterstützung und der Austausch zwischen den ScrumMastern, um nicht die Orientierung auf das übergeordnete Ziel zu verlieren. Die ScrumMaster eines Unternehmens gestalten gemeinsam die Organisation und verbreiten das agile Mindset.
Setzen wir abschließend noch die Brille des Managements auf. Lassen wir stellvertretend einen Manager sprechen, der unsere Gedanken wunderbar zu Ende bringt:
„Mit dem Scrum of Scrums möchte ich für meine Mitarbeiter die Möglichkeit zum Austausch eröffnen; einen Austausch über empfehlenswerte Arbeitsweisen im Team, aber auch über schiefgegangene Versuche, das eigene Team produktiv zu machen. Das wichtigste Ziel ist und bleibt, dass die einzelnen Teams liefern und zwar in hochwertiger Qualität und zur Zufriedenheit unserer Kunden. Ist dieses Ziel erreicht, hat der ScrumMaster seine Arbeit effektiv erledigt.“
Entstanden in Zusammenarbeit mit Cathleen Spröte und Lisa Zenker

Selbstorganisierte Teams müssen lernen dürfen

Machmal frage ich mich, ob wir vor lauter Tools und Techniken – von der Timer-Uhr für Meetings bis zu Tipps für die richtigen Umgebungsbedingungen – die Quintessenz unseres Jobs als ScrumMaster übersehen. Natürlich, das höchste Ziel des ScrumMasters ist es letztendlich, die Produktivität zu erhöhen. Es geht dabei aber nicht darum, die Teams mit Tools zu überschütten, sondern sie auf dem Weg zur Selbstorganisation zu begleiten. Es geht darum, die Kraft des Teams freizusetzen.
Scrum als Methode hat vor allem ein Ziel: Die Entscheidungen dorthin zu bringen, wo das Wissen vorhanden ist – also beim Team. Darüber hinaus ist eines der Prinzipien: learn fast and fail fast. Zu Deutsch: Mach das, was du für richtig hältst, finde eine Möglichkeit, schnell eine Ergebnis zu erhalten und dann lerne aus deinen Fehlern. So sehr wir diese Werte als ScrumMaster vertreten mögen, manchmal vergisst man dabei, was es konkret heißt.

Auch ScrumMaster müssen lernen

In einer meiner letzten Retrospektiven als ScrumMaster habe ich um Feedback gebeten. Es ging mir darum, mich selbst und meine Arbeit als ScrumMaster zu verbessern. Am prägnantesten sind mir zwei Kommentare in Erinnerung geblieben: „Entspann dich, wir müssen mehrere Stories parallel fertigstellen, die Abhängigkeiten sind einfach zu groß“ und „Lächle mal wieder“. Der Hintergrund dieser Geschichte war, dass ich mein Team immer wieder motivierte, einzelne Stories abzuschließen, statt viele Stories auf einmal zu eröffnen und parallel zu bearbeiten. Ich wusste ja, dass die Leistung bei parallelen Tätigkeiten abnimmt (siehe Synchronitis).
Und plötzlich hat es Klick gemacht. Seien wir doch mal ehrlich: Ich arbeite in einem multidisziplinären Team, ich bin nur oberflächlich in das tägliche Doing involviert und last but not least bin ich nicht die Stelle, an der die meisten Informationen zentriert sind. Sprich, ich weiß einfach nicht am besten, was das Team braucht. Das Team selbst weiß es und wenn es auch einmal falsch liegen sollte, dann muss ich darauf vertrauen, dass es lernt und es beim nächsten Mal besser macht. Das Elementare ist dabei aber nicht, jeden Fehler zu vermeiden, sondern die Möglichkeit zum Lernen zu etablieren. Schafft er das nicht, wird ein ScrumMaster immer wieder das Gefühl haben, am Ende die Kohlen aus dem Feuer holen zu müssen. Das mag dem Ego schmeicheln, funktioniert aber sicher nicht als Basis für die Selbstorganisation eines Teams.

Zeit zum Nichthandeln

Was ich von da an machte, war von außen betrachtet genau so simpel, wie es innerlich schwierig war. Ich hielt mich raus. Ich ging zum Management und sagte: „Ich kann nicht sagen, wie wir den nächsten Sprint abschließen werden. Kann sein, dass unsere Leute eine schlechtere Performance ablegen und daraus lernen. Langfristig betrachtet sollen sie sich selbst organisieren und dazu müssen sie aus ihren Fehlern lernen. Kann aber auch sein, dass sie eine wahnsinnig gute Performance hinlegen und ich mich geirrt habe. Dann habe ich sie in den letzten Monaten zu sehr darauf getrimmt, fokussiert an einer Sache zu arbeiten. Fakt ist, wir wollen selbstorganisierte Teams, also müssen wir ihnen auch den Platz fürs Lernen einräumen.“
Ja, aus dem Feedback hatte ich definitiv gelernt, dem Team Raum zu lassen, um sich zu entfalten. Ich muss ihnen den Freiraum verschaffen, möglicherweise Fehler zu machen und eventuell muss ich in meiner Rolle als ScrumMaster auch den Kopf dafür hinhalten. Denn am Ende des Tages ist und bleibt es meine Aufgabe, die Produktivität zu erhöhen und ich werde danach vom Management beurteilt. Aber ich habe vor allem auch das Management informiert und über meine Beweggründe auf dem Laufenden gehalten, denn das Management muss wissen, woran es ist. Darüber hinaus habe ich dem Team zeitweise meine Hilfe angeboten und mit einzelnen Teammitgliedern über den Stand der Dinge geredet. Was gebraucht wurde, habe ich organisiert. In anderen Punkten hat mir das Team gesagt, dass es sein Bestes tun werde, um das Commitment zu halten. Mehr kann ich mir nicht wünschen.

Der Effekt

In den letzten Tagen vor Sprintende bemerkte ich, dass eine große Anzahl an Stories noch offen war, dass aber auch kaum mehr Tasks bei diesen Stories vorhanden waren. Die Ruhe, die mich und das Team umgab, war Neu. Die Teammitglieder hetzten nicht, sondern arbeiteten konzentriert und Sie committeten eine Vielzahl von Stories (aus meiner Sicht zu viele). Der Druck war hoch, aber alle blieben ruhig. Zum ersten Mal hatte ich das Gefühl, dass es ihr Sprint war, weil sie für ihre Fehler und Erfolge gerade stehen durften und es nicht für jemand anderen taten.
In diesem Sinne: Lassen Sie als ScrumMaster Ihrem Team die Luft zum Atmen. Es fällt schwer, die Dinge aus der Hand zu geben, aber echte Selbstorganisation braucht Raum für Fehler, um sich entfalten zu können. Und was Sie nicht vergessen sollten: Halten Sie das Management am Laufenden – schließlich ist Transparenz einer der Grundwerte von Scrum.

Entscheidungsgremien: Erfolgsfaktor in agilen Projekten?

In einem unserer Projekte ging es darum, einen Systemverbund zu stabilisieren, der bisher durch eine fehlerverursachende Schnittstelle nur eingeschränkt genutzt werden konnte. Im Vorgängerprojekt sollten die beiden Systeme zusammengeschalten werden – es wurde klassisch abgewickelt und musste schließlich wegen Erfolglosigkeit gestoppt werden. Wegen der guten Erfahrungen mit Scrum in anderen Projekten lag es nahe, im zweiten Anlauf den agilen Ansatz zu wählen – hier kam ich ins Spiel. Und bevor ich weitererzähle, hier mein Appell gleich zu Beginn: Seid bereit, das Management aktiv an die Hand zu nehmen. Sie werden es euch danken!

Klassische Wünsche im agilen Rahmen

Schon in der Setup-Phase wurde klar, dass im vorherrschenden Umfeld ein tatsächlich agiles Projektvorgehen eine wahre Herausforderung werden wird. Erstens lastete hoher Druck auf dem Projekt, die Systeme endlich stabil zu bekommen und jede Form von Mehrkosten zu vermeiden. Zweitens wurde das Projekt noch mit einem zusätzlichen Gesamtprojektleiter, der übergeordnet die Verantwortung für das Projekt trug, besetzt. Und drittens hatten die entscheidenden Personen, allen voran das Top Management in Form eines Lenkungskreises, alles andere als agile Ansätze im Sinn. Beginnend mit der Forderung nach einem Reporting mit dem Fokus auf Budget und Zahlen kam auch schnell die Frage nach dem „großen“ Projektplan über die angesetzten 6 Monate auf. Was wird bis Datum XY geliefert und viel wichtiger: Was kostet dieses Unterfangen?

Ein Schritt zurück, um vorwärts zu kommen

Um dem Management einen groben Projektplan zu bieten, erarbeiteten die Product Owner mit Unterstützung der ScrumMaster einen physischen Releaseplan mit Post-Its. Dabei planten sie nach dem Eisberg-Prinzip: die kommenden Sprints detailliert und die zukünftigen Sprints auf höherer Ebene. Mit diesem Instrument konnten sie nun auch auf Gesamtprojektsicht einen Plan vorweisen. Anfangs wurde das noch skeptisch beäugt und als schwammig kritisiert. Das größte Hindernis war dabei wohl, dieses Nichtvorhersagen-Können zu akzeptieren. In traditionellen Projekten gibt man sich von Anfang an der Illusion hin, alles bis zum letzten Tag hin genauestens geplant und damit im Griff zu haben. Den Schritt zurück zu machen und zu akzeptieren, dass der Plan sehr wahrscheinlich so nicht eintreten wird, ist schwierig, aber notwendig. Es gelang in diesem Projekt und im Laufe der Zeit entwickelte sich der Releaseplan zu einem zentralen Planungsinstrument.
IMG_0464 Kopie 3

Sehen, worüber wir reden

Trotz des Releaseplans traf das Management in seinem Lenkungskreis (in dem nur der Gesamtprojektleiter, aber kein Product Owner oder ScrumMaster vertreten war) Entscheidungen, die mehr oder weniger große Auswirkungen auf unser Projekt und unseren Releaseplan hatten. Jedes Mal passten die Product Owner resigniert den kompletten Releaseplan an die neuen Entscheidungen an. Bei der x-ten Diskussion über Inhalt und Budget nahmen wir ScrumMaster schließlich das Zepter in die Hand. Wir forderten das Management auf, seine Diskussionen zu neuen Entscheidungen direkt mit uns – den ScrumMastern und Product Ownern – vor unseren Artefakten zu führen und Befürchtungen mit uns zu besprechen. Um es kurz zu machen: Das war die beste Entscheidung, die wir je treffen konnten. Noch nie zuvor hatte es zwischen dem Management (dem Lenkungskreis) und den Projektverantwortlichen einen so regen Austausch über den Scope und das Budget des Projekts gegeben. Alle Unklarheiten wurden geklärt und wir erzielten ein gemeinsames Commitment. Die Teams hielten dieses Commitment auch ein und lieferten.
Im Nachhinein hat es über den Erfolg des Projekts entschieden, dass das Top Management eingebunden wurde und sich mit den Verantwortlichen direkt und regelmäßig ausgetauscht hat. Wie oft hatten wir in der Vergangenheit das Gefühl gehabt, dass reines „Management by Desk“ praktiziert wurde, ohne zu wissen, wie es um das Projekt wirklich bestellt war. Wie oft hatte das Projektteam Angst vor folgenschweren Entscheidungen im Lenkungskreis. Angst davor, dass das Projekt gestoppt werden könnte, trotz erster nachweisbarer Erfolge. Angst vor Budgetkürzungen, die uns den notwendigen innovativen Freiraum nehmen könnten.
Daher nochmals mein dringender Appell: Nehmt euer Management an die Hand! Führt es zu den Artefakten und trefft dort mit den richtigen Personen die richtigen Entscheidungen — gerade und vor allem in traditionell geprägten Unternehmen.

Multikulti – vom Umgang mit Internationalität in Projekten

Wir reden immer davon, dass es bei verteilten, global verstreuten Teams um das Verständnis geht, dass Amerikaner eine andere Kultur als die indischen Kollegen haben (Stichwort Skalierung). Es geht also immer darum, die unterschiedlichen Nationalitäten im Blick zu haben und deren Kultur zu verstehen. Bei meiner Arbeit mit internationalen Teams bin ich zu einer anderen Schlussfolgerung gelangt: Internationale Firmen haben selbst eine Kultur. Sicher, es gibt Einflüsse – Lokalkolorit. Aber die Kultur eines Unternehmens ist viel stärker als die des Landes.
Schaut man genau hin, dann sind die auftretenden Probleme oft nicht der unterschiedlichen Landeskultur zuzusprechen, sondern der Tatsache, dass sich zugekaufte Firmen nicht in den internationalen Konzern eingliedern lassen. Klar, Amerikaner ticken ein wenig anders als Deutsche – aber dass die Firma zugekauft wurde, eine andere Firma war, eine andere Art des Umgangs miteinander hatte, ist viel wichtiger und hat größeren Einfluss auf das Selbstverständnis des Einzelnen in einem Unternehmen als seine Nationalität.
Besonders deutlich wird das, wenn man Scrum in Hardware- oder Medizintechnik-Projekten einführt und cross-funktionale, multidisziplinäre Teams aufbauen will: Da bemerkt man plötzlich, dass nicht nur Tester und Entwickler in einer Abteilung unterschiedlich funktionieren, sondern dass es vollkommen andere Weisen gibt, die Welt wahrzunehmen. Wenn Ingenieure auf Biologen oder Chemiker treffen, wenn Metallfacharbeiter sich mit Elektrikern unterhalten sollen, wenn Grafiker sich mit Softwareentwicklern unterhalten, dann treffen die verschiedensten Weltbilder aufeinander.
Das wäre ja nicht weiter tragisch, wenn sich alle darüber im Klaren wären, entsprechend viel Zeit für den gemeinsamen Abgleich einplanen würden und das Management verstehen würde, dass es hier zu Konflikten kommen muss. Doch auch das Management hat natürlich seine blinden Flecken. Einige von ihnen waren vielleicht Ingenieure und sehen die Welt von ihrer Warte, andere sind Soziologen, Biologen oder Chemiker. Da wird oftmals gar nicht verstanden, was der andere meint oder warum er diesen und nicht jenen Zugang wählt.
Das alles sind lösbare Probleme und genau das ist die Aufgabe von ScrumMastern. Doch was passiert jetzt: Diese Teams sollen sich nicht nur aus unterschiedlichen Disziplinen, sondern auch noch aus unterschiedlichen Nationen an unterschiedlichen Standorten zusammensetzen. Vielleicht aus der Not heraus, weil es gar nicht anders geht. Nun wirken oft die Kräfte des Separatismus: Die Vertreter jeder Disziplin verstehen sich untereinander besser als mit den anderen. Sind diese auch noch verteilt, entsteht schnell ein Abwehrhaltung gegen die Kollegen am eigenen Standort, wenn dieser von einer anderen Disziplin ist und in der Minderheit. Oft nimmt man sich nicht die Zeit, sich wirklich kennenzulernen. Die ScrumMaster haben oft gar keine Chance – denn sie sind nicht vor Ort, sie steuern ihre Teams mit Hilfe von Tools und einem Video Conference Call. All das sind wirklich harte Bedingungen. Es wird noch schwerer werden, garantiert. Es wird immer öfter zu Konstellationen dieser Art kommen.
Doch eines wird sich durchsetzen: der Wille zu liefern. Der Druck auf Unternehmen, die so arbeiten (müssen), wird so hoch werden, dass sie sich etwas einfallen lassen werden. Sie werden Teams temporär zusammenziehen, sie werden wieder Menschen nahe zusammenbringen. Wenn Firmen wie Google und Facebook das können, wenn Apple in Cupertino ein Gebäude genau aus diesem Grund heraus baut, damit alle zusammen sind, dann sind diese Firmen schon längst wieder auf dem Weg, die Internationalisierung zugunsten der Produktivität zu reduzieren.
Die Voraussetzung dafür, dass dies gelingen kann: Eine gute Führung. Separatismus, das Auseinanderbrechen von Teams, kann sehr einfach verhindert werden – durch gute Führung. Durch eine Führung, die innerhalb des Teams, innerhalb der Abteilung und innerhalb der Firma die „gleiche“ Kultur schafft. Die gemeinsame Firmenkultur ist in der Lage, die Menschen zum Zusammenarbeiten zu bringen und Ungleichheiten vergessen zu machen. Die Aufgabe von Führungskräften wird schwerer werden. Scrum kann die Themen schneller ans Licht bringen. Lösen müssen es die Beteiligten zusammen.

Who should be in (agile) HR?

In his short article “It’s time to split HR” Ram Charan proposes to split HR into an administrative department and a department for leadership and organization. His main point is that HR members need experience in other management functions such as i.e. finance. His criticizes that most of the current HR people cannot relate to business issues from the „real world“. I understand what his point is all about. People who study HR usually want to work with people and help them to release their potential. But this seems rather difficult as HR is mostly sitting in parts of the building with restricted access for “real world” people due to confidentiality reasons. The majority of them become experts in one specific field of HR (i.e. training, recruiting). Again, relating to business issues from the “real world” is rather difficult.
In an agile organization I would propose the ScrumMasters / agile coaches to take some of the HR duties. Mainly those that concern leadership and organization, but also, from time to time, administrative duties. Such a setup creates links to product development teams and their daily business issues. The ScrumMasters, being lateral leaders, know what it means to solve these “real world” problems – also known as impediments.
ScrumMasters are responsible for increasing the productivity of development teams. In order to reach their goal, they are supposed to change the organization as needed. Being involved in HR activities would be the perfect opportunity to create a link between the HR expertise and the “real world”. The adjustment of “People Systems”, as described by Jay Lorsch in the Strategy Pyramid, would be much easier. Also the other way round: the integration of the HR perspective into change initiatives would be given at any time.
What I also like about the idea of Charan is that HR is not a job position for life. Rather it should be a “pass through”, where one can gain experience in another field of management. In an agile organization this could mean that ScrumMasters and HR experts organize themselves in communities of practice. This way, they can work together and contribute to the success of the enterprise in different ways, for example like this:

For a limited amount of time, ScrumMasters can be solely engaged in HR activities. Still it is mandatory that they return into leading a team after a certain HR deliverable has been released. An HR deliverable could be a new training, a cultural change that is clearly visible, new processes etc. But not only ScrumMasters can engage in HR topics, also other team members can take part in the communities of practice. How? The ScrumMasters and HR experts will find a way!

Egal, was es ist: Ich war's nicht!

Scrum ist großartig. Entscheidungen werden dort getroffen, wo die größte Kompetenz liegt. Nur was, wenn mein Team das gar nicht so großartig findet? Wenn die Teammitglieder lieber tun, was man ihnen sagt? Dann sind sie hinterher, falls etwas schief geht, wenigstens nicht schuld. Schuldkultur führt zu Pflichterfüllung statt Verantwortungsübernahme. Wenn ich das als ScrumMaster erkannt habe, wie kann ich dann damit umgehen? Wie schaffe ich es, meinem Team Mut zu machen, selbst Entscheidungen zu treffen?

1. Rahmen schaffen Sicherheit

Je größer das Sicherheitsbedürfnis, desto enger sollte der Rahmen sein, um kleine Entscheidungen mit geringfügigen Konsequenzen treffen zu können. Mit der Erfahrung kommt das Vertrauen. Das Vertrauen liegt übrigens auf beiden Seiten: Bei demjenigen, der Verantwortung übernimmt ebenso wie bei dem, der Kontrolle abgibt.
Jeder ScrumMaster kennt die Situation am Anfang einer Scrum-Einführung: Im Daily stehen alle Teammitglieder in einem großen Sicherheitsabstand zum Board, niemand will etwas sagen müssen.
Durch die 4 Fragen

geben wir dem Daily einen engen Rahmen. Die Teammitglieder haben nicht viel eigenen Gestaltungsspielraum. Es entsteht umso mehr Vertrauen, je häufiger Dailies gemacht werden. Der ScrumMaster macht die Erfahrung, dass das Team die 15 Minuten nutzt, um sich auszutauschen. Beim Team entsteht das Vertrauen, dass der Termin nicht dazu gedacht ist, sie zu kontrollieren. Ebenso wie im Beispiel ‘Daily’ funktioniert das mit dem Scrum-Framework als Ganzes. Der feste Rahmen gibt den benötigten Freiraum.

2. Schulddiskussionen rigoros unterbinden

Es ist wichtig herauszustellen, dass die Frage, wer schuld ist, gänzlich uninteressant ist. Jedwede Diskussion der Schuldfrage muss vom ScrumMaster sofort unterbrochen werden. Für eine konstruktive Analyse der Ursachen bieten sich die 5-Warums und die Fischgräten-Analyse an. Die Erfahrung, nicht vorgeführt zu werden, wenn etwas nicht wie erwartet funktioniert hat, schafft Vertrauen.
Mein persönlicher Erfolg war, als eines Tages ein Kollege sagte: „Da standen drei Leute aus drei verschiedenen Abteilungen vor dem Gerät zusammen, und statt wie früher drei Tage lang darum zu streiten, wer schuld ist, haben wir innerhalb von ein paar Stunden eine Lösung erarbeitet.”
Lächeln auf den Gesichtern. Stille Freude und Stolz, dass sie es geschafft haben, die lästige Schuldfrage hinter sich zu lassen.

Die vier Spielfelder der Teamkommunikation

Agile Teams organisieren ihre Prozesse, Strukturen und ihre Performance über ein hohes Maß an Kommunikation. Kurz gesagt, Selbstorganisation ist gleich Kommunikation. Für die Führung agiler Teams, ob disziplinarisch oder lateral, gehört das Initiieren und Gestalten von funktionalem, aber auch sozialem Austausch zu den zentralen Aufgaben. Die verschiedenen “Spielfelder”, die für die interne Teamkommunikation relevant sind, müssen im Auge behalten und bei Bedarf aktiv entwickelt und gesteuert werden.
Teamkommunikation findet grundsätzlich auf zwei Ebenen statt. Zum einen auf der sachlich-fachlichen und zum anderen auf der emotional-sozialen Ebene. Beide können natürlich nicht wirklich unabhängig voneinander betrachtet werden, sie wirken in der Praxis permanent aufeinander ein. Es zeigt sich jedoch in den Teamprozessen, dass im Alltag situativ unterschiedliche Schwerpunkte zu erkennen sind und die vier Spielfelder durchaus unterschiedlich gut funktionieren können. Folgendes Modell kann für Teamentwickler und Führung eine Folie zur Analyse und Intervention bezogen auf die komplexe Teamkommunikation sein.
Spielfeld_Teamkommunikation
Im Mittelpunkt von selbstorganisierter Teamarbeit steht naturgemäß das Feld Fachinformation und Austausch – im Sinne von fachlichen und organisatorischen Absprachen, gegenseitigem Lernen. Kommunikation in diesem Feld entscheidet wesentlich über die Performance des Teams. Probleme können dann entstehen, wenn es im Team Wissensmonopole gibt, wenn nicht genügend Zeit für den Austausch zur Verfügung steht oder sich genommen wird, unklare Botschaften gesendet werden, z.B. zu viel E-Mail statt direkter Austausch, etc.
Entwicklungsfragen zu diesem Feld sind u.a.:

Das Feld Auseinandersetzung ist gekennzeichnet von hoher, z.T. unkontrollierter,
Emotionalität. Es steht in der Regel für ungelöste, eskalierende Konflikte und deren
Dominanz über die sachliche Kommunikation. Die eigentliche Arbeit wird partiell aus den
Augen verloren, es droht Schwächung der Leistung. Es kommt zu Koalitionen, die intensiv
miteinander kommunizieren und sozialem und kommunikativem Ausschluss von
einzelnen oder Teilgruppen usw. Es kann aber auch sein, dass Auseinandersetzungen
zu stark vermieden werden, Harmonie über alles gestellt wird. Das bedeutet oft
Stagnation und Mittelmaß, bzw. die Gefahr unvermittelter Eskalationen.
Entwicklungsfragen zu diesem Feld sind u.a.:

Das Feld Small Talk definiert die entspannte, beziehungsorientierte Kommunikation im Team. Hier wird über Privates und Alltägliches gesprochen und soziales Miteinander gepflegt. Small Talk ist wichtig für den Abbau von Stress und das persönliche Kennenlernen auf einer nicht leistungsbezogenen Ebene. Und ein oft unterschätztes Element von Teamgeist und Wir- Gefühl. Probleme können hier eigentlich kaum auftreten, höchstens wenn zu viel oder zu wenig Small Talk läuft.
Entwicklungsfragen zu diesem Feld sind u.a.:

Spannend ist das Feld des Dialogs. Hier kommuniziert das Team im kooperativen Dialog und bearbeitet gemeinsam vor allem komplexe fachliche Probleme und innovative Themen. Dieses Spielfeld heißt, in unterschiedlichen Meeting- und Workshop-Formaten zu kommunizieren und sich mit positiver Emotionalität, Engagement für das Ganze und hoher Fachkompetenz einzubringen. Dialog heißt Austausch auf höchstem Niveau und immer mit dem Fokus auf der Sache. Probleme können hier mangelnde Dialogbereitschaft, “Kopfmonopole”, schlampige Meetings, fehlende Methoden, zu wenig Beteiligung u.a. sein.
Entwicklungsfragen zu diesem Feld sind u.a.:

Diese vier Felder kennzeichnen die komplexe und anspruchsvolle Vielfalt der Kommunikationsprozesse in selbstorganisierten Teams. Weit mehr als in konventioneller Teamarbeit sind alle im Team aufgefordert, diese vier Felder optimal mitzugestalten und zu entwickeln. Führung als funktionales Mitglied des Teams sollte sich hier schwerpunktmäßig als Moderator, Impulsgeber und konstruktiv-kritischer Beobachter verstehen und sich entsprechend einbringen. Das heißt, Feedback geben, ggf. Trainer sein, Rahmenbedingungen schaffen, Impediments aus dem Weg räumen.
Wie im Fußballspiel: Auf dem Platz spielt dasTeam, in der Kabine agiert der Coach.
Wie geht das – die Kommunikation im Team fördern und gestalten? Antworten darauf gibt es im Training “Team Bo
oster” mit Dieter Rösner – alle Infos hier

Muss ich, soll ich, will ich meine ScrumMaster loben?

Als Führungskraft oder Manager kommt man in der Literatur, in den Medien, in Seminaren etc. an den folgenden Aufforderungen nicht vorbei: „Loben Sie“ , „Anerkennen Sie Leistungen“ und „Wertschätzen Sie Ihre Mitarbeiter“. Jedes Mal, wenn ich diese Aufforderungen höre, folgen darauf meist zwei unterschiedliche Antworten von zwei Typen von Managern:

Weder bei Typ 1 noch bei Typ 2 fühlen sich die Mitarbeiter ausreichend für ihr Engagement und ihre Leistung anerkannt oder wertgeschätzt. Fazit: Sie sind demotiviert und unzufrieden.
Mögliche Fehler des Typ-1-Managers:
Er lobt einfach nicht, weil er keinen Mehrwert dahinter sieht und nicht so ganz versteht, warum seine Mitarbeiter Lob von ihm brauchen. Meistens sind diese Typen von Führungskräften jene, die selbst selten gelobt werden. Ihnen reicht die Leistung an sich, um sich zu motivieren. Sie benötigen keine weiteren Verstärker, um motiviert und zufrieden  zu sein. Leider verstehen sie auch nicht, dass ein Zuspruch, Lob oder ein positives Feedback die Motivation ihrer Mitarbeiter verstärken kann. Führungskräfte sollten nicht den Fehler machen, von sich auf andere zu schließen.
Mögliche Fehler des Typ-2-Managers:
Dieser lobt jeden und alles. Jeder Mitarbeiter wird für die kleinste, noch so einfache Tätigkeit großzügig gelobt. Dieser Manager nimmt sich die Aufforderung zum Wertschätzen sehr zu Herzen und übertreibt maßlos. Leider führt das oft dazu, dass seine Mitarbeiter das Lob als wertlos einstufen, da sie viel zu oft und viel zu großzügig gelobt werden.
Nun stellt sich doch die Frage: Was wollen Mitarbeiter eigentlich? Lobt man sie nicht, sind sie unzufrieden. Lobt man sie öfter, sind sie wieder unzufrieden? Meistens höre ich diese Fragen, wenn es um ScrumMaster geht, denn Führungskräfte und Manager verfallen leider in der Zusammenarbeit mit ihren ScrumMastern sehr schnell in die Muster der vorgestellten Typen 1 und 2. In mehreren Studien konnte nachgewiesen werden, dass Lob und Anerkennung von Leistungen und Engagement dazu führen, dass Mitarbeiter produktiver und motivierter arbeiten – und vor allem sind sie zufriedener mit ihrer Arbeit. Auch ScrumMaster brauchen Lob, Wertschätzung und Anerkennung für ihre Arbeit, ihr Engagement und ihre Leistungen, denn die meisten ScrumMaster haben in dieser Rolle weder finanzielle noch hierarchische Benefits. Angemessenes Lob, angemessene Wertschätzung und Anerkennung motivieren und verbessern das Arbeitsklima. Und das kommt jedem Veränderungsprozess zugute!
Aber wie lobt man nun „richtig“? (Und ja, man sollte auf jeden Fall loben!)
Natürlich möchte ich nicht die absoluten Naturtalente außer Acht lassen. Ich lerne immer wieder Führungskräfte kennen, die Lob und Wertschätzung aussprechen, ohne dass es ihnen auffällt. Sie machen es ganz locker nebenbei, sie denken nicht nach, sie haben einfach einen Instinkt, der sie genau und gut anleitet. Wenn Sie eine solche Führungskraft sind, haben Sie meistens ein Team, das einfach gerne für Sie arbeitet und hoch motiviert ist. Ja es gibt sie, die lobenden Naturtalente, aber für alle anderen gilt es, ein paar Punkte bei Lob und Anerkennung zu beachten.

Wann ist ein ScrumMaster erfolgreich?

Woran erkennt man einen erfolgreichen ScrumMaster bzw. welche Kriterien könnten herangezogen werden, um einen ScrumMaster als erfolgreich zu bezeichnen
Ich selbst bezeichne mich als erfolgreichen ScrumMaster, wenn ich

In der Realität ist es etwas schwieriger, diese Vorhaben umzusetzen und somit als ScrumMaster erfolgreich zu sein. Es gibt immer wieder Teams, denen die Umstellung auf Scrum sehr schwer fällt und die neue Arbeitsweisen anfangs ablehnen.
In diesen Teams ist es umso wichtiger, einen ScrumMaster zu haben, der das Team an Scrum heranführt und den Sinn sowie den Zweck der Meetings, Artefakte und Rollen in Scrum dem Team näher bringt. Während sich dieses Vorgehen in der Theorie sehr einfach anhört, gibt es in der Realität Teams, die zu Meetings kommen und angeben, sie seien nur anwesend, “weil sie dazu ja gezwungen werden“. Diese Meetings verlaufen dann in etwa so: Die Teammitglieder sind demotiviert und geben dem ScrumMaster das Gefühl, dass sie dieses Meeting über sich ergehen lassen. Sie meckern bei jedem einzelnen Punkt gefühlte 20 Minuten, damit man auch ja weiß, dass sie keine Lust haben. In dem ganzen Unmut bin ich der ScrumMaster. Ich bin motiviert, ich glaube an mein Team und an mein Ziel. Ich weiß, dass ich es schaffe, das Team zu motivieren und anzuleiten um mitzumachen. Ich schaffe es, sie von den Vorteilen in Scrum zu überzeugen. Das sind mal Ambitionen. Leider vergehen diese, zwar nicht sofort, aber mit der Zeit, und das Team gibt einem auch noch das Gefühl, es hätte seine Sache doch gut gemacht. Das Team hat es schlussendlich doch geschafft, den ambitionierten ScrumMaster zu frustrieren.
In einem dieser Teams, bei dem ich glaubte, dass mein Tun einfach nichts weitergebracht hatte und nichts von dem angekommen war, was ich gesagt oder getan hatte, passierte etwas.
Ja, es passierte tatsächlich: Ich, der ScrumMaster, war erfolgreich. Nicht in dem Sinne wie ich mich persönlich als erfolgreich bezeichnet hätte, aber ich war es. In einer Diskussion zwischen dem Product Owner und der Geschäftsführung sagte der PO: “Ja, der ScrumMaster hat gesagt, wir sollen das so machen …“ Daraufhin mischte sich ein Teammitglied ein und sagte: “Der ScrumMaster hat so etwas nicht gesagt.“ Es war auch so gewesen: Ich, der ScrumMaster, hatte niemandem gesagt, wie er oder sie etwas zu tun hat – und das Team hat mich in Schutz genommen, vor dem Manager und dem PO. Ich hatte es geschafft! Es hatte sich etwas bewegt, ich war erfolgreich.
Wir ScrumMaster dürfen einfach nicht außer Acht lassen, was wirklich ein Erfolg ist und dieses unwillige und demotivierte Team hat mir gezeigt, was es heißt, erfolgreich zu sein. Ein ScrumMaster darf sich als sehr erfolgreich bezeichnen, wenn er es geschafft hat, dass sein Team hinter ihm steht. Ich habe es geschafft, mein Team steht hinter mir und es fühlt sich wirklich wirklich gut an.

Der ScrumMaster – zwischen Stühlen und Fronten

Ort: Meetingraum
Zeit: 08:47
Zweck des Meetings: Sprint Planning 1
Die Beteiligten meiden Augenkontakt. Hochrote Köpfe, betretene Stille. Es geht nicht mehr weiter. Soeben haben sich zwei erfahrene Entwickler des Teams mit dem Product Owner angelegt.
Streiten. Der Product Owner fordert eine sehr große Story für den zu planenden Sprint, weigert sich jedoch, sie zu splitten. Sie in zwei zu teilen. Die Gründe dafür verstehen die Entwickler nicht. Sie verweigern das Commitment. Als ScrumMaster kann ich der Diskussion aus fachlicher Sicht schon lange nicht mehr folgen. Ich fühle mich gelähmt, frustriert, fast unfähig, zum Ziel des Meetings, dem Commitment zu führen. Klar ist mir nur eines: Die Gründe für diese Bewegungslosigkeit liegen im Verborgenen. Weit unter der Oberfläche, denn die Entwickler überzeugen sachlich und argumentatorisch auf ganzer Linie.
Als klar wird, dass es nicht mehr weitergeht, wird das Commitment um einen verträglichen Zeitraum verschoben, um eine Klärung herbeizuführen und die Gemüter zu beruhigen.
Nach ca. einer Stunde kommt der Product Owner zum Team, lenkt ein und stimmt sichtlich erbost zu, die Story doch noch anzupassen. Die Situation scheint gelöst.
Weit gefehlt.
Nach ein bis zwei Stunden taucht die Story im Computersystem wieder auf und … ist unformuliert, aber nicht gesplittet. Die Verärgerung ist den Entwicklern am ganzen Körper und vor allem an ihrer Gesichtsfarbe anzusehen. Die Entwickler bitten mich mit meinen „politischen Fähigkeiten“ – so die Entwickler – um Hilfe und darum, zum Product Owner zu gehen und letztlich zu erbitten, was er doch zugesagt hatte: Die Story in zwei kleinere zu splitten. Ich stimme zu und mache mich sofort auf den Weg.
Ich, als Fachfremder, sehe meine Chance, mir weiteres Standing beim Team zu verdienen. Nun bin ich gefordert und kann meine Fähigkeiten unter Beweis stellen. “Hoffentlich”, denke ich. Es fühlt sich wie ein bewegender Schlüsselmoment für mich und die weitere Zusammenarbeit mit meinem Team an. Ist doch sonst so schwer spürbar, was man an einem langen Tag geleistet hat.
Reden. Ich betrete das Büro des Product Owners. Leider sitzt er noch nicht beim Team. Änderung ist jedoch in Sicht. Ich begebe mich freundlich zum Product Owner und frage ihn mit einem einladenden Lächeln, ob er mir drei Minuten seiner Zeit schenken kann. Ich setze mich zu ihm und danke für die Bereitschaft, über die Story zu sprechen. Ich nehme eine ähnliche Körperhaltung ein wie er, um eine positive Stimmung zu erzeugen und bitte ihn erneut, die Story zu teilen. Es braucht drei Minuten freundliche Worte und ein wenig Small Talk. Der Product Owner stimmt zu, die Story gemeinsam mit mir so umzuformulieren, dass das Entwicklerteam umgehend bereit ist, sein Commitment abzugeben.
„Wie leicht war das denn?“, frage ich mich, kehre voller Stolz zum Team zurück und verbreite die gute Nachricht. Das Team kann nun die neu entstandene und kleinere Story committen.
Verbinden. Ich spüre Freude, Stolz und Erfolg auf ganzer Linie. Mir wird bewusst, was es heißt, ScrumMaster zu sein. Wir ScrumMaster sind das Sprachrohr zwischen den Gemütern, die Mittler zwischen den Parteien, die Mediatoren und Psychologen. Die mit den geheimnisvollen Soft Skills, die Impediments jedweder Art aus dem Weg räumen. Es wird klar, wozu es uns ScrumMaster braucht. In vielen Fällen blockieren die Dinge aufgrund von Befindlichkeiten, Ängsten, Politik oder zwischenmenschlichen Themen.
In meinem Fallbeispiel wird sehr deutlich, dass es oft nur der richtigen Ansprache oder dem Schaffen einer positiven Stimmung braucht, um ein gemeinsames Ziel zu erreichen.
Erschöpft und zufrieden zugleich sinke ich in meinen Bürostuhl und kann kurz darauf das Sprint Planning 1 mit einem einstimmigen Commitment des Teams beenden.
Was habe ich aus meinem Erlebnis mitgenommen? Zum einen wird mir klar, wie wichtig regelmäßige und qualitativ wertige Estimation-Meetings sind, an denen immer alle Teammitglieder teilnehmen. Zum anderen sehe ich die Vorteile, als externer ScrumMaster tätig sein zu können. Frei von Ängsten oder gar Abhängigkeiten kann ich mit verschiedensten Vertretern eines Unternehmens kommunizieren.

Der ScrumMaster als Identitätsstifter

ScrumMaster sind dazu da, die Produktivität ihrer Teams zu erhöhen. Gerade in Projekten mit hohem Erfolgsdruck ist diese Erwartung deutlich zu spüren. Vorbei die rosaroten Zeiten, als der ScrumMaster sein Team von den wirtschaftlichen Zwängen der Wirklichkeit zu befreien suchte. Das ist eine gute Entwicklung, denn sie gehört zum Erwachsenwerden dazu. Damit Scrum auch von Vorständen und Geschäfsführern ernst genommen wird, müssen ScrumMaster zur Führungsinstanz werden, auf die sich Top-Manager verlassen können.

Nötig: ein eigener Führungsstil

Macht dieses Bild aus ScrumMastern bloße Erfüllungsgehilfen des Top-Managements? Verkümmert der ScrumMaster zum verlängerten Arm der Geschäftsleitung? Die Gefahr besteht immer dann, wenn der ScrumMaster zu schwach ist, um einen eigenen Führungsstil zu entwickeln. Dann ist er schlimmstenfalls das Sprachrohr anderer Leute – und dazu noch ohne disziplinarische Führungskompetenz.
Aktuelles Beispiel: Ein strategisch wichtiges Projekt, in das viele Ressourcen gesteckt wurden, steht auf der Kippe. Das Top-Management steht unter Druck und gibt diesen Druck an die Scrum-Teams weiter. Begründung: Allen beteiligten Akteuren soll klar werden, wie wichtig dieses Projekt und die Einhaltung von Lieferterminen ist.
In einer solchen Situation kann der ScrumMaster zwei Dinge tun: Entweder stellt er sich entschieden gegen das Management und versucht, das Team von dieser Drohkulisse so gut wie möglich fern zu halten. Oder er gibt nach und erhöht selbst den Druck auf das Team. Beide Optionen sind für die Legitimität des ScrumMasters fatal, denn er riskiert den Vertrauensbruch mit der einen oder der anderen Seite.
Gibt es aber eine dritte Möglichkeit – eine, die weder auf Gehorsam noch auf Rebellion basiert? Kann ein ScrumMaster die Erwartungen des Managements mit den Erwartungen des Teams zusammenbringen, ja vielleicht sogar versöhnen? Damit das gelingen kann, müssen ScrumMaster sich auf ihre ureigene Stärke zurück besinnen: Die soziale Bindung an ihr Team. Ein ScrumMaster ist nur in zweiter Linie Facilitator, Servant Leader und Change Agent. Primär ist er Teil des Scrum-Teams und sitzt damit mit dem DevTeam und dem Product Owner im gleichen sozialen System.

Unbezahlbar: die großen und kleinen Gesten

Das eröffnet ihm ganz eigene Möglichkeiten, die nicht auf den klassischen Einflussfaktoren Macht und Geld beruhen. Die vielen kleinen und großen Gesten eines guten ScrumMasters – vom Bereitstellen einer wohligen Arbeitsatmosphäre bis hin zur intensiven Auseinandersetzung mit jedem Teammitglied – sie dienen allesamt dazu, eine Form der Transaktion innerhalb des Scrum-Teams zu schaffen, die nicht auf den Normen des Marktes, sondern auf sozialen Normen basiert.
Und hier liegt auch die Chance des ScrumMasters. Er kann sein Team mit genügend Selbstbewusstsein und Ehrgeiz impfen, dass es auch stürmische Zeiten erfolgreich meistert. Er schafft das, indem er die Identität seines Teams stärkt. Mit “Identität” meine ich ein Selbstbild, das eigentümlich genug ist, um das Team von anderen Gruppe abzugrenzen. Man kann in diesem Zusammenhang auch von Idiosynkrasie sprechen.
Ein Beispiel: Ich fragte neulich ein Teammitglied, warum er und seine Teamkollegen die Einladung eines (neuen) Kollegen ausgeschlagen haben, als dieser sie zu sich nach Hause zum Abendessen einladen wollte. Die Antwort war verblüffend: “Wir sind im Unternehmen die Außenseiter – wir versuchen erst gar nicht, uns beliebt zu machen.” Dazu muss man wissen: Das Team war in einem Projekt unterwegs, das allseits unbeliebt und von ständig wechselnden Anforderungen sowie Stillständen gebeutelt war. Das für dieses Projekt eingesetzte Scrum-Team hat den Lärm von außen ignoriert und ist seinen eigenen, oftmals rauen Weg gegangen. Dabei hat es offenbar eine eigene Identität – die des rebellischen Außenseiters – entwickelt. Damit war es erfolgreich: In nur sechs Monaten gelang es ihnen, gegen alle Erwartungen die Entwicklung zu einem glücklichen Ende zu bringen.
Als ScrumMaster habe ich vielfache Möglichkeiten, auf die Identität des Teams Einfluss zu nehmen: Das Review, die Retrospektive, die Dailies… das sind alles Happenings, in denen das Team Bilder von sich selbst produziert und dabei seine eigene Identität konstruiert. Als ScrumMaster kann ich im Sinne eines Stifters oder Förderers bestimmte Entwicklungen gezielt unterstützen und andere hinterfragen. Das hier genannte Team war zum Beispiel stets der Gefahr ausgesetzt, in Selbstgerechtigkeit und -mitleid zu verfallen. Hier konnte ich etwa durch paradoxe Interventionen dafür sorgen, dass mein Team die Bodenhaftung nicht völlig verlor. Auf der anderen Seite gab ich unserem Team reichlich Raum, um erfolgreiche Sprints zu feiern und jeden Tag den eigenen Weg zu bestärken. Hierzu ist es essenziell, dass das Team den gleichen Raum teilt und somit tatsächlich zusammenarbeiten kann.
Der Jahresbeginn eignet sich übrigens hervorragend dafür, um das Selbstverständis eines Teams zu reflektieren. Eine Frage könnte sein:
Was hat uns in 2013 stark gemacht? Und: Was davon brauchen wir in 2014? Was noch?
Siehe dazu auch:
http://blogs.hbr.org/2012/09/stop-wasting-money-on-motivati/
 

How the Grinch did not steal the Christmas Retrospective

Have you ever encountered the situation that a large part of your Scrum-Team was absent during a Sprint?! I have. It‘s called the time between Christmas and New Year‘s. As a human being living in Western Europe, I very much enjoy that time. As a ScrumMaster in charge of making sure that the Scrum-Team is productive by adhering to the Scrum process – I wouldn‘t say that I‘m too keen on December.
This January, the situation reappeared. Returning from our holidays, the Team naturally questioned the point of carrying out the Sprint Retrospective, as not even half of the Team had been present for most of the Sprint. As a ScrumMaster, I believe that leaving out the final meeting for process improvement would break the rhythm. A rhythm that is necessary in seeking continuous improvement.
So instead of cancelling the meeting, I decided to make it extra-short and not limit the time scope to the last Sprint. I took a flip-chart, wrote the header “Within our Scrum-Team, I feel …“, drew a vertical line down its middle, and wrote on the left-hand side of the paper “productive“, while on the other side “unproductive“. I then asked each Scrum-Team member to limit one’s input to overall three cards per person.
The result was fantastic.

My Feedback Door showed that the Retrospective had fulfilled the necessary criteria: it had gotten everyone involved, taken little time, we had stayed focused, and we had again found some aspects that we could and would improve in.
Try it. I‘m sure you‘ll like it.

Führung ja, nein, jein?

Das Thema Führung hat in Unternehmen und Organisationen in den letzten Jahren eine erstaunliche und erfreuliche (scheinbare?) Renaissance erfahren. Man scheint auf breiter Basis erkannt zu haben, dass Führung – und ebenso Hierarchien – zentrale Elemente sozialer Systeme sind. Viele Dynamiken der vergangenen Jahrzehnte, wie Globalisierung, neue Technologien und vor allem die Herausforderungen permanenter und schneller Change-Prozesse, verlangen nach Orientierung, Sicherheit und Entscheidungen – also Führung. Was allerdings häufig noch fehlt: diese Erkenntnis auch stringent in die Unternehmenspraxis umzusetzen. Denn das heißt schlicht: Aufwand, Zeit und Kosten.
Reinhard K. Sprenger ist überzeugt, „dass die Aufgaben von Führung Universalien sind…“ („Radikal führen“ Campus Verlag 2013). Damit ist gemeint, dass Führung ein gegebenes, natürliches und unverzichtbares Element für Unternehmen ist. Dem ist uneingeschränkt zuzustimmen. Es kann also in diesem Sinne nicht mehr darum gehen, das Führen als Funktion und Rolle in Frage zu stellen, sondern darum, wie Führung ihre Aufgaben wirkungsvoll und effektiv erbringen kann. Zweifellos kostet schwache oder dysfunktionale Führung viele Unternehmen jährlich eine Milliardensumme. Ablesbar ist das u.a. an mangelnder Leistung, zahlreichen Krankenständen, Konflikten und hoher Fluktuation.
Führung ist zum einen das gezielte Gestalten von Interaktionen zwischen Führenden und Geführten (Mitarbeiterführung) und zum anderen das Steuern und Managen der Organisation (Unternehmensführung), beides meist in einer Rolle. Es braucht auf der einen Seite Führungspersönlichkeiten mit Ausstrahlung, sozialen Kompetenzen und Freude an der Führungsrolle. Auf der anderen Seite professionelle Werkzeuge und Instrumente zur Umsetzung in die Führungspraxis. Sache ist also, dass jedes Unternehmen höchsten Wert auf die Auswahl, Ausbildung und Pflege ihrer Führungsmannschaft legen muss. Und zwar nicht als Alibifunktion, um etwas getan zu haben, sondern als hoch priorisiertes, strukturiertes und nachhaltig umgesetztes strategisches Kernanliegen.
Dies gilt genauso, oder gerade, für laterale Führungsrollen, also Führung ohne disziplinarisches Mandat. ScrumMaster, Product Owner, Projektleiter, Teamkoordinator, Supervisor, Arbeitsplatzsteurer, oder wie immer sie auch fantasievoll tituliert werden, findet man immer häufiger in lateraler Führungsverantwortung. Gerade diese, oft neu definierten Rollen, haben meist eine ungünstige Ausgangssituation. Zum einen wird ihnen jede Menge Verantwortung übertragen und zugeschoben, zum anderen fehlt ihnen aber die echte Legitimation, gezielte Ausbildung und Weiterentwicklung und vor allem Unterstützung von oben. Ist die disziplinarische Führung schwach, zu wenig präsent, sich ihrer Unterstützungsfunktion nicht ausreichend bewusst, geraten die lateralen Funktionen in eine schwer lösbare Sandwichsituation. Im Scrum-Kontext wird das dann auch noch mit dem „Prinzip der Selbstorganisation“ verbrämt. So kann man die wertvollsten Mitarbeiter mittelfristig frustrieren oder gar ausbrennen.
Konsequenz für das Unternehmen – siehe oben: Führung als strategisches Kernanliegen betrachten, HR-Abteilungen stark machen und entsprechend investieren.
Konsequenz für betroffene Führungskräfte, insbesondere in lateraler Position: offensiv Legitimation von oben fordern und transparent machen, entsprechende Weiterbildungsmöglichkeiten nutzen und vor allem dazu stehen, dass ihre Führungsfunktion für Teams und Unternehmen elementar ist und ein genuiner Teil von Selbstorganisation.
Tipp: Die eigene Führungskraft stärken – mit dem Wissen aus den Scrum Supplements

Was macht eigentlich ein ScrumMaster – Leader, Trainer, Change Agent und Facilitator

Ich treffe sie immer häufiger, die ScrumMaster in den großen Unternehmen. Mal sind sie eingestellt, mal haben sie sich als Freiberufler dazu berufen gefühlt, ScrumMaster zu werden. Diese Entwicklung ist an sich wunderbar, zeigt sie doch, dass sich Scrum in Deutschland immer mehr durchsetzt. Aber … (ich weiß, in Scrum sagt man nicht “aber”, sondern “und”) – da ist etwas, das mich bei all meiner Begeisterung stutzig werden lässt. Die Scrum-Teams, die von ca. 95% dieser ScrumMaster betreut werden, entwickeln sich nicht, die Organisationen um diese Scrum-Teams verändern sich nicht. Frage ich dann mal in Trainings, auf Konferenzen und auch in persönlichen Gesprächen die ScrumMaster nach den Gründen dafür, höre ich immer wieder die Aussage: “Meine Rolle als ScrumMaster ist es, das Team (Anm.: gemeint ist das Development-Team) zu facilitaten!”
Bei dieser Aussage stellen sich mir alle Nackenhaare auf! Ich gehe, und zugegeben bin ich in diesem Punkt nicht sehr tolerant, bei dieser Aussage oftmals sofort auf 180 und werde leicht bis mittelschwer aggressiv. Diese Einstellung, dieses Selbstverständnis der meisten ScrumMaster, führt in die Sackgasse. Denn es beschreibt nicht einmal 20 Prozent der Aufgaben und Verantwortlichkeiten eines ScrumMasters.
Müsste ich heute, nach 11 Jahren Scrum-Erfahrung und 10 Jahre nach meinem ersten Training zum Certified ScrumMaster damals in Edinburgh, sagen, was die Aufgaben des ScrumMasters sind, so hat sich das einerseits dramatisch verändert und andererseits ist es im Kern gleich geblieben.
1) Der ScrumMaster ist ein Leader – er führt ein Scrum-Team (wir wissen heute, dass das Scrum-Team aus Product Owner und ScrumMaster und Entwicklungsteam besteht). Führen heißt u.a.:

Es heißt aber auch: Er entwickelt als Servant Leader ein Team, nachdem er das Entwicklungspotential gesehen hat.
2) Deshalb ist er auch ein Trainer und entwickelt sein Scrum-Team u.a. in …

Das alles tut er/sie und muss er/sie tun, damit er/sie
3.)  als Change Agent die Organisation rund um das Scrum-Team verändern kann, denn er/sie ist an erster Stelle dafür zuständig, die Produktivität seines/ihres Scrum-Teams zu erhöhen. Damit er/sie das kann, muss er/sie die Veränderung durchführen und u.a.

All das geht aber nicht in einer Top-Down “ich bin der Scrum-Boss” Manier, sondern nur gemeinsam mit den Menschen, für die er/sie u.a. verantwortlich ist. Daher ist er/sie vor allen auch ein
4.) Facilitator. Als Facilitator arbeitet er/sie mit den Gruppen partizipatorisch. Das gelingt, weil er/sie u.a. …

All das macht den ScrumMaster von 2013 aus.
Die banale Frage, ob ein ScrumMaster technische Skills braucht, ist einfach zu beantworten: Natürlich! Auf jeden Fall! Genauso braucht er/sie Skills in:

Ein ScrumMaster war und ist eine 100-Prozent-Beschäftigung. Der Job ist viel viel anspruchsvoller als der eines Projektmanagers, viel anspruchsvoller als der eines Teamleiters. Wird er jede Aufgabe 100-prozentig erfüllen können? Sicherlich nicht – dazu wäre ein Übermensch nötig. Aber im Sinne Nietzsches ist er möglciherweise tatsächlich ein Übermensch. Er/Sie gestaltet sich und seine/ihre Rolle selbst. Jeder SM erschafft in seiner Funktion ein neues Bild, ein Vorbild für die nächsten ScrumMaster.

Wir ScrumMaster haben eine Verantwortung: Wir wollen die Unternehmen in agile Unternehmen wandeln, weil wir als Menschen in Arbeitsbedingungen arbeiten wollen, die sich an den Menschen ausrichten. Dazu braucht es mehr, als zu wissen, wie man ein Taskboard an die Wand schraubt und sich zu überlegen, ob man nun eine Spalte mehr oder weniger im Taskboard hat.
Mein Anliegen an Euch, liebe ScrumMaster, ist es, diese Verantwortung ernst zu nehmen! Die Development Teams und die Product Owner, sie brauchen Euch als ScrumMaster, die für sie in der Organisation einstehen. ScrumMaster, die für sie mit dem Management reden und Prozesse, Mindset und Bedingungen um Euch herum verändern. Nicht gegen die Organisation, sondern mit ihr, für sie, damit die Organisationen sich am Markt ausrichten können und Produkte erzeugen können, die von den User gebraucht werden. Auf diese Weise tragen ScrumMaster dazu bei, die Organisationen agil zu halten. So agil und flexibel, dass man dem Markt nicht hinterherrennen muss, sondern vorausgehen kann.

Der ScrumMaster als Coach im Heimatsystem

Dass ein ScrumMaster auch Berater sein soll, ist für mich selbstverständlich. ScrumMaster müssen in der Lage sein, das Rahmenwerk Scrum in der Organisation so einzusetzen, dass es Früchte trägt. Diese Erwartungshaltung ist auch für den ScrumMaster nicht die schlechteste – gibt sie ihm doch die Möglichkeit, seine Existenz zu rechtfertigen. Ich helfe, also bin ich. Zugespitzt formuliert: Der klassisch denkende Projektmanager muss doch merken, dass der ScrumMaster (und nicht er) die Lösung seiner Probleme kennt.
Sonja Radatz schreibt von drei Beratungshaltungen, die ein differenzierteres Bild aufzeigen:

Radatz warnt vor einer „konsequenten“ Anwendung der ersten beiden Beratungshaltungen. Dadurch könne der Kunde seine Verantwortung problemlos an den Berater delegieren und gerate so in eine Abhängigkeit des Kunden vom Berater (Radatz 2000, 88-92). Allein eine konsequente Coaching-Haltung, in der der Coach Verantwortung für den Prozess und der Coachee Verantwortung für die Inhalte (Probleme, Problemlösung) trägt, führe zur Selbstständigkeit des Kunden beim Bewältigen seiner Probleme (ebda.).
Auch diese Dreiteilung in Experte, Arzt und Coach entpuppt sich bei genauerem Hinsehen für die Rolle des ScrumMasters als zu einfach. Nehmen wir als Beispiel die Rolle des ScrumMaster im Daily.
Die anfängliche Verantwortung des ScrumMasters im Daily Scrum, nämlich dem Team beizubringen, wie das Daily funktioniert, lässt sich am besten mit einer zeigenden oder vormachenden Haltung wahrnehmen. Ein Beispiel: Unerfahrene Entwicklungsteams schreiben häufig Tasks (Aufgaben), die kaum Aussagekraft besitzen. So schrieb neulich eines meiner Teammitglieder, das Teile einer neu entwickelten Schublade anpassen wollte, das Wort “Anpassungen” auf seinen Task-Zettel. Nach dem Daily nahmen wir uns den Zettel gemeinsam vor. Wir schrieben dann für jede Anpassung an jedem Teil der Schublade jeweils einen Task. So war aus ursprünglich einer Aufgabe ein gutes Dutzend Aufgaben entstanden, die klein und aussagekräftig genug waren, um im Laufe eines Tages erledigt zu werden.
Die Körpersprache des betroffenen Teammitglieds verriet zu Beginn, dass er den Sinn meiner Aufforderung in dem Augenblick nicht nachvollziehen konnte. Er tat es vermutlich, weil ich es als ScrumMaster, der Autorität über den Prozess hat, von ihm gefordert hatte. Im nächsten Daily fragte ich mein Team am Beispiel dieser neu formulierten Tasks nach der Sinnhaftigkeit des Herunterbrechens von Tasks auf kleine Aufgaben. Das Team erkannte mehrere Vorteile (z.B. wird für andere nachvollziehbar, was der Teamkollege gerade macht). Mein Vorgehen war also dreistufig: Ich gebe vor, wie etwas zu machen ist, mache es dann gemeinsam mit einem Teammitglied – und stoße dann das Team an, darüber selbst zu reflektieren.
Jetzt wird deutlich, warum die Dreiteilung von Radatz zu grob ist, um der Arbeitswelt des ScrumMasters gerecht zu werden. Scrum ist nämlich keine Schritt-für-Schritt-Anleitung zum Lösen von Problemen. Scrum ist eher ein Prozess, dessen Befolgung das Erkennen und Bewältigen von Problemen leichter macht. Jedes Meeting in Scrum, vom Daily bis zur Retrospektive, kann als Übung zur Stärkung der Reflektions- und Wahrnehmungsfähigkeit des Teams in Bezug auf eine gelungene Produktentwicklung ausgelegt werden. Deshalb passt die Anwendung von Coaching-Techniken (ich denke hier beispielsweise an die Wunderfrage oder die Skalenarbeit) nahezu nahtlos in die Arbeitswelt des ScrumMasters.
Sowohl systemisches Coaching als auch Scrum sind ein Prozess, der die Handlungsmöglichkeiten des Kunden erweitert, indem er ihn dazu ermuntert, von seinen eigenen Ressourcen stärker Gebrauch zu machen.
Ein relevanter Unterschied bleibt jedoch mit der beabsichtigten Einmischung des ScrumMasters im Heimatsystem seines Teams und des gesamten Unternehmens. Ein Coach arbeitet mit dem Coachee nur im Beratungssystem – das Heimatsystem bleibt dem Coachee vorbehalten (Radatz 2000, 76-78). Als ScrumMaster habe ich diese Grenzziehnung nicht: Wir erklären dem Kunden wie Scrum funktioniert, und sind im nächsten Schritt schon mitten dabei, im Tagesgeschäft zu intervenieren. Wir greifen damit im Heimatsystem aktiv ein.
Diese Einmischung ist zugleich Chance und Gefahr des Berater- und ScrumMaster-Jobs. Zum einen ermöglicht sie das, was unser Beratungsverständnis bei bor!sgloger auszeichnet und so besonders macht: Wir wollen dem Kunden keine Ratschläge geben, sondern mit anpacken. Deshalb ziehen wir uns auch nicht zurück, wenn der Kunde mal nicht mitmachen mag, sondern setzen uns mit ihm hin und zeigen durch Vor- und Mitmachen, wie zum Beispiel ein gelungenes Daily aussehen kann. Zum anderen birgt diese Einmischung in das Heimatsystem die Gefahr, dass der ScrumMaster zum neuen Projektleiter wird, der in klassischer Manier dem Team diktiert, was es zu tun hat. Für das Entwicklungsteam kann es ja durchaus komfortabel sein, wenn ihr ScrumMaster der Vorturner vom Dienst bleibt. Diese Gefahr besteht aber nur dann, wenn der ScrumMaster sich wie ein schlechter Sporttrainer verhält, der vor lauter Eigeninitiative und Gestaltungsdrang vergisst, dass es am Ende nicht um seine eigene Entwicklung geht.
Radatz, Sonja (2000): Beratung ohne Ratschlag. Systemisches Coaching für Führungskräfte und BeraterInnen. Literatur-VSM e.U.

Wie viel fachliches Know-how braucht ein ScrumMaster?

Die Frage, wie viel fachliches Wissen ein erfolgreicher ScrumMaster wirklich braucht, erinnert mich an mein Sportstudium. Wir mussten für unsere Abschlussprüfung eine Sprint- (z.B. 100m) und eine Langstrecke (z.B. 5000m) trainieren. Beide Strecken gingen gleich gewichtet in die Benotung ein. Physiologisch betrachtet benötigt man für eine Kurzstrecke vornehmlich rote, schnell zuckende (fast twitch oder FT) Fasern, für die Langstrecke braucht es vor allem gut ausgebildete weiße, langsam zuckende (slow twitch oder ST) Fasern. Für mich hieß das hinsichtlich Trainingsvorbereitung, einem echten Dilemma ausgeliefert zu sein. Würde Usain Bolt, Weltmeister und Olympiasieger über die 100 Meter überwiegend Ausdauertraining betreiben und seine sogenannten ST-Fasern trainieren, würde er mit großer Wahrscheinlichkeit nicht sehr lange konkurrenzfähig über die Kurzdistanz bleiben. Man kann nun mal nicht alles haben bzw. können – und mehr von dem einen, bedeutet häufig, bei dem anderen Abstriche zu tolerieren.

Must, should oder could have – die Frage spaltet die Community

Aber wie viel von was braucht es nun wirklich, um als ScrumMaster erfolgreich zu sein? Unter Erfolg verstehe ich, dass ein ScrumMaster seine Rolle und die damit verbundenen Verantwortungen wirkungsvoll erfüllt: Er hütet den Scrum-Prozess, er schützt das Scrum-Team, er löst Impediments. Schaut man sich die Diskussionsforen in der agilen Szene an, die ihre Meinung zu dem Thema äußern, dann findet man vor allem drei Meinungslager: das Must-, das Should- und das Could-have-Lager.

Must have

Die, die fachliches Wissen beim ScrumMaster für ein Must have halten, favorisieren, dass der ScrumMaster mindestens Ahnung, noch besser Expertenwissen in der Softwareentwicklung haben muss/soll. Im Idealfall war er in der Vergangenheit Teil eines Entwicklungsteams und möchte sich jetzt der Herausforderung stellen, als ScrumMaster zu arbeiten. Erst kürzlich hatte ich ein längeres Gespräch mit einer Person, die ein Must have als bindend versteht. Das Gespräch startete ungefähr so:
Manager: Ein ScrumMaster ohne fachliches Wissen ist kein guter ScrumMaster.
Ich: Woran machst du deine Aussage fest?
Manager: Nur ein Softwareentwickler kann einen Softwareentwickler wirklich verstehen. Da führt kein Weg dran vorbei.
Ich komme später beim Could have noch mal auf das Interview zurück. Der Dialog soll erst mal völlig wertfrei darstellen, was die Must-have-Vertreter als die für sie wichtigste Eigenschaft bzw. Erfolgsrezept eines ScrumMaster anführen. In meinen vielen Gesprächen über und Erlebnissen mit Scrum fällt mir außerdem verstärkt auf, dass die Gruppe “Must have” oftmals auch kein Problem darin sieht, dass ein ScrumMaster gleichzeitig als vollwertiges Mitglied des Entwicklungsteams agiert und mit zwei Hüten ausgestattet beides machen kann, ScrumMaster und Teammitglied. Im Gegensatz zum ersten Argument bin ich diesbezüglich weniger offen für Spielräume in der Bewertung. Mein Blog “ScrumMaster und gleichzeitig Teammitglied – ein Oxymoron” veranschaulicht das.

Should have

Mike Cohn ordne ich dem Should-have-Lager zu, weil er fordert, dass “ein idealer ScrumMaster auch technisches, betriebswirtschaftliches oder sonstiges Fachwissen mitbringen” (Cohn, 2010, S. 148) soll. Damit geht Cohn konform mit LaFasto und Larson, die in “When teams work best. 6,000 team members and leaders tell what it takes to succeed” fordern, dass ein Teamleader neben Aspekten wie der Zielfokussierung, dem Stärken von Vertrauen oder dem Setzen von Prioritäten seinen Führungsanspruch auf einem ausreichend verfügbaren Fundament von technischem Know-how aufbaut. Er, der Teamleader, “should understand the body of knowledge directly related to the achievement of the goal” (LaFasto & Larson, 2001, S. 130).
An dieser Forderung ist definitiv nichts auszusetzen. Die Formulierung “should unterstand” verstehe ich als nachdrücklichen Wunsch, der aber auch Spielräume für Varianten in der Intensität und Ausprägung lässt. Persönlich würde ich mir von Mike Cohn wünschen, dass er eine etwas größere Lanze für den Anteil der “weichen” Faktoren bei einem ScrumMaster brechen würde, aber die Softskills haben zumindest einen Platz, auch wenn er mir zu klein ist. Schaut man sich Stellenausschreibungen für einen ScrumMaster an, von denen ich die meisten ebenfalls dem Should-have-Denken zuordne (es gibt auch einige Must-haves), dann ist die Gewichtung ähnlich. Man sucht nach einem Akademiker mit technischem und/oder IT-Background, der vor allem Erfahrungen in der SE hat. In der Reihung findet man dann später noch Wünsche nach Eigenschaften, die Kommunikationsfähigkeit, Teamgeist und manchmal noch Konfliktmanagement voraussetzen. Die “Softseite” des Change Agents wird aber erst auf den zweiten oder dritten Blick interessant.

Could have

Ich bin ein leidenschaftlicher (andere würden “leidenschaftlich” mit dogmatisch gleichsetzen, aber das ist eine Wortspielerei) Vertreter der Could-have-Gruppe. Ich stelle die These auf, dass ein guter ScrumMaster nicht zwingend Fähigkeiten oder Kenntnisse im Bereich der Softwareentwicklung haben muss, um ein wirksamer ScrumMaster zu sein. Im Gegenteil. Ich vertrete die Ansicht, dass ihm genau dieses Fachwissen, die Spezialisierung, das Mehr an Know-how, die Detailkenntnis im Weg stehen, andere, ungeahnte Perspektiven einnehmen zu können. Neben meinen täglichen Erfahrungen im agilen Umfeld stütze ich meine These u.a. auf einen wissenschaftlichen Beleg.
Angenommen, du nimmst an einem Millionenquiz teil und das Einzige, was noch zwischen dir und der Million steht, ist die alles entscheidende letzte Frage. Der Quizmaster atmet nochmal tief durch, die Zuschauer kauen nervös auf ihren Fingernägeln, die Spannung ist zum Greifen nah. Alfred Hitchcock sitzt am Mischpult. Hier kommt deine Frage: Welche Stadt hat mehr Einwohner? A: Detroit oder B: Milwaukee?
Nun!? Erdkunde ist wohl nicht dein Spezialgebiet, oder? Der Countdown läuft. Außer einer Ahnung und der Erkenntnis, dass eine logische Ableitung der richtigen Antwort eher unwahrscheinlich ist, kommst du wohl nicht darum, eine vage Vermutung zu äußern. Was weißt du von Detroit? Geburtsstätte der Automobilindustrie, Industriestadt. Noch was? Milwaukee? Ich weiß ja nicht, wie es dir geht, aber hätte ich so wie du gerade keine Chance nachzufragen, dann wüsste ich, dass es einen Basketballverein gibt, die Milwaukee Buchs. Und damit wäre ich mit meinem Latein am Ende. Wie sieht das bei dir aus? Und was kannst du daraus für die Beantwortung der Frage nach der Millionen schließen?
Goldstein und Gigerenzer (2002, S. 75ff.), zwei Psychologen vom Max-Planck-Institut, stellten sowohl amerikanischen College-Studenten als auch einer vergleichbaren Gruppe mit deutschen Studenten die oben erwähnte Millionenfrage. Während die amerikanische Gruppe eher geteilter Auffassung war (60 Prozent setzten auf Detroit, der Rest auf Milwaukee), wies die Meinung der deutschen Studenten nahezu Einigkeit in der Antwortgebung auf. Praktisch alle Studenten entschieden sich für die Antwortalternative A und lagen damit richtig. How could more knowledge be no better—or worse—than significantly less knowledge? Sind deutsche Studenten schlauer als amerikanische oder haben sie bessere Kenntnisse in Erdkunde? Mitnichten. Das Gegenteil ist der Fall und eben dies war für die erfolgreiche Auswahl der Antwort ausschlaggebend.
Weil die deutsche Studentengruppe nur wenig über Detroit und noch weniger bis fast nichts von Milwaukee wusste, musste sie sich einer Ressource bedienen, die der amerikanischen Gruppe verwehrt blieb: der Intuition. Ergebnis: Ein nützliches Maß an Unwissenheit sorgt für ein erhöhtes Maß an Entscheidungsqualität. Jeder, der schon mal eine Diplomarbeit geschrieben hat oder sich in ein komplexes Thema fachlich einlesen musste, weiß, dass man um so mehr man weiß, um so mehr darüber erfährt, was man wiederum (noch) nicht weiß. Und so blieb der deutschen Gruppe nur das Bauchgefühl. Diese Quelle zur Entscheidungsfindung ist genau dann ergiebig, wenn man auf wenig relevante und verwertbare Daten zurückgreifen kann. Es ist ein Gefühl – kaum beschreibbar und trotzdem äußerst wirksam.

Die Kunst des Nichtwissens

Ein ScrumMaster, der wenig oder keine Fachkenntnisse mitbringt, denkt und agiert anders. Es bleibt ihm auch gar nichts anderes übrig. Und genau darin liegt sein Erfolgsrezept! Er kann und muss sich viel ausgiebiger auf sein Bauchgefühl verlassen, was, wie gerade gelesen, durchaus erfolgreich sein kann. Dies allein macht ihn aber noch zu keinem wirksamen ScrumMaster. Fachfremde ScrumMaster bedienen sich der Macht der Lethologie. Die Lethologie ist das sogenannte Nichtwissen. Vereint in einer Haltung von Neugierde, Empathie und Wertschätzung geht der ScrumMaster auf die Suche nach Antworten: Er stellt Fragen, um auf diesem Wege die innere Landkarte seines Gegenübers zu ergründen und ihm so bei der Suche nach Lösungen zu helfen. Dieses Handlungskonzept weicht vollkommen vom handelsüblichen Kommunikationsvorgehen im heutigen Business ab. Während man üblicherweise davon ausgeht, dass das Gegenüber (meist viel zu schnell) versteht, erarbeitet sich der lethologische ScrumMaster eine hypothesenfreie Meinung und fragt sich gemeinsam mit seinem Kommunikationspartner zu dessen Lösung.
Wenn ich es nicht selber erlebt, gesehen und erfahren hätte, ich würde vielleicht auch meine Zweifel haben. Vielleicht ist es nicht pauschal so, dass ein wirksamer ScrumMaster auch fachfremd sein kann. Aber eins steht fest: Ein ScrumMaster muss keine Fachkenntnisse haben, um wirksam für die Produktivität seines Teams agieren zu können. Ich kenne mindestens eine Handvoll solcher erfolgreicher Servant Leader. Sie bringen stattdessen andere Qualitäten mit: Führungserfahrung, Offenheit, Vertrauen in die Fähigkeiten anderer, Intuition und Emotionale Intelligenz.

Vertrauen macht produktiv

Wer kennt es nicht? Die größtmögliche Kreativität und Energie entfaltet sich erst, wenn nicht ständig ein Chef, Vorgesetzter oder Gruppenleiter hinter einem steht und Anweisungen bzw. Aufgaben verteilt. Das zeigt auch das sogenannte „Boss-Worker-Game“ sehr deutlich, das wir in unseren ScrumMaster Avanced Trainings durchführen. Dabei geht es darum, in einem eng gesteckten Rahmen (beispielsweise durch Tische begrenzt) möglichst viele Schritte in kurzer Zeit zu gehen, obwohl viele andere Teilnehmer zur gleichen Zeit dasselbe tun.
Hinter dem “Worker” steht ein „Boss“ und dirigiert ihn mit einfachen Kommandos. Nach einer gewissen Zeit wird das Ergebnis festgehalten und das Spiel mit einer kleinen, aber entscheidenden Änderung wiederholt. Der „Boss“ hat nun keine Befugnis mehr und der „Worker“ darf selbstorganisiert die Schritte tun, die er für richtig hält.Jedes Mal zeigt sich das gleiche Ergebnis: Die Leistung des „Workers“ steigt in der zweiten, selbstbestimmten, Runde erheblich an. Man kann sagen, seine Produktivität erhöht sich deutlich. So viel zur Moral von der Geschicht aus unserem Spiel.
Dass Selbstorganisation innerhalb eines sinnvoll gesteckten Rahmens viel Sinn macht, liest man auch in der Autobiografie “Das bin ich” des Profigolfers John Daly, der noch vor seinem 30. Geburtstag zwei der vier Major-Turniere gewann.
“Coach Loy hatte dafür gesorgt, dass wir alle im Team verhalten spielten. Er vertrat die Mentalität: „Spiel nicht auf Birdie, sonst kommt am Ende Bogey dabei heraus.“ Wir konnten unser Talent nicht beweisen. 1986 übernahm Coach Bill Woodley das Team, nachdem Coach Loy gegangen war. Sie unterschieden sich wie Tag und Nacht. Vollkommen verschieden. Wir waren alle gewissermaßen geschockt. Während Coach Loy gewollt hatte, dass die Dinge nach seinem Willen liefen, liess Woodley uns spielen. Bei Coach Loy hatte sich alles um Disziplin gedreht. Bei Coach Woodley ging es darum, ein Turnier zu gewinnen – wie du es anstelltest, lag an dir. Unter Coach Woodley zeigten wir, wo unsere Stärken lagen. Meine Stärke war der Abschlag. Nun machte mir niemand mehr Handzeichen, wie ich zu spielen hatte. Als Team rückten wir viel enger zusammen und spielten viel lockerer.”
Der kurze Ausschnitt aus John Dalys Geschichte zeigt sehr schön, was Scrum mit Selbstorganisation beabsichtigt:

Letztlich geht es für uns als ScrumMaster darum, dass unser Team sein eigenes Turnier gewinnt, welches auch immer es sein mag. Betrachten wir uns doch einmal als Scrum Coach unseres Teams und stellen uns die Frage, wie sehr wir Selbstorganisation zulassen. Oder macht es uns nervös, wenn das Team selbst über die Schritte entscheidet, die es wann innerhalb des Rahmens geht? Natürlich ist es manchmal schwer, diese Verantwortung abzugeben. Aber viele Beispiele zeigen, dass sich dieser Mut lohnt und Vertrauen mit Leistung belohnt wird.

Inseln der Agilität

Weh mir, wo nehm’ ich, wenn
Es Winter ist, die Blumen, und wo
Den Sonnenschein,
Und Schatten der Erde?
Die Mauern stehn
Sprachlos und kalt, im Winde
Klirren die Fahnen.
Friedrich Hölderlin (Hälfte des Lebens)
„Es gibt kein richtiges Leben im falschen.” Theodor W. Adorno hat damit die moralphilosophische Frage aufgeworfen, ob ein gutes Leben in einer Welt voller Ungerechtigkeit möglich ist.
Im Berufsleben lässt sich die Frage ebenso stellen: Ist ein guter, erfüllender Job in einem schwierigen, frustrierenden Unternehmensumfeld möglich? Menschen reagieren unterschiedlich, wenn sie spüren, dass sie sich in ihrem Job nicht entfalten können. Manche überfallen Selbstzweifel und Angst, andere gehen in den Widerstand bis hin zur Kündigung. Wiederum andere versuchen, sich mit den Verhältnissen zu arrangieren und eine halbwegs komfortable Nische zu finden, in der sie möglichst unbehelligt weitermachen können. Das ist dann so, wie wenn man im Regen unter einem Vorsprung Schutz sucht: Man wird nicht nass, aber wirklich schön ist es dort auch nicht.
In agilen Implementationen gibt es einen anderen Weg. Er läuft auf die Schaffung eines Mikrosystems mit eigener Anatomie hinaus. Dieses Mikrosystem nennen wir Scrum-Team. Indem wir ein Scrum-Team aufsetzen, schaffen wir für seine Mitglieder eine Heimat mit eigenen Werten und Regeln. Indem wir dem Team nach und nach die Verantwortung zur Produktgestaltung übertragen, schaffen wir darüber hinaus eine Arbeitsumgebung mit eigener Taktung.
Beides – Wertesystem und Taktung – sind zunächst nichts anderes als ferne Versprechen. Mitarbeiter, die es gewohnt sind, ihre Verantwortung entlang der Wertschöpfungskette nur punktuell oder diffus wahrzunehmen, stehen dem Versprechen häufig skeptisch gegenüber. Sie sehen im Großsystem Unternehmen alle Ursachen für ihre Unzufriedenheit – und müssen deshalb erst gar nicht anfangen, über ihre eigenen Handlungsfreiheiten zu reflektieren.
Bei der Errichtung eines solchen Mikrosystems hilft eine Führungskraft, die sich einerseits schützend vor das Team stellt, es andererseits aus der Komfortzone locken kann. Wir nennen sie ScrumMaster. Dann passiert etwas Spannnendes: Das Team fängt an, sich aus dem Schneckenhaus heraus zu tasten. Es beginnt zu spüren, dass nicht alles Übel fremdverschuldet ist. Und es bemerkt, dass es mit etwas Kreativität und Elan viel mehr leisten kann, als es sich bisher zugetraut hat.
Die ersten Früchte des Erfolges zeigen sich, wenn das Team anfängt, seine Frustration und Resignation in eine gewisse Unbekümmertheit und Leichtigkeit zu verwandeln. Frei nach dem Motto: Wenn keiner die entscheidenden Fragen stellen kann, dann tun wir das halt selber. Von dort an ist es nicht mehr weit, bis das Team damit beginnt, Entscheidungen selber zu treffen. Und eh‘ man sich versehen hat, ist sie da: Die Insel der Agilität. Zart und zerbrechlich, aber da.
Es gibt es also doch, das „richtige“ Leben im „falschen“. Das Sprint Review ist übrigens das Meeting par excellence, in dem das Großsystem Unternehmen den Gesinnungswandel innerhalb des Scrum-Teams registriert und auch zu schätzen versteht. Was dann folgt, ist ein Geben und Nehmen: Das Scrum-Team fordert heraus – und das Unternehmen lernt, damit umzugehen.
Tipp zum Abschluss: Lass dein Team auf einer Skala von 0-10 positionieren. Die Null bedeutet: Ich habe in meinem Unternehmen gar keine Freiheiten, selber zu entscheiden. Die zehn: Ich habe alle Freiheiten der Welt, selber zu entscheiden. Lass jeden kurz erzählen, warum er dort steht, wo er steht. Und bitte jeden dann, sich eine Maßnahmen zu überlegen, die er sofort umsetzen könnte, um auf der Skala um eine Zahl aufzurücken. Bilde dabei Gesprächspartner, die möglichst unterschiedlich auf der Skala stehen (also z.B. ein „Dreier“ mit einer „Siebener“). Lass die Maßnahmen aufschreiben und jedes Paar innerhalb von 72 Stunden berichten, wie es die Maßnahme umgesetzt hat und was es dabei beobachtet hat.
Theodor W. Adorno (1969): Minima Moralia. Suhrkamp Verlag, Frankfurt am Main.

Sind Taskforces die besseren Scrum-Teams?

Vor kurzem gab es eine spannende Situation bei meinem Kunden. Es gab plötzlich ein produktgefährdendes, technisches Problem – und ohne groß nachzudenken, wurde eine Taskforce gegründet. Die Taskforce hat das Feuer bravourös gelöscht und somit die gesamte Abteilung gerettet. Danach konnten diese Helden wieder in ihre alten Scrum-Teams zurückkehren und „normal weiterentwickeln“. Konkret bedeutet das: endlose Diskussionen zu Design-Konzepten, Murren bzgl. der vielen Scrum-Meetings und laufenden Absprachen, Über- bzw. Untercommittment, mangelndes Interesse an Tests etc.
Kommt euch das bekannt vor?
firefighters-115800_tpsdave_pixabay
Immer wieder stelle ich mir dieselbe Frage: Wieso scheinen Taskforces so viel besser zu funktionieren als Scrum-Teams? Wo ist der ausschlaggebende Unterschied zwischen einer Taskforce und einem Scrum-Team? Für mich ist das ganz einfach: es gibt keinen wesentlichen Unterschied. Doch denke ich, dass die Scrum-Welt noch viel zu lernen hat.
Die letzten Wochen habe ich damit verbracht, unterschiedlichste Personen zu befragen, weshalb die Taskforce so gut funktioniert hat und die Scrum-Teams nur langsam zum Laufen kommen. Hier sind ein paar der Mythen, denen ich auch schon früher begegnet bin:
„Eine Taskforce löst sich nach vollbrachten Tätigkeiten wieder auf.“
Ja, die Taskforce löst sich auf, sobald ihre Aufgabe zu Ende gebracht wurde. Genauso sollte das mit einem Scrum-Team sein: Wenn das Produkt vollbracht ist, kann sich das Team auflösen und anderen, neuen Aufgaben nachgehen. Hier ist die Dauer vielleicht unterschiedlich, aber nicht zwingend.
„Jede Taskforce hat ein klares Ziel.“
Hat das ein Scrum-Team nicht auch? Es gibt eine Produktvision – das übergreifende, große Ziel. Es gibt Backlog Items (Stories), die eines nach dem anderen kleine Meilensteine auf dem Weg zum Ziel darstellen. Und es gibt Sprintziele – greifbar, verständlich, SMART – damit das Team in jedem Sprint weiß, woran es seinen Erfolg orientieren kann.
„Die richtigen Personen kommen zusammen.“
Scrum ist eine Produktentwicklungsmethode. Aus diesem Grund sollte sich der Product Owner sein Team selbst zusammenstellen können – immerhin ist er für den Erfolg des Produktes hauptverantwortlich. Eine andere Möglichkeit wäre es, die operativ tätigen Dev.Teammitglieder selbst entscheiden zu lassen, wo sie etwas beitragen können und möchten. So finden sich auf kurz oder lang auch die richtigen Personen. Inspiration hierzu findet man unter anderem hier auf der Seite der Scrum Alliance.
„Wir stehen vor einer Herausforderung.“
Lasst uns „The New New Product Development Game“ zur Hand nehmen. Darin beschreiben Nonaka und Takeuchi die ersten Scrum-Teams. Und wie sahen die so aus? Jedes der genannten Teams hatte die klare Aufgabe, ein Produkt in kürzester Zeit performanter, besser, innovativer bzw. günstiger zu bauen. Ich kann euch nur raten: Wenn euer Product Owner bzw. das Management diese Herausforderung nicht an das Scrum-Team stellt, solltet ihr enger mit ihnen zusammenarbeiten und eine ähnlich klare Herausforderung einfordern.
„Eine Taskforce hat mehr Freiheiten.“
Genau darum geht es doch in Scrum. Der Rahmen ist gesteckt – einerseits durch das Management durch gewisse Budget-, Revisions- bzw. Infrastrukturvorgaben – andererseits durch den Prozess, der dem klaren, leicht überschaubaren Scrum-Framework folgt. Das gibt dem Team die Möglichkeit, sich innerhalb dieses gesteckten Rahmens frei zu bewegen und sich komplett auf seine eigentliche Arbeit zu konzentrieren – nämlich ein qualitativ hochwertiges Produkt zu liefern. Und falls sich das Team seine Freiheiten doch nicht selbst einräumen kann, gibt es einen ScrumMaster, der als direkter Link zur restlichen Organisation die Möglichkeit hat, jene Probleme transparent zu machen, die die Arbeit des Teams behindern. Der direkte Link zum Management hilft, um klar kommunizieren zu können, was das Team benötigt bzw. eben nicht benötigt, um die Herausforderung zu schaffen.
„Das Management zeigt Interesse an der Arbeit der Taskforce.“
Ist das nicht genau der schöne Nebeneffekt, den das Sprint Review Meeting nach jedem Sprint – typischerweise alle 2 Wochen – schafft, um genau diese Anerkennung und Wertschätzung vom Management bzw. anderen Außenstehenden zu erhalten?! Hier möchte ich aber auch die jeweiligen ScrumMaster und Product Owner auffordern, einfach mehr interne Werbung für ihr Produkt und das dahinterstehende Team zu machen.
„Taskforces müssen sich aufgrund ihrer Kurzlebigkeit nicht um ihre Konflikte kümmern.“
Nicht jedes Scrum-Team muss gleich harmonisch sein. Oft entstehen die besten Produkte durch Heterogenität (siehe Firmen wie IDEO  bzw. das Prinzip der T-shaped People). Die gebündelte Kreativität, die durch die verschiedensten Personen und Meinungen aufeinanderprallt, ist oft sehr anstrengend, aber auch fantastisch (genauso wie bei uns). Wichtig ist, dass die Dynamik des Teams stimmt, damit gemeinsam Leistung erbracht werden kann.
Jedoch, ich gebe es zu, hier gibt es einen kleinen Unterschied. Um genau dieses Thema – die Dynamiken des Teams – kümmert sich der ScrumMaster. Manche Taskforces existieren nicht lang genug, um besonders unterschwellige Konflikte austragen zu müssen. Ein Scrum-Team existiert meist länger, weswegen wir eine dezidierte Rolle für genau solche Fälle haben: den ScrumMaster.
Was haltet ihr von diesen Vergleichen? Mir zeigen diese Mythen bzw. Argumente zwei Aspekte auf:

Seht ihr das genauso?

How to organise a ScrumMaster Team in a large-scale environment?!

Late in the evening at the XP2013 in Vienna, I hosted an open space session under this title and am still surprised at how many participants actually joined me in discussion. It seems that I was not the only one faced with this question. While the session did not provide me with the sought-after perfect solution, it did give me an insight into how other companies structure the collaboration between individual ScrumMasters in order to act as a singular, strong force of change agents.
 
Here are some of the options that came up in conversation and that I can relate to due to having experienced them myself. Of course, these options may vary accordingly.
 

  • Meet on a weekly basis to talk about lessons learned when solving impediments and best practices in Scrum.
  • Meet on a daily basis in front of a ScrumMaster Taskboard (Impediment Backlog) to talk about current impediments and their progress.
  • Form a Scrum-Team and work in Sprints. If necessary, appoint your own ScrumMaster and Product Owner. Hold Backlog Groomings for identifying and prioritising general organisational impediments, Sprint Planning meetings for discussing the ‘What‘ followed by the ‘How‘, and Daily Scrums for synchronising your work. Make sure to finish each Sprint with a public Review and a Retrospective. Hint: Facilitating these meetings in a rotating manner can offer the ScrumMasters a chance to practice and learn new facilitation methods in a safe environment (i.e. different Sprint Retrospective styles).

 
In the end, however, I do not think that there is a right or a wrong answer. The only question that really matters is whether the Scrum-Teams are delivering valuable features or not. And if they aren‘t, the impediments hindering their productivity must be addressed and solved as quickly as possible. I do believe that a Team of like-minded persons with the same mission can achieve more than singular change agents. Once the ScrumMasters understand this for themselves, I am convinced that the right ‘how to‘ will come automatically. And this will probably differ depending on the persons involved and their specific system.

ScrumMaster aufgepasst! Wie Veränderung mit Popcorn funktionieren kann

Scrum bringt Veränderung. Das steht fest. Um Veränderung allerdings wirksam zu machen, muss man sich als ScrumMaster der Herausforderung stellen, wie man Menschen dazu bringen kann, sich zukünftig anders als bisher zu verhalten.
Dabei wird ein solches Unterfangen nicht leichter, wenn man bedenkt, dass es sich fast immer um die Änderung von Verhaltenskonzepten dreht, die automatisiert sind: Sie haben sich in der Vergangenheit bewährt, waren bis zu diesem Zeitpunkt – zumindest subjektiv für den Betroffenen – erfolgreich und sind damit im Handlungskonzept fest verankert. Man muss also mit Widerstand rechnen, weil Widerstand eine normale menschliche Reaktion auf Veränderungen ist. Dabei ist zweitrangig, ob die Mitarbeiter Widerstand gegen die Veränderung an sich leisten oder gegen die Art und Weise, wie der Veränderungsprozess gestaltet wird.
Wie kann es also einem ScrumMaster gelingen, dass die Menschen, auf die er in der Erfüllung seiner Verantwortung (z.B. in seinem Team, in der Organisation) Einfluss nehmen möchte, Veränderungen akzeptieren, diese für sinnvoll erachten und ihr Handeln danach (neu) ausrichten? Vielleicht ist die nachfolgende Antwort auf diese Frage nicht allgemein gültig oder auf jedes Veränderungsszenario übertragbar. Sie ist aber zumindest ein mögliches Lösungskonzept und somit eine versuchsreife Option, eine Probierpackung ohne doppelten Boden. Ich möchte sie euch gerne unter Anführung einer in den Staaten durchgeführten Studie nahe bringen.

Popcorn für alle

Vor ein paar Jahren kam der Actionfilm Zahltag mit Mel Gibson in die amerikanischen Kinos. In einem Vorstadtkino in Chicago spendierte man den Besuchern dieser Vorstellung ein alkoholfreies Getränk ihrer Wahl und einen Eimer Popcorn, wenn sie als Gegenleistung nach dem Film Fragen zur Qualität des Süßwarenstands beantworteten. Die Sache hatte allerdings einen (bewusst gewählten) Haken: Das Gratis-Popcorn war bereits vor fünf Tage gemacht worden und schmeckte entsprechend. Ein Zuschauer verglich das Popcorn mit Styropor, zwei andere hatten sogar vergessen, dass das Knabberzeug gratis war und wollten ihr Geld zurück. Und trotzdem aßen die meisten während des Films, “schoben die Packung weg, nahmen sie einige Minuten später erneut in die Hand, um sich Nachschub zu holen, stellten sie noch einmal weg, griffen nach einer Weile wieder hinein und so weiter und so fort.” (Wansink, 2008, S. 22) Noch wichtig zu erwähnen ist, dass die Kinofans nicht wussten, dass sie Teil einer Studie über irrationales Essverhalten waren. Eine Hälfte der 158 Probanden erhielt das Popcorn in einem mittelgroßen Eimer, die andere bekam einen richtig großen Eimer. Die Frage, die die Studie zu beantworten suchte, lautete:

Essen die Leute mit den größeren Eimern mehr Popcorn?

 
Die Studie sah vor, die Popcorneimer vor und nach dem Film zu wiegen, um auf diesem Wege eine valide Aussage darüber treffen zu können, wie viel Popcorn jede Person gegessen hatte. (Anmerkung: Bevor du weiterliest, schreib bitte auf einen Zettel auf, was deines Erachtens das Ergebnis dieser Studie war und finde Argumente für deine Entscheidung).

Popcorn-Vielfraße 

Das Ergebnis war tatsächlich erstaunlich und wirft ein vollkommen anderes Licht auf die Bewertung von Problemursachen und damit auf die Optionen, wo man nach Lösungen suchen sollte:
Die Probanden mit den größeren Eimern aßen 53 Prozent mehr Popcorn, als die mit den mittelgroßen Eimern. Sie nahmen folglich 173 Kalorien mehr zu sich und griffen rund 21-mal öfter in den Eimer” (Heath & Heath, 2010, S. 10).
Decken sich deine Ergebnisse mit den Ergebnissen der Studie? Angenommen, ich hätte euch zwar die Ergebnisse der Studie gezeigt, also wie viel die einzelnen Personen gegessen haben, hätte die Größen der Eimer und die damit einhergehende Wirkung auf das Essverhalten aber unerwähnt gelassen. Ihr könntet aus der Studie so lediglich ableiten, dass es einige Menschen gibt, die weniger Popcorn konsumiert haben, andere, die mehr gegessen und wiederum andere, die ziemlich viel Popcorn zu sich genommen haben. Darüber hinaus hättet ihr voreilig den Schluss gezogen, dass die letztgenannten echte Popcorn-Vielfraße sind. Hätte ich euch nun um die Sammlung von Ideen gebeten, wie man das Essverhalten (vor allem) der Vielfraße ändern kann, hättet ihr euch in der Lösungssuche wahrscheinlich auf Veränderungswege konzentriert, die der Frage auf den Grund gehen, welche Gesundheitsrisiken es mit sich bringt, so viel Popcorn zu essen.
Mit dem Wissen der unterschiedlichen Eimergrößen klingt die Lösung für das zu verändernde Problem „Essverhalten“ fast schon zu einfach: Nimm kleinere Eimer! In puncto Veränderungschance ist diese Lösung für mich die eigentliche Erkenntnis der Studie: „Was wie ein Problem aussieht, das den oder die Menschen betrifft, ist oft ein Situationsproblem“ (Heath & Heath, 2010, S. 27).
Und jetzt liegt es an euch, liebe ScrumMaster: Was sind die kleineren Eimer in eurem Scrum-Team? Erzählt mir davon.
 
Literatur
Heath, C. & Heath, D. (2010). Switch. Veränderungen wagen und dadurch gewinnen. Fischer
Wansink, B. (2008). Essen ohne Sinn und Verstand. Wie die Lebensmittelindustrie uns manipuliert.

Produktivität mal anders

Als ScrumMaster hat für mich die Produktivität meines Entwicklerteams die höchste Priorität. Impediments, sprich Blockaden, zu identifizieren und aus dem Weg zu räumen ist dabei meine hauptsächliche Tagesaufgabe. In einem meiner Projekte lief das mal auf ganz andere Art und Weise.

Ich seh etwas, das du nicht siehst

Ich drehte wieder einmal meine Runden durch unser Großraumbüro und da fiel mir plötzlich auf, dass einige Entwickler Schwierigkeiten mit dem Sehen zu haben scheinen. Das merkt man zum Beispiel an  verkniffenen Gesichtern, unnatürlichen Kopf- und Körperhaltungen oder gar gerötete Augen.
Als ursprünglicher Augenoptikermeister war ich gleich wieder in meinem alten Element und betrachtete das Thema Software-Entwicklung einmal mit ganz anderen Augen. Ich stellte mir die Frage, wie ein Entwickler wohl produktiv sein kann, wenn ihn aufgrund der nicht idealen Brille für den Arbeitsplatz brennende Augen, Rücken oder Kopfschmerzen plagen. Denn häufig ist dem so. Passt die Brille nicht zum Arbeitsplatz oder die Stärke der Brillengläser ist nicht mehr die aktuelle, hat das die eben beschriebenen Folgen.
Viele Menschen klagen darüber. Oft müssen sich Menschen am PC-Arbeitsplatz sogar täglich die Frage stellen: „Will ich gut sehen oder bequem sitzen?” Das eine darf im Idealfall das andere natürlich nicht ausschließen. Mit der richtigen Brille. Abhilfe muss also her.
Über alte Kontakte organisieren wir nun eine „Sehtest-Initiative“, in der ich den Entwicklern eine Augenüberprüfung anbieten möchte, um daraufhin mit einer Messbrille die ideale Korrektion der Sehschwäche direkt am Arbeitsplatz zu simulieren. Dem Entwickler kann der Nutzen einer optimalen Versorgung auf diese Art und Weise direkt vor Augen geführt werden. Im wahrsten Sinne. Und dies direkt an seinem Arbeitsplatz.
Lassen wir uns überraschen. Die Aktion wurde von den Team-Mitgliedern mit Vorfreude aufgenommen und wir organisieren derzeit das nötige Equipment für die Messungen über einen ortsansässigen Optiker.
Das formulierte Ziel ist jedenfalls klar: Produktivität bei gutem Sehen und bequemer Kopf- und Körperhaltung.

Wann ist ein Impediment ein Impediment?

Impediments sind häufig gar nicht so sichtbar und es ist eine Herausforderung , diese letztlich doch immer wieder zu identifizieren. Lange habe ich mich gefragt, wann ist ein Impediment wirklich ein Impediment und wann nur eine Kleinigkeit? Letztlich habe ich für mich und meine Arbeit herausgefunden, dass tatsächlich alles, was das Team davon abhält produktiv zu sein, ein Impediment darstellt. Und sei es nur die defekte Schreibtischlampe, deren Neubeschaffung in großen Konzernen leider Tage und zig Unterschriften bei Einkauf, Management etc. in Anspruch nimmt.
Also arbeite ich nach dem Motto: “Nichts ist zu klein, um ein Impediment zu sein.”

Mit dem Computer Code bessere Teamarbeit erreichen

Zusammenarbeit im Team ist das A und O. Dabei werden Ergebnisse oder Lieferungen dann besonders gut, wenn es das Team geschafft hat, auf der Grundlage einer gemeinsamen Strategie zu planen und das Geplante dann Stück für Stück umzusetzen und anzuwenden. Bei Veränderungen, Unwägbarkeiten oder Lageänderungen gilt es, flexibel reagieren zu können und nicht an seinem ursprünglichen Plan festzuhalten (inspect and adapt). Dies gelingt durch regelmäßiges Feedback und/oder Innehalten. Im Laufe eines solchen Prozesses erlebt man immer wieder die Wirkung unterschiedlicher Handlungsmuster und muss darauf reagieren. Hier hat die Rollenverteilung im Team (who is who, wer macht was und warum, etc.) herausragenden Einfluss auf den Prozessverlauf und die Ergebnisse. Nicht selten kommt es bereits vor, aber auch während des Entstehens einer Lieferung zu Zielkonflikten (z.B. Was ist wichtiger? Arbeitsqualität oder Arbeitsgeschwindigkeit).
 
Die im ersten Absatz beschriebenen Aspekte sind für ein Team nichts Neues, sondern eher Alltag. Was kann man nun verbessern? Wie kann die Teamperformance gesteigert werden? Wie wird ein gutes Team noch besser? Wo fängt man an? Was ist das Wichtigste? Auf all diese oder weitere Fragen in dieser Richtung gibt es zumindest eine Musterantwort: Das ist von Team zu Team verschieden, man muss es ausprobieren und im wahrsten Sinne des Wortes erleben.
Mit dem nachfolgenden Teamspiel möchte ich euch einladen, die Reise “Wie verbessere ich Teamarbeit” anzutreten und durchzustarten. Nirgendwo ist der Mensch authentischer als beim Spielen. In diesem Sinne: Lasst das Spiel beginnen.

Der Computer Code – was braucht es, um mit dem Spiel zu starten?



Teilnehmer:   bis 25
Zeit:   30 Minuten
Ort:   Freifläche
Material:   50 Moderationskarten (rund und mit den Zahlen von 1 bis 50 beschriftet), Marker (schwarz), langes Seil (ca.15m), Stoppuhr
 
Ablauf und Regelwerk
Der ScrumMaster bereitet die Übungsfläche vor, ohne dass die Gruppe dabei zusieht. Mit der Schnur wird eine Spielfläche eingegrenzt, in die anschließend die Moderationskarten mit der beschrifteten Seite nach oben und nach dem Zufallsprinzip in der von der Schnur eingegrenzten Spielfläche verteilt werden. In ca. 10 Meter Entfernung wird eine Linie (Start) gezogen. Die Gruppe positioniert sich hinter der Startlinie.
Die gesamte Gruppe startet immer hinter der Startlinie (Stoppuhr läuft los – Versuch 1 bis 5). Der jeweilige Versuch endet mit der Rückkehr des letzten Teilnehmers hinter die Startlinie (Stoppuhr stoppt – Versuch 1 bis 5 endet). Damit endet ein Versuch. Die Gruppe hat in einer Gesamtzeit von 30 Minuten fünf Versuche, das Spielproblem zu lösen. Während eines Versuches darf sich immer nur eine Person innerhalb der umgrenzten Spielfläche aufhalten. Alle Teilnehmer dürfen bis zum Rand an die Spielfläche treten. Bei einem Verstoß berechnet der Spielleiter 20 Sekunden auf die Endzeit. Die “Strafzeiten” werden jeweils laut ausgerufen.
 
Ziel des Spiels ist es, dass die Gruppe es schafft, in möglichst kurzer Zeit alle in der Spielfläche liegenden Moderationskarten in der richtigen Reihenfolge (1, dann 2, dann, 3, dann, …bis 50) zu berühren (z.B. Hand oder Fuß) – also der richtige Code muss in den Rechner eingegeben werden. Falls eine Zahl in verkehrter Reihenfolge (z.B. 5 vor 4) berührt wird, werden ebenfalls 20 Sekunden auf die Endzeit berechnet. Schnelligkeit bringt also nur dann einen Nutzen, wenn das Endprodukt eine entsprechend hohe Qualität hat (z.B. wenige Fehler).
Die Moderationskarten dürfen ihren Ursprungsort nicht verlassen. Sind die fünf Versuche beispielsweise nach 20 Minuten beendet, dann ist auch das Spiel beendet. Hat das Team nach 30 Minuten erst drei Versuche absolviert, ist das Spiel ebenfalls zu Ende.
 
Besondere Spielhinweise
Die Entfernung zwischen Startlinie und Spielfläche sollte so groß sein, damit die Position der Zahlen nicht sichtbar ist. 50 Moderationskarten sind eine mögliche Anzahl. Es können entsprechend der Teamgröße auch weniger sein (d.h. bei 25 Personen ca. 50 Karten, bei 10 Personen reichen ca. 30).
Wichtig: Es darf nur hinter der Startlinie gesprochen werden! Nonverbale Signale sind auch sonst möglich. Sprechen im Spielfeld, also nach der Startlinie, wird jeweils mit 20 Sekunden Strafe versehen.
 
Varianten
Es können einzelne Zahlen in der Reihenfolge weggelassen werden.


Das Wichtigste zum (Ab-)Schluss
Lasst eine Intervention, in diesem Fall das Teamspiel “Computer Code”, nicht allein für sich stehen oder geht gar zur Tagesordnung über. Natürlich macht Spielen Spaß, aber es wäre schade, wenn ihr das Erlebte nicht reflektiert. Ich halte es für essentiell, zu hinterfragen, welche Erkenntnisse das Team aus der Intervention für sich ziehen kann, die in das Daily Business transferierbar sind. Rundet daher eine Intervention stets mit einem Debriefing ab! Nur auf diese Weise könnt ihr sicher stellen, dass eine intensive und wirksame Auseinandersetzung mit den Gedanken, Gefühlen und Reflexionen zur Umsetzung in den Teamalltag gewährleistet ist. Wie man ein gutes Debriefing gestalten kann, um eine gemeinsame Beschreibung der gemachten Erfahrungen zu erreichen, könnt ihr in meinem Blog “Wie viel Standing braucht ein ScrumMaster” nachlesen.
 
Literatur
Kriz, C. & Nöbauer B. (2006). Teamkompetenz. Konzepte, Trainingsmethoden, Praxis. Vandenhoeck & Ruprecht.
 
 
Übrigens: Seid ihr bei der XP 2013 in Wien dabei? Vom 3.6.-7.6. ist auch das bor!sgloger-Team vor Ort und wird die Besucher ordentlich in Bewegung bringen. Versäumt nicht das Supersize-Ball-Point-Game beim Open Space am Dienstag Nachmittag (4.6.)!

Lass dich überzeugen

Manchmal ertappe ich mich dabei, etwas ungeduldig zu werden, wenn Teams nicht sofort auf sinnvolle Vorschläge anspringen. Dabei weiß ich natürlich ganz genau, dass man nur das (gut) tut, von dem man auch überzeugt ist.
Ein anderer ScrumMaster erzählte mir dann, wie er kürzlich mit einer solchen Situation umgegangen ist. Er hat den Spieß quasi umgedreht. Nachdem das Team über die Vor- und Nachteile einer bestimmten agilen Praktik (automatisierte Tests) diskutiert hatte und sich dann als Team dafür entschieden hatte, diese Praktik fortan anzuwenden, hat er sich nochmals davon überzeugen lassen, um die Entscheidung zu verstärken.
Er begab sich in die Position/Haltung des Nichtwissens und ließ sich von den Teammitgliedern erklären, warum sie nun „unbedingt“ die Praktik einführen wollen. Dabei hat er so getan, als würde er das Vorgehen selbst nicht kennen und somit auch nicht die damit verbundenen Vorteile. Mit interessiertem Nachfragen hat er das Team dazu gebracht, ihm genau zu erklären, wie diese Tests funktionieren und warum es gut ist, automatisiert zu testen. Mit neugierigem Nachfragen hat er sich vergewissert, ob die Wirklichkeit des Gegenübers mit seiner übereinstimmt bzw. hat er die innere Landkarte des Teams besser kennengelernt. Er hat nicht einfach etwas angenommen und sich mit Hypothesen aus der vorangegangenen Diskussion zufrieden gegeben, sondern über diese Intervention seine und die vom Team konstruierte Wirklichkeit miteinander abgeglichen.
Nach einiger Zeit sagte er dann: “Achso, ihr wollt also diese automatischen Tests machen!”
Geradezu erleichtert rief das Team im Chor: “JA, GENAU!!!!” (Und meinte damit: “Endlich hat er es verstanden!!!”)
Kann man sich ein schöneres Commitment für die Anwendung einer bisher nicht genutzten agilen Praktik vorstellen, die man an viele Teams nur mit Mühe und Not herantragen kann?
Leider war ich nicht dabei. Bei der nächsten Möglichkeit werde ich mich aber auch mal überzeugen lassen anstatt überzeugen zu wollen!

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

Interview mit einem ScrumMaster oder die Reise zu einem fremden Planeten

Ein guter ScrumMaster zeichnet sich dadurch aus, dass er immer und überall auf der Suche nach Verbesserungen ist, die zur Steigerung der Produktivität seines Teams beitragen. Hierzu sollte er seinen Blick in alle Richtungen schweifen lassen. In der operativen Hektik des täglichen Tuns passiert es dann nicht selten, dass ein Bereich übersehen oder gar vergessen wird: der Blick auf sich selbst. Wer andere bewegen und verändern will, der sollte zuerst sich selbst bewegen, um so zu (s)einer Veränderung beitragen zu können.
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:

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.

Sagen Sie jetzt nichts: Ich bin Company ScrumMaster

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?
 

 
 
 

Sed quis custodiet ipsos custodes oder braucht es einen Company ScrumMaster?

Die lateinische Frage “Sed quis custodiet ipsos custodes” heißt übersetzt: “Aber wer bewacht die Wächter?” Die von Juvenal, einem römischen Satiriker (58 – 140), aufgeworfene Frage trifft den Nagel auf den Kopf, wenn man nach der Berechtigung der Rolle des Company ScrumMasters (CSM) fragt. Aber was ist ein Company ScrumMaster überhaupt? Was unterscheidet ihn von einem ScrumMaster? Wann braucht es ihn? Wie wird man CSM? Was sind seine Aufgaben, welche Verantwortung trägt er? Fragen über Fragen zu einer Rolle, die auf dem Weg zu einer agilen Organisation eine wegweisende Handschrift zu hinterlassen vermag.
 
Der Company ScrumMaster, der ScrumMaster der ScrumMaster, füllt eine Rolle aus, die im skalierten Scrum-Umfeld eine Schlüsselfigur ist, wenn man sich entscheidet, sie zu etablieren. Einen Company ScrumMaster einzusetzen ist kein Muss. Steigt jedoch die Anzahl der Scrum-Teams und damit auch die der ScrumMaster, dann wird nicht nur ein regelmäßiger Informationsaustausch zu Abhängigkeiten und Impediments nötig, sondern die steigende Komplexität der Themen verlangt nach Struktur und einer Sicht von “oben”. Der CSM ist demnach eine logische Konsequenz und ein Instrument, Komplexität zielgerichtet und werteorientiert zu reduzieren.

Die Verantwortung des Company ScrumMasters

Ein Company ScrumMaster führt die ScrumMaster. Idealerweise tut er dies genauso wie ScrumMaster ihre Entwicklungsteams führen, nämlich lateral, also ohne Befehlsgewalt und mit der klaren Verantwortung, die Produktivität seines Teams kontinuierlich zu steigern. Unter der Produktivität des ScrumMaster-Teams verstehe ich, dass die ScrumMaster im Verbund agieren und auf der Grundlage gemeinsamer Ziele und Werte das agile Mindset in ihre Teams tragen und die Organisationskultur nachhaltig beeinflussen. In seiner Verantwortung tritt der CSM wie ein Nant`an auf. Er ist der kulturelle Führer der ScrumMaster, dem die ScrumMaster folgen, weil sie es von sich aus wollen, nicht weil man es ihnen vorschreibt. Bei den Apachen war dies ähnlich. Jeder traf die Entscheidung für sich selbst, dem Nant‘an zu folgen oder auch nicht. Interessanterweise gibt es in der Sprache der Apachen nicht einmal ein sprachliches Äquivalent zu „du musst“. Zwang ist in der Kultur der Apachen ein unbekanntes Handlungskonzept.
 
Ein Company ScrumMaster sollte, nicht zuletzt aus besagter Verantwortung, wenn möglich kein ehemaliger Vorgesetzter aus einer Linienverantwortung sein. Vielmehr sollte er sich aus der Gruppe der ScrumMaster aufgrund seiner Leistung, seines Ansehens, seiner Erfahrung, seines Einflusses herausheben. Es sollte auf der Hand liegen, wer für diese Rolle in Frage kommt und die ScrumMaster sollten ihn wählen oder zumindest ein Mitspracherecht dabei haben, wer zukünftig diese Verantwortung tragen soll. Gegen die Variante, dass der Company ScrumMaster aus den eigenen Reihen kommt, spräche, dass er dann der Prophet im eigenen Haus ist. Das kann ein Hindernis sein, muss aber nicht. Was ich empfehle ist, die Rolle des CSM keinem Rotationsmodus zu unterwerfen, d.h. jeder darf mal Company ScrumMaster sein.
Noch ein weiterer Aspekt ist mir im Zusammenhang mit der Verantwortung des CSM wichtig: Sollte es sich die Organisation leisten können und eine ausreichende Anzahl an ScrumMastern verfügbar haben, dann empfehle ich, dass der Company ScrumMaster (nur) die Verantwortung über ein Team hat, nämlich über das Team der ScrumMaster.

Was macht ein Company ScrumMaster den lieben langen Tag?

Eine wesentliche Herausforderung des Company ScrumMasters ist es, dafür Sorge zu tragen, dass die ScrumMaster motiviert sind, weil ihre Arbeit wichtig und sinnvoll ist. Ihr fragt euch jetzt vielleicht, was wichtiger als wichtig sein kann. Ich möchte hier als Antwort Ken Blanchards und Sheldon Bowles Gedanken aus ihrem Buch Gung Ho! anführen. Die beiden Autoren sehen dreierlei als beachtenswert:

  • Die zu erledigende Arbeit muss als wichtig empfunden werden.
  • Sie muss zu einem gemeinsamen Ziel führen, das für alle verständlich ist.
  • Bestimmte Wertvorstellungen müssen das Fundament aller Pläne, Entscheidungen und daraus resultierender Handlungen sein.

Kommen diese drei Aspekte zusammen, dann kann man von einer Arbeit sprechen, die das Prädikat “sinnvoll” verdient (vgl. Blanchard & Bowles, S. 40). Damit der Company ScrumMaster diesbezüglich seine Handschrift hinterlassen kann, sollte er herausfinden, in welche Richtung seine ScrumMaster (mit ihren eigenen Zielen und Werten) tendieren und sich dann an ihre Spitze setzen, um gemeinsam auf zwei Zielvorstellungen hinzuarbeiten:

  1. Es muss klar sein, was das ScrumMaster-Team erreichen will (angestrebte Ergebnisse).
  2. Es muss klar sein, was das ScrumMaster-Team für die Entwicklungsteams und die Organisation erreichen will (angestrebte Werte).

Der Company ScrumMaster schafft hierfür die Voraussetzungen und ist Navigator für die ScrumMaster. Er lenkt, er moderiert, er regt an, er hinterfragt, er führt (lateral). Dies tut er auf zwei Ebenen, mit jedem einzelnen ScrumMaster und mit dem ScrumMaster-Team.

Company ScrumMaster ist ScrumMaster auf zwei Ebenen

Im Verhältnis Company ScrumMaster – ScrumMaster agiert der CSM als Mentor. Er ist Ansprechpartner auf Augenhöhe. Er coacht den ScrumMaster und dient ihm als Sparringpartner, als Spiegel, als schlechtes Gewissen, als Challenger. Er entwickelt den ScrumMaster in seinen Fähigkeiten als Meeting Facilitator und Servant Leader. Hierbei zeichnet sich der CSM besonders dadurch aus, dass er durch sein Handeln in der Lage ist, den Unterschied zu machen. Im Verhältnis Company ScrumMaster – ScrumMaster-Team versteht sich die Rolle des CSM als ScrumMaster. Er führt sein Team ohne den Anspruch auf Autorität. Der Fokus seines Tuns liegt hierbei auf der Wertearbeit (Werte dienen meines Erachtens dazu, eigenes Handeln zu bestimmen und nicht, Handeln dogmatisch vorzuschreiben). Auf dieser Grundlage sollen Ideen umgesetzt werde, die u.a. die Reputation der Rolle “ScrumMaster” in der Organisation stärken, damit diese einen wesentlichen Beitrag leisten kann, die Kultur des Unternehmens beeinflussen zu können. Darüber hinaus ist der CSM kontinuierlich darum bemüht, zu den übrigen Keyplayern im agilen Miteinander, Product Owner (Team) und Management, einen engen Kontakt zu pflegen. Er ist in seiner Rolle der Anführer der Change Agents und setzt sich für die agilen Werte in der Organisation ein.

Braucht es einen Company ScrumMaster wirklich? Und wenn ja, ab wann?

Auf diese Fragen gibt es keine richtigen oder falschen Antworten. Es kommt vielmehr auf die jeweilige Situation an. Ab einem bestimmten Grad an Komplexität halte ich eine laterale Führung der ScrumMaster für essentiell. Hierbei geht es mir weniger um Kontrolle oder, wie es der Titel verstehen lassen könnte, Überwachung. Vielmehr soll die Instanz eines Company ScrumMasters die Chance bieten, aus den Ressourcen einer Adlerperspektive das eigene Handeln anders, neu zu betrachten – eine zweite Meinung zu erhalten. Bei zwei ScrumMastern braucht es sicher noch keinen CSM. Da lassen sich Prozesse etablieren, die ein regelmäßiges und gegenseitiges Feedback mit sich bringen. Sobald ein dritter ScrumMaster auf die Bühne tritt, sollte man zumindest die Optionen “Wer bewacht die Wächter” oder “bewachen wir uns untereinander” gegeneinander abwägen und/oder beide Varianten über einige Sprints ausprobieren.
 
Aber vielleicht fragen wir einfach einen aktiven Company ScrumMaster nach seiner Meinung.
Beim nächsten Mal: Interview mit einem Company ScrumMaster.
 
Literatur
K. Blanchard & S. Bowles (2012). Gung Ho! Wie Sie jedes Team in Höchstform bringen. rororo.

Der ScrumMaster im Sprint Review oder warum Ja-Aber-Sager ein Impediment sind

In meinen Beobachtungen des Daily Business von Scrum-Teams stoße ich in regelmäßigen Abständen auf ein interessantes, aber auch bedenkenswertes und manchmal ärgerliches Phänomen. Viele ScrumMaster kommen beim Sprint Review ihrer essentiellen Verantwortung als Meeting Facilitator, Change Agent und Servant Leader nur bedingt nach. Immer wieder erlebe ich, dass das Sprint Review vom ScrumMaster als eine Art Auszeit genutzt wird. Während der Product Owner u.a. allen Anwesenden das Sprint Goal vorstellt, in diesem Kontext die ausgewählten Backlog Items erläutert, einen Ausblick auf die nächsten Userstories in der Roadmap gibt und das Entwicklungsteam die Ergebnisse des Sprints vorstellt, sollte der ScrumMaster die vornehmliche Aufgabe verfolgen, das Sprint Review zu moderieren. Moderation ist jedoch vielschichtig und wird von so manchem ScrumMaster nur eingeschränkt oder gar nicht umgesetzt.
Bevor ich allerdings hier tiefer erkläre, was mir bei der Umsetzung durch die ScrumMaster fehlt, möchte ich noch einen Schritt zurück gehen und beleuchten, warum das Sprint Review ein so wichtiges Meeting ist.
 

Warum das Sprint Review so wichtig ist

Glaubt man Boris Gloger und seiner Meinung in Scrum – Produkte zuverlässig und schnell entwickeln zur Sprint Review, kann die „Bedeutung dieses Meetings nicht genug betont werden“ (Gloger, 2011, S. 176). Das Sprint Review dient der Statuserhebung im laufenden Projekt und soll im Wesentlichen eine Antwort auf die Frage geben, ob „das Team geliefert (hat), was es versprach“ (a.a.O.). In noch unerfahrenen Scrum-Teams und Unternehmen, die noch am Anfang ihrer agilen Organisationsentwicklung stehen, wird das Meeting häufig als Präsentation durchgeführt. Das Sprint Review ist jedoch mitnichten eine Veranstaltung, in der den anderen (z.B. Management, Customer, Anwender, Fachabteilungen, Lieferanten, etc.) lediglich via Power Point das Produkt gezeigt wird. Vielmehr dient die Review (engl. Bewertung) als Einladung, „die Funktionalität auszuprobieren“ (Gloger, 2011, S. 178). Auf diesem Weg erhofft sich das Team, Feedback zu bekommen, „neue Ideen zu generieren und neue Möglichkeiten nutzen zu können“ (a.a.O.).
 

Feedback(un)kultur

Ein Feedback zu geben, ist jedoch eine hohe Kunst. Dieser sind leider nur wenige wirklich gewachsen, was dazu führt, dass das, was an Feedback bei jenen (Entwicklungsteam) ankommt, die damit ursprünglich den Wunsch und die Hoffnung verbunden hatten, Anerkennung für die getane Arbeit im vergangenen Sprint zu erhalten und/oder ungenutzte Perspektiven aufgezeigt zu bekommen, oftmals ernüchternd, manchmal sogar erschütternd und vor allem demotivierend ist. Den Klassiker der Feedback(un)kultur vertritt in diesem Zusammenhang die Gruppe der Ja-aber-Sager. Die Ja-aber-Sager sind während einer Sprint Review leicht zu erkennen. Haltet Ausschau nach Kopfschütteln und übermotivierten Meldeversuchen (z.B. Handmeldung, die durch Fingerschnipsen verstärkt wird), die von paraverbalen Ungedulsäußerungen (z.B. Seufzen) begleitet werden und schließlich in einem Wortbeitrag münden, die mit der Einleitung „Ja, aber“ ein (aus Sendersicht) plausibles und unumstößliches Gegenargument (z.B. Befürchtung, unüberwindbares Problem, etc.) liefern. Die Reaktion auf ein „Ja, aber“ ist fast immer die gleiche: Man (das Entwicklungsteam) rechtfertigt sich und es entbrennt ein fieberhafter Wettstreit darüber, wer Recht hat. Schließlich und letztendlich ist es die abgelaufene Timebox, die Schlimmeres verhindert. Zurück bleibt ein kritisiertes und verunsichertes Entwicklungsteam.
 
Möglicherweise habe ich das Szenario ein wenig überspitzt dargestellt und es geht keineswegs darum zu sagen, dass Ja-Aber-Sager unrecht haben. Nichtsdestotrotz erlebe ich regelmäßig solche Beispiele in ähnlicher Ausprägung. Und weil ein „Ja, aber“ zu keiner Zeit ein konstruktiver oder gewinnbringender Einstieg in einen ernsthaften Fachdiskurs ist, sondern „ein erbitterter Kampf um die Unanfechtbarkeit der eigenen Meinung“ (http://www.gedankenzirkus.de/wordpress/die-ja-aber-dummschwatzer), muss es eine aktive Instanz geben, die Regeln aufstellt und Ja-Aber-Argumente nicht einfach zur Kenntnis nimmt und so ein Entwicklungsteam mit der Kritik – im wahrsten Sinne des Wortes –  im Regen stehen lässt. Dieser Jemand ist und kann nur einer sein: der ScrumMaster.
 
Der ScrumMaster muss wie in jedem anderen Scrum Meeting auch in einem Sprint Review seiner Verantwortung in dreifacher Weise nachkommen:

  • Als Meeting Facilitator gibt der ScrumMaster für das Sprint Review Kommunikationsregeln vor und macht diese für alle Besucher transparent. Eine Regel könnte beispielsweise lauten: “Eine Wortmeldung beginnt nicht mit „Ja, aber“.” Er tritt als Moderator des Meetings auf und sorgt unter anderem dafür, dass sich die Beteiligten ausreden lassen und verschiebt (zeitintensive) Diskussionen auf einen späteren Zeitpunkt.
  • Als Servant Leader stellt sich der ScrumMaster schützend vor sein Team. Er bestärkt es, kritisches Feedback ebenso offen und dankbar wie positives anzunehmen, ohne es zu kommentieren oder sich zu rechtfertigen: don`t feed the feedback!
  • Als Change Agent setzt er sich im Rahmen des Sprint Reviews konsequent für die Einhaltung der vorgegebenen Kommunikations- und Feedbackregeln ein, um auf diese Weise Werte wie Wertschätzung oder Respekt zu stärken und sie über die Teamgrenze hinaus zu transportieren und unternehmensweit zu etablieren.

Rezept gegen Ja-Aber-Sager

Man mag es kaum glauben. Es sind nur zwei Worte und sie können trotzdem eine vernichtende Wirkung haben. Es scheint nahezu unmöglich, noch an positive Kommunikation zu denken, wenn die Kommunikation des Gegenübers alles andere als wertschätzend ist. So schwierig muss der konstruktive Umgang mit Ja-Aber-Sagern allerdings gar nicht sein, wenn es gelingt, den eigenen Ärger über den gerade geäußerten Widerstand zu reframen (umzudrehen) und dem Gegenüber mit Verständnis für seinen Einwand zu begegnen.
 
Also: Beginnt eure Reaktionen auf das Ja-Aber-Argument mit „Das verstehe ich…“, „Da hast du recht…“ oder „Das ist ein interessanter Punkt …“ und fügt dann das magische Wort „und“ ein, bringt euer nächstes Argument oder verstärkt das vorangegangene Argument durch mehr Detailtiefe!
 
Ein einfaches “Dankeschön” ist ein weiteres, sehr erfolgreiches Rezept gegen Ja-Sager. Ja, ihr habt richtig gelesen. Gerade wurde eure Arbeit des letzten Sprints nicht besonders wertschätzend beurteilt und ihr sollt euch bedanken, z. B. mit den Worten: “Vielen Dank für dein Feedback. Wir nehmen dein Argument mal mit ins Team und diskutieren es aus. Was hältst du davon, wenn du dann einfach dazukommst und wir schauen, was das für das Ergebnis unseres Sprints bedeutet. Wann hast du Zeit für uns?“


Literatur
B. Gloger (2011). Scrum – Produkte zuverlässig und schnell entwickeln. Hanser Verlag

Führung und Management in Spannungsfeldern (Teil 2)

Es gibt für den Umgang mit Spannungsfeldern (siehe Teil 1) keine eindimensionalen Rezepte oder Bilderbuchlösungen. Jedes Dilemma, jede Spannungssituation ist spezifisch und beeinflusst von Kontextvariablen (aktuelle Unternehmenssituation, Führungskultur, Mitarbeiter, individuelle Muster und Prägungen etc.) und muss daher im Einzelfall konkret bearbeitet und entschieden werden. Die folgenden Tipps verstehen sich daher als Anstöße, sich auf die Spannungsfelder im Feld der Ziele und Werte einzulassen und sie aktiv zu bearbeiten und zu lösen.

  1. Gelassen bleiben: Führungskräfte sollten signalisieren und verdeutlichen, dass Spannungsfeldkonflikte (Ziele- und Wertekonflikte) Teil der Normalität sind. Sie liegen in der Komplexität der Management- und Führungssituation begründet und sind somit eine immanente Herausforderung. Auch wenn sie individuell erscheinen, haben sie nicht mit persönlichem Versagen zu tun, wenn Entscheidungen sich als dysfunktional herausstellen. Besser eine „falsche“ als keine Entscheidung. Das heißt auch offen bleiben für Zurücknahme und Modifikation.
  1. Abwägen und eruieren: Unterschiedliche, ambivalente Anforderungen schließen sich häufig nicht so grundsätzlich aus, wie es auf den ersten Blick scheint. Es geht häufig nicht um ein Entweder-oder, sondern um ein Sowohl-als–auch. Ein Kompromiss ist häufig eine überlegenswerte Alternative und macht handlungsfähig. Prinzipien sind wertvoll, können aber auch sehr hinderlich sein. Also zumindest hinterfragen.
  1. Situativ entscheiden: Management und Führung kann sich nicht permanent an vorgegebene Richtlinien und Regeln halten. Stattdessen muss immer wieder neu von Situation zu Situation entschieden werden, welcher Weg weiterführt und im Idealfall zum Erfolg führt. Flexibilität im Entscheiden ist heute eine zentrale Kompetenz im Führungsalltag. Routinen hinterfragen, das Gegenwärtige anerkennen und das Neue erwägen. Widersprüche aushalten und als Teil der Führungsrolle akzeptieren.
  1. Nach Alternativen suchen: Meist bieten sich auch für verfahrene Situationen mehr Lösungsmöglichkeiten an als zuerst angenommen. Innere Distanz zum jeweiligen Spannungsfeld zu nehmen und die Perspektiven zu wechseln führt zu möglichen dritten Lösungswegen. Von Situation zu Situation müssen ggf. gewohnte Handlungsmuster, Ideale, moralische Glaubenssätze in Frage gestellt und situativ modifiziert werden. Die Kunst dabei ist es, authentisch, klar und transparent zu bleiben.
  1. Sich Konflikten stellen: Manager und Führungskräfte können es nicht immer allen recht machen. Konfliktsituationen gehören zum Alltag. Werden Konflikte verdrängt, besteht die Gefahr von Eskalation. Konfliktmanagement ist eine genuine Führungsaufgabe immer dann, wenn Klima und vor allem Leistung gefährdet sind.
  1. Risiken eingehen: Jede echte Entscheidungssituation ist ein Konflikt, ist ein Risiko. Das heißt nichts anderes, als dass der Umgang mit dem Risiko und das Entscheiden trotz Risiken zu den grundlegendsten Aufgaben von Führung gehört. Risiken sollten minimiert werden, dort wo dies durch rationale Absicherung möglich ist. Sie können auf mehrere Schultern verteilt werden (Managementteam!) d.h. im Konsens erarbeitet werden, im Rahmen der Zeit die zur Verfügung steht. Letztlich muss der Feuerwehrmann ins brennende Haus, auch wenn es ein Risiko bedeutet. Er weiß dies und entscheidet sich, weil es zu seiner Funktion und Aufgabe gehört.
  1. Entscheidungen treffen: „Eine falsche Entscheidung ist meist besser als keine Entscheidung.“ Vom Management werden Entscheidungen erwartet, an der Entscheidungsfähigkeit wird u.a. ihre Kompetenz und Wirkung gemessen. Jeder Manager, jede Führungskraft trifft täglich eine Vielzahl von Entscheidungen. Die meisten sind Routine- und Standardentscheidungen und fallen eher leicht. Spannungsfeldentscheidungen stellen hohe Anforderungen an Willen und Kompetenz bezüglich der Entscheidungspraxis. Sich mit den eigenen Entscheidungsmustern auseinanderzusetzen und sie zu optimieren, gehört zu den zentralen Elementen des Berufes Management und Führung (siehe unten)
  1. Sich austauschen: Führungskräfte tendieren aus verschiedenen Gründen dazu, Probleme und Spanungssituationen mit sich alleine auszumachen. Jedoch verhindert die „einsame“ Entscheidung häufig den Blick auf neuen Lösungen und macht es schwierig, Situationen realistisch und distanziert einzuschätzen. Kollegiale Beratung kann hier Abhilfe schaffen und wertvolle Unterstützung in Problemsituationen sein. Führungsarbeit wird ohnehin zwangsläufig immer mehr zur kollegialen und kooperativen Teamarbeit. Auch Rat von loyalen und kompetenten Mitarbeitern oder Freunden kann sehr wirkungsvoll sein.
  1. Professionelle Unterstützung suchen: Das Beratungsmodell Coaching bietet Managern eine wirkungsvolle Möglichkeit, mit Spannungsfeldern umzugehen. Im vertraulichen Rahmen von Coachingsitzungen können die unterschiedlichsten Elemente schwieriger, auch spezifisch persönlicher Themen intensiv und ergebnisorientiert bearbeitet werden. Auch für „echte“ Dilemmata können so Anstöße für Entscheidungen und Handlungsmöglichkeiten gewonnen werden.
  1. Mut zum eigenen Weg haben: Die unterschiedlichen, sich oft widersprechenden Ausgangslagen erfordern Mut, eigene Wege zu finden, zu kommunizieren und zu vertreten. Führungskräfte müssen auch anecken, herausfordern, sich durchsetzen. Führung hat systemisch gesehen Vorrang im Sinn höherer Verantwortung und somit die Legitimation für „nicht entscheidbare Entscheidungen“.

Führung und Management in Spannungsfeldern (Teil 1)

Im Management- und Führungshandeln gibt es Spannungsfelder und Dilemmata, die im Führungskontext eine wesentliche Herausforderung sind. Im Zeichen ständig wachsender Komplexität und Agilität im Umgang mit Werten, Zielen, Strategien, Information, Mitarbeitern, Kunden, Technologien etc., werden Entscheidungen und Handlungen erforderlich, die in ihrer Ausgangslage vielschichtig und zum Teil hoch widersprüchlich erscheinen. Reinhard K. Sprenger spricht von einer „Überfülle der Möglichkeiten“ (Reinhard K. Sprenger „Radikal Führen“ Campus Verlag, 2012). Unterscheiden muss man zwischen alltäglichen Widersprüchen, die situativ gelöst werden müssen und Spannungsfeldern, die sich grundsätzlich auf der Ebene von Zielen und Werten bewegen. Von einigen dieser Herausforderungen für Führung soll hier die Rede sein.
„Führung wird erst dann wertvoll, wenn Routinen versagen.“ (Reinhard K. Sprenger)

Spannungsfelder in Ziel- und Wertekonflikten

Kontrolle versus Vertrauen

Vertrauen in die Mitarbeiter ist ein wesentliches Element von Beziehungsmanagement und hat großen Einfluss z.B. auf Motivation der Mitarbeiter, ihr Engagement und ihren Willen zur Mitgestaltung. Damit sich Vertrauen als Basis für Selbstorganisation aufbaut und entwickelt, braucht man Zeit und ggf. einen „Vorschuss“ zur Erprobung. Vertrauen beinhaltet immer auch das Risiko. Zur Prozess- und Ergebnissicherung scheint Kontrolle ein unverzichtbares Element sozialer Leistungssysteme zu sein. Kontrolle konterkariert aber evtl. Vertrauen und kann Misstrauen signalisieren.
Wo liegt das richtig Maß, wo die Balance?

Qualität/Kundenorientierung versus Kosten

Qualität ist eine zentrale Forderung kundenorientierter Unternehmen. Qualität kostet Geld und braucht Zeit. Kostenmanagement ist ein wesentlicher Faktor für die Zukunftssicherung von Unternehmen und zeigt Grenzen von Qualitätssicherung auf, die häufig einen kostenintensiven Aufwand bedeutet.
Was hat Vorrang?

Individualität/Konkurrenz versus Kooperation/Kollektiv

„Konkurrenz belebt das Geschäft“. Wettbewerb fördert Motivation und Leistung und zeigt wichtige Unterschiede für die Leistungsbeurteilung von Mitarbeitern auf. Interne Konkurrenz macht stark gegen externe Konkurrenz, der sich jedes Unternehmen stellen muss. Ohne Kooperation zwischen Mitarbeitern und Teilsystemen sind viele Unternehmensleistungen nicht mehr effektiv zu erbringen. Projektarbeit, team- und selbstorganisierte Gruppenarbeit basiert auf Kooperation und Dialog, bezieht daraus ihre Synergieeffekte. Jedoch, ein Team besteht aus eigenständigen Individuen, die ihre Interessen, Bedürfnisse berücksichtigt sehen wollen.
Wann soll man Konkurrenz zulassen, wann und wie Kooperation nutzen, fördern?

Ehrlichkeit versus Taktik

Ehrlichkeit ist ein soziales Phänomen, das für viele Menschen eine hohe moralische Bedeutung hat. Ehrlichkeit wird von unten nach oben und von oben nach unten erwartet. Ehrlichkeit schafft Vertrauen und Glaubwürdigkeit, sie macht authentisch. Taktik ist ein rationales Instrument des Handelns, das abwägt, Funktionalität prüft und entscheidet, was wann, bezogen auf wen transparent werden soll. Taktik entscheidet wenig moralisch, ergebnis- und zielorientiert. Taktik erscheint oft als unumgänglich, obwohl sie in gewissem Maße gegen Ehrlichkeit steht.
Wie viel Taktik, wie viel Ehrlichkeit, Ehrlichkeit total?

Veränderung/Innovation versus Stabilität

Das einzige Stabile ist die Veränderung. Veränderung ist ein wesentliches Kennzeichen unseres Zeitalters. Veränderungen bringen Weiterentwicklung, Chancen bergen aber auch Risiken. Veränderungen sind Herausforderungen und bedeuten Instabilität, Unruhe, Anstrengungen, immer neues Lernen, sich ein- und umstellen etc. Stabilität ist Ruhe, Entspannung Sicherheit. Routine bedeutet möglicherweise aber auch Stillstand, das Nachsehen haben, abgehängt werden. Stabilität bedeutet Risiko.
Wo ist das Maß, was ist notwendig, was ist schützens- und bewahrenswert?

Macht versus Beteiligung/Selbstorganisation

Macht heißt individuelle Stärke, heißt sich und seine Meinung, seine Optionen und Entscheidungen durchsetzen zu können. Macht heißt oben sein, aber auch einsam sein. Macht bedeutet, sich in Szene setzten und allein wirken. Beteiligung bedeutet zu allererst teilen. Beteiligung heißt Macht abgeben, andere einbeziehen, viele (alle?) mitreden lassen. Beteiligung heißt viele und vielseitige Kompetenzen nutzen, kollektive Ideen entwickeln, Motivation und  Umsetzungsengagement aufbauen. Selbstorganisation schafft Motivation.
Auf die eigene Macht bauen oder die Mitarbeiter einbeziehen, in welchem Maße, mit welchen Konsequenzen?

Konflikt versus Harmonie

Konflikte gefährden soziale Beziehungen, binden Energien, blockieren Leistungen und Synergie. Sie sind schwer zu handhaben, haben die Tendenz zu Eskalation und sind zerstörerisch. Konflikte sind nicht immer vermeidbar, klären Positionen, reinigen die Luft und bieten Chancen für Entwicklung. Harmonie sorgt für Ruhe und positive Kontakte, ermöglicht entspanntes Arbeiten und schützt vor Verletzung und Kränkungen.
Wann eingreifen, wie reagieren, wann schützen, wann Klartext reden?

Routinen/Regeln versus Kreativität/Abweichung

Routinen und Regeln geben Stabilität, Sicherheit und sollen Komplexität reduzieren. Sie schaffen überschaubare Gemeinsamkeiten, Kontinuität und Zuverlässigkeit. Sie bedeuten aber auch mangelnde Flexibilität, setzen enge Grenzen. Kreativität und Mut zur Abweichung ermöglichen neue Impulse, schaffen neue Wege und Lösungen, führen über Irritation zur Innovation.
Wo das Gewohnte, wo das Neue, wohin führen Regelverstöße, wo braucht es Grenzen und Möglichkeiten?


Sich diesen Herausforderungen und Spannungsfeldern zu stellen, sie sich grundsätzlich und situativ bewusst zu machen, ist ein zentrales Element des Managens und Führens. Entscheidungen in Spannungsfeldern zu treffen, obwohl die Situation eigentlich nicht entscheidbar ist und keine rational sichere Lösung machbar erscheint, ist ein wesentliches Element, das Hierarchie und damit Management und Führung legitimiert und notwendig macht.
Lösungsideen und Tipps demnächst in Teil 2!

ScrumMaster und gleichzeitig Teammitglied – ein Oxymoron

Ich mag unterschiedliche Meinungen. Ich halte fachliche Diskussionen für immens wichtig, wenn man sich und seinen Horizont erweitern möchte und die Tiefe einer Problemstellung ergründen will. Manchmal finde ich es sogar noch gewinnbringender, Diskurse von Menschen zu bestimmten Themen nur beobachten zu dürfen – aus der Adlerperspektive Fakten, Stimmungen und Argumente durch den Raum fliegen zu sehen und sein eigenes Bild zu schärfen, z.B. wer denn nun die Schuld trägt, dass der Berliner Flughafen ein Synonym von Michael Endes Bestseller „Die unendliche Geschichte“ zu sein scheint, ob es eine gute Entscheidung von Bayern München war, Pep Guardiola als neuen Trainer an die Isar zu holen oder wie (un)sinnig, Aufwandsschätzungen tatsächlich sind.
Es gibt allerdings auch Themen, die sind aus meiner Sicht indiskutabel. Das klingt dogmatisch, absolut, sogar intolerant. Ja, das stimmt. Und dennoch vertrete ich diese Auffassung mit absoluter Hingabe und Leidenschaft. Nicht, weil ich ein Besserwisser bin oder ein Problem habe, andere Meinungen anzunehmen. Keineswegs. Vielmehr nehme ich meine Profession als Berater ernst und möchte mit dieser Intoleranz andere Menschen an meinen Erfahrungen teilhaben lassen und sie davor bewahren, dieselben Fehler zu machen, die anderen zum Verhängnis wurden und immer wieder werden.
Ein Thema, das mich (manchmal) meine gute Erziehung vergessen lässt (ich nutze gerade das Stilmittel der Übertreibung, um mein Anliegen zu betonen, habt bitte Nachsicht mit mir), ist die fortwährende Diskussion, ob ein ScrumMaster auch gleichzeitig Mitglied des Entwicklungsteams sein kann. In jedem ScrumMaster Advanced Training wird diese Frage gestellt. Und das ist auch gut so. Meine Antwort beginnt immer gleich: „Die Frage ist ein Oxymoron – ein Widerspruch in sich!“ Ein ScrumMaster kann nicht gleichzeitig Teil des Entwicklungsteams sein. ScrumMaster zu sein ist ein Fulltime-Job. Jeder, der behauptet, das die three-hats-challenge (Change Agent, Servant Leader und Meeting Facilitator) nebenbei erledigt werden kann, ist meines Erachtens auf dem Holzweg. Die Doppelrolle, ScrumMaster und Teammitglied, bringt immer einen Interessenkonflikt mit sich und erinnert an das Gefangenendilemma: Sage ich zu dem einen Ja, verneine ich das andere. Ich kann nicht an zwei Orten gleichzeitig sein. Zwei simple Beispiele und doch so entwaffnend für die Argumentationslogik all derer, die postulieren, dass es doch gar nicht so schwer sei, beide Rollen und Verantwortungsbereiche unter einen Hut zu bekommen:

Ein Widerspruch in sich – ganz gleich wie groß die Schlupflöcher sind

So klein das Schlupfloch auch sein mag, es bleibt ein Widerspruch in sich. Hier eine Auflistung der beliebtesten Schlupflöcher „ScrumMaster und Teammitglied zugleich – das geht“:
Schlupfloch 1 oder weniger ist mehr: Das Entwicklungsteam besteht nur aus wenigen Entwicklern.
Schlupfloch 2 oder die sachliche Romanze: Der ScrumMaster ist nur ein Nebenjob (SM als Overhead und unterfordert).
Schlupfloch 3 oder das offenkundige Geheimnis: Der ScrumMaster hat als Entwickler eine geringere Entwicklungslast als seine Teamkollegen zu tragen.
Schlupfloch 4 oder das absichtliche Versehen: Als Servant Leader-Tätigkeiten werden Aktivitäten rund um das Konfigurationsmanagement, also Source-Code-Repositories aufsetzen, Toolketten pflegen, Continuous Deployment organisieren und optimieren, Continuous-Integration-Server aufsetzen, Jobs konfigurieren und verbessern, Toolketten optimieren, Backup-Prozeduren kontrollieren und testen, Branches aufräumen, etc., verstanden, um die Vollzeit-Entwickler zu entlasten.
Schlupfloch 5 oder das herrenlose Damenrad: Der ScrumMaster entscheidet für sich selbst, welche Verantwortung gerade die höhere Priorität hat, ScrumMaster sein oder Teammitglied.
Schlupfloch hin oder her, ScrumMaster und gleichzeitig Mitglied eines Entwicklungsteams zu sein ist und bleibt ein Oxymoron – ein Widerspruch in sich – sogar rechnerisch: 2 x 50% Auslastung macht eben nicht 100%, sondern 150%, da der Mensch (vielmehr sein Gehirn) jedesmal Zeit und Energie aufbraucht, um den Rollenwechsel zu schaffen. Und wer jetzt noch immer der Überzeugung ist, dass beide Rollen in einer Person vereinbar sind, der soll zumindest wissen, dass er gegen einen der fünf agilen Scrum-Werte verstößt: Fokus. Wie kann man das Ziel verfolgen, als Vorbild vorangehen und Menschen dazu bringen zu wollen, sich zu fokussieren, wenn man sich selbst schon bei der Übersetzung seiner eigenen Verantwortung widerspricht?

Der Führungsanspruch des ScrumMasters

Kennst Du ScrumMaster, die auch starken Gegenwind aus dem eigenen Team aushalten können? Die mit ihrem Team in leidenschaftliche Diskussionen gehen und auch dann nicht von ihrem Standpunkt abrücken, wenn das Team geschlossen anderer Meinung ist? Wenn ein ScrumMaster wirklich laterale Führung ausüben soll, dann müssten wir solche Situationen viel öfter erleben.

Was aber ist Führung?

Reinhard K. Sprenger zeigt in seinem Buch Radikal führen, dass Führung zum Lösen von Konflikten da ist. Was tun, wenn zwei oder mehr Handlungsalternativen da sind – und keine sich auf den ersten, zweiten oder gar dritten Blick als die eindeutig bessere entpuppt? Oft muss eine Entscheidung her. Und genau das – die Fähigkeit, in solchen Momenten Entscheidungen zu treffen und durchzusetzen – macht Führung aus.
Sprenger unterscheidet zwischen Wahl und Entscheidung. Bei einer Wahl können wir die verschiedenen Optionen auf die Waagschale legen. Wir können dann sehen, welche schwerer wiegt – wo die besseren Argumente sind. Bei einer Entscheidung ist die Ausgangslage komplett anders: Es gibt für jede Handlungsoption Argumente, aber keine Option sticht deutlich genug hervor, um die Situation entscheidbar zu machen.

Entscheiden in einer unentscheidbaren Situation: Wie lösen wir die Paradoxie?

Stellen wir uns folgende Situation vor: Ein Scrum-Team möchte nach sechs Monaten die Länge des Sprints von zwei auf drei Wochen verlängern. Es hat diesen Wunsch nun schon in mehreren Retrospektiven thematisiert und verschiedene Argumente dafür vorgebracht. Das Meinungsbild im Team ist seit mehreren Wochen unverändert geblieben.
Der ScrumMaster dieses Teams hat zumindest zwei Möglichkeiten:

Angenommen, der ScrumMaster wählt den zweiten Weg. Seine Position ist für die Beibehaltung der zweiwöchigen Sprints – damit geht er in das Team. Da der ScrumMaster keine disziplinarische Führungkraft ist, darf er seine Entscheidung dem Team nicht einfach vorschreiben. Er muss es dazu bringen, seine Entscheidung mitzutragen.
Wichtig sind hier vor allem zwei Dinge:

  1. Der ScrumMaster muss dem Team deutlich machen, warum ihm seine Position wichtig ist. Ansonsten wird das Team nicht verstehen, warum es ihm folgen soll. Das heißt im Umkehrschluss, dass ein ScrumMaster sich überlegen muss, wo er seinen Führungsanspruch geltend machen muss und wo das Team besser selber entscheidet.
  2. Der ScrumMaster muss dem Team deutlich machen, dass er nicht bereit ist, ohne Weiteres von seiner Position abzuweichen. Fängt er nämlich an, beim ersten Gegenargument ins Zweifeln zu geraten und seine Meinung zu revidieren, lässt er seine Führungsrolle fallen und wird zum Mitdiskutierer auf gleicher Ebene. Das Team merkt dann, dass es sich nicht wirklich an seinem ScrumMaster reiben kann. Standhaftigkeit ist aber nicht mit Sturheit zu verwechseln. Deshalb sollte der ScrumMaster seine Position so vermitteln, dass sie dem Team zugleich eine Perspektive bietet: Was muss alles getan werden, damit zweiwöchige Sprints besser werden? Damit die Skepsis des Teams verschwindet? Und wie kann der ScrumMaster als Servant Leader dabei helfen? Eventuell ergibt sich dann sogar eine Kompromisslösung. Zum Beispiel: Zweiwöchige Sprints ja, aber dafür Commitment auf weniger Stories, die dann dafür wirklich fertiggestellt werden.

Für den ScrumMaster ist die Situation eine Probe seiner Autorität: Wenn das Team seine laterale Führungsrolle anerkennt, wird es ihm letztlich folgen. Wenn es das nicht tut, wird es seiner ursprünglichen Überzeugung folgen und damit dem ScrumMaster signalisieren: “Du gibst uns nicht den Weg vor.”
So gesehen hat der ScrumMaster für sein Team eine Ankerfunktion: Er markiert Positionen als unverrückbar und setzt damit dem Team Handlungsgrenzen. Diese Grenzsetzung darf ruhig Irritation auslösen und konträr zum Team stehen. Negativ wird Führung erst dann, wenn sie die Entwicklung des Team einschränkt. Dann wird der ScrumMaster zum Impediment – und sollte besser gehen.
Keine Führung  (und das ist unter ScrumMaster die weitaus häufigere Situation) kann aber ebenso verheerend sein. Denn ein ScrumMaster, der immer nur sein Team entscheiden lässt, mag zwar jede Menge von Scrum verstehen – sein Team wird er damit nicht wirklich befruchten können. Denn Meister kann nur sein, wer die Gefolgschaft eines Lehrlings für sich gewinnen kann.
Reinhard K. Sprenger 2012: Radikal führen. Campus Verlag.
Siehe auch:

Der ScrumMaster, der besser keiner sein sollte
Führung selbstorganisierter Teams – alte Theorie vs. Scrum

Führung selbstorganisierter Teams – alte Theorie vs. Scrum

Die Rolle des ScrumMasters wird gerne schnell auf die des Moderators und des Organisators reduziert. Das ist schön greifbar und man hat die Erfahrung, dass solche Aufgaben wichtig sind und somit ihre Daseinsbereichtigung haben. ScrumMaster zu sein ist allerdings mehr als das. Es ist eine moderne Art der Führung, ohne disziplinarisch vorgesetzt zu sein. Die Kombination mit der Führung eines selbstorganisierten Teams wirft daher schon lange Fragen auf wie:

Solche Fragen tauchen nicht nur in Scrum auf, sondern begleiten die Forschung und Praxis selbstorganisierter Teams seit jeher. Schon 1986 versuchten sich Manz/Sims in ihrem Artikel “Leading Self-managed Groups: a Concept  Analysis of a Paradox” an einer integrativen Perspektive zur Führungsrolle in selbstorganisierten Teams. Dabei fassen sie auf Grundlage der sozio-technischen Systemtheorie und der sozial-kognitiven Lerntheorie das im Folgenden beschriebene Führungsverhalten zusammen. Da mir beim Lesen und Zusammenstellen vieles doch sehr bekannt vorkam, werde ich einfach die entsprechende Scrum-Sicht der Dinge ergänzen. In diesem Blog die gruppeninternen Aufgaben (direkt auf die Gruppe bezogen) und beim nächsten Mal die Aufgaben/Verhalten an der Grenze von der Gruppe zur Organisation.
Obwohl es in der Darstellung nicht explizit benannt wird, betrachten Manz/Sims (1986, S. 147) externes Führungsverhalten. Vielleicht hilft die Aufstellung dem einen oder anderen bei der Argumentation, warum wirklich ein ScrumMaster pro Team bzw. nur ein Team pro ScrumMaster drin ist!

Aufgaben Teamleitung eines selbstorganisierten Teams nach Manz/Sims Aufgaben des ScrumMasters
Mit dem allgemeinen Ziel, die Leistung des Teams zu steigern, sorgt der externe Teamleiter für die Förderung, Ver- und Bestärkung (und ggf. Unterstützung), nicht Durchführung oder Anleitung der Gruppe (vgl. Manz/Sims, 1986, S. 148f., 150f. ): 
Der ScrumMaster beschützt das Team vor externen Unterbrechungen und Störungen. Er hilft Probleme zu beseitigen, verbessert die Produktivität des Teams, treibt „inspect and adapt“ Zyklen voran. Er ist Moderator und lateraler – d.h. nicht weisungsbefugter – Leiter des Teams. Er arbeitet mit dem Product Owner, um die Rentabilität von Investitionen ins Produkt zu maximieren. Er stellt sicher, dass agile Prinzipien und Ideale verstanden und organisationsweit respektiert werden. Aber: Er ist nicht verantwortlich für die Lieferung des Produkts.
  • gruppeninterne Kommunikation – Austausch und Diskussion von Ideen und Bedenken
  • Der ScrumMaster sollte beim Team sitzen, damit er den Austausch mit Fragen initiieren, oder ggf. das Weiterführen fördern kann
  • Training unerfahrener Mitarbeiter durch das Team – Erschließung der Potenziale der Gruppe
  • Der ScrumMaster sorgt dafür, dass z.B. durch Pairing, Reviews, gemeinsame Plannings etc. der Wissensaufbau und Austausch funktioniert und somit alle bestmöglich beisteuern können
  • Problemlösung im Team – Evaluation und Lösung der eigenen Probleme
  • Der ScrumMaster gibt keine Lösungen vor (selbst wenn ihm sofort eine einfällt) oder Anweisungen, sondern versucht z.B. durch Fragen das Team zur eigenständigen Lösungsfindung und ggf. Alternativenbetrachtung zu bringen
  • teaminterne Arbeitsverteilung – effektive Aufteilung der Aufgaben zwischen Mitgliedern
  • Nicht nur im Daily achtet der SM darauf, dass der nötige Fokus bleibt und die Teammitglieder gemeinsam an der Lösung arbeiten
  • Planung – Koordination und Festlegung der notwendigen Aktivitäten vor der Durchführung
  • Moderation im Sprint Planning 1 und 2 und bei aufkommenden Unklarheiten oder Verbesserungsvorschlägen sorgt für ein gemeinsames Bild und Verständis, bevor man anfängt umzusetzen
  • Selbstbeobachtung / Selbstüberwachung – Gewinnung von Informationen über die eigene Arbeit als Grundlage für Evaluierung, Anpassungen, Soll-Ist Vergleiche bzgl. Zielen und z.B. Bestärkung bei Zielerreichung
  • Einfordern der Transparenz über z.B. die Bearbeitungslänge der Tasks (Punkt drauf, falls es länger als einen Tag dauert), empirische Erhebung und Visualisierung der gelieferten Story oder Function Points pro Sprint, Abweichungen vom Commitment etc. helfen dem Team – der ScrumMaster sorgt “nur” dafür, dass es auch gemacht wird
  • Selbstzielsetzung – Spezifische, realistische, herausfordernde Ziele können die Leistung positiv beeinflussen. Das eigenständige Setzen dieser bietet den Teams Arbeitsziele, an denen sie sich ausrichten können sowie die Basis für Selbstverstärkung bei Zielerreichung.
  • Hauseigen im Commitment angelegt. Das Einfordern gerne mit Hilfe des SM. Auch die Selbstverstärkung bei Zielerreichung kommt oft etwas kurz – geht mal feiern, wenn ihr es geschafft habt … wem nicht nach Feiern zumute ist, sollte das nächste Mal ehrgeiziger committen …
  • Modifikation der Anreize – Selbstbestärkung und Selbstkritik / Selbstbestrafung:
    • Selbstbestärkung sind Belohnungen, über deren Inhalt und Anwendung die Gruppe selbst (und nur selbst), entscheiden kann. Gewünschtes Verhalten wird von der Gruppe anerkannt, gelobt oder anderweitig belohnt und führt somit zu kontinuierlicher Anstrengung.
    • Selbstkritik oder Selbstbestrafung zur Reduktion von unerwünschtem Verhalten sollte offen und konstruktiv unter den Teammitgliedern eingesetzt werden. Zu starker Gebrauch kann zu Nachteilen wie Demotivation, Unzufriedenheit und verminderter Leistung führen. Teams können diese Form der Selbstorganisation jedoch auch (bewusst) vermeiden.
  • Der ScrumMaster sorgt dafür, dass das Team die Möglichkeit zur Modifikation bekommt.
    • Hat das Team momentan nicht die Möglichkeit oder wünscht sich andere Mittel für die Selbstbestärkung, sollte der ScrumMaster sich dafür einsetzen, diese dem Team zur Verfügung zu stellen oder mit dem Team Alternativen erarbeiten.
    • Der ScrumMaster sorgt dafür, dass die Kritik konstruktiv bleibt, jedoch durchaus ausgesprochen wird. Bei Kritik, die immer gegen eine Person geht, geht der ScrumMaster den Gründen nach und versucht diese zu beheben.
  • Proben – Diskussion oder Ausprobieren möglicher Lösungen für Probleme im Team bevor die Umsetzung erfolgt
  • Mit dem SP 2 auch schon im Prozess angelegt, dennoch sollte der SM immer wieder ermutigen, etwas zu skizzieren und auszuprobieren – auch wenn das bei Scrum schon die Umsetzung bedeutet. Verbesserungen bzw. mögliche Problemlösungen werden natürlich spätestens (!!!) in der Retro diskutiert.
Um diese Verhaltensweisen (SLT, gruppenintern) in Teams zu fördern, raten Manz/Sims (13 – S. 152) dem externen Teamleiter zu

  1. Vorleben, Vormachen, „Vorbild sein“ in der spezifischen Strategie zur Selbstorganisation;
  2. Ermutigung und Beratung, Orientierung, Leitung bei der Nutzung sowie
  3. Verstärkung, wenn das Team diese Strategien nutzt.



Am Beispiel Zielsetzungen beschreiben Manz/Sims (13 – S. 152) konkret, dass der Teamleiter den Prozess der eigenen Zielsetzung vormachen oder abbilden (1), Anleitung und Tipps wie Nutzung spezifischer und herausfordernder Ziele und Hilfe bei der z.B. der Formulierung (2) sowie das Verhalten der Zielsetzung bei Beobachtung loben (3) könnten. Sicher auf für ScrumMaster gute Tipps!

Ich finde es immer wieder faszinierend, wie viel in der ScrumMaster Rolle untergebracht ist und wie oft die Organisationen dennoch an ihrer Berechtigung zweifeln. Ein guter ScrumMaster zu sein ist verdammt schwer und mit Sicherheit kann man all diese Punkte nicht von der ersten Stunde an abdecken. Aber wenn man gleich nach einer eventuellen ersten Schonfrist neben dem einen Team noch ein oder zwei weitere aufgebrummt bekommt, nimmt man sich (die Organisation sich selbst) die Möglichkeit zu lernen, zu wachsen und den Nährboden für richtig gute ScrumMaster !!!


Quellen
Manz, C. &  Sims, H.  (1986): Leading Self-managed Groups: a Conceptual Analysis of a Paradox, Economic and Industrial Democracy Vol. 7, S. 141-164.

Stewart, G. & Manz, C. (1995): Leadership for Self-Managing Work Teams: A Typology and Integrative Model, Human Relations, Vol. 48, Nr. 7, S. 750.

Manz, C. &  Sims, H.  (1987): Leading Workers to Lead Themselves: The External Leadership of Self- Managing Work Teams, Administrative Science Quarterly, Vol. 32, No. 1, S. 106-129.

Gloger, B. (2012): Scrum Checklist.

Die Herausforderung und das Daily Scrum

Die größte Herausforderung für das Management ist es, Zusammenarbeit zu ermöglichen. Die größte Herausforderung für die Mitarbeiter ist es: zusammenzuarbeiten.
Zwei Hypothesen? Vielleicht. Vielleicht auch nicht.
Es ist zwar die Aufgabe des Managements, Zusammenarbeit zu fördern, zu fordern, zu ermöglichen, zu verbessern – trotzdem scheitern viele am eigenen Kleindenken und den eigenen Interessen, an einem unterschiedlichen Verständnis des Ziels oder mangelnder Abstimmung und gemeinsamen Planung und Anpassung. Komplexität kann nur von mehreren Menschen in der Interaktion aufgelöst werden, daher gilt es zusammenzuarbeiten. Gelingt uns das? Weitgehend ja, mitunter immer wieder verbunden mit größeren Anstrengungen. Eine Anstrengung betrifft das Management selbst.  Manchmal gelingt es Mitarbeitern zusammenzuarbeiten, wenn ihr Management auch zusammenarbeitet. Frage: Warum? Antwort: Anreize – mein Manager beurteilt mich, ich nehme stillschweigend an, dass eine übergreifende Zusammenarbeit nicht erwünscht ist und so ergibt sich der Rest… wäre zumindest eine Hypothese. Diametral dazu: die gute Zusammenarbeit in der Chefetage zeigt mir was gewünscht ist und ich übernehme das Verhalten als selbstverständlich.
Zusammenarbeit ermöglichen heißt: Ich schaffe einen Rahmen und helfe damit meinen Mitarbeiten bei der Zusammenarbeit. Bspw. unterstütze ich meine Mitarbeiter dadurch, dass ich ihnen einen Freiraum gebe, indem sie ungestört arbeiten können, indem ich Verantwortung und eigene Mittel im Gleichgewicht halte, sie als Experten anerkenne, ihre Entscheidungen respektiere und zum Schutz dieser Punkte bspw. einen ScrumMaster zur Seite stelle. Ein ScrumMaster unterstützt das Team bei der gegenseitigen Abstimmung im Team, bei Konflikten und moderiert die Kommunikation. Neudeutsch: Er ist ein Facilitator. So jemand schafft es üblicherweise, dass ein Team besser zusammenarbeitet. Am besten unterstützt ein Facilitator sein Team täglich. In Scrum ist das sowieso der Fall und ein täglicher Anlass ist das Daily Scrum.

Das Daily Scrum

An sich ein alter Hut. Dailies gab es schon vor Scrum, gibt es ohne Scrum, gibt es mit Scrum. Ein Scrum ohne Daily ist für mich kein Scrum – ganz klar. Nun stellt sich die Frage: Was macht ein gutes Daily aus?
Aus meiner Sicht ist das nicht viel und trotzdem sieht man es zu selten. Es bedeutet Zusammenarbeit und zwar im Sinn eines: “Wir planen den Tag.” D. h. wir als DevTeam möchten, dass jeder aus dem DevTeam bekannt macht, woran er gerade arbeitet, woran er arbeiten wird und möchte, ob er Unterstützung braucht oder wo er welche geben kann. Im Daily gibt jeder seine Arbeitsergebnisse kurz und knapp weiter. Frei nach: Wenn ein gemeinsames Bild geschaffen wird, dann lässt sich leichter planen, wie man zusammen weiter vorgeht. Die Basis dafür legt ein Team bereits im Sprint Planning 1 und insbesondere Sprint Planning 2, indem im Vorfeld das WAS und das WIE besprochen wurde. War das nicht der Fall, dann tun sich die meisten DevTeams während des Sprints schwer, gemeinsam den Tag zu planen.
Das DevTeam plant den Tag und was machen ScrumMaster und Product Owner? Beide haben im Daily ihre Aufgaben: Der Product Owner muss auskunftsfähig und erreichbar für das DevTeam sein, der ScrumMaster achtet auf den Kommunikationsfluss und auftretende Hindernisse.
Das DevTeam plant den Tag, das Daily Scrum gehört dem DevTeam? Ja, im Daily Scrum sprechen die Experten mit den Experten wie sie etwas umsetzen müssen, welche Schnittstellen fertig sind, woran wer arbeitet, woran wer plant zu arbeiten, wer wo helfen kann, wer wo hängt, wo etwas blockiert ist. Das klingt eigentlich nicht schwer, trotzdem bleibt die Interaktion eine Herausforderung. Zu dieser Herausforderung gehört vor allem auch die Selbstverantwortung des DevTeams: Vor allem Verantwortung zeigen, wenn etwas nicht funktioniert. Selbstdisziplin zeigen, indem man sich beschränkt, sich zurückhält und anderen zuhört, sich an die Timebox zu halten ist da nur ein Nebeneffekt.

…und wie unterstütze ich als ScrumMaster jetzt?

Einmal Abstand nehmen, darauf achten, wer mit wem im Daily redet. Ist es nur ein Statusbericht an Stakeholder, ScrumMaster oder Product Owner? Wenn ja, dann hilft es, dass sich alle Chicken ein paar Schritte vom Team und bspw. deren Taskboard entfernen.
Gehen die Teammitglieder nicht darüber hinaus zu sagen, was sie getan haben? Wenn ja, dann sprechen Sie vor dem Daily mit einzelnen Personen über das, woran sie gerne heute arbeiten würden und empfehlen Sie ihnen, den Wunsch auch im Daily kund zu tun. Um im Daily das Team-Mitglied zu erinnern, reicht dann oftmals ein ermunternder Blick, ein Räuspern oder Augenzwinkern.
Sind die Teammitglieder unsicher, was sie im Allgemeinen sagen sollen? Wenn ja, dann simulieren Sie im Vorfeld mit den Personen das Daily. Hier hilft es, die Person zu befragen, was wichtig für die anderen sein könnte, was der folglich nächste Schritt wäre, an dem gearbeitet werden soll, was die Person am liebsten als Nächstes tun möchte oder welche Probleme derzeit existieren und wie bzw. wer hier helfen könnte?
Letztlich kann man als ScrumMaster immer nur anschubsen und inspizieren ob sich etwas verändert, Dinge ausprobieren, pro-aktiv agieren und unterstützen. Auch hier gilt: Manchmal ist es besser sich zurückzunehmen und mal nichts zu tun, also einfach nur zu beobachten. Denn nur wenn Menschen eine Wahl haben, können sie die eigene Verantwortung wählen und ausfüllen.

Team Spirit stärken – "Magic Moments" gezielt nutzen

Team Spirit, Teamgeist, ist für jedes Team, und jeden, der in Teams eine besondere Funktion bekleidet, etwas außerordentlich Erstrebenswertes. “Teamgeist ist eine starke Form des Wir-Gefühls, die sich im Gegensatz zum bloßen Wir-Gefühl in gegenseitiger Unterstützung der Gruppenmitglieder ausdrückt, während das Gruppengefühl lediglich vom gemeinsamen Ziel getragen wird.” (Zitat Wikipedia) Man kann zweifellos davon ausgehen, dass ein vorhandener Teamgeist Elemente wie Motivation, Leistungsbereitschaft und Klima positiv beeinflusst und dass damit ein synergievoller Output des Teams gefördert wird. Gerade in Scrum-Teams, in denen ein hohes Maß an Kooperation, Kommunikation und Selbstorganisation zwingend ist, stellt sich somit die Frage, wie Teamgeist durch Teamentwicklung gefördert werden kann.
Teamentwickler können als spannendes Element sogenannte “Magic Moments” gezielt einsetzen, um aktiv den Team Spirit zu gestalten. “Bei Magic Moments handelt es sich um Phänomene im Zusammenspiel von Gruppendynamik und Arbeitsebene, die sprunghaft zu einer neuen Prozessqualität führen können.” (C. Nowak, E. Neubert- Liehm)*
„Magic Moments“ haben zum einen den wunderbaren Vorteil, dass sie in der Regel spontan in der Teamdynamik und im Arbeitsprozess in Erscheinung treten. Sie können aber zum Beispiel auch in Workshops “inszeniert” werden. “Magic Moments” haben einen ganzheitlichen Charakter, sie sprechen also Ratio, Emotionen und sogar körperliche Aspekte (z.B. Gänsehaut) in der Wahrnehmung von konkreten kollektiven Situationen an. Bewusste und unbewusste Erlebnisinformationen, Gedanken, Bilder und Szenen werden einerseits aktiviert, anderseits intensiv erlebt und perspektivisch abgespeichert. Und zwar sowohl individuell, als auch im kollektiven Teamgedächtnis und fördern so intensiv und nachhaltig das Gemeinsame im Sinne von Team Spirit.

 

Beispiele für Magic Moments

 

Teamentwickler (SrumMaster, Manager, Product Owner) brauchen eine sensible und differenzierte Wahrnehmung und Beobachtung, um “Magic Moments” zu erkennen und gezielt in den Team- und Arbeitsprozess einzubinden. Praktisch bedeutet das, das was auftaucht aufzugreifen und zu thematisieren. Gefühle und Erlebnisse wie Freude, Stolz, Euphorie, Aha-Erfahrungen usw. prägnant zu machen, zu intensivieren und ihnen Zeit und Raum zu geben. Diese Phänomene können im Alltag situativ auftauchen. Erfahrungsgemäß bieten alle gängigen Meetingformate in Scrum ideale Gelegenheiten. Bei der Gestaltung von Retrospektiven, Daily Scrums, Sprint Plannings, Estimation, Teamentwicklungsmeetings oder Change Management Workshops kann man mit kreativen, lebendigen Methoden und Techniken das Entstehen von “Magic Moments” fördern. Bilder, Symbole, Metaphern, Bodenanker, Rollenspiele, Outdoor-Aktivitäten etc. sind dafür ein gutes Ausgangsmaterial. Wichtig dabei: Das Team steht im Mittelpunkt, der Teamentwickler nimmt sich zurück. Jedes Team reagiert anders und nur das Team als Kollektiv kann letztlich entscheiden, was es als „Magic Moment“ empfindet und wie es damit umgehen will. Der Teamentwickler fungiert konsequent in der Rolle als Moderator und Feedbackgeber, evtl. auch vorsichtig als „Verstärker“.
TIPP: Lernen, wie man den Team Spirit stärken kann – im Training “TeamDevelopment” mit Dieter Rösner

Der ScrumMaster, der besser keiner sein sollte

Wir haben hier schon oft über die Aufgaben des ScrumMasters geschrieben. Was mir aber in den letzten Monaten bei Gesprächen mit Kunden und Kollegen, mit anderen Consultants, ja selbst bei Blog-Beiträgen anderer Scrummies auffällt: Vielen scheint immer noch nicht klar zu sein, dass ein ScrumMaster eine Führungspersönlichkeit ist. Eine Person, die ein Scrum-Team führt. Seine Hauptaufgabe ist in erster Linie die Produktivitätssteigerung des Scrum-Teams. Aber wie kann er das erreichen, wenn er dieses Team nicht führt, wenn er keine Rahmenbedingungen setzt, wenn er mit dem Scrum-Team keine Ziele definiert und sich nicht darüber im Klaren ist, wohin er selbst will?
Mir ist vollkommen klar, dass die meisten Organisationen, die sich mit Scrum beschäftigen, noch nicht genau wissen, was ein ScrumMaster wirklich ist. Aber wie sollen sie es auch lernen, wenn die ScrumMaster selbst das nicht wissen und leben?

ScrumMaster sind konstruktiv, nicht destruktiv

Hey, der Job ist beinhart! Ja wirklich, denn ein ScrumMaster muss positiv sein, motivieren und vor allem muss er Zuversicht ausstrahlen. ScrumMaster, die die Bedeutung ihrer Rolle noch nicht verstanden haben, erkennt man unter anderem daran, dass sie anfangen, wie kleine Kinder zu nörgeln und darüber zu jammern, wie schlecht die Organisation zu ihnen und ihren Teams ist. Ich kann noch verstehen, dass ein ScrumMaster nicht immer gut drauf ist, das wäre zu viel verlangt. Wenn er aber destruktiv wird, möglicherweise aus Frustration, dann sollte er Urlaub machen. Am besten gleich sechs Wochen am Stück, nachdenken und sich einen Coach suchen, der ihm bei der Selbstreflexion hilft. Denn er muss für sich Gewissheit schaffen, ob er nur “fertig” ist, weil der Job echt anstrengend war, oder ob er möglichweise gerade seine eigentliche Aufgabe aus den Augen verloren hat.
Ein Resultat dieses Denkprozesses kann sein: Man hat einfach keine Lust mehr dazu hat, ScrumMaster zu sein. Genauso wie ich nach sieben Jahren als Wochenend-Krankenpfleger für mich entschied: “Aus! Keine Bettpfannen mehr ausleeren!” Von heute auf morgen war Schluss mit dem Job. Und ich hatte ihn sehr gerne gemacht. Aber wenn man morgens aufsteht und sich ständig selbst sagen hört: “Das geht nicht, weil, … hier komme ich nicht weiter, weil die anderen, …. das haben wir versucht, das funktioniert nicht …” – dann ist man negativ unterwegs, selbst wenn man es nicht einmal so meint. Ich meine nicht, den Tag an dem man einfach mal mit dem falschen Fuß aufgestanden ist. Das ist völlig ok. Ich meine den Tag, an dem dir klar wird: “Jetzt ist es zum Routinenörgeln geworden.”

Denn das Problem ist: Das Scrum-Team bekommt es mit. Die destruktive Haltung wirkt sich sofort aus.

Ein anderes Ergebnis des inneren Dialoges kann sein, dass man sich aufmachen will, um die hohe Kunst der Führung ohne Macht zu erlernen. Ich muss es hier noch einmal betonen: Der ScrumMaster führt ein Scrum-Team an. Dann wird ihm hoffentlich klar: Er steht dem Management gegenüber dafür gerade, wenn das Scrum-Team nicht besser liefert. Sich hinter den Impediments zu verstecken und zu sagen: “Die Organisation lässt mich nicht, ich hab ja schon alles versucht” – sorry, das habe ich schon viel zu oft gehört. Zumal es ja die Aufgabe ist, die Impediments zu beseitigen. Davon darf man sich nicht einfach abbringen lassen. Die NASA hat einen Leitspruch: “Scheitern ist keine Option!” Ich hätte keine Verfahren für funktionierende Sprint Plannings, Daily Scrums, Massen-Sprint Plannings, Retrospektiven usw. entwickelt, wenn ich zufrieden damit gewesen wäre, dass unsere Meetings halt langweilig und unproduktiv waren, oder meine Teams keinen Spaß hatten.

Oft war der Schlüssel zur Lösung der Fragestellung, die mich tagelang frustrierte, mit anderen zu reden, stundenlang zuhause darüber zu sprechen und meinen Frust seitenweise in meinem Journal runterzuschreiben. Und kaum schaut man von außen drauf, vielleicht mit der Hilfe eines Coaches oder im Gespräch mit einem anderen ScrumMaster, kommt oft die Lösung, ganz nebenbei. Der ScrumMaster, der gerade noch verzweifelt war, sieht: “Es gibt ja doch noch viele Möglichkeiten.”

Um das aber zu können, braucht es das innerliche Commitment des ScrumMasters, die Rolle in ihrer Gänze zu leben.

Als die Führungsrolle von heute, die Scrum-Teams trotz der umgebenden Organisation produktiver macht. Dazu braucht ihr Führungs-, und Coachingskills, methodisches Verständnis zum Lean Product Development, Fachkenntnis über den technischen Hintergrund eurer Teams und eine ganze Menge Mut zur Selbstreflexion. All das erlernt man nicht über Nacht. Es dauert 10.000 Stunden, etwas wirklich meisterhaft zu beherrschen. Dazu ist kontinuierliches Arbeiten an euren ScrumMaster Skills notwendig. Doch all das könnt ihr euch schenken, wenn ihr den Kern nicht leben wollt: ein Scrum-Team trotz der Widerstände, die leider unvermeidlich sind und dazugehören wie der Kater zur durchzechten Ballnacht, erfolgreich zu machen.
Für viele bor!sgloger Consultants, ScrumMaster und Trainer liegt die Befriedigung trotz aller Widerstände darin, die selbst gesteckten Ziele zu erreichen. Das geht nie auf die einfache Tour. Wir müssen, obwohl unsere Kunden mit uns den Weg gehen wollen, am Widerstand entlang arbeiten, ihn nutzen und dabei nicht den Mut verlieren. Glaubt mir, wir haben oft stundenlang über den Wahnsinn, den wir in einigen Projekten gesehen habe, den Kopf geschüttelt und gemeckert. Aber nicht vor unseren Kunden und wir haben unsere momentane Demotivation nicht vor ihnen gezeigt. Die Aufgabe als Consultant ist ähnlich der des ScrumMasters: Zuversicht ausstrahlen, selbst dann, wenn gerade niemand mehr an den Erfolg glaubt. Das ist unser Job und auch der eines ScrumMasters. Diese Art der Führung kann man lernen, aber nicht über Nacht und nicht ohne Hilfe des eigenen Vorgesetzten oder eines Coachs.
Immer aber gilt, dass ihr euren Job zunächst als das verstehen müsst, was er im Grunde ist: Der ScrumMaster ist ein Veränderer ohne Macht, der nur durch die Kraft seiner Überzeugung die anderen ansteckt, dabei mitzumachen. Wir finden diesen Job bereichernd und sinnvoll. Wir wünschen Euch viel Freude und Erfüllung dabei.

Die Sprint Retrospektive – es kann noch viel verbessert werden (Teil 2)

In Teil 1 Die Sprint Retrospektive – es kann noch viel verbessert werden habe ich euch die Übung „Options Run“, als eine Möglichkeit vorgestellt, den Separator in eurer Retrospektive sinnstiftend auszufüllen. Heute habe ich für euch drei weitere Ideen, wie ihr Farbe in eure Separator-Time bekommt.

Snap-the-ball

Was auf den ersten Blick kinderleicht aussieht, entpuppt sich im Tun als Herausforderung und sensibilisiert dafür, dass auch leichte Aufgaben mit Sorgfalt und einer gewissen Portion Demut zu tun sind. Fragt eure Teammitglieder nach der Übung mal, was sie gedacht haben, als ihr ihnen die Übung vorgestellt habt. Hochmut kommt vor dem Fall.
Für diesen Separator benötigt ihr eine leere, auf einem Tisch stehende Plastikflasche und einen Tischtennisball. Diesen legt ihr auf die Öffnung der Plastikflasche. Die Teammitglieder stellen sich mit ein paar Meter Abstand zu der Flasche hintereinander auf und gehen zügig (nacheinander) und mit ausgestrecktem Arm auf die Flache zu und versuchen dabei, im Vorbeigehen mit dem Finger, den Tischtennisball von der auf dem Tisch stehenden Flaschenöffnung zu schnippen. Wichtig hierbei ist, dass ihr als ScrumMaster darauf achtet, dass eure Teammitglieder ihre Geschwindigkeit nicht kurz vor der Flasche abbremsen. Ihr werdet feststellen, dass die Koordination von Arm, Hand und Finger gar nicht so leicht ist. Wer dreimal hintereinander erfolgreich war, der ist Sieger des Separators.

Blindenführung

Vertrauen in ein anderes Teammitglied zu haben, ist für den Erfolg ein Teams essentiell. Sich auf eine andere Person verlassen zu können, blind zu vertrauen, ist ein Zustand, der nicht automatisch entsteht. Bei der Blindenführung agieren die Teammitglieder paarweise. A (sehend und stumm) führt B (blind). A kann sich entscheiden, wie er B führt – an der Hand, am Arm, an den Schultern. A entscheidet, welchen Weg er mit B beschreitet und welche Schwierigkeiten (z.B. Treppe, Tempovariation) er B hierbei zutraut. Wichtig bei dieser Übung ist, dass der ScrumMaster mehrmals betont, dass der Führende die absolute Verantwortung für den Blinden trägt. Im Rahmen der Timebox soll es die Möglichkeit, sich über die Gedanken, Gefühle, Wahrnehmungen in der jeweiligen Rolle auszutauschen.

Des Rätsels Lösung

Wahrnehmung erzeugt Wirklichkeit. Diese Erkenntnis ist für Teams kein Segen. Des Rätsels Lösung sorgt nicht nur für Heiterkeit, sondern soll euren Teammitgliedern verdeutlichen, wie schwierig Kommunikation sein kann, wenn unterschiedliche Bilder (Wahrnehmungen) die eigene Perspektive verzerren und auf diese Weise, weg von der Lösung führen. Das nachfolgende Rätsel ist lediglich ein Beispiel, um euch zu inspirieren:
Du betrittst ein Zimmer. Cäsar und Kleopatra liegen regungslos auf dem Boden. Sie sind tot. Der Teppich ist feucht und es liegen Glasscherben herum. Es ist keine Waffe zu sehen. Blutspuren sind auch keine da. Was ist hier passiert? 
Eure Teammitglieder sollen nun mit geschlossenen Fragen des Rätsels Lösung finden. Ist das Team dem Rätsel auf die Spur gekommen, zeigt sich deutlich, dass Menschen in Denkrillen kommunizieren. Jeder Mensch hat seine individuellen Denkarten und Denkwelten, die durch Erfahrungen und unterschiedliche Sozialisation geprägt sind. Dies für eine gemeinsame und erfolgreiche Kommunikation zu berücksichtigen, ist die Grundlage für Kongruenz von Verständnis.
Weitere Inspirationen finden sich beispielsweise in den Black Stories.

Die Sicherheitsfrage in der Retrospektive oder der Wert eines klaren Neins

Neulich durfte ich eine Retrospektive für ein kleines ScrumMaster-Team moderieren. Wir fingen mit der Sicherheitsfrage an: Bietet diese Retrospektive den Schutz, um die eigene Meinung ungehindert sagen zu können? Ich verteilte Zettel, auf denen jeder anonym mit “Ja” oder “Nein” antworten sollte.
 
Gute ScrumMaster hinterfragen alles. Und so kam dann auch hier schnell die Sinnfrage auf: Wozu stellen wir eigentlich die Sicherheitsfrage? Manche halten sie für unnötig, andere für überflüssig. In einer kleinen Gruppe, die sich gut und lange kennt, sind Vertrauensfragen einfach nicht üblich. Und dann stellt sich natürlich noch die Frage, was denn passieren soll, wenn jemand die Sicherheitsfrage mit “Nein” beantworten sollte. Wer auf diese Punkte keine guten Antworten hat, wird ein genervtes Augenrollen seiner Teammitglieder als Antwort bekommen.
 
Umso wichtiger ist es, den Sinn der Sicherheitsfrage klar vor Augen zu haben, um sie nach außen mit Überzeugung vertreten zu können. Unter allen Scrum-Meetings ist die Retrospektive mit Abstand das intimste. Ein Team, das sonst ständig das Produkt im Fokus hat, kehrt den Blick nach innen und reflektiert darüber, wie das Miteinander funktioniert. Allein das ist schon schwer. Wenn dann auch noch negative Gefühle wie Frustration, Enttäuschung, Wut oder Neid mitschwingen, haben wir es mit Zündstoffen erster Güte zu tun. Retrospektiven, in denen Teammitglieder sich anbrüllen oder durch abfällige Kommentare tief verletzen, sind keine Einzelfälle.
 
Die Sicherheitsfrage kann solche Situationen nicht vermeiden. Aber sie gibt jedem ganz am Anfang die Chance zur Reflektion: Wie gehe ich in diese Retrospektive rein? Fühle ich mich dabei frei oder eingeengt? Diese persönliche Reflektion geht dann als Signal an die gesamte Gruppe: Starten wir alle unbeschwert in die Retro? Falls nein, müssen wir innehalten und dem Betroffenen die Chance geben, sich zu äußern. Vielleicht wünscht er sich einen anderen Moderator. Vielleicht möchte er vom Team die Versicherung haben, dass man ihn diesmal endlich ausreden lässt. Solche Wünsche lassen sich manchmal schnell klären – manchmal aber auch nicht. Und manchmal sagt auch keiner etwas.
 
In jedem Falle wird die Sicherheitsfrage dann ein zweites Mal wiederholt und die Ergebnisse vorgelesen. Dann geht es mit der Retro weiter – auch wenn die “Neins” noch nicht verschwunden sind.
Wozu dann überhaupt die Sicherheitsfrage? Jeder im Team weiß nun, dass zumindest ein Mitglied sich in dieser Retro nicht frei fühlt. Und auch das ist ein Ergebnis sowie eine äußerst wichtige Information, die alle zum Nachdenken anregen sollte. Ohne die Sicherheitsfrage fiele es gewiss leichter, über Umstimmigkeiten hinwegzuschauen. Die Retro ist aber kein Heile-Welt-Spiel, sondern eine ernsthafte Auseinandersetzung. Deshalb brauchen wir die Sicherheitsfrage.
 
Weitere Tipps & Tricks zum Beispiel hier: http://www.akashb.com/blog/2012/05/28/agile-retrospectives-the-safety-check/

Die Sprint Retrospektive – es kann noch viel verbessert werden (Teil 1)

Die Retrospektive gehört zu den Nachzügler-Meetings im Scrum-Flow. Erst 2004, auf dem Scrum Gathering in Wien (vgl. Gloger, 2011, S. 180f.), erlebte die Agile Community die eigentliche Geburtsstunde des Meetings und es etablierte sich fortan zum unverzichtbaren Bestandteil des Scrum-Prozesses, weil Retrospektiven, fragt man Esther Derby, vor allem eins mit Teams tun: „Keep improving“ (Derby & Larsen, 2006, S. 2).
 
Retrospektiven haben das Ziel, auf der Grundlage des Erlebten (des vergangenen Sprints), Maßnahmen für die Zukunft (den nächsten Sprint) zu generieren, die sowohl die Arbeitsabläufe verbessern sowie  störende Blockaden (Impediments) identifizieren, analysieren und beheben sollen. Um das zu erreichen, stehen zwei Fragen im Fokus der Betrachtung: „Was lief gut?“ und „Was könnte verbessert werden?“ – Erfolgsfaktoren und Potentiale.
 
In meinen täglichen Beobachtungen erkenne ich sowohl in der Moderation als auch in der methodisch, didaktischen Führung des Meetings jede Menge „Luft nach oben“. In diesem Beitrag möchte ich daher das Augenmerk auf die oben bereits erwähnten Schritte 3 (finde funktionierende Prozesse) und 4 (finde nicht-funktionierende Prozesse) (vgl. Gloger, 2011, S. 184ff.) richten. Hier offenbart sich leider ein Trend, den ich nicht nur nicht gutheißen kann, sondern der meines Erachtens auch für eine gewinnbringende Retrospektive kontraproduktiv ist.
 
Die sechs Schritte einer erfolgreichen Retrospektive setzen einen stringenten und lückenlosen Ablauf voraus:
 
Schritt 1: Schaffe Sicherheit
Schritt 2: Sammle Fakten
Schritt 3: Finde funktionierende Prozesse
 
Separator


Schritt 4: Finde nicht-funktionierende Prozesse
Schritt 5: Leite Veränderungen ein
Schritt 6: Entscheide über die Wichtigkeit
 
Zu diesem gehört, dass zwischen Schritt 3 und Schritt 4 ein Zwischenschritt, der sogenannte Separator, eingesetzt werden soll. Dieser hat den Zweck, den „gemeinsamen Denkraum“ (a.a.O, S. 188f.) kurz zu verlassen, um eine spürbare Trennung der beiden Teile „gut“ und „verbesserungswürdig“ zu erreichen. Boris Gloger empfiehlt dafür kreative Arbeitstechniken und betont, dass er mit dem Zwischenschritt „keine Kaffeepause“ meint. Leider ist es aber allzu häufig so, als würde man zu einem kleinen Kind mit erhobenem Zeigefinger sagen: „Fass die Herdplatte nicht an!“
 
Der Separator wird entweder für eine Kaffeepause genutzt oder es wird einfach darauf verzichtet. In beiden Fällen, im zweiten noch mehr als im ersten, verstärkt sich das Risiko, dass die positiven Effekte und Energien (rewards) aus Schritt 3 nicht konserviert werden und durch die nachfolgende Rückschau der nicht-funktionierenden Prozesse, also negative Erlebnisse (threats), sich sogar neutralisieren können. Daher lautet mein deutlicher Appell an alle ScrumMaster und Retrospektiven-Facilitator:



Baut in eure Retrospektiven einen Separator ein, der mehr als ein Durchlüften der Räumlichkeiten ist oder Zeit für einen Toilettengang lässt!
 
Ich möchte euch eine etablierte und gleichzeitige aufheiternde und alle Beteiligten aktivierende Kreativtechnik für euren nächsten Separator vorstellen: den Options Run.
 
Was brauchst du dafür?

  • Einen 5 Meter langen Streifen aus Kreppband (auf dem Boden als Linie geklebt)



Was hast du als ScrumMaster zu tun?

  • Alle Teammitglieder inkl. ScrumMaster stehen an einem Ende der Kreppbandlinie (Start). Die Linie versteht sich als Brücke über einen Fluss. Ziel ist es, ans andere Ende des Ufers zu gelangen. Allerdings gibt es für die Überquerung Constraints.

 
Constraints

  • Der ScrumMaster muss als Letzter ans andere Ufer.
  • Jedes Überqueren ist mit einem Lob (Applaus) zu versehen und verdient die Wertschätzung des gesamten Teams.
  • Bei jeder weiteren Überquerung muss eine neue/andere/eigene Art der Überquerung gewählt werden.

 
Sinn und Zweck des Option Runs

  • Wertschätzung der Leistung jedes Teammitglieds
  • Jede (neue) Lösung ist gut, richtig, besonders. Es gibt kein Falsch!

 
Variante

  • Das Team wählt die kreativste Form der Überquerung aus und der Sieger erhält einen kleinen Preis.

 
In Die Sprint Restrospektive – es kann noch viel verbessert werden (Teil 2) stelle ich euch noch andere kreative Ideen für energiereiche Separatoren vor und weise auf weitere typische Fallstricke in der Retrospektive hin. 
 
 
Literatur
 
Derby, E. und Larsen, D. (2006). Agile Retrospectives: Making good teams great. The Pragmatic Programmers.
Gloger, B. (2011). Scrum – Produkte verlässig und schnell entwicklen. Hanser.

Gute ScrumMaster können Emotionen erkennen oder die Wahrheit steht uns ins Gesicht geschrieben

Vor kurzem kam nach einem Review, bei dem ich Gast war, ein ScrumMaster auf mich zu und fragte, ob und wenn ja, woran er erkennen könne, wie sich seine Teammitglieder, Review-Besucher oder Gesprächspartner gerade fühlen. Mit seiner Frage verband er die Annahme, dass ich als Psychologe und Coach doch sicher immer genau weiß, was mein Gegenüber gerade denkt oder fühlt und ob ich Tipps hätte, wie er das erlernen kann. Wie auf Knopfdruck setzte ich mein strahlendstes Lächeln auf und fragte zurück: „Was vermutest du, welches Gefühl ich gerade in mir trage?“ Ohne lange zu überlegen, antwortete der ScrumMaster: „Du bist glücklich. Ich weiß zwar nicht genau, warum, aber dein Lachen war für mich ein Zeichen von Freude. Ich nickte ihm zu und fragte ihn weiter: „Woran hast du das erkannt?“ Er antwortete wieder sehr schnell: „Das war doch kinderleicht. Wenn ein Mensch lacht, dann freut er sich über etwas.“ Wieder konnte ich ihm zu dem Gesagten nur Recht geben.
 

Meistens ist es etwas schwieriger, die Gefühle vom Gesicht des Gegenübers abzulesen.


 
Mit der Frage „Kennst du die sieben Basisemotionen des Menschen?“ setzte ich unser Gespräch fort. Der ScrumMaster antwortete mit einem Kopfschütteln. Ich erläuterte ihm, dass Basisemotionen, auch Grundgefühl oder Primäreffekt genannt, die Gefühle oder Affekte sind, die als wesentlicher Bestandteil jeder menschlichen Existenz verstanden werden sollen und dass Angst, Überraschung, Ärger, Ekel, Verachtung, Trauer und Freude in der heutigen Forschung als die sieben Basisemotionen anerkannt sind. Mit gespannter Miene fragte mich der ScrumMaster: „Und wie erkenne ich nun, wann welche Emotion zu sehen ist? Kannst du mir noch ein wenig mehr darüber erzählen?“ Ich nickte und fuhr mit meinen Ausführungen fort: „1969 haben die Wissenschaftler Ekman, Sorensen und Friesen in ihrer Studie „Pan-Cultural elements in facial displays of emotions“ dokumentiert, dass der Ausdruck der Basisemotionen kulturübergreifend gleich ist (1). Charles Darwin war einer der Ersten, die sich mit dem Ausdruck von Gefühlen in der Mimik (= Miene) auseinander gesetzt haben. Seiner Meinung nach enthüllen „die Bewegungen der Mimik die Gedanken und Absichten eines Menschen mehr als Worte“. Heute ist die Mimik das am besten beforschte Handlungsfeld der nonverbalen Kommunikation (2).”
 

Die Wahrheit steht uns ins Gesicht geschrieben

Fest steht, dass es einen Zusammenhang zwischen unserer Mimik und dem limbischen System (= Emotionszentrum) gibt. Das bedeutet, dass eine Veränderung bzw. Bewegung in unserer Mimik (z.B. Stirnrunzeln, Mund verziehen, etc.) eine Aktivität im limbischen System verzeichnet. Dieses Aktivitätspotential nennt sich sensorisches Feedback der Mimik und ist ein integraler Bestandteil unserer Empathie, die uns, je stärker sie ausgeprägt ist, dazu befähigt zu erkennen, wie sich andere Menschen gerade fühlen, was sie brauchen könnten oder von uns wollen. Denn fest steht: die Wahrheit steht uns ins Gesicht geschrieben. Das sensorische Feedback der Mimik ist mit verantwortlich dafür, dass wir in einem Gespräch die mimischen Gesten unseres Gegenübers unbewusst und kaum erkennbar nachahmen. Auf diese Weise stellen wir eine gefühlsmäßige Verbindung zum anderen her und verstärken das eigene Gefühl dafür, was im Gesprächspartner gerade passiert. Darüber hinaus bewirkt nicht nur eine Bewegung in der Mimik eine Bewegung im limbischen System, sondern auch umgekehrt! Wenn wir etwas fühlen, zeigt sich dies meist auch in der Mimik. Auch wenn wir die Emotion unterdrücken möchten oder uns dieser noch nicht bewusst geworden sind.
 
Dieser ganz kurze, unbewusst zum Ausdruck kommende und aus einer Emotion entstandene Ausdruck in unseren Gesichtern nennt sich Mikroexpression. Sie zeigt sich in emotional intensiven Momenten (z.B. bei Ärger oder Skepsis, Panik oder während eines Streits) 40 bis 500 Millisekunden lang (bzw. kurz) und soll dem Gegenüber eigentlich verheimlicht werden. Da sich eine Mikroexpression der Kontrolle unseres bewussten Denkens und Handelns vollständig entzieht, weil sie direkt von unserem Emotionszentrum gesteuert wird, ist sie als Signal für ein bestimmtes Gefühl äußerst zuverlässig. Ihr sehr kurzes Auftreten hat für uns zur Folge, dass, wenn wir mimische Signale bei unseren Mitmenschen erkennen und auf Grundlage dieser Analyse diese interpretieren wollen, braucht es vor allem eins: Übung.“
Der ScrumMaster schaute mich mit skeptischem Blick an und entgegnete auf meine Ausführungen: „Das klingt alles ziemlich spannend. Aber die Theorie kann ich auch in Büchern nachlesen. Kannst du mir nicht etwas Handfestes geben. Wie kann ich Mimik denn nun verstehen lernen, um besser, vielleicht schneller, achtsamer gegenüber meinem Team zu reagieren?“ „Wenn du mimische Signale deiner Mitmenschen erkennen, treffsicher interpretieren und achtsam damit umgehen lernen möchtest, dann solltest du erstens Mimik lesen (= Mimikscouting) lernen, zweitens Mimik entschlüsseln (= Mimik(en)coding) lernen und drittens achtsam mit den erhaltenen Informationen umgehen (= Resonanztraining) können.”(2)

Emotionen erkennen lernen 

Hier sind zwei einfache Übungen, die ein erster Schritt dahin sind.
 
Übung 1: Fotoapparat
Diese wunderbare Übung kannst du auch mit den Mitgliedern deines Teams ausprobieren. Stellt euch zu zweit gegenüber. Einer von euch übernimmt die Rolle des „Objekts“, der andere ist der „Fotoapparat“. Der Fotoapparat beobachtet nun aufmerksam das Gesicht des Objekts. Irgendwann schließt der Fotoapparat seine Augen. Daraufhin verändert das Objekt genau eine Sache in seinem Gesicht. Bitte verändert eure Mimik anfänglich so, dass es nicht ganz so schwer für euer Gegenüber ist (z.B. Mund auf oder Augenbrauen stark anheben). Später darf es dann auch gerne schwerer werden. Hat das Objekt etwas verändert, tippt es den Fotoapparat an, der dies zum Anlass nimmt, seine Augen kurz zu öffnen und dann gleich wieder zu schließen (wie ein Augenzwinkern). Mit geschlossenen Augen ahmt der Fotoapparat nun das nach, was er „gesehen“ hat. Er kann es auch beschreiben, wenn die mimische Veränderung zu schwierig ist, um sie nachzumachen. Wechselt euch nach fünf Versuchen ab und gebt euch danach gegenseitig Feedback zu dem, was ihr erlebt/gesehen oder nicht gesehen habt.
 
Tipp zur Ausführung: Achtet wirklich darauf, dass ihr als Fotoapparat nur kurz eure Augen öffnet. Verlasst euch auf euer Gefühl. Es wird euch den Weg verraten.
 
Übung 2: Emotionen erkennen im Selbst-Test

Wenn du diesen Link anklickst, kannst du kostenlos den Selbst-Test „Emotionen erkennen“ machen. Finde heraus, wie gut deine Fähigkeit ist, die Gefühle in den Gesichtern anderer Menschen zu erkennen.“

Der ScrumMaster strahlte mich an und ich sagte zu ihm: „Scheint, als hätte ich dich neugierig gemacht und du bist schon ganz gespannt, wie gut die Übungen funktionieren.“ „Das stimmt“, antwortete er. „Hast du noch einen letzten Tipp für mich, bevor ich in meine Team-Retrospektive gehe?“
„Ja, den habe ich“, entgegnete ich ihm. „Wenn du in die Gesichter deiner Teammitglieder schaust und dich probieren magst, dann beachte zwei wichtige Regeln:

  1. Trenne deine Wahrnehmung und Beobachtung immer von deiner Interpretation.
  2. Mimik verrät dir nie, warum ein Gefühl aufgetreten ist.“

 
 
Literatur


(1) Ekman, P., Sorenson, E.R. & Friesen, W. V. (1969). Pan-Cultural elements in facial displays of emotions. Science 164 (3875), S. 86 – 88.
 
(2) Eilert, D. (2013). Mimikresonanz-Trainerausbildung. Eilert-Akademie, Berlin.

Sprint Planning with geographically dispersed teams located in different timezones

When working with geographically dispersed teams (where the members of one team are spread across different locations), the team members and I find it rather difficult to keep focused on the phone during the entire Sprint Planning 1 and 2. Even more so when considering the different time zones. As one part of the team comes in right after lunch, the other part is nearly on their way home, while the third part is starving for lunch. In this situation, the retrospectives showed that the quality of the Sprint Planning 2 and the common understanding of the design ideas should be improved. Additionally, I (as ScrumMaster) wished to improve the team members’ communication and their participation within both Sprint Plannings. For reasons of seniority, experience and cultural differences, it was always the same few members who participated in the discussions.
 
Noticing a possibility for killing two birds with one stone, I changed the set-up of the Sprint Plannings – despite some team members complaining about long planning sessions and that Scrum was creating too much overhead ;-). So I changed the Sprint Plannings in such a way that they would not be held within one day, but split into two different days, using the morning in Europe for the three hours overlap of working time. That gave us the opportunity to use two full hours for the Sprint Planning 1 and 2 on each day.
 
Furthermore, to increase the participation of the team members, I asked all members working in the same location to hold their own smaller version of a Sprint Planning 2 on the day or morning before the session with the whole team. By doing so, I automatically created some competition amongst the dispersed team to come up with the „best“ solutions and share them with the others. This was particularly interesting, as I had not split the pulled stories for the Sprint Planning 2, but instead asked every location to put forward a design for every story. Now that we had three different solutions on the table in the Sprint Planning 2, the team was able to discuss which one would be preferred or which combination of the different design solutions made the most sense. Since all members had participated in the design of a solution, their involvement and the variety of possibilities for implementation clearly increased. At the same time, the meetings were not as long and stiff anymore.
 
Plus: The additional time now available after the Sprint Planning 2 or before the Sprint Planning 1 could now be used for working through the feedback from the review, continuing on the development of technical topics, or even refactoring 😉
 
What advice do you have for working with geographically dispersed teams?
 
 
See also the interview series by Stephanie Gasche about internationally distributed Scrum-Teams.

Scrum Spaces of internationally distributed Teams – the Do's and Dont's

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

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?
Part 2: Should internationally distributed Teams be avoided?
 
Stephanie G.: So now that we’ve discussed reasons for and against setting up internationally distributed Teams as well as analysed their efficiency, I would like to get down to the more practical questions. Imagine that you’re a ScrumMaster for an internationally distributed Team and you were given a reasonable budget – what would your Scrum Spaces (meaning: Team offices) look like and what would you equip them with?!
 
Deborah W.: Is this a trick question? Can I also use the budget to fly the Team mates in? Because that is what I would do! I know that we have already discussed this, but it‘s important enough to be mentioned over and over again: face-to-face meetings are absolutely vital for building up trust amongst Team members. If – however – that’s not an option and I am really only allowed to use the budget for furnishing the Scrum Spaces, I would make sure that all artefacts are present in all locations. Also, a decent webcam is an absolute must, as it kind of makes up for the lack of face-to-face time.
 
Bernd K.: Yes, anything that you do should really lead towards resembling a co-located Team. I would put up large photos of the other Team members in order for everyone to know that they‘re always there – even if they physically aren’t. As a Team member, I would probably also appreciate it if my ScrumMaster were to set up a desk for me in each location, so that whenever I fly over (for a sprint change or at other times), I always feel welcome and can settle in right away. This empty desk can also be seen as symbolic for those who aren‘t physically in the same room. Now, if the budget were truly large enough, I certainly wouldn‘t hesitate to buy a proper conference system, where people can be seen and understood well and tasks on Post-Its can be zoomed in on. Of course, this leads us to the next step of putting up a huge screen (the bigger, the better) that always shows the image of the webcam(s) in the other location(s). If I could also choose the Scrum Space itself, I would make sure that we have a large enough room to stand in front of the conference system and screen as a Team as well as to manoeuvre around a flipchart or a desk.
 
Christof B.: I would take this money-spending a step further and actually put up two screens in the Scrum Spaces. One for showing the other Team members at all times and another for permanently depicting the Taskboard. These screens would have to be turned on every day all day … after a while, it would just become a habit that the first person to arrive in the office turns them on along with the conference system. I find it a great idea to actually put up a static webcam that permanently shows the other Scrum Space(s). That way, the Team can really feel connected as it provides the feeling of working in adjacent offices. Sadly, these gigantic screens together with an expensive conference system are often not an option, as – in reality – budgets are limited and tightly supervised. However, Skype sessions (which are free) or comparable programmes could always be kept on, too – thereby conveying a similar feeling of „togetherness“. The sound of the others being there and the possibility of talking on the phone or chatting to each other in any location at any time conveys the same idea.
 
Stephanie G.: I like the idea of the screens, but wouldn‘t the noise of constantly leaving the telephone conference on loud speakers become slightly irritating? 
 
Kristina K.: Not necessarily. I think it‘s a great idea, as I would have loved to leave on the telephone system at all times. However, I would try to get a separate, adjacent room next to all Scrum Spaces, which can be used for meetings or pair programming. The room would simply ensure that no Team member feels bothered. Also, I love Bernd‘s idea of the additional desks. I would at least expect one more desk in every location, as the Product Owner of an internationally distributed Team should be a frequent traveller. This way, he can come and go whenever he wishes and there‘s no additional effort.
 
Hélène V.: And always make sure to involve the rest of the Scrum Team in your ideas and plans. Perhaps they are completely against leaving the telephone on, so then another option would be to have a speed dial installed in the conference system, with allows the reaching of the other Team members upon pressing one button. Generally, the numbers of the individual Team members as well as the conference systems in the other Scrum Spaces should be found on the wall. I also like Bernd’s idea of putting up photos of the other Team members. And, of course, one large photo of the entire Team together.
 
Ina K.: I agree with everything that my colleagues have said so far. However, let‘s not forget one important element of establishing and maintaining a Team spirit: it is vital that everything found in one Scrum Space, must be available the other Scrum Spaces, too. This starts with the flipcharts (they simply need to be photographed, sent over, printed off on large paper and hung up on the wall), continues with the technology (no way should the HQ get a better conference system than the other locations) and ends with the type of furniture. The first element does not need much of a budget, but requires an attentive ScrumMaster. Don‘t let things slide – ask your Team members to send you a photo of their Scrum Space from time to time. If you notice that something on the walls is old, just throw it out. After all, that‘s what ScrumMasters expect of their Team: if a functionality makes no sense, kill it. This is the same for posters – but make sure to do this for all locations. And a little piece of advice for all ScrumMasters who don‘t get the same budget for all of the locations: if we‘re talking about something like headsets or webcams, just buy them and post them over. It usually doesn‘t cost much, but does wonders for the Team.
 
Stephanie G.: Oh, how I wish that internationally distributed Scrum-Teams would be provided with larger budgets – it would make such an enormous difference. In a nutshell, this would allow ideal Scrum Spaces to be equipped in the following way:

  • high-quality conference system (telephone, webcam) – preferably on during all office hours
  • additional desk(s) for absent Team members
  • two huge screens (Taskboard/ desktop sharing and non-stop screening of the other Scrum Spaces)
  • separate, additional room next door
  • equipped with the same items/ technology/ equipment etc. (mirroring each other)
  • pictures on the walls of the other Team members as well as a Team photo

Thank you for your input! I think this will provide all ScrumMasters out there with really good ideas.

S.O.S! Was tun, wenn Teammitglieder keine Tasks schreiben wollen? (Teil