Agility@Office – Was ist Scrum?

Was steckt genau hinter diesem Wort und vor allem hinter der Methode?

Spannenderweise kennen viele die Herkunft des Begriffs Scrum nicht. Auf der einen Seite ist Scrum eine englische Bezeichnung für Gedränge oder Menschenauflauf. Auf der anderen Seite ist es ein Spielzug im Rugby. Scrum wurde am Anfang für IT-Projekte als Methode angewendet. Statt ein Projekt am Anfang komplett durchzuplanen und dann die Planungen umzusetzen, werden unter Beteiligung des Scrum-Teams einzelne Aufgaben ausgewählt, die dann abgearbeitet werden. So kann schneller auf Veränderungen im Markt oder beim Kunden reagiert werden. Missverständnisse werden schneller klar und kosten weniger Zeit oder Geld beim Beheben. Im Unterschied zum klassischen Projektmanagement ist Scrum ein Framework, das Leitplanken und Orientierungspunkte bietet. Aus diesen werden für das jeweilige Projekt die passenden Ansätze ausgewählt. Der Freiheitsgrad und damit die Notwendigkeit zur Selbstorganisation sind damit wesentlich höher als in klassisch durchgeführten Projekten.

Welche Rollen gibt es im Scrum neben dem Scrum-Master?

Der Scrum-Master gehört zu den wichtigen Rollen im Scrum-Ansatz. Diese Rolle darf nicht mit der Projektleitung verwechselt werden. Ein Scrum-Master ist so etwas wie ein Coach für den Product Owner und das Scrum-Team. Neben der Kenntnis von Scrum ist für den Scrum-Master die Haltung ausschlaggebend. Dazu gehört sich nicht inhaltlich einzumischen und dem Scrum-Team die Verantwortung zu überlassen. Die Aufgaben eines Scrum-Masters sind:

• Arbeitsweise und Vereinbarungen bzw. das ausgewählte Framework kennen
• Dafür sorgen, dass alle diese Regeln kennen
• Dafür sorgen, dass sich alle an diese Regeln halten
• Dafür sorgen, dass bei Unkenntnis, eine Weiterbildung ermöglicht wird
• Dafür sorgen, dass die täglichen Meetings des ScrumTeams (Daily Scrum) stattfinden
• Darauf achten, dass das Timeboxing bei den Meetings eingehalten wird (pünktlicher Anfang und pünktliches Ende z. B. mit einer Küchenuhr, die nach Ablauf der Zeit klingelt)
• Darum kümmern, dass die vom ScrumTeam genannten Hindernisse beseitigt werden (Kümmern meint nicht, alles selbst erledigen)
• Das ScrumTeam vor ungewollten Einflüssen von aussen schützen
• Sich um den Informationsfluss im ScrumProzess kümmern.

Alle diese Anforderungen erinnern mich sehr an die Rolle der Assistenz!

Eine weitere Rolle ist derProduct Owner. Dieser hat die wichtige Aufgabe, die Interessen des Unternehmens und der Anwender bzw. Kunden in Einklang zu bringen. Darüber hinaus verfolgt er wirtschaftliche Ziele, nämlich den Wert aus dem Produkt oder Projekt zu maximieren. Der Product Owner formuliert die Vision für das Projekt oder Produkt. Grundlagen dafür sind ein tiefgreifendes Verständnis der Kundenbedürfnisse und der strategischen Rahmenbedingungen aus Sicht des Unternehmens. Ein wesentliches Werkzeug für den Product Owner ist das Product Backlog (Speicher). Dort werden alle Themen zum Projekt / Produkt erfasst und priorisiert. Aus diesem Speicher heraus wird das Inkremente, ein Teilstück, für den Sprint ausgewählt. Oft geschieht das gemeinsam mit dem Scrum-Team. Mit dem Scrum-Team vereinbart der Product Owner das Ziel für den Sprint – im Sprint-Planning-Meeting. Ein Sprint ist der Zeitraum für die Bearbeitung des Ziels. Das Scrum-Team einigt sich auf die «Definition of ready», um zu beurteilen, ob die Aufgabe aus dem Product Backlog sprintfähig ist. Damit ist beispielsweise gemeint, dass die Aufgabe klar genug spezifiziert ist, um in einem Sprint daran arbeiten zu können. Die Vereinbarung zur «Definition of done» geschieht ebenfalls zwischen Product Owner und Scrum-Team. Hier werden die Kriterien für die erfolgreiche Erledigung festgelegt.

Zu den Aufgaben des Product Owners gehört noch die Beziehungspflege zu den Stakeholdern.

Die Arbeit geleistet wird vom Scrum-Team. Das darf nicht verwechselt werden mit einem klassischen Projektteam. Ein Scrum-Team organisiert sich selbst, entscheidet selbst und hat keine Projektleitung, die Vorgaben macht. Das kann auch zu einer Überforderung führen. Selbstorganisation muss daher gepaart sein mit Selbstfürsorge. Das Scrum-Team wählt gemeinsam mit dem Product Owner eine passende Aufgabe (Inkrement) aus dem Sprint Backlog aus und bearbeitet dieses in einem Sprint. Dieser hat immer die gleiche Länge, also zum Beispiel eine Woche. Länger als vier Wochen sollte ein Sprint nicht dauern. Während des Sprints trifft sich das Scrum-Team zum Daily Scrum mit dem Scrum-Master. Dieses Treffen sollte nicht länger als 15 Minuten dauern. Hier wird passend zum Ziel geschaut:

• Wer ist gerade mit was beschäftigt?
• Was ist erledigt seit gestern?
• Welche Hindernisse stören den Sprint?

Dabei wandern die festgehaltenen Teilaufgaben in einem Kanban von «geplant» über «in Bearbeitung» zu «erledigt». Wer im Scrum-Team was macht, welche Absprachen dafür nötig sind, etc. klärt das Scrum-Team untereinander und verantwortet diese Entscheidungen gemeinsam. Das ist einer der grossen Unterschiede zum klassischen Projektmanagement. Am Ende des Sprints stellt das Scrum-Team die erledigte Aufgabe im Sprint Review Meeting dem Product Owner und eventuell den Stakeholdern vor. Danach wird im Sprint Retrospektive Meeting geschaut, ob und wie die Zusammenarbeit optimiert werden kann.

Scrum ist schon lange nicht nur eine agile Methode für Start-ups. Warum gelingt es dort aber gefühlt einfacher als in gewachsenen Unternehmen?

Gewachsene Unternehmen haben oft langjährige Erfahrung mit klassischem Projektmanagement. Die Haltung der einzelnen Rollen unterscheidet sich sehr zum Scrum-Framework. Ein Scrum-Master mischt sich in die Arbeit des Scrum-Teams nicht ein, der Product Owner ebenso wenig. Die Selbstorganisation im Scrum-Team fordert viel von den Mitgliedern. Es gibt niemand, der Vorgaben macht – ausser der Definition of Done und dem Sprint-Ziel. Für den Weg dahin ist das Scrum-Team selbst verantwortlich. Entscheidungen werden gemeinsam getroffen und gemeinsam verantwortet. Das müssen gewachsene Unternehmen erst einmal lernen. Auch die Rolle des Scrum-Masters ist mit grossem Umdenken in gewachsenen Unternehmen verbunden. Sich inhaltlich rauszuhalten und der Selbstorganisation des Scrum-Teams zu vertrauen, braucht Zeit. Das ist für mich ein Grund, warum ich Assistenzen für sehr geeignet halte, Scrum-Master zu sein! Im Alltag der Assistenz ist diese Haltung schon lange geübt.

Wie kann man die Methode Scrum auf Assistenzen runterbrechen? Welche konkreten Anwendungsbeispiele haben Sie für uns?

Scrum zeichnet sich durch ein schrittweises und iteratives (in Schleifen) Vorgehen aus. Ich kenne aus meinem Trainings- oder Coaching-Alltag Assistenzen, die einen ungenauen Auftrag erhalten, diesen ohne Rückfragen abarbeiten und sich am Ende wundern, dass Chefs nicht mit dem Ergebnis zufrieden sind. Das Konzept der «Definition of ready» lässt sich zum Beispiel mit Checklisten gut umsetzen. Was müssen Chefs oder Kollegen an Input liefern, damit die Assistenz die Aufgabe erledigen kann? Solange die «Definition of ready» nicht erfüllt ist, wartet die Bearbeitung durch die Assistenz.

Auch das Prinzip des «Daily» lässt sich gut ausserhalb des Scrum-Frameworks anwenden. Schon lange gibt es die klassischen Rücksprachen zwischen Chef und Assistenz. Der Kanban-Ansatz (Backlog / in progress / done) ist eine gute Ergänzung der bisherigen Rücksprachen. Dafür lässt sich die Planner-App aus Office 365 gut nutzen.

Nach meiner Erfahrung ist die Arbeitsweise der Sprints ebenso im Alltag einer Assistenz gut anwendbar. Sich bei komplexeren Aufgaben wöchentlich zu treffen und über den Fortschritt zu auszutauschen, ist ein guter Ansatz. Von Woche zu Woche werden die Arbeitspakete geschnürt, die die Beteiligten dann erledigen.

Für die aktive Gestaltung der eigenen beruflichen Zukunft sollte sich die Assistenz mit der Rolle des Scrum-Masters auseinandersetzen. Es braucht nur noch das Scrum-Wissen, die notwendige Haltung bringt die Assistenz schon mit. Bringen Sie sich aktiv in Scrum-Projekte ein!

Agilität in Meetings – das hört sich nach einem grossen Feld für die Assistenz an. Was sind Ihre top Tipps für effiziente Meetings mit der Scrum Methode?

Das für mich wichtigste Prinzip ist Time Boxing. Meetings beginnen und enden pünktlich. Das bedeutet nicht, dass alle nach dem Meeting-Ende auseinander gehen müssen. Meist gibt es bilateral oder in kleinen Gruppen kurze Absprachen – aber eben nicht in der gesamten Runde.

Im Scrum gibt es unterschiedliche Arten von Meetings, die unterschiedliche grundlegende Ziele haben. In meinem Beratungsalltag finde ich meist Mischformen vor, wo etliche grundlegende Ziele in einem Meeting verfolgt werden. Ein Planungsmeeting von einer Retrospektive (Optimierung der Zusammenarbeit) zu trennen ist unabdingbar, wenn die Besprechungsteilnehmenden klar und fokussiert das grundlegende Ziel verfolgen sollen.

Als letztes gefällt mir ein Ansatz von Seth Godin gut: Er schlägt vor, regelmässige Meetings auf öffentlichen Tafeln bewerten zu lassen!

Welche anderen agilen Arbeitsmethoden gibt es und wo liegen Ihre Empfehlungen für Assistenzen?

Das Scrum Framework selbst ist schon ein grosser und gut gefüllter Baukasten für agile Arbeitsmethoden. Je nach Branche und Problem kann Design Thinking noch ein guter zweiter Baukasten sein.

Meine Empfehlung in dem sich sehr verändernden Feld der Assistenz ist, sich aktiv in agile Methoden einzubringen. Schauen Sie, was in Ihrem Unternehmen gerade eingeführt wird oder wurde. Lesen Sie sich ein, informieren Sie sich in einem Webinar oder einem Seminar dazu. Setzen Sie sich selbst auf die Teilnehmendenliste bei internen Seminaren zu agilen Methoden. Und dann bringen Sie Ihre Expertise als Assistenz in Projekten ein. Niemand sonst im Unternehmen hat so viel Einblick in Abläufe, Prozesse und Verfahrensweisen. Warten Sie nicht, bis Sie gefragt werden, sondern werden Sie selbst aktiv.