We do something else, but not Scrum!
Agiles Arbeiten nach Scrum in der Praxis
von Elisa Erbe, Februar 2023
Viele Projekte parallel zu bearbeiten, dazu zahlreiche Deadlines und ein kleines Team – gerade jüngere Agenturen stellen sich den Herausforderungen eines sich stetig verändernden Projektportfolios. Wie kriegen wir alles unter einen Hut und stellen dabei die Servicequalität sicher? In diesem Artikel erfahrt ihr, wie wir agiles Arbeiten und Scrum für uns nutzen.
In Kürze: Scrum ist ein Modell für agiles Projektmanagement, das kleine Teams dabei unterstützt, komplexe Projekte zu organisieren und zu bearbeiten. So sind auch bei einem Softwareprodukt die konkreten Anforderungen am Anfang noch unscharf und werden erst während des Prozesses genauer definiert. Agiles Arbeiten gibt uns hier die Freiheit, auch dann bereits mit der Arbeit beginnen zu können, wenn wir noch nicht jeden Schritt genau kennen. Im Gegenteil: Gemeinsam mit unseren Kundinnen und Kunden durchlaufen wir einen iterativen Prozess und tasten uns an das Ergebnis heran. Wer mehr über Scrum lesen möchte, kann dies hier tun.
1. Wer sind wir und was tun wir?
Unser vierköpfiges Team – bestehend aus der Unternehmensinhaberin, die als Consultant und Developerin tätig ist, zwei Webentwicklern und einer Projektmanagerin – entwickelt Webanwendungen mit strategischer Relevanz für Unternehmen und Institutionen in verschiedenen Branchen. Wir betreuen den gesamten Entwicklungsprozess einschließlich Beratung, Konzeption, Programmierung, Testingphase und Livegang. Zu unseren Kundinnen und Kunden gehören Organisationen und private Dienstleistungsunternehmen aus den Bereichen Gesundheit & Pharma, Medienbildung, Kultur, Verlagswesen, Architektur, Telekommunikation, IT und Banking & Finanzwesen.
Zeitgleich bearbeiten wir in der Regel etwa acht bis zehn Projekte, die zwischen 20 und 400 Stunden umfassen und dementsprechend nur wenige Stunden und Tage oder auch einige Wochen und Monate in Anspruch nehmen. Für unsere tägliche, wöchentliche und längerfristige Planung verwenden wir hauptsächlich die Verwaltungssoftware Jira. Wir arbeiten remote und orientieren uns seit etwa einem Jahr zunehmend an den Prinzipien von Scrum.
2. Wie integrieren und adaptieren wir agile Methoden und Scrum?
a. Stop starting, start finishing
In Scrum: Eine Grundhaltung in Scrum lautet Stop starting, start finishing. Sie zielt darauf ab, keine neuen Aufgaben zu bearbeiten, bevor laufende Aufgaben nicht erledigt sind. So simpel, so wichtig, und auf alle Ebenen anwendbar: auf der Mikroebene kleinster Teilaufgaben, auf der Makroebene von Milestones sowie auf der Projektebene.
Bei uns: Da wir parallel immer an mehreren Projekten arbeiten, lässt sich dieses Prinzip für uns hauptsächlich auf der Mikroebene einzelner Aufgaben und kürzerer Projektabschnitte anwenden. Hier hilft es uns dabei, unnötige Kontextwechsel zu vermeiden, die Performance im Team realistisch einzuschätzen und auf regelmäßiger Basis neue Teilfunktionalitäten an Kundinnen und Kunden weiterzugeben. Auch wenn die Vorteile absolut nachvollziehbar sind, fällt die Umsetzung nicht immer leicht. Denn manchmal kann es verlockender sein, mit einer neuen Aufgabe zu beginnen, als das Ergebnis einer anderen zu testen. Vielleicht bringen auch dringende Bugfixes die Planung durcheinander oder eine Kundin bzw. ein Kunde erbittet aus anderen Gründen kurzen Support. Stop starting, start finishing ist also eine Grundhaltung, die sich erst nach und nach etabliert und dabei unsere ständige Rückbesinnung erfordert.
b. Scrum Team
In Scrum: Ein Scrum Team besteht aus einem Product Owner, einem Development Team und einem Scrum Master und umfasst in der Regel nicht mehr als zehn Personen. Neben diesen Scrum-Rollen gibt es innerhalb eines Scrum Teams keine Untergruppen oder hierarchischen Ebenen. Der Product Owner strebt danach, den Wert des Produktes maximal zu erhöhen und ist innerhalb des Scrum Teams diejenige Person, die Entscheidungen zum Produkt trifft und dafür mit den verschiedenen Interessengruppen außerhalb des Scrum Teams kommuniziert. Zu diesen Stakeholdern gehören die Kundinnen und Kunden, aber auch die IT, das Design oder mögliche Investoren. Das Development Team ist eine selbstorganisierte cross-funktionale Gruppe, die ein Produkt entwickelt. Alle Mitglieder des Development Teams sind dabei gemeinsam für das Erreichen eines jeden Zwischenziels verantwortlich. Der Scrum Master wiederum wird in Scrum als ein „true leader“ beschrieben (weitere Infos hier). Seine oder ihre Aufgabe ist es, das Team für agile Methoden und Scrum zu sensibilisieren. Neben der Umsetzung von Scrum und Agile kann sich ein Scrum Master je nach Bedarf auch als Coach, Managerin oder Mentor betätigen.
Bei uns: Die Position des Product Owners lässt sich in unserem Team am ehesten auf die Unternehmensinhaberin übertragen, da sie in letzter Instanz Entscheidungen zum Produkt und Prozess treffen kann und einen Großteil der Kommunikation nach außen übernimmt. Unser Development Team weicht in seiner Arbeitsweise teils recht deutlich von den Vorgaben in Scrum ab. Das liegt zum einen daran, dass wir die kleineren Projekte in Zuständigkeiten aufteilen und daher nicht alle Developer immer an den gleichen Projekten arbeiten. Zudem kommunizieren auch sie manchmal mit den Kundinnen und Kunden, wenn es sich sinnvoll aus dem Prozess heraus ergibt. Die Position des Scrum Masters wird in unserem Team am ehesten von mir als Projektmanagerin übernommen. Die Rolle eines Scrum Masters ist aber insgesamt individueller als die eines Projektmanagers bzw. einer Projektmanagerin. Sie bleibt in Scrum recht unscharf und schwer zu greifen, zudem scheinen die konkreten Aufgaben auch stark interpretativ zu sein. Des Weiteren können in Scrum auch der Product Owner und der Scrum Master partiell als Developer tätig sein, und dieses mögliche Überschneiden der Scrum-Rollen bei einzelnen Personen erschwert eine klare Abgrenzung zusätzlich.
Auch wenn Scrum keine Hierarchien im Scrum Team vorsieht, stellen wir fest, dass es in den verschiedenen Domänen der Teammitglieder durchaus unterschiedliche Handlungsspielräume gibt. Wir nehmen hier vor allem mit, dass Scrum uns dazu anregt, Entscheidungen möglichst im Konsens zu treffen oder da, wo es nicht möglich ist, Entscheidungsprozesse transparent zu machen.
c. Arbeiten in Sprints
In Scrum: Ein Sprint ist ein sich wiederholender, fester Zeitabschnitt, um mithilfe eines vorher festgelegten Planes ein bestimmtes Zwischenziel zu erreichen, z.B. ein neues Softwarefeature. In Scrum ist er das wichtigste Event.
Bei uns: Auch wir arbeiten in Sprints mit einer festen Länge von zuerst sieben, mittlerweile vierzehn Tagen. Bei der Strukturierung eines Sprints achten wir darauf, die Anzahl regelmäßiger Meetings so weit wie möglich zu minimieren und dafür die wenigen, aber verbindlichen Meetings gut zu strukturieren. Auch wenn Urlaubstage, Feiertage oder Krankheitsfälle auftreten, ändern wir die Länge eines Sprints in der Regel nicht. Früher begann unser Sprint am Montag und endete am Freitag. Da aber nicht alle Teammitglieder am Freitag arbeiten, beginnt und endet ein Sprint bei uns mittlerweile am Mittwoch.
d. Meetings: Planning, Review und Retrospective
In Scrum: Sprint-Planning, Sprint-Review und Sprint-Retrospective sind in Scrum feste Bestandteile eines Sprints. Während des Planungsmeetings zu Anfang eines jeden Sprints werden die Sprintziele (Sprint Goals) festgelegt, die dafür zu erledigenden Aufgaben bestimmt (Sprint Backlog) und überlegt, wie ihre Umsetzung erfolgen kann. Im Review Meeting vor Sprintende werden die Ergebnisse des Sprints evaluiert, häufig gemeinsam mit Stakeholdern. Der Fokus richtet sich hier auf das Produktinkrement, also auf ein Teilprodukt dessen, was insgesamt entwickelt wird. Das Retrospective Meeting zum Abschluss eines Sprints wiederum dient der gemeinsamen Reflexion, wobei der Fokus nun auf dem Prozess während des vergangenen Sprints liegt: Was lief gut? Was könnte verbessert werden? Mindestens ein Verbesserungsvorschlag sollte dann im nächsten Sprint umgesetzt werden.
Bei uns: Wir behandeln die Events Retrospective und Planning hintereinander in einem großen Meeting, was verschiedene Vorteile hat. Zum einen reduziert sich die Anzahl der festen Meetings während eines Sprints. Zum anderen werden die Erkenntnisse aus dem Retrospective-Meeting nicht übers Wochenende vergessen, sondern fließen gleich in die neue Planung ein. Außerdem ist der Montagmorgen nun nicht mehr durch ein langes und intensives Meeting geprägt, was den Start in die neue Kalenderwoche deutlich angenehmer gestaltet.
Die Kommunikation mit Stakeholdern erfolgt bei uns allerdings asynchron, das heißt, sie korreliert nicht mit unserer Sprintstruktur. Da wir immer parallel an mehreren Projekten arbeiten, ist die Einhaltung eines regelmäßigen Review Meetings vor Sprintende schwierig. Stattdessen übergeben wir eine fertige Funktionalität nach ihrer Umsetzung an unsere Kundinnen und Kunden und erbitten ein Feedback. Diese Übergaben folgen aber keinem festen Rhythmus. In langfristigen Projekten gibt es regelmäßige Jour fixes, in denen alles besprochen werden kann, was sich per E-Mail oder mithilfe unseres Ticket-Systems nicht zufriedenstellend kommunizieren lässt.
Nachdem ein Sprint einmal gestartet wurde, sollte das festgelegte Sprint Backlog nach Möglichkeit nicht mehr verändert werden. Wir priorisieren jedoch spontane Anfragen nach Dringlichkeit: Eindeutige Blocker ziehen wir vor in den aktuell laufenden Sprint, aber alles andere wird eingeplant, anstatt es zwischenzuschieben. So können wir einerseits unseren Kundinnen und Kunden Service bieten und andererseits die Qualitätssicherung unserer Arbeit gewährleisten.
e. Morgendliches Stand up
In Scrum: Das morgendliche Stand up (oder auch Daily Scrum) ist ein festes Event in Scrum. Es dient dazu, den Projektfortschritt zu kontrollieren und die nächsten 24 Stunden zu planen. Das Stand up dauert maximal 15 Minuten und findet morgens immer zur gleichen Zeit und am selben Ort statt. Alle Mitglieder des Development Teams geben einander ein kurzes Update und gehen dabei auf die Fragen ein: Was habe ich gestern getan, um das Sprintziel zu erreichen? Was werde ich heute für das Sprintziel tun? Welche Hindernisse könnten das Sprintziel gefährden?
Bei uns: Das morgendliche Stand up war für einige Monate fester Bestandteil unserer morgendlichen Arbeitsroutine und fand täglich um 9.00 Uhr und digital statt. Zu Beginn hatte es eher die Funktion, den Arbeitstag gemeinsam zu beginnen und uns gegenseitig einen guten Morgen zu wünschen. Später haben wir es an die Vorgaben in Scrum angepasst. So wurden die gestrigen und heutigen Aufgaben besprochen, mögliche Schwierigkeiten erörtert und der Fortgang des Sprints im Hinblick auf die gesetzten Ziele bewertet. Nach einiger Zeit fiel jedoch auf, dass das Bedürfnis nach einem täglichen Meeting bei keinem Teammitglied besonders ausgeprägt war, da es inhaltlich zu Redundanzen kam und vor allem die zeitliche Platzierung am Morgen zur besten Fokuszeit eher als störend wahrgenommen wurde. So haben wir das tägliche Morgenmeeting abgeschafft und stattdessen ein einzelnes Mid-Sprint-Meeting eingeführt. Wenn wir das Bedürfnis nach mehr, aber etwas weniger strukturiertem Austausch haben, setzen wir ein gemeinsames Mittagsmeeting oder eine Coffee Break an.
f. Storypoints
In Scrum: Storypoints sind Maßeinheiten, die Auskunft über den Gesamtaufwand geben, der für die vollständige Umsetzung einer Aufgabe erforderlich ist. Hierbei werden keine zeitlichen Vorhersagen getroffen. Storypoints werden relativ zur Komplexität einer Aufgabe, ihrem erwartbaren Arbeitsaufwand und möglichen Risiken und Unsicherheiten zugewiesen. Solch ein vergleichendes Schätzen berücksichtigt die Tatsache, dass das menschliche Gehirn nicht gut darin ist, absolute Werte zu bestimmen, weshalb exakte Zeitspannen schwer vorherzusagen sind. Jedoch fällt es uns relativ leicht, Beziehungen wie einfach und kompliziert, lang und kurz oder groß und klein herzustellen. Das Schätzen in Story Points ist nicht zwingend Bestandteil von Scrum, wird in agilen Teams aber häufig praktiziert. Nach jedem Sprint wird der Mittelwert der erledigten Storypoints neu berechnet, der sich mit der Zeit um einen bestimmten Wert herum – die teameigene (!) Velocity – einpendelt, was hilfreich für die Planung jedes weiteren Sprintumfangs ist.
Bei uns: Auch wir haben das Schätzen in Wochen, Stunden oder Minuten abgeschafft und durch das Schätzen in Storypoints ersetzt. Dadurch verringert sich der gefühlte Druck, etwas innerhalb einer vorher festgelegten Zeitspanne erledigen zu müssen, deutlich. Mittlerweile gibt es keine signifikanten Abweichungen vom Mittelwert mehr, auch wenn „Störfaktoren“ wie spontane Krankheitsausfälle, Urlaubstage oder Änderungen am Sprintumfang auftreten. Man könnte also sagen, dass wir unsere Velocity gefunden haben.
Wir haben mittlerweile auch gelernt, ab welchem Storypoint-Wert eine Aufgabe mit hoher Wahrscheinlichkeit nicht innerhalb eines Sprints abgeschlossen werden kann. Es ist dann besser, solche Aufgaben zu strukturieren, auf mehrere Tickets zu verteilen und diese dann einzeln zu schätzen. Der initiale Mehraufwand lohnt sich, da so die Teilaufgaben sichtbar gemacht werden müssen und ein Projektabschnitt auch gleich für mehrere Sprints vorgeplant werden kann.
Für die Wertung der Storypoints am Ende eines Sprints haben wir eine individuelle Regelung gefunden, die von den Vorgaben in Scrum abweicht. So definieren wir eine Aufgabe auch dann als (vorerst) erledigt und die Storypoints somit als erbracht, wenn sie sich am Ende des Sprints noch im Testingverfahren bei der Kundin oder beim Kunden befindet. Die Reaktionszeit von Dritten können wir nicht kontrollieren, weshalb sie für uns auch nicht relevant für das Gelingen eines Sprints ist. Mögliches Feedback wird dann später als eigene Aufgabe definiert, neu geschätzt und in einem der nächsten Sprints umgesetzt. Schwieriger ist es, wenn Kundinnen und Kunden gerade bei Funktionieren einer Anwendung keine Rückmeldung mehr geben und Vorgänge unnötig lange geöffnet bleiben. Hier hilft dann meist nur gezieltes Nachfragen.
3. Zum Schluss
Wir streben nach einer Arbeitsatmosphäre, die sich produktiv und bereichernd anfühlt. Uns ist daher wichtig, die Arbeitsstrukturen an unsere Bedürfnisse anzupassen, neue sinnvolle Aspekte aufzunehmen und dafür andere wieder zu verabschieden, wenn sie keinen positiven Effekt zeigen. Agiles Arbeiten hilft uns dabei, eine bessere Organisation und Struktur zu finden. So werden nach und nach Kapazitäten frei, die wir nutzen, um auch eigene Projekte voranzutreiben. Allerdings richtet sich Scrum in seiner Standardausführung eher an Teams, die gemeinsam an einem einzigen großen Projekt arbeiten. Abweichungen bei den Voraussetzungen führen demnach zu Abweichungen bei der Adaptierung. Scrum selbst hat dafür allerdings eine sehr geringe Toleranz. Das Urteil lautet dann: „They do something else, but not Scrum.“1 Dann sei es so. Schließlich muss es für uns funktionieren. Aber inspiriert sind wir allemal.
Learnings
- Stop starting, start finishing ist nicht generell umsetzbar, aber grundsätzlich erstrebenswert.
- Scrum-Rollen werden von uns tendenziell übernommen, sind aber nicht scharf abgegrenzt.
- Handlungsmöglichkeiten unterscheiden sich im Team je nach Person und Domäne, Transparenz ist daher wichtig.
- Das Arbeiten in Sprints von gleicher Länge und mit wenigen, verbindlichen Meetings funktioniert für uns gut. Verbindliche Scrum-Elemente wie das morgendliche Stand up behandeln wir unverbindlich, wenn sie dem Team keinen Mehrwert bieten. Ebenso erlauben wir uns ein gewisses Maß an Flexibilität bei Änderungen am Sprint Backlog.
- Storypoints funktionieren für uns gut, denn sie nehmen den Druck, der an zeitliche Schätzungen gebunden ist. Doch gelten sie bei uns bereits dann als erledigt, wenn das Ergebnis zum Testen an Kundinnen und Kunden übergeben wurde.
- Die Abhängigkeit von Dritten bleibt eine Herausforderung. Feedback von Kundinnen und Kunden muss manchmal aktiv eingefordert werden.
- Scrum und Agile sind für uns eine wertvolle Inspiration, aber wir streben bei der Umsetzung nicht nach Perfektion.
1Ignacio Paz. Agile & Scrum in Depth: Guide, Simulation and Best Practices. Udemy.com. 2021.