How to SCRUM – mit agilem Arbeiten Teamwork neu denken 

Steht ein neues Projekt in einer Firma an, kommt immer öfter die Frage auf: »Agil« oder »klassisch«? Agiles Arbeiten und agiles Projektmanagement haben sich in den letzten Jahrzehnten etabliert und basieren auf den vielen und schnellen Weiterentwicklungen im Bereich der Technik und der Arbeitsweisen. Mehr und mehr Firmen stießen mit ihren klassischen Strukturen und Prozessen an ihre Grenzen und bedienten sich immer öfter dem Prinzip des agilen Arbeitens, das ursprünglich aus der Softwareentwicklung stammt. Doch was zeichnet agiles Arbeiten aus?

Was es heißt, agil zu arbeiten

Das Wort »agil« bedeutet in erster Linie, dass etwas dynamisch und flexibel erfolgt. Agiles Arbeiten und die agile Steuerung von Projekten brechen die bisherigen klassischen Arbeitsstrukturen auf, die oftmals durch eine Top-Down-Hierarchie geprägt sind. Durch die neuen Arbeitsformen stehen Zusammenarbeit, das schnelle Umsetzen von Änderungen im Prozess und bessere Arbeitsergebnisse im Fokus. Das spart idealerweise Zeit bei Korrekturschleifen und vermeidet Mehraufwand. Kurz gesagt: Beim agilen Arbeiten wird ein großes Projekt in mehrere, kleinere Zwischenprojekte zerlegt, um schnell präsentierbare (Zwischen-)Ergebnisse zu erzeugen.

Ein weiterer Vorteil? Agiles Projektmanagement bietet die Möglichkeit, sich auf kurzem Weg abzustimmen. Das wiederum führt zu einer hohen Transparenz, denn jeder weiß, wer gerade an was arbeitet und wo welche Zuständigkeiten liegen. Durch die kurzfristigen Abstimmungen können die Teams auch schnell (Zwischen-)Ergebnisse entwickeln. Damit das funktioniert, ist ein eigenverantwortliches Arbeiten der Mitarbeitenden entscheidend.

Agiles Arbeiten ermöglicht es allen Beteiligten, sich eigenständig Ziele zu setzen. Das zielt zum einen auf deren individuellen Stärken und Schwächen ab, heißt aber auch: Stay flexible! Sich an kurzfristige Änderungen anpassen zu können und in der Folge auch Prozesse entsprechend zu adaptieren, ist wichtig. Die eine Version des agilen Arbeitens gibt es übrigens nicht – das würde auch dem Gedanken des ganzen Prinzips widersprechen. Somit sollte jede Firma ihre eigene Art und Weise finden, agil zu arbeiten. Damit das funktioniert, gibt es einige Basics, die die Leitplanken des agilen Arbeitens setzen.

Es gibt unterschiedliche Methoden des agilen Arbeitens: SCRUM zählt neben Kanban und Design Boxing zu den bekanntesten. Auch wir arbeiten mit der SCRUM-Methode und haben sie an unsere Arbeitsweise angepasst – sozusagen OPUS-Style, da wir mit Kund:innen über zwei Häuser hinweg zusammenarbeiten. Das alleine erfordert eine gewisse Flexibilität. Doch was genau verbirgt sich hinter der SCRUM-Methode?

Die SCRUM-Methode erklärt

Die SCRUM-Methode besteht aus unterschiedlichen Bestandteilen und stellt ein Framework mit Rollen, Meetings und Tools dar, in dem das Team gemeinsam an einem Projekt arbeitet. Dabei wird ein großes Projekt in mehrere kleinere To-dos umgewandelt, die in kurzen, sich wiederholenden Zyklen – sogenannten Sprints – umgesetzt werden. Das hilft, um auf kürzestem Weg erste Ergebnisse zu erzielen.

Klassischerweise werden agile Arbeitsmethoden innerhalb einer Firma oder eines Projekts angewendet. Da wir mit unseren Kund:innen über zwei Häuser und Firmen hinweg zusammenarbeiten, haben wir die SCRUM-Methode an unser Agenturmodell angepasst. Und das passiert auch bei jeder Zusammenarbeit aufs Neue. Damit wollen wir uns bestmöglichst auf die Kund:innen und ihre Bedürfnisse einstellen.

Das Wort Scrum kommt übrigens aus dem Rugby. Scrum direkt übersetzt bedeutet »Gedränge« und hat eine metaphorische Bedeutung: Nur, wer im Team arbeitet, aufeinander achtet und flexibel agieren kann, kommt beim Rugby weiter.  So ist es auch beim agilen Arbeiten. Die Methode zeichnet sich nicht nur durch eine flexible Arbeitsweise aus, es lehrt alle Beteiligten auch, sich selbst zu organisieren, aus Fehlern zu lernen und sich schnell an neue Situationen anzupassen.

Die Basics des agilen Projektmanagements

Die Rollenverteilung

Product Owner

Der Product Owner arbeitet an einem ausgewählten Part im Projekt als Führungskraft oder Project Manager. Somit kann es pro Projekt auch mehrere Product Owner geben, die für unterschiedliche Parts verantwortlich sind – einen Zuständigen für die Texte, einen Zuständigen für die Layouts…

Der Product Owner legt die Produkteigenschaften fest. Diese werden im (Product) Backlog festgehalten, der die Sammlung aller anstehenden To-dos darstellt. Die Eigenschaften werden dann priorisiert und in Sprints abgearbeitet, die vorher einen festgelegten Zeitraum erhalten. In unseren Projekten dauern Sprints meist etwa 2 bis 3 Wochen. In den Sprint-Terminen sprechen die Product Owner mit allen Beteiligten die einzelnen Aufgaben und Arbeiten durch. Seine Aufgabe ist es, alle Informationen und Ansichten sowie das Feedback zu bündeln. Im Anschluss holt er Freigaben ein und informiert alle relevanten Personen, die nicht im Projektteam sind, über den Projektstatus.

SCRUM Master

Der SCRUM-Master trägt die Verantwortung für den SCRUM-Prozess und moderiert die Treffen und Meetings im Projektteam. Seine Aufgabe ist es sicherzustellen, dass der vereinbarte Ablauf eingehalten wird. Dafür betreut er das Team und bespricht hier regelmäßig mögliche Verbesserungen.

Team / Developers

Agiles Arbeiten bedeutet auch, sich agil abzustimmen. Damit das klappt, gibt es im Team klare Zuständigkeiten und viel Kommunikation für schnelle Updates. Das Team setzt die To-dos aus den Sprints und die Anforderungen des Product Owners um. Dabei arbeitet es eigenständig und selbstorganisiert.
In den Sprints ist das Team ebenfalls gefragt. Die Mitglieder präsentieren die Ergebnisse und gehen miteinander in Diskussion. Hier sind alle gefragt, die eigene Meinung zu vertreten.

Die Termine und Elemente

(Product) Backlog

Klassischerweise werden bei SCRUM zunächst anstehende Items im Backlog gesammelt. Der Backlog ist somit eine Auflistung aller Anforderungen an das Projekt. Diese werden vom Product Owner so priorisiert, dass schnellstmöglich erste Ergebnisse erzielt werden. Der Backlog kann im Laufe des Projekts immer wieder ergänzt und angepasst werden. Die Items im Backlog sind nicht als Aufgaben formuliert, sondern stellen ein erwartetes Arbeitsergebnis oder eine Produkteigenschaft dar – ein sogenanntes Inkrement. Ein Inkrement könnte beispielsweise ein Text sein, der bereits ein fertiges und präsentierbares Teilprodukt darstellt.

Um auf mögliche Änderungen flexibel reagieren zu können, wird der Backlog nicht mit zu vielen Aufgaben befüllt. Bei 100-prozentiger Auslastung ist es sonst schwer, agil zu bleiben.

Sprint

Sprints dienen dazu, To-dos aus dem Backlog abzuarbeiten und regelmäßig die Möglichkeit zu haben, Inhalte auszutauschen und Zwischenstände zu kommunizieren. Hier haben die Teammitglieder auch die Möglichkeit, Feedback zu bekommen. In einem Projekt finden mehrere Sprints ab, bis das Produkt fertiggestellt ist. Daher spricht man auch von einem iterativen Vorgehen. Jeder Sprint innerhalb eines Projekts hat in etwa dieselbe Zeitspanne. Die Dauer wird am Anfang gemeinsam definiert. Am Ende eines Sprints sollte ein vorzeigbares (Zwischen-)Ergebnis – das Inkrement – vorhanden sein.

Damit die Teams nicht wochenlang in Stille ihre To-dos abarbeiten, gibt es innerhalb eines Sprints weitere Termine, um sich über den aktuellen Stand upzudaten. Wichtig bei dieser Methodik ist, sich persönlich und in regelmäßigen Abständen auszutauschen. Zu den Terminen zählen:

1. Sprint Planning: Der Kick-off eines Sprints, bei dem das ganze Team zusammenkommt. Die Ziele eines anstehenden Sprints werden gemeinsam definiert und Aufgaben durch den Product Owner priorisiert. Diese Tasks werden dann vom Team in den anstehenden Sprints umgesetzt.
2. Daily: Das Team updated sich täglich über den Arbeitsstand. Woran wird gerade gearbeitet? Das hilft, mögliche Hindernisse aus dem Weg zu schaffen. Es ist wichtig, die Daily-Meetings kurz zu halten. Wir bei OPUS beschränken uns mit unseren Kund:innen auf Weekly-Termine.
3. Sprint Review: Am Ende jedes Sprints werden dessen Ziele und Ergebnisse vom Product Owner gesammelt. Das Team hat die Möglichkeit, das Produkt zu präsentieren. Mit dabei sind hier auch andere Stakeholder und Entscheidende wie beispielsweise die Kund:innen, die dort ihr Feedback geben können. Das wird dann in den anstehenden To-dos berücksichtigt.
4. Sprint Retrospective: Dieses findet typischerweise direkt nach dem Sprint Review statt. Das Team kommt zusammen und reflektiert in einer offenen Feedbackrunde die Zusammenarbeit. Das Ziel ist es, so die Teamarbeit zu stärken.

Voraussetzungen, um agil arbeiten zu können

Soweit die Theorie. Damit’s mit dem agilen Arbeiten und agilen Projektmanagement klappt, müssen ein paar Voraussetzungen erfüllt werden:
Die Mitarbeitenden brauchen als erstes die entsprechende Eigenverantwortung, Dinge auch umzusetzen zu können und zu dürfen. Entscheidungen werden dann auf kurzem Weg im Team getroffen, anstatt sich erstmal die Genehmigungen vom CEO oder Abteilungsleitung einzuholen. Das setzt natürlich auch ein gewisses Vertrauen und Arbeiten auf Augenhöhe voraus – eine klassische Top-Down-Hierarchie würde dem agilen Arbeitsprozess schaden.
Um sich schnell updaten zu können, ist viel Kommunikation wichtig. Dafür sollte Raum geschaffen werden und die Mitarbeitenden leicht erreichbar sein. Wer gerade an was arbeitet, wird regelmäßig an die anderen kommuniziert. Damit das funktioniert, braucht ein Unternehmen nicht nur ausreichend Tools, um sich auszutauschen, es sollten auch fixe Termine festgelegt werden.

Agiles Projektmanagement ist ein Prozess, den auch wir durchlaufen haben. Von heute auf morgen zu beschließen, agil zu arbeiten, ist schwierig. Auch wir lernen jetzt noch jeden Tag dazu! Wie wir bei OPUS agiles Projektmanagement mit Kund:innen umsetzen, erklären wir im nächsten Blogbeitrag an einem Praxisbeispiel. Bis dahin, stay flexible!