Sie haben ein Problem? Der Scrum Master wird’s schon richten: dafür ist er ja da. Der „dienende Anführer“ soll sicherstellen, dass das Team im Verlauf des Sprints offenkundige Hindernisse und Probleme (gemeinhin Impediments genannt) so schnell wie möglich beseitigen kann. Dafür benötigt er ein Selbstverständnis, Coaching Grundlagen, agiles Prozess Know-how, ein Impediments Log und natürlich einen Stock.

Warum der Scrum Master einen Stock braucht

Mit dem Stock prügelt der Scrum Master sein Scrum Team bis ins Sprint Ziel. Möchte sich das Team dafür revanchieren, knallt es dem Scrum Master einfach das Impediments Backlog voll. Das mit dem Stock hat der Scrum Master natürlich aus dem Buddhismus. Dort werden Zen Mönche die während des Zazens einschlafen mit dem Stock an die Aufgabe erinnert Erleuchtung und inneren Frieden zu finden. Soll ja klappen …

Chefchen sein is nich

Neben der-Mönch-mit-dem Stock-sein hat der Scrum Master vier Rollen, die er ausfüllen muss. Wer jetzt wegen Shades of Earl Grey und dem Master hofft das „Dominatrix“ zu diesen Rollen gehört, den muss ich leider enttäuschen. Die Scrum Master Rolle lässt viele Freiheiten zu, aber die Rolle des klassischen Team- oder Abteilungsleiters gehört leider nicht dazu.

Der Coach

Jedes Team und jedes Teammitglied und auch der PO und sogar Stakeholder haben immer wieder Probleme agil zu handeln. Agilität ist nicht schwer, aber tricky und die Macht der Gewohnheit lässt viele immer wieder in ein klassisches Mindset zurückfallen. Als Coach findet der Scrum Master für jedes Problem mit dem agilen Prozess eine individuelle Lösung, manchmal sogar zusammen mit dem Teammitglied.

Der Coach Teil 2

Daneben soll der Scrum Master auch den Teambildungsprozess steuern, der aus Einzelkämpfern ein Scrum Team macht. Das nennt man auch Peoples Management. Die Impediments aus dieser speziellen Rollenaufgabe gehören aber nicht ins Backlog oder ins Impediment Log. Warum nicht? Ganz einfach: persönliche Entwicklung oder Probleme haben nichts darin zu suchen.

Zwischen Stasi und NSA

Das Impediments Log ist öffentlich. Normalerweise sollten alle Mitarbeiter aus allen Abteilung darauf Zugriff haben, so dass Probleme und Lösungen frei zirkulieren können. Das umfasst natürlich auch Vorgesetzte und die Firmenleitung. Tauchen jetzt persönliche Entwicklungsziele im Log auf, wird das eventuell auch für eine Leistungsbeurteilung verwendet. Das ist sogar ziemlich sicher. Die Folge: die Teammitglieder hüten sich solche Probleme überhaupt anzusprechen oder einzugestehen. Es ist schwer sich in einer solchen Umgebung den konstruktiven Umgang mit dem eigenen Potenzial vorzustellen. Aus diesem Grund sind für das Impediments Log Know-how und Wissenslücken tabu.

Versteckte Baumstämme

Viele Projektteams haben eine natürliche Scheu ihre Probleme nach draußen zu tragen. Zum Beispiel macht der DFB und die FIFA das schon seit Jahren so. Leider ist ein privates Impediments Log genauso eine doofe Idee wie ein geheimer Sprint oder ein virtuelles Backlog. Der gute Scrum Master weiß, das Problem immer Rudeltiere sind. Hat ein Team ein Problem, haben wahrscheinlich noch andere Teams dasselbe Problem. Wenn nicht jetzt, dann später. Weiß aber keiner davon, dann muss jeder das Rad teuer neu erfinden, und es gibt keinen Metalerneffekt für das Unternehmen.

Herrschaftswissen

Die Scrum Master könnten als Zirkel der Wissenden die Impediments Logs ja auch nur unter sich teilen? Wie jeder gute Wissenspool, in dem zwar alle einzahlen, aber nur ein paar abheben dürfen, trägt das ein hohes Risiko von Ressentiments in sich. Die Folge: Teammitglieder werden vehement darauf bestehen, dass dieses und jenes Problem auf keinen Fall im Impediments Log landet. Wer weiß schon, wer’s alles zu sehen bekommt! Stellen Sie sich doch einfach mal die Frage: wieso dürfen Sie alles wissen was die anderen vorhaben und was sie gerade machen, aber nicht wie sie mit ihren Problemen umgehen?

Wasch mich, aber mach mich nicht nass

Wenn das persönliche Ego (von wem auch immer) mit Problemen so seine Probleme hat, dann machen Sie – um Ärger aus dem Weg zu gehen – eben ein zweigeteiltes Impediments Log. Der öffentliche Teil beinhaltet dann die gelösten Probleme, der private Teil dann die noch offenen Probleme. Das Team ist zwar gerade dann zum Einzelkämpfertum verdammt, wenn es darauf ankommt, aber die wertvollen Egos bleiben unversehrt. Gerade in der ersten Übergangsphase der agilen Transformation, wo noch nicht klar ist, ob ein Impediment nicht doch ein Eingeständnis von Schwäche ist, sind solche Vorgehensweisen durchaus nervenschonend und verhindern endlose Diskussionen. Vergessen Sie nur nicht, den Kram irgendwann wieder öffentlich zu machen. Spätestens, wenn Sie Scrum skalieren wollen und bei Scrum of Scrums angelangt sind, klappt es ohne Transparenz eh nicht mehr.

Auf nach Jerusalem

Neben der Rolle als Coach ist der Scrum Master auch der Prozess-Heilige oder der Kreuzritter der Agilität. Er achtet auf die Einhaltung der agilen Abläufe und Tools und versucht das agile Mindset bei seinem Team im täglichen Alltag zu stärken. Typisch ist hier der Kampf Stories vs. Dokumentation von Spezifikationen. Daneben sind es viele kleine Nachlässigkeiten im Team die immer wieder nachkorrigiert werden müssen. Keine Zeiten in den Tickets vor dem Daily Standup zu pflegen oder nicht die oberste Story aus dem Sprint Backlog zu nehmen zermürben mit der Zeit auch den besten Bürokraten. Tritt in einem Sprint so etwas öfter als zweimal auf, empfehle ich das als Impediment aufzunehmen und eine Art digitale Strichliste damit zu führen – auch hier kommen meine geliebten Klebepunkte gerne zum Einsatz. Das Thema kann dann in der Retrospektive bei ausreichendem Interesse thematisiert werden. Viele Teams ändern lieber ihr Verhalten als sich fünfmal hintereinander anzuhören, wie wichtig die tägliche Zeiterfassung in den Tickets für das Burndown ist. Stetige Exception höhlt das Logfile …

Troubleshooter shooten Troubles

Die dritte Rolle hat endlich einen fühlbaren Nutzen für das Team: der Scrum Master schafft Impediments aus der Welt. Damit er das überhaupt machen kann, braucht er mehrere kommunikative Werkzeuge. Das erste ist seine Frage Technik: damit entdeckt er Probleme, und vor allem auch Ursache hinter den Problemen. Klassische ist hier die fünf Whys Technik. Für größere Problemkomplexe lohnt sich auch das Problem nicht einmalig zu lösen, sondern auf den Continous Inprovment Process aufzustzen.

Of by One

Versuchen Sie an dieser Stelle technische Probleme möglichst weder zu verstehen, noch sie überhaupt ins Impediments Log aufzunehmen. Viele werden jetzt aufschreien und im Brustton der Überzeugung das Kompetenz-Mantra runterbeten. Selbstredend, das der Scrum Master ja wohl ein Haufen Fachkompetenz braucht! Der beste von Allen muss er sein! Interessante Meinung. Was glauben Sie, wie viel in einem Projekt tatsächlich richtige Fachprobleme sind, so in Prozent? Nein, falsch. Es sind ca. 5%, d.h. jedes zwanzigste Problem. Ist Statistik nicht etwas Wunderbares? Ich denke, jeder Scrum Master schafft es für jedes zwanzigste Problem jemanden zu finden der ein größerer Experte als er selber in diesem Thema ist. Oder eine Arbeitsgruppe dafür zu organsieren. Einen Spike, externe Hilfe, was auch immer.

Inkompetent, aber nützlich

Ich kann diesen Punkt nicht genug hervorheben. Wenn Sie ein Experte in der Fachdomäne, dem Stack oder der Entwicklungssprache sind, dann werden Sie Probleme zu oft durch die entsprechenden Brille sehen und wie auf Knopfdruck darauf reagieren. Ich verzichte an dieser Stelle auf den nur-ein-Hammer-alles-Nägel Quatsch. Ihr Ziel und das Ziel des Impediment Log ist nicht, das jedes technische Problem gelöst wird, sondern das ihr Team in den hyperproduktiven Flowzustand kommt und das Sprintziel mit Links schafft. Lehen Sie das Lösen solche Probleme kategorisch ab. Sie arbeiten nicht im Team, sondern für das Team. Fachprobleme sind aber Teamsache, auch und gerade die komplizierten. Die Entwickler sind gut in der Lage ihre technischen Probleme in angemessener Zeit selber zu lösen, und sie lernen an diesen Problemen am meisten. Häufig ist es mehr die Verzweiflung, das ein Ticketaufwand gerade explodiert, der zum Hilfschrei führt. Das Tickets größer werden ist kein Problem, sondern eine Erkenntnis. Erkenntnisgewinn ist gut, weil wir etwas daraus lernen. Zum Beispiel warum wir so beschissen abgeschätzt haben und was wir beim nächstne Schätzen anders tun werden.

Technische Probleme, die 1002te

Die Frage ist eigentlich immer wieder dieselbe: Frage nicht, wie Du für das technische Problem tun kannst, sondern Frage, was das Problem für dich tun kann. Oder einfacher: wo es herkommt. Die sogenannten Rootcause Analyse zielt genau auf diesen Punkt und versucht keine Symptome zu beheben, sondern die Ursachen aufzudecken. Versuchen Sie bei technischen Problemen immer genau das. Oder raten Sie einfach.

Delphi

Als erfahrener Scrum Master sehen Sie viel zu oft schon frühzeitig Problemsymptome. Spielen Sie in diesem Fall nicht die Rolle des Orakels. Der Lernprozess bei ihrem Team kann nur dann einsetzen, wenn sie das Problem auch als tatsächliches Problem wahrnehmen. Natürlich gibt es für diese Regel eine Ausnahme: wenn sie merken, dass das Team erschöpft und durch ist, handeln Sie proaktiver. Niemand lernt, wenn er supergestresst ist. Dasselbe gilt für eine gewisse Kategorie von Problemen: stellen sie sich vor, Sie wären Vater. Natürlich können Sie Ihren Jungen auf die harte Tour lernen lassen, dass die Kreissäge prima Fleisch schneidet. Würde ich aber so nicht vorschlagen. Diese Art von Kategorie meine ich, oder anders ausgedrückt: wenn der Projekterfolg, der Sprint, oder die emotionale Unversehrtheit eines Teammitglieds auf der Kippe steht handeln Sie proaktiv und pronto. Sonst nicht. Nehmen Sie diese Probleme, die sie vorher lösen ebenfalls ins Impediment Log auf und thematisieren Sie diese Probleme explizit in der Retrospektive.

Lottototo Rennquintett

Es soll sogar Scrum Master geben die ein geheimes Delphi Orakel Log führen, das sie dann in der Retrospektive offen legen. Je nach erreichten Punktestand gibt dann entweder der Scrum Master ein aus oder das Team. Da ich selber einen perfekten Superriecher habe, freue ich mich über das eine Bier im Jahr meistens wie ein Schneekönig. Sehen Sie es als Investitionen in die Teambildung, lustig ist es auf jeden Fall. Lehrreich auch, wenn Sie beim Bier über das Warum-genau-das-Problem reden.

Hausmeister und Putzfrauen

Das Tolle an dem ganzen agilen Gedöns ist, dass es eigentlich für alles entsprechende Tools gibt. Muss irgendwie dran liegen, dass das nicht von Architekten erfunden worden ist, sondern von Softwareentwicklern. Wenn Sie bemerken, dass Sie für zehn Leute das Telefon entgegennehmen, die Arbeitzeiten nachtragen, Burndown-Charts ausdrucken und die Urlaubskalender pflegen dann sind Sie in eine typische Falle eingetreten. Ihre Aufgabe als Scrum Master ist es, das Impediments Log leer zu halten und nicht die Teamassistenz überflüssig zu machen. Es gibt genug Leute in einer Firma, die sich um allen möglichen Kram kümmern können, aber nur Sie können sich darum kümmern das das Impediments Log nicht voll läuft. Tun Sie Ihren Job und delegieren Sie den Rest. Wenn Sie können möglichst nicht zurück ans Team, aber viele Aufgaben sind einfach schlicht und ergreifend Bequemlichkeit.

Die leere Hand

Nehmen wir mal an, Sie haben ihre Rollen alle gut ausgefüllt und Sie haben Impediments in ihrem Log. Herzlichen Glückwunsch! Wenn das jetzt kein trivialer Scheiß ist, müssen wir einen Weg finden wie Sie damit umgehen. Da Impediments ihr Team aufhalten, ist es wichtig dass sie zum einen schnell, zum anderen nachhaltig, und zum Dritten ohne verbrannte Erde gelöst werden. Oft erlebe ich, das Impediments einfach nur in eine Excelliste reingeklatscht werden. Das ist lustig. Wussten Sie das man mit Ticketsysteme Aufgaben steuern kann? Ein spannendes Konzept, nicht?

Impediments mangels Testplan abgewiesen

Wenn Sie Impediments als Tickets anlegen möchten, tun Sie das als eigenen Typ. Mit einem eigenen Typ können Sie den meisten Systemen auch gleichzeitig einen neuen Workflow mitgeben. Sie möchten doch nicht, dass die QA ihre Impediments Tickets mit dem trockenen Hinweis das Testdaten fehlen bounced. Der Vorteil von Tickets ist, das Sie, wenn Sie das möchten, die Story Points für dieses Ticket auf den Sprint drauf rechnen können. Das Schöne dabei ist: die Velocity wird beim Auftreten von Hammer-Impediments positiv beeinflusst, wenn Sie Ihren Job gut machen. Die Velocity zeigt damit die Fähigkeit des Teams seine Probleme aus der Welt zu schaffen. Bei Schönwetter kann jedes Team auf der Erfolgswelle surfen. Wenn Sie Impediments auch Story Points zuordnen, bleibt zumindest ihre Costbase sauber, wenn der Sprint aufgrund dieser Impediments scheitert. Wenn sich herausstellt, dass die explodierenden Story Points unmöglich vom Team zu leisten gewesen wären, rettet das immerhin die Teammoral, und die ist ein nicht gerade einfach wiederherzustellender Erfolgsfaktor. Machen Sie das nicht, dann sieht es einfach so aus als ob das Commitment des Teams aus der Luft gegriffen war.

Alternative Heilmedizin

Alternativ führen Sie ein eigenes Kanban Board mit den Impediments. Die Tools dafür haben sie. Das Verfahren kennen Sie und die Sache bleibt transparent ohne den eigentlichen Sprint zu verwässern. POs sind davon ganz angetan. Weniger Filternotwendigkeit im Backlog, findet der PO immer gut. Kanban bietet hier die Möglichkeit auch den Durchsatz mit dem Sie Probleme lösen im Vergleich zu anderen Scrum Master oder in anderen Projekten zu messen. Aufgrund dieser Zahlen können Sie beginnen zu analysieren, warum es so schwierig ist gewisse Probleme zu lösen. Ein typischer Fall ist das die Vorgaben für Projekte mit niedriger Priorität genauso hoch sind, wie für Projekte mit hoher Priorität. Das führt zu einer geringeren Bereitschaft auftretende Probleme in den niedrig priorisierte direkt zu lösen und zu einer intransparenten Verschleppung der Impediments. Hardfacts sind an dieser Stelle wesentlich besser geeignet, um solche Probleme aufzuzeigen und damit in den Lösungsbereich zu kommen, als blödes rumlamentieren dass der Horst immer mehr Ressourcen und alles Mögliche bekommt als jeder andere in der Firma.

Unbewegliches Objekt trifft auf unwiderstehliche Kraft

Jetzt ist es ihnen doch passiert. Das Impediments lässt sich nicht einfach vom Tisch reden, es weitet sich sogar vielleicht noch aus oder zeigt zumindest eine gewisse Beharrlichkeit jedem Lösungsversuch gegenüber. Das Sprint Ende ist nahe. Das Impediments blockiert den Sprint Erfolg. Was jetzt, Master Desaster? Diesen Zahn muss ich Ihnen leider direkt ziehen. Agil macht Probleme transparent, führt einen kontinuierlichen Verbesserungsprozess ein, und kann leider nicht das Heilversprechen der unberührten Lösungsempfängnis einlösen. Wenn Sie sauber mit Rootcause Analysen arbeiten und Problem hartnäckig auf den Grund gehen, laufen Ihre Projekte immer noch um Welten besser, als alle klassischen Projekte bei denen die Probleme zwar ebenfalls bekannt sind, aber durch die mangelnde Transparenz und fehlende handgreifliche Schriftform niemals richtig wahrgenommen werden.

Schulden sind Investitionen

Technische Schulden sind Kram den sie eigentlich hätten machen müssen in diesem Sprint, für den es aber leider nicht gereicht hat, Tut uns aufrichtig Leid, wirklich. Technische Schulden verhindern nicht die Abnahme eines Features im Review durch den PO, aber fallen ihnen spätestens in zwei oder drei Sprints volle Möhre vor die Füße. Wenn Ihnen jetzt dabei Worte wie U-Boot, refactoring, oder code smell einfallen, dann wissen Sie schon was ich meine. Hacks und Workarounds gehören übrigens ebenfalls dazu. Machen Sie sich nichts draus: das Erreichen der Sprintvision ist eine tolle Sache. Manchmal muss man dafür Zugeständnisse machen. Schreiben Sie diese Zugeständnisse aber bitte auf.

Mit Ihrem eigenen Blut unterschrieben

Damit Sie am Ende den Sprint auch ordnungsgemäß schließen können, schieben Sie diese technische Schulden über das Impediments Log und die Retro wieder ins Backlog. Buchhaltertricks, ja. „Vergessen“ Sie nicht beim nächsten Sprint diese Tickets an die Spitze des Backlog zu schieben. Das ist eine der zwei Gründe, warum Sie den PO mit einem Veto überstimmen dürfen. Denken Sie daran: das Begleichen von Schulden ist Ehrensache. Wenn Sie Murphy gut kennen, wissen Sie auch das er technische Schulden immer dann eintreibt, wenn Sie es wirklich noch weniger als Sie es sich im Moment überhaupt vorstellen können, gebrauchen können. Das ist keine hohle Warnung. Und Ehrenschulden sind es, weil sonst jeder im Team quasi jeden Scheiss über Pfuschen noch hinbekommen kann. Diese Arbeitsweise unterhöhlt das Involvement der Entwickler, und demoralisiert nachhaltig.

Für den Weltfrieden

Einige unlösbare Probleme im Impediments Log sind übrigens dadurch gekennzeichnet, dass sie selbst beim besten Willen nicht innerhalb der verbleibenden Sprintzeit gelöst werden können. Versuchen Sie immer die Frage nach dem Scope zu stellen: sehen wir eine realistische Chance dieses Impediment innerhalb des Sprints zu lösen? Wenn ja, nehmen Sie es auf. Wenn nein, nehmen Sie es auch auf, aber in einer getrennten „Weltfrieden Liste“. Diese Liste können Sie, wenn Sie das nächste Mal in einer Retrospektive nicht viel zu tun haben rausholen und gemeinsam mit dem Team überlegen, wie Sie solchen global-galaktischen Probleme vielleicht in Zukunft besser angehen können. Eignet sich auch hervorragend als Vorlage für Feedbacktermine mit Chefs oder Stakeholdern, galant auf den Tisch gelegt mit dem Worten „Ich habe da mal was vorbereitet, genau die Art von hochkarätigen Problemen die nur das Top-Management …“.

Die Cloud für Scrum Master

Nicht alle Projekte sind gleich und so sieht es auch mit dem Füllgrad der Impediment Logs aus. Während in einigen Projekten der Scrum Master nicht hinterher kommt, läuft in anderen Projekten erfreulicherweise alles glatt. Dazu kommt: der Scrum Master ist immer ein single point of failure. Alle anderen Teammitglieder sind crossfunktional aufgestellt und sollten im optimalen Fall sich gegenseitig ersetzen können. Beim Scrum Master ist das im Allgemeinen nicht so. Ist der Scrum Master krank, überlastet oder einfach nicht verfügbar dann läuft alles schief. Viele Probleme im Projekt lassen sich aber auch von anderen Scrum Master, die etwas mehr Zeit mitbringen, lösen. Arbeiten Sie deshalb mit einer Cloud von Scrum Master und einem gemeinsamen Kanban Board. Je besser die Beschreibung der Impediments und je allgemeiner das Problem desto eher wird ein anderer Scrum Master mit etwas mehr Zeit das Ticket ziehen können. Denken Sie aber dran: selbst wenn ein anderer Scrum Master das Problem von ihnen übernimmt und Sie es somit delegiert haben, bleibt es weiterhin Ihr Problem. Es gibt zwar bei agilen Projekten keine Codeownership mehr, aber trotzdem bleiben Aufgaben die einmal eine Person zugeordnet sind bei dieser Person bis sie gelöst sind. Es hat in erster Linie mit der Verantwortlichkeit zu tun, die lässt sich nämlich nicht delegieren.

Honigtöpfe und Bauernopfer

Es gibt eine Einrichtung in manchen Firmen, die nennt sich Impediment Ampel. Dort wird je nach Alter und Größe der Impediments eine Ampel aufgestellt die mit Ihren Farben den Gesundheitsstand des Sprints und meistens auch des Projektes anzeigt. Ampelfarben, Mensch, woher kommt das denn? Natürlich aus dem klassischen Projektmanagement – die Ampelfarben kennen wir dort alle. Wenn das agile Team sich nämlich „weigert“ ein klassischen Statusbericht abzuliefern, wie es der normale Manager so gerne hätte, mit kritischen Punkten, Entscheidungsbedarf und Projektfortschritt dann muss ebenso zumindest eine Ampel her. Verfallen Sie bitte nicht auf den Irrtum und machen es sich einfach und schreiben sich klassische Projektberichte für das Status Reporting und packen sie unter Entscheidungsbedarf einfach die Impediments. Sie berauben sich als Scrum Master damit der Entscheidungshoheit und damit ihres Handlungsspielraums. Außerdem wirken Sie für das Team damit wie eine olle Petze und gefährden so das agile Mindset von allen.

tl;dr

• Führen Sie ein öffentliches Impediment Log.
• Nutzen Sie Tickets anstelle von Excellisten.
• Hören Sie in jeder Rolle mit dem entsprechenden Ohr auf Probleme.
• Nehmen Sie immer eine Rootcause Analyse vor.
• Eins von 20 Problem ist technisch, falls nicht, machen Sie etwas falsch.
• Keine persönlichens Skill Impediments anlegen.
• Nutzen Sie die Cloud of Scrum Master.
• Technische Schulden sind ok.
• Begleichen Sie Ehrenschulden umgehend.
• Ampeln sind Todesfallen für Agilität.