Scrum ist nichts für HR? Doch! – Ein Erfahrungsbericht

Inspiriert von ersten Erfahrungen mit agilen Methoden beschäftigte ich mich im letzten Jahr intensiver mit dem Scrum Framework, einem agilen Projekt- und Produktmanagementansatz, der vorrangig in der Softwareentwicklung genutzt und gelebt wird, aber seinen Weg langsam auch in andere Funktionsbereiche bahnt. Auch wenn ich in meiner Rolle als Personalentwicklerin zunächst nicht genau wusste, wozu ich es gebrauchen könnte, nutze ich meine Motivation am Thema und ließ mich online über scrum.org zum Scrum Master zertifizieren. Keine leichte Prüfung, aber mit ein bisschen Pauken bekommt man es gut hin. Die Frage war nur, was ich nun mit meiner neuen Zertifizierung anfangen kann.


Ich wusste, dass meine Chefin immer offen ist für neue Ideen und Experimente im Team. Unser Team hatte erst kürzlich Zuwachs bekommen und wir standen vor neuen Herausforderungen in der Abstimmung und Prioritätensetzung, weil es nicht mehr möglich war, sich täglich bilateral abzustimmen. Auch die Aufgabenvielfalt und die Zusammenarbeit mit vielen verschiedenen Stakeholdern länder- und funktionsübergreifend macht die Arbeit nicht nur spannend, sondern verlangt auch einen hohen Organisationsaufwand. Wir benötigten einen Ansatz zur Teamorganisation, -koordination und -abstimmung, welcher den Herausforderungen gerecht wird und uns zudem ermöglicht, unsere eigenen Themen und Veränderungen proaktiv voranzutreiben und nicht reaktive Opfer von „höheren Mächten“ zu sein.


Meine Idee: Lasst uns Scrum ausprobieren. Die Antwort des Teams: Warum nicht.

So setzte ich mich hin und überlegte mir, welche Elemente des Scrum Frameworks für uns Sinn machen und wie wir die Idee von Transparenz, Inspektion und Adaptation für uns nutzen können.


Auch wenn die Personalentwicklung auf den ersten Blick nicht so viele Gemeinsamkeiten mit der Softwareentwicklung hat, konnte ich viele Parallelen finden, die für die Nutzung von Scrum sprachen. Die Grundidee ist, in kurzen iterativen Abschnitten, sogenannte Sprints, zu arbeiten, sodass man eine realistische kurzfristige Planung machen kann, Feedback von Stakeholdern frühestmöglich einholt und flexibel mit sich verschiebenden Prioritäten umgehen kann. Auch ist das Ziel, nach jedem Sprint ein fertiges Produktinkrement zu haben, welches (falls gewünscht) freigegeben werden kann. Das ist ein großer Vorteil zu einer bisher häufig gelebten Praxis, in der man meistens über einen langen Zeitraum hinweg parallel an zu vielen Themen arbeitet und am Ende zu wenig fertig bekommt. Was bedeutete die Umsetzung des Scrum Ansatzes jetzt für uns konkret?


Zunächst bauten wir unser Product Backlog auf, indem wir alle Tasks, Stories und Ideen für das Jahr 2019 auf verschiedenen Detaillevels in einer Liste sammelten. Diese Liste ist dynamisch, d.h. neue Dinge entstehen und Bestehende verändern sich in ihrer Ausprägung und Priorisierung. Anstatt für das ganze Jahr oder für jedes einzeln laufende Projekt einen großen Projektplan zu haben, der spätestens ab dem zweiten Monat über den Haufen geworfen werden muss, einigen wir uns auf Zwischenziele in kleinen Etappen. Bei uns dauert ein Sprint einen Monat. Am Anfang des Monats machen wir unser Sprint Planning, d.h. wir entscheiden gemeinsam im Team, auf welche Sprintziele wir uns für den folgenden Monat verpflichten möchten. Der initiale Vorschlag wird vom Team noch einmal kritisch hinterfragt, denn aus den Learnings der vorherigen Monate wissen wir, dass wir uns hier leicht überschätzen. Danach geht es in die Detailplanung, d.h. was bedeutet es konkret, welche Tasks wir in unseren Monthly Sprint Backlog bearbeiten und wer sich um welche Aufgaben kümmert. Damit haben wir einen klaren, abgestimmten Plan, der uns für den kommenden Monat die Richtung gibt.


Um uns während des Sprints bzgl. des aktuellen Status abzustimmen, haben wir uns für zwei Standup Meetings pro Woche (die ich deshalb nicht Daily nennen sollte) entschieden. Unser virtuelles Board zeigt an, welche Items noch im Sprint Backlog des Monats sind, welche auf „Doing“ und welche auf „Done“ stehen. Die klassischen Fragen „Was hast du seit dem letzten Standup gemacht“, „Was machst du heute“ und „Gibt es irgendwelche Hindernisse bei deiner Arbeit, wo wir dir helfen können”, werden pro Teammitglied besprochen. In meiner Doppelrolle als Scrum Master und Teammitglied fällt es mir leider etwas schwer, mich aus den inhaltlichen Diskussionen herauszuhalten und auf Disziplin und eine 15minütige Time Box, wie es in Scrum vorgegeben ist, zu achten. Hier haben wir noch expliziten Verbesserungsbedarf.


Am Ende eines jeden monatlichen Sprints, treffen wir uns im Team zu den beiden Events (Events = Meetings im Scrum) Sprint Review und Sprint Retrospective. Im Review schauen wir uns noch einmal im Detail an, was wir im Sprint erreicht haben und wo wir mit den einzelnen Produkten und Aufgaben stehen. Update und Feedback sowie nächste Schritte werden direkt festgehalten, wobei Letzteres auch direkt ins Product Backlog übergeht, damit diese beim Sprint Planning für den nächsten Monat berücksichtig werden können.

In der Retro nehmen wir uns dann die Zeit, auf unsere Zusammenarbeit im vergangenen Sprint zurückzuschauen mit dem Ziel, Zu identifizieren was wir für die Zukunft noch verbessern können. Typische Fragen, die wir gemeinsam beantworten sind: Was hat gut funktioniert? Wo gab es eher Probleme/ Hindernisse? Was können wir in Zukunft besser machen? Bei der Retro sind der Kreativität keine Grenzen gesetzt, z.B. kann man eine Teamwetterkarte anfertigen, eine Aufstellung im Raum machen oder von den Teilnehmern selektierte Fotografien sprechen lassen. Für die Gestaltung von Retrospektiven findet man sehr viele Ideen online. Insbesondere für die Punkte, die wir heute in der Retro besprechen, haben wir uns früher kaum Zeit genommen, da man doch häufig nur auf Aufgabenebene aber nicht auf der Ebene der Zusammenarbeit reflektiert und Actions ableitet. Auf der Metaebene zu beleuchten, wie wir im Team arbeiten und uns weiter zu einem High Performing Team entwickeln können, ist aus unserer Erfahrung sehr wertvoll investierte Zeit.


Am Anfang gab es noch ein bisschen Zweifel, ob wir die große Anzahl an Meetings (Planning, Standups, Review, Retro) überhaupt brauchen. Zuvor haben wir uns jedoch mindestens einmal die Woche in mindestens zweistündigen Meetings aufgehalten, um uns irgendwie zu koordinieren. Die Rechnung hat den Beweis geliefert - mit dem Scrum Setup sind wir sogar schlanker aufgestellt und holen mehr aus der investierten Zeit heraus. Insbesondere zum Sprintwechsel ist die Meeting-Häufigkeit etwas intensiver und das gesamte Team muss auch involviert sein. Dafür brauchen wir dann während des Sprints viel weniger Abstimmung.


Auch wenn wir keine langfristige Detailplanung machen, einigen wir uns auf Jahresziele, um das große Ganze, die Vision der Abteilung, nicht aus dem Auge zu verlieren. Agil bedeutet nicht, nicht zu planen, sondern so weit voraus zu planen, wie man in einer sich ständig ändernden, komplexen Welt vorausplanen kann. Der Ansatz ist, sich in kleinen Schritten nach Vorne zu tasten, um ein schnelles Testen und Lernen zu ermöglichen und fatale Fehlentscheidungen sowie Fehlinvestitionen zu vermeiden. Ziel ist außerdem, sich von Sprint zu Sprint auch kontinuierlich in der Planbarkeit, Effizienz und Zusammenarbeit zu verbessern.


Ich bin total froh, den Vorschlag für die Scrum Einführung in unserem Personalentwicklungs-Team gemacht zu haben. Nach nur vier Monaten Erfahrung mit der Methode, können wir sicher sagen, dass wir uns abgestimmter fühlen und dass wir am Ende eines Sprints stolz darauf sind, was wir geschafft haben. Das ist nur möglich, weil wir uns die Zeit nehmen, über Inhalt und Zusammenarbeit zu reflektieren. Engpässe werden schneller erkannt, sodass Umpriorisierung ohne Probleme möglich ist. Jeder im Team fühlt sich informiert darüber, an was der andere arbeitet. Und als positiver Nebeneffekt erkennen wir schneller gegenseitige Abhängigkeiten und Überschneidungen unserer Aufgaben, um auch hier wiederum den Austausch zu verstärken und Doppelarbeit zu vermeiden. Nicht zuletzt unterstützt das Vorgehen die Selbstorganisation und das Selbstmanagement im Team. Denn wenn wir gut auf unsere Ziele abgestimmt sind und die gegenseitigen Erwartungen kennen, ist es viel einfacher, Verantwortung zu übernehmen und alleine loszulaufen. Der wahrgenommene Gestaltungsspielraum hat im Team einen zusätzlichen Motivationsboost ausgelöst!


Es gibt sicher noch einiges, was wir verbessern können. Mit unsere Sprintplanung sind wir meistens doch zu optimistisch und rechnen den hohen Prozentsatz an spontanen und operativen Aufgaben nicht ein. Hilfreich könnte sein, in Zukunft eine Schätzung von Storys und Aufgaben zu machen, um sich hier noch intensiver über den Aufwand auszutauschen. Ein weiterer wichtiger Schritt wäre zudem, auch unsere Stakeholder stärker insbesondere in die Reviews einzubeziehen und das Kernteam zu erweitern. Erste Versuche, weitere Personen einzubeziehen, scheiterten jedoch. Die Idee wurde abgetan mit der Begründung „Scrum passt nicht auf HR“.


Ich sage „Doch, Scrum passt sehr gut“. Es geht nicht darum, zwanghaft jedes Detail zu übernehmen, aber die Leitgedanken und das Framework für sich so anzupassen, dass man einen Nutzen daraus zieht. Und vielleicht einfach mal auszuprobieren und agil zu sein, wenn man merkt, dass man mit bisherigen Methoden nicht mehr so weit kommt. Ich kann nur jeden dazu ermutigen, ähnliches in den Teams, egal welcher Fachbereich, auszuprobieren. Zumindest für Bereiche, die entwickelnd und in Projekten tätig sind, kann Scrum mit Sicherheit ein effektives Vorgehen für die Teamarbeit sein.


Ich bin überzeugt, dass wir hier in unserer Abteilung eine Vorreiterrolle einnehmen können. Unsere Aufgabe sollte sein, den Erfolg weiter in die Organisation zu tragen und hoffentlich andere Bereiche mit Scrum oder anderen agilen Vorgehensweisen „infizieren“ zu können. Wir brauchen keine groß angelegte agile Transformation, wenn wir einfach iterativ auch in der Organisation experimentieren und uns selbst mehr Veränderung zutrauen.

0 Ansichten0 Kommentare

Aktuelle Beiträge

Alle ansehen