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 🙂