Möchtet ihr ausprobieren, ob agiles Arbeiten mit Scrum für euch funktioniert? Doch wie soll das im Tagesgeschäft funktionieren? Hier steht nicht die Agile Transformation im Vordergrund, sondern die Erledigung von Aufgaben aus dem Tagesgeschäft. Für ein Projekt sind Mitarbeiter dann häufig nur mit 20% Kapazität zugeteilt. Das bedeutet, dass mindestens 80% der Arbeitszeit an anderen Aufgaben gearbeitet wird. Fokus und Transparenz sind hier kaum zu finden. Mit einer solchen Aufgabe hat man mich als Agile Coach betraut.

Kann Scrum in solch einer Situation funktionieren?

Die mir anvertrauten Mitarbeiter waren zu 20% für die Entwicklung von Maßnahmen zur Weiterführung des Betriebs von Bankschließfächern in Filialen mit nur zwei Kundenbetreuern zuständig. Die Herausforderung besteht darin, dass, wenn ein Kunde zu seinem Schließfach begleitet wird, der andere Bankmitarbeiter alleine in der Filiale ist. Dies ist, was die Sicherheit angeht, kritisch. Es sind daher strikte Regelungen zu beachten. Organisatorische und technische Maßnahmen mussten erarbeitet und umgesetzt werden. Das Knowhow zur Bewältigung der Aufgabe war auf wenige Experten verteilt, die zudem deutschlandweit verteilt waren.

Die Problemstellung und Herausforderung

Die Personen arbeiteten nun schon seit einiger Zeit an der Aufgabenstellung, jedoch ohne nennenswerte Ergebnisse. Es gab kein Vorankommen. Bei näherer Betrachtung hat sich herausgestellt, dass die Experten, die gemeinsam mit jeweils 20% an dem Thema arbeiten sollten, an unterschiedlichen Tagen, Zeiten und an unterschiedlichen Orten im Projekt arbeiteten. Zeitnahe Abstimmungen und eine gute Zusammenarbeit im Team waren dadurch kaum möglich. Die Aufgaben aus dem Tagesgeschäft haben jegliche Planung und Koordination zerstört. Die Motivation war entsprechend schlecht und der Druck auf die beteiligten Personen wurde immer größer.

Mein radikaler Ansatz mit sechs 1-Tages-Sprints

Jedem sollte klar sein, dass die Einführung eines klassischen zwei Wochen Sprints in diesem Setup nicht weitergeholfen hätte. Meine Idee war es vielmehr, das Team radikal zu fokussieren. Wenn schon jeder nur 20% an dem Thema arbeiten durfte, dann doch bitteschön zur selben Zeit und am selben Ort. Nach einem Scrum Intro Workshop mit anschließendem Backlog Refinement konnte das Abenteuer beginnen. Geplant waren sechs 1-Tages-Sprints. Jede Woche am Donnerstag wurde fortan gemeinsam co-located gesprintet. Zusätzlich gab es dienstags eine 30-minütige Telefonkonferenz für das Backlog Refinement.

Die Ergebnisse nach dem ersten Sprint

Dieses Setup hat tatsächlich funktioniert! Am Ende des ersten Sprints (also nach nur einem Tag!) wurden Ergebnisse vorgestellt, die in den 2 Monaten zuvor nicht erzielt werden konnten. Entsprechend gab es beim Review vom Management viel positives Feedback. Das neu geformte Scrum Team war aufgrund des Ergebnisses außerordentlich motiviert. Die neue Art der Zusammenarbeit machte den Mitarbeitern ersichtlich mehr Spaß.

Hier seht ihr die Meeting-Kaskade des 1-Tages-Sprints:

1-Tages-Sprint Planung

Welche Erfolgsfaktoren kann man also nach sechs Sprints erwarten?

Nach den sechs Sprints wurde eine abschließende Retrospektive durchgeführt. Dabei haben die Teammitglieder folgende Erfolgsfaktoren genannt:

  • Co-Location am Sprint-Tag
  • Schaltung einer Abwesenheitsmeldung in Outlook für Anfragen aus dem Tagesgeschäft
  • Ausschalten der Telefone
  • Gemütlicher „War Room“ mit geeigneter technischer Infrastruktur für alle Teammitglieder
  • Snacks und Getränke (jeder brachte etwas mit zum Teilen)
  • Backlog Refinement Telko mit Screen Sharing mindestens zwei Tage vor dem Sprint, um zu priorisieren und sich auf den SCRUM Tag vorzubereiten. Dies ermöglichte es bei Bedarf für den Sprint-Tag zusätzliche Experten einzuladen oder identifizierte Abhängigkeiten zu managen
  • Teilnahme des Kunden bzw. des Managements am Sprint Review Meeting für direktes Feedback
  • Ein SCRUM Master, der striktes Timeboxing durchsetzte, gut vorbereitet war und gut moderierte
  • Mut, Entscheidungen direkt im Team zu treffen oder mit Annahmen zu Arbeiten. Ihr könnt euch sicherlich gut vorstellen, dass Entscheidungsvorlagen und -prozesse den Rahmen des 1-Tages-Sprint sofort gesprengt hätten. Im Umkehrschuss herrschte Vertrauen und Respekt des Managements gegenüber dem SCRUM Team und Offenheit für die Ergebnisse der Sprints.
  • Und nicht zuletzt die freiwillige Teilnahme der Teammitglieder. Fragt die Kollegen, ob sie mitmachen möchten. Habt keine Angst davor, dass keiner kommt.

Lässt sich dieses Konzept erweitern?

Die Idee des hier geschilderten 1-Tages-Sprint lässt sich wunderbar erweitern. Mit einem anderen Team habe ich einen 2-Tages-Sprint durchgeführt. Diesmal mit einem Team, das Reportings zur Unternehmenssteuerung implementiert hat. Dieses Experiment war in Bezug auf das Ergebnis und die Motivation ebenfalls ein Erfolg.

Probiert dieses agile Experiment aus! Danach könnt ihr mit dem Team und Management über die tatsächlich erlebten Erfahrungen sprechen und Euch darauf aufbauend ganz im agilen Sinne weiterentwickeln. Doing as another Way of Thinking!

Auch Ihr habt nun Interesse an einem 1-Tages-Sprint?

Schreibt mir gerne unter m.enden@proventa.de

Blog Martin Enden

Martin Enden

Martin Enden arbeitet seit 2005 in anspruchsvollen international besetzten digitalen Transformationsprojekten. Dabei hat er als Vermittler zwischen „Fach- und IT-Bereichen“ cross-funktionales Arbeiten immer schon vorangetrieben. Seit 2013 ist er als Agile Coach tätig und hat bereits über 40 agile Teams aufgesetzt und begleitet. Für Martin Enden ist Agilität die Antwort der Unternehmenskultur auf den digitalen Wandel. Er ist zertifiziert in klassischen und agilen Projekt Management Methoden und versteht dadurch Ausgangslage und Zielbild von agilen Transformationen. Durch die Schwerpunkte Wirtschaftsinformatik und Marketing im Rahmen seines BWL Studiums versteht Martin Enden sowohl IT-Prozesse als auch Kundenbedürfnisse. Martin Enden vermittelt zwischen gegensätzlichen Standpunkten und führt Teams und Organisationen in turbulenten Projektsituationen durch den Change Prozess.