Agiles Arbeiten im Controlling

Prüfsiegel gültig bis 2025

Einleitung

Der nachfolgende Beitrag ist ein Bericht aus der Praxis, ohne Ansprüche an wissenschaftliche Vollständigkeit hinsichtlich der Methoden oder Prozesse. Er soll dazu dienen, Denkimpulse zu geben, wie man Agilität einem Team vermittelt und erfahrbar macht. Agilität bedeutet in diesem Zusammenhang nicht, einen lupenreinen Scrum-Prozeß im Unternehmen einzuführen, sondern den gesamten Prozeß oder Teile daraus so auf das Unternehmen oder speziell das Controllingteam anzupassen, dass der größtmögliche Nutzen für die Organisation entsteht. Dabei darf Agilität nicht vor einer effizienten Organisation stehen, sondern sollte diese unterstützen.

Scrum ist ein Rahmenwerk für die Zusammenarbeit von Teams basierend auf einer Definition von Rollen, Meetings und Werkzeugen, die einem Team Struktur und einen klar definierten Arbeitsprozess basierend auf agilen Prinzipien geben.

1. Agiles Arbeiten im Controlling – Erste Schritte

Da wie üblich im Controlling viele Themen und etliche Termine anstanden, stand die Woche, in der das Controlling-Team die agilen Methoden ausprobieren sollte und wollte, unter der Überschrift: ‚kurze theoretische Einführung und dann einfach ausprobieren‘. Im Nachgang gesehen war dies ein wesentlicher Erfolgsfaktor. Dieser Ansatz führte nicht dazu, dass einer euphorischen Stimmung im Einführungsprojekt die Ernüchterung in der Praxis folgte, sondern eher umgekehrt, die anfängliche Skepsis einer Begeisterung für die Methodik wich. Ausgewählt wurde im Rahmen einer Managementklausur als ‚Projekt‘ der Budgetprozeß, um Struktur, Wirkungsweise, Rollen und Ablauf der agilen Methoden im Controllingteam auszuprobieren. Ein erfahrener Scrum-Master aus einem großen IT-Projekt im Unternehmen stand dem Team dabei zur Seite.

Nach einer kurzen theoretischen Einführung (ca. 2 Stunden) wurden Aufgaben für die erste Phase des Budgetprozesses geklärt und als User Stories in einem Backlog aufgeschrieben. Zum Ausprobieren war der erste Sprint auf eine Woche begrenzt, um schnell den Gesamtablauf und die Wirkmechanismen eines Sprints zu erfahren. Aufgaben für die erste Woche wurden aus dem Backlog priorisiert und so entstand die Sprint-Planning für diesen ersten Sprint. Das Controlling-Team war das ‚Entwicklungsteam‘, denn hier wurden die Aufgaben der Sprint-Planning erledigt. Die schematische Darstellung eines Sprints ist in der folgenden Grafik ersichtlich:

• Der Scrum-Master fungiert meist als Coach, kann aber auch selbst Teil des Entwicklungsteams sein.

• Eine User Story oder Anwendererzählung ist eine kurze Beschreibung (Story) dessen, was ein Benutzer (User) will.

• Backlog ist eine dynamische Liste von durchzuführenden Arbeitsaufträgen.

• Der Scrum Sprint, ein fest definierter Zeitraum, bildet die Grundlage eines Scrum-Projekts... Jeder Sprint besteht aus einer Anzahl festgelegter Themen: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

• Beim Scrum Sprint Planning-Meeting, an dem das gesamte Projektteam teilnimmt, wird die Arbeit eingeplant, die in einem Sprint geleistet werden muss.

• Das Daily Scrum, auch Standup-Meeting oder Daily Standup-Meeting genannt, ist ein täglich stattfindendes Treffen des Scrum-Teams, das höchstens 15 Minuten dauert... Das Ziel des Daily Standup-Meetings liegt darin, die Arbeiten aufeinander abzustimmen und einen Plan für die nächsten 24 Stunden zu haben.

• Bei Scrum wird mit einem Task Board gearbeitet. Das Scrumboard ist als Hilfsmittel gedacht, mit dem der Stand der Dinge während eines Sprints übersichtlich dargestellt werden kann.

• Das Sprint Review Meeting findet am Ende eines jeden Sprints statt. Bei diesem informellen Treffen sollen die erzielten Ergebnisse reflektiert und gegebenenfalls der Product Backlog angepasst werden.

Tägliche fanden sogenannte Stand-Ups statt, in denen sich das Team kurz austauschen konnte, was am Vortag erledigt wurde und was für den selben Tag noch ansteht, sowie die Absprache der optimalen Abfolge der noch durchzuführenden Aufgaben. Sie wurden aber auch als Plattform des Austauschs für Erfolge und schwierige Aufgaben genutzt. Stand up bedeutet eigentlich, dass alle vor einem Bord stehen. Dies fördert aktives Zuhören und Disziplin. Mittlerweile ist es digital, funktioniert aber mit Disziplin vor dem PC auch gut. Schon beim ersten Stand-up merkten einige Teammitglieder, dass sie Input von Kollegen brauchten, dies aber nicht in deren Tagesplan vorgesehen war. Ineffizienzen konnten so schnell ‚entlarvt‘ werden und Adaptionen im Tagesablauf waren möglich, so dass Inputs und Outputs gut aufeinander abgestimmt werden konnten.

Auf einem Scrum-Board , welches später digitalisiert wurde, wurden die Aufgaben transparent dargestellt und mit ihrem Erfüllungsstand gepflegt. Auf dem Board wanderten die Kärtchen mit den beschriebenen Arbeitsaufgaben von ‚to do‘ zu ‚doing‘ und schließlich auf ‚done‘. Plötzlich konnte man sehen, was schon fertig war, was gerade in Arbeit war oder eben noch im Backlog wartete. Das System funktionierte!

Am Ende der Woche erfolgte dann die Sprint-Review , zu dem zusätzlich der Stakeholder (beim Controllingsteam der Abteilungsleiter) eingeladen wurde. Jeder berichtete: Was hatte man sich vorgenommen, was wurde geschafft? Was wurde nicht geschafft und warum nicht? Der Stand der Arbeit wurde präsentiert und diskutiert, ob und welche Hilfe aus der Organisation oder Leitungsebene nötig war, um den nächsten Prozeßschritt fertigzustellen.

2. Retrospektive und Reflexion

In der anschließenden Retrospektive ging es für das Team darum, die agile Projektwoche zu reflektieren. Was war gut, was lief nicht so gut? Offenes Feedback war wichtig, um daraus zu lernen und Prozeßverbesserungen anzustoßen. Was können wir tun, um effizienter und schneller zu werden? Auch neue Ideen, um Dinge auszuprobieren, waren dabei erlaubt. Ein Working Agreement des Teams schloß die Retrospektive ab, in diesem Falle war es, weiter die agilen Methoden für die Budgetplanung zu nutzen und diesen in Sprints aufzuteilen.

Die Retrospektive ist ein essentieller und neuer Bestandteil im Teamprozeß bei Scrum. Bisher war das Team gewohnt, in der zunehmenden Komplexität zu agieren und auf neue Prozeßanforderungen zu reagieren. Retrospektive ermöglicht dem Team ein kurzes innehalten und setzt dabei gemeinsam Potential für neue Ideen frei.

Retrospektive ist nicht alles, aber ohne gute Retrospektive ist alles nichts!

Die Retrospektive findet zyklisch am Ende eines jeden Sprints statt. Der Betrachtungszeitraum geht über eben genau diesen Zeitraum. Der Fokus des Rückblicks liegt hierbei auf die verbesserte Teamzusammenarbeit und weniger auf das individuelle Feedback.

Um Verbindlichkeit in der Retrospektive sicher zu stellen, werden hier konkreten Punkte beschlossen, Verantwortlichkeiten festgelegt und mit einer Zeitleiste versehen.

3. Vom Projekt zur Routine

Nach dieser erstaunlich erfolgreichen Woche kam das Team zu dem Schluss, das Projekt ‚Budget‘ in der Scrum-Methodik weiterzuverfolgen. In 14-tägigen Sprints wurden aus dem Backlog die neuen Aufgaben priorisiert. Da sich der Budgetprozeß und auch andere Tätigkeiten im Controlling in klar definierten Zeitfenstern bewegen, wurde Focus darauf gelegt, wann Aufgaben erledigt sein müssen und welche Inputs und Outputs dafür benötigt werden. Zeitverzüge bei einzelnen Aufgaben wurden sofort sichtbar!

Plötzlich war sehr viel transparenter: wo liefen Aufgaben nicht so und waren schon seit ein oder zwei Sprints ‚in Arbeit‘? Wo waren Aufgaben unklar definiert, so dass zwar ein Ergebnis da war, aber als Input für einen Nachfolgeprozess nicht den Anforderungen entsprachen? Wurden immer die wirklich wichtigen Themen priorisiert oder die von einem Stakeholder, der den größten Druck machte?

Am Ende des Budgetprozesses gab es von den Stakeholdern, Schnittstellen und der Geschäftsleitung viel Lob, dass dieser Prozess nun viel transparenter und für alle Beteiligten nachvollziehbarer war als zuvor. Ein Lob, das das Team stolz machte. Es hatte sich was bewegt. Die Begeisterung für Scrum war so groß, dass das Team beschloss, die agilen Methoden nach dem Budgetprozess nicht zu verwerfen, sondern auf die tägliche Arbeit auszuweiten. Das Backlog füllte sich dann mit Themen aus dem Controlling, sowohl für Routinethemen, als auch für Projekt- und Sonderthemen der Controller. Aber auch hier hat das Team im Laufe der Zeit einiges ausprobiert und in iterativen Schritten Verbesserungen im Prozeß angeregt und umgesetzt.

4. Reaktionen aus dem Team

Wichtig ist, von Zeit zu Zeit dem Team die Möglichkeit des Reflektierens auch über die Retrospektive hinaus, zu geben. Nicht alle Teammitglieder waren gleichermaßen begeistert, Bedenken gegen die neue Arbeitsorganisation durften offen ausgesprochen werden und wurden gehört. Hier hat geholfen, diese Themen zuzulassen und ernst zu nehmen, aber auch nicht von den vielen positiven Reaktionen überschatten zu lassen. Im Team entstand eine gute Dynamik, die selbst vom Management wahrgenommen wurde. Einige konkrete Punkte sind in der folgenden Grafik auf einem Teamtag zusammengetragen worden:

5. Der Teamleiter als Katalysator

Um solch einen umfassenden Prozeß im Team in Gang zu bringen, muss der Teamleiter von der Prozeßänderung, in diesem Falle vom „agilen Arbeiten“ überzeugt sein und dies ausstrahlen. Es gehört genauso ein langer Atem dazu, immer wieder zu überzeugen, wie auch über einige Rückschläge hinwegzusehen. Zuhören ist dabei genauso wichtig, wie das Team aufzufordern und zu ermuntern, neue Dinge auszuprobieren und immer wieder mit neuen, eigenen Ideen zu kommen. Im günstigen Falle kann damit eine Teamdynamik in Gang gesetzt und Potentiale gehoben werden, die sonst nicht erkennbar gewesen wären. Neue Rollen bringen auch neue Chancen für Teammitglieder!

6. Fazit

Zusammenfassend gab es für das Team drei wesentliche Punkte durch Scrum, die für die Arbeit sprunghafte Verbesserungen gebracht haben:

1. Die konkrete Formulierung von Aufgaben: was soll erledigt werden, wie soll der Output aussehen?
2. Die richtige Priorisierung von Themen: Was sind die wirklich wichtigen Themen, die im nächsten Sprint bearbeitet werden sollen?
3. Transparenz: Wer arbeitet gerade an welchen Themen im Team? Wie ist der Stand dazu?

Aber auch die Anwendung von Teilen der Scrum-Methodik ist völlig zulässig, solange es die Organisation und das Team unterstützt. Wichtig ist, erstmal loslegen, Mut haben und

Ideen zulassen!

Ausprobieren!

Anpassen!

Literatur

Andreas Diehl, Was ist Scrum? – Eine kompakte Einführung in die Scrum Methode, https://digitaleneuordnung.de/blog/scrum-methode/ vom 04.01.2022

Ratgeber: Was macht eigentlich ein Scrum-Master?, https://t3n.de/news/scrum-master-aufgaben-ausbildung-gehalt-800972/ vom 04.01.2022

Agile Scrum Group, Us.er Stories: https://scrumguide.de/user-story/ vom 4.1.2022

Dr. Geord Angermeier (08.03.2018), Backlog, https://www.projektmagazin.de/glossarterm/backlog vom 04.01.2022

Agile Scrum Group, Der Scrum Sprint, https://scrumguide.de/scrum-sprint/ vom 04.01.2022

Agile Scrum Group, Scrum Sprint Planning.Meeting, https://scrumguide.de/sprint-planning/ vom 04.01.2022

Agile Scrum Group, Das Daily Standup-Meeting: Erläuterungen und Tipps, https://scrumguide.de/daily-standup-meeting/ vom 04.01.2022)

Agile Scrum Group, Das Scrumboard, https://scrumguide.de/scrumboard/ vom 04.01.2022

Agile Scrum Group, Sprint Review Meeting, https://scrumguide.de/sprint-review/ vom 4.1.2022

Online Projektmanagement, Die Retrospektive in Scrum, https://www.online-projektmanagement.info/agiles-projektmanagement-scrum-methode/scrum-meetings/retrospektive/ vom 4.1.2022

Susanne Grätsch, Kassandra Knebel (17.04.2019) Die Scrum Retrospektive . Erklärung und Praxis, https://www.berlinerteam.de/magazin/scrum-retrospektive/#Decide_what_to_do_Massnahmen_beschliessen vom 4.1.2022)

Ersteinstellender Autor

Angela Saloch

Gruppenleiter Operatives Controlling und Technical Fleet Management, Lufthansa Airlines

Mail: angela.saloch@dlh.de