Anmelden

Neue Arbeitswelt im Recruiting-Team: Von klassisch zu Scrum

Autor*innen: Nastassja Deutsch
Datum: 17.06.2021
Lesedauer: 10 Minuten

Was seinen Ursprung in der Softwareentwicklung hat, ist mittlerweile in aller Munde: An „Agilität“ kommt man nicht mehr vorbei. Von vielen immer noch als modisches Buzzword belächelt, ist agiles Arbeiten aus den Tech-Konzernen dieser Welt längst nicht mehr wegzudenken – und wird nun auch bei uns im Team HR DPT Solutions gelebt.

Fotos der Kolleg*innen zur Darstellung des Teamaufbaus

BU: Der Aufbau unseres Scrum-Teams HR DPT Solutions

Im Recruiting der DKB hat sich in den letzten Jahren viel getan: Der steigende Bedarf an Tech-Talenten brachte einen immer höheren Bedarf nach Spezialisierung und Fokussierung mit sich, sodass Anfang 2019 ein erstes kleines Tech-Recruiting-Team gegründet wurde. Die Kolleg*innen arbeiteten zu Beginn in klassischer Organigramm-Struktur. Mit dem steigenden Fachkräftebedarf unseres Bereichs Digital Products & Technology (DP&T) ist auch unser Team Stück für Stück auf bis zu 7 Kolleg*innen mit verschiedenen Rollen angewachsen. Und unser Zusammenarbeitsmodell brauchte dringend ein Update.

Veränderung: Warum und wohin?

Der Arbeitsablauf im Recruiting kurz erklärt: Nach der Genehmigung der zu besetzenden Stelle werden Anforderungen an die Stelle zusammengetragen und ein Anforderungsprofil erstellt. Die Suche nach Kandidat*innen läuft später sowohl klassisch über unsere eigenen Bewerbungskanäle als auch über Active Sourcing (also über Direktansprache insbesondere via Social Media). Was hier sehr einfach klingt, kann in Wirklichkeit – vom Vorbereiten der Suche bis zur Einstellung – ein langwieriger Prozess sein. Mit unserer klassischen Arbeitsweise hatten wir schon alle Effizienzpotenziale ausgeschöpft. Und die sich ändernden Anforderungen und Rahmenbedingungen unseres Tech-Umfelds erhöhten die Dynamik noch weiter. Was das bedeuten kann? Dass z.B. die Anforderungen an eine Stelle nachträglich geändert werden müssen, obwohl wir die Kandidat*innensuche schon gestartet hatten. Das Resultat: Ein verändertes Profil, die Neuausrichtung der Suche und zusätzlich benötigte Kapazitäten. So haben wir gemerkt: In einer hochfluiden VUCA-Welt können wir nicht unabhängig und langfristig planen. Wir brauchen ein – zeitlich festgestecktes – gültiges Commitment zur Suche von Kandidat*innen. Zusätzlich wollen wir für unsere Kund*innen und Stakeholder auch transparent mit Sonderthemen rund um das Recruiting umgehen. An Relevanz bekommen hat das Thema „agiles Framework“ bei uns dann im Januar 2020. Wir wollten uns verändern! Und hatten unsere Ziele dabei deutlich vor Augen:

  • klarere Prioritäten
  • Fokus auf bestimmte Ziele und transparentere Kommunikation – intern im Team und mit Kund*innen und Stakeholdern 
  • Reduzieren von kurzfristigen thematischen Kehrtwenden bzw. bewussterer Umgang damit.
     

Wichtig war uns dabei, Mensch und Team über die – selbstauferlegte – Veränderungsnotwendigkeit und Methode zu stellen. Uns war klar: agiles Framework ja – aber auf unsere Art und Weise.
Doch welcher Ansatz passt zu uns und unserer Arbeit? Um das rauszufinden, haben wir uns zwei agile Methoden – Scrum und Kanban – genauer angeschaut. Teile des Kanban-Modells hatten wir in der Vergangenheit bereits genutzt – insbesondere für das bessere Tracking des Bewerbungszyklus und des Kandidat*innenstatus. Allerdings ist das Modell für „agile Einsteiger*innen“ schwieriger umzusetzen, als beispielsweise Scrum. Zudem wollten wir mit konkreten Vereinbarungen von (Teil-)Zielen innerhalb kürzerer, festgelegter Zeiträume arbeiten.

Nach ausreichend Überlegungen stand deshalb unser Favorit fest. Das Scrum Framework hat uns vor allem durch den Sprint-Charakter und die gelebte Transparenz überzeugt. Klare Erwartungs- und Kapazitätensteuerung, transparentes Arbeiten und Kommunizieren, gemeinsame Verlässlich- und Verbindlichkeit sowie der feste Zeithorizont sind nur einige Vorteile der Methode. Was ist die Besonderheit bei „unserem“ Herangehen an Scrum und was unser Anspruch? Wir wollen gar nicht die 1a-Lehrbuch-Anwendung umsetzen. Uns geht es darum, genau die Elemente auf unsere Arbeitsweise zu übertragen, die am besten zu uns und unseren Zielstellungen passen. Das agile Mindset steht für uns an erster Stelle. Wir haben die wichtigsten Pfeiler der Methode übernommen, erlauben es uns aber auch mal, den festen Scrum-Pfad zu verlassen.

Mittendrin statt nur dabei: Unser Transformationsprozess

Auf die Plätze, fertig los. Nicht ganz. Seit Anfang 2020 unterstützen in der DKB die Change Coaches unsere Teams oder Fachbereiche projektbezogen bei der agilen Transformation und weiteren Veränderungsvorhaben. Ein großes Glück für uns: Wir erhielten Support von Julia als Change Coach. Ihr erstes Projekt war die Begleitung unserer Transformation. Durch ihre Erfahrungen aus dem IT-Projektmanagement und als Scrum Master war sie die perfekte Mentorin für unser Vorhaben.

Die gemeinsame Vorbereitung für die Umstellung lief grob in 3 Schritten:

Schritt

Das Scrum Framework kennenlernen, verstehen und verinnerlichen. Testen, Fragen stellen, zusammen Antworten suchen.

Schritt

Die Erkenntnisse auf unsere Bedürfnisse des Recruitings übertragen und die passenden Elemente identifizieren.

Schritt

Das Wissen und Verständnis an das Team weitergeben und näherbringen.

Unsere Kund*innen einbinden, Workflows definieren und Rollen annehmen

Neben unseren eigenen Bedürfnissen war uns natürlich ebenso das Feedback unserer „Kund*innen“ aus dem Bereich DP&T wichtig. So haben wir z.B. gemeinsam den Status Quo im Recruiting analysiert und Prozesse detailliert aufgezeichnet. Wo können wir ansetzen? Welche Abhängigkeiten gibt es? Wo sind unsere Abläufe so individuell, dass wir ggf. vom klassischen Scrum abweichen müssen? Wie lässt sich der gesamte Prozess in unser Kollaborations-Tool umsetzen? Und wie binden wir regelmäßig unsere Kund*innen ein und sorgen für Transparenz?

Wir wollten unsere künftige Arbeit eng an das Kollaborations-Tool „JIRA“ knüpfen. Dabei hatten wir folgende Vorteile im Kopf: festgelegte Workflows, klare Zuständigkeiten, Dokumentation und Transparenz. Wir haben also wesentliche Workflows (z.B. Veröffentlichung von Stellenanzeigen oder Spezialthema) identifiziert und im Tool angelegt: So sollten wirklich alle Aufgaben und Auslastungen sichtbar werden. Den neu angelegten Prozess haben wir dann immer wieder getestet und nochmal angepasst. Am Ende können wir sagen: Wir haben ihn genau so gebaut, wie er für unsere Recruiting-Needs aussehen musste.

Um agile Arbeitsweisen erfolgreich umzusetzen, sind klare Verantwortungen (Rollen) und hierarchieunabhängige, kurze Abstimmungen essentiell. Ebenso darf die Zuversicht, diese neuen Rollen auszufüllen und zu leben, nicht fehlen. Gemeinsam haben wir folgende Rollen vergeben und uns im Team auf das Ausfüllen vorbereitet: Scrum Master, Product Owner (PO) und das Development Team (unsere Recruiting-Kolleg*innen).

Ausgestaltung der Sprints

Viele Teams aus dem Tech-Bereich sprinten in Zyklen von zwei Wochen. Aus den Erfahrungen des Recruitings heraus war uns klar, dass dies für unsere Aufgaben zu kurz ist. Rechnet man alle Einzelaufgaben im Recruitingprozess zusammen (u.a. Bewerbersuche, Interviews, Freigaben), sind 14 Tage zu knapp bemessen bzw. die Zielsetzungen werden zu granular. Deshalb haben wir uns für Sprintzyklen von 4 Wochen entschieden. Durch die langen Sprints und somit weniger Sprint-Wiederholungen bestand zwar die Gefahr, dass wir uns langsamer an die neue Form der Zusammenarbeit gewöhnen würden. Dies haben wir jedoch bewusst in Kauf genommen.

Zusammengefasst lässt sich zur Transformation und der Vorbereitung hin zum agilen Team sagen:

  • Wir brauchten etwa 4 Monate, um den Umstieg auf Scrum für uns vorzubereiten.
  • Wir arbeiten in 4 Wochen Sprints. Dabei beginnen wir mit der Sprintplanung und enden mit der Sprint-Retrospektive
  • Alle Themen landen zunächst im Backlog und werden anschließend (vom PO) priorisiert und in Sprints bearbeitet
  • mittels JIRA bilden wir sämtliche Arbeitsabläufe ab und erfassen unsere Fortschritte

Erleben der Umstellung

Im Juni 2020 haben wir den Schalter dann umgelegt: Recruiting goes agile! Eine richtige Übergangsphase gab es nicht. Trotz Start in Pandemiezeiten und der Remote-Arbeit hatten wir keine großen Schwierigkeiten dabei. Wir haben bewusst einen relativ harten Schnitt gemacht: ausschließlich laufende Recruitingprozesse wurden noch im alten Umfeld beendet. Nach der ersten Sprintplanung direkt in den ersten Sprint. Die strikte Trennung war hilfreich - vor allem durch das schnellere Gewöhnen an die neuen Formate und die andere Art der Zusammenarbeit.

Das war natürlich an mancher Stelle ungewohnt. Den Aufwand der einzelnen Aufgaben (Tickets) treffsicher zu bewerten, fiel uns anfangs nicht leicht. Wir haben diese Unsicherheit gelöst, indem wir die Methode „Planning Poker“ genutzt haben. So lassen sich Aufwände bzw. Komplexität einfacher und vor allem aus verschiedenen Sichtweisen einschätzen. Am Anfang brachte die Umstellung natürlich vieles auf einmal. Auf der einen Seite waren wir total enthusiastisch, auf der anderen Seite gab es eine Menge Veränderungen: die neuen Formate, die veränderten Arbeitsweisen, die neuen Rollen und natürlich auch die Änderung des eigenen Vorgehens und Verhaltens. Es ist nicht immer einfach, nicht in „alte Muster“ zu verfallen. Mit ein wenig Übung, dem Durchführen von Retrospektiven und dem Lernen aus gemachten Erfahrungen, verschwinden die Unsicherheiten jedoch schnell. Um dies zu beschleunigen hilft vor allem eins: offen sein und ausprobieren! Die meisten unserer Meetings moderiert unsere Scrum Masterin – allerdings übernimmt manchmal jemand aus dem Team, sodass alle ein noch besseres Gefühl für die Formate entwickeln.

“Umstellungsschmerzen“? Kaum zu spüren

Die Umstellung vom klassischen Team hin zu Scrum war ein echter Mammut-Prozess. Aber uns war klar: Transformation bedeutet Veränderung und Bewegung. Bewegt haben wir uns viel auf dem Weg zum agilen Team – und sind daran extrem gewachsen.

Eine große Sorge, dass sich auch bei unseren Stakeholdern „Umstellungsschmerzen“ bemerkbar machen würden, hat sich nicht bewahrheitet. Ganz im Gegenteil: Die Offenheit während des Veränderungsprozesses und die frühe Einbindung aller Parteien machten unseren Change hin zu Scrum nicht nur einfacher. Die neue Arbeitsweise hat an vielen Stellen auch zu mehr gegenseitigem Verständnis und engerer Verzahnung geführt. Von der erhöhten Transparenz über Aufgaben und Arbeitsfortschritte profitieren heute alle Seiten.

Teamgeist gestärkt, Planbarkeit erhöht

Mit Scrum erleben wir die Abstimmung im Team und mit unseren internen Tech-Kund*innen als noch ausgeprägter und effizienter. Und wir sind deutlich selbstorganisierter geworden. Als Team sind wir weiter zusammengewachsen, man spürt eine hohe Motivation und starkes Commitment für unsere gemeinsamen Ziele. Das zeigt sich immer wieder auch in unserer Retrospektive: Offenes und direktes Feedback fällt uns leichter als früher. Und sollte einmal etwas im Argen sein, kommen wir schneller wieder „back on track“.

Der genauere Überblick über alle Aufgaben lässt uns besser und sicherer planen. Die Verantwortung für die eigenen Themen wird angenommen. Und auch mögliche Stolpersteine fallen seit der Umstellung deutlicher auf – wir können sie außerdem schneller und besser beheben. Die technische Komponente, die Nutzung von JIRA, ermöglicht uns zudem – fast nebenbei – eine automatische Dokumentation. Wenn ein*e Kolleg*in ausfällt, können wir dringende Themen so gut auffangen.

Zettel mit persönlicher Wertung der Zusammenarbeit im Team werden in die Kamera gehalten

BU_Digitale Retrospektive im Team

Von Fallstricken und Aha-Momenten

Scrum bedeutet vor allem eins: Disziplin. Und das nicht nur in der Umstellungs- und Eingewöhnungsphase, sondern auch im „Regelbetrieb“. Die im Scrum-Framework stark aufeinander abgestimmte Arbeit bringt hohen Kommunikationsbedarf mit sich, der in unterschiedlichen Regelterminen (wie z.B. Daily, Review oder Retro) strukturiert aufgefangen wird. Viele Meetings bedeuten hohen Zeitaufwand. Darum stellen feste Abläufe und strikte Regeln einen hohen ROI, im Sinne schneller und eindeutiger Gesprächsergebnisse, sicher. Ist man hier inkonsequent, werden Termine schnell wieder zu „Plauderstunden“ – der Mehrwert für die eigene Arbeit sinkt, das Vertrauen in die Methode ebenfalls.

Und was wir noch bemerken: Der Spagat zwischen Ad-hoc-Anforderungen und dem agilen Arbeiten ist nicht immer leicht. So gilt eigentlich, nach Sprintstart keine Themen mehr aufzunehmen. Wenn allerdings kurzfristig wichtige Anforderungen oder stark veränderte Rahmenbedingungen aufkommen, müssen wir diese spontan aufnehmen und bearbeiten. Gerade bei solchen Ad-Hoc-Themen ist eine zeitliche Einschätzung oftmals schwer zu treffen. Der worst case: die Bearbeitung geht zu Lasten der vorher gesteckten Sprintziele.

Und natürlich gab es auch Dinge, mit denen wir nicht unbedingt gerechnet haben: So haben wir z.B. gemerkt, an wie vielen Sonderthemen wir parallel arbeiten und wie viel wir dadurch in einem 4 Wochen-Sprint erledigen. Dabei spielt uns erneut die Nutzung von JIRA in die Karten: wir können Erfolge tracken und abrechnen. Es herrscht das positive Gefühl, viel zu schaffen – weil man deutlich sieht, was bereits erledigt ist.

Wo stehen wir heute?

Mittlerweile arbeiten wir nun schon ein Jahr agil. Kleinere und größere Herausforderungen gab es in den letzten Sprints natürlich immer wieder. An vielen Stellen leben wir das Scrum-Framework schon automatisch, an anderen Stellen muss es sich noch stärker etablieren. Das betrifft z.B. die Disziplin, die Sprint-Events im jeweils eigenen Rahmen zu belassen. Hier müssen wir uns manchmal noch gegenseitig bremsen (z.B., dass im Sprintreview keine Retro-Themen besprochen werden). Durch „agile games“ oder das Vorstellen von Artikeln zum Thema verinnerlichen wir das agile Mindset jedoch immer stärker. Zudem bedeutet die Abgrenzung der neuen Rollen und das Leben einer flachen Hierarchie auch eine Veränderung des eigenen Denkens. Diese kommt in den meisten Fällen nicht einfach von heute auf morgen. Hierarchien gibt es so nicht mehr - der PO hat beispielsweise nicht automatisch das letzte Wort.

Unterm Strich können wir allerdings sagen, dass die meisten unserer Erwartungen an Scrum in Erfüllung gegangen sind. Im klassischen Gefüge haben wir damals gemerkt, dass wir mit langfristiger Planung nicht weit kommen und uns die nötige Flexibilität fehlt. Das hat sich verändert. Wir stecken uns klare Zeiträume, in denen fest definierte Aufgaben erledigt werden. Kommen weitere Aufgaben dazu oder ändert sich der Fokus eines Tickets, werden diese Themen durch unseren PO in den Backlog gegeben. Diese Aufgaben landen dann in einem der nächsten Sprints. Die klare Priorisierung von Themen ist ein weiterer Vorteil. Anfangs haben wir uns in unseren Sprints auch mal zu viel vorgenommen. Aber auch das hat sich schnell gegeben. Mittlerweile arbeiten wir viel bewusster in Teilschritten und -projekten.

Durch die Arbeit mit JIRA und den regelmäßigen Formaten ist die teaminterne Auslastung deutlich ersichtlich. Gleiches gilt für die bearbeiteten Themen – voll nach dem Motto: maximale Transparenz. Für uns selbst – aber auch für unsere Kund*innen und Stakeholder, die jederzeit Einblick darauf haben, woran wir arbeiten

Wir hinterfragen dennoch regelmäßig, in wie weit unser Scrum-Framework zu uns und den (möglicherweise veränderten) Anforderungen an unser Team passt. Hier und da passen wir an. Dafür nutzen wir z.B. einmal im Quartal den „Spotify Health-Check“. Eine Methode, die hilft herauszufinden, wo das Team steht und Ableitungen für Verbesserungspotential zu treffen.

4 Tipps für (Recruiting-)Teams, die auf Scrum umstellen wollen:

 

Mutig sein & sich aus der Deckung wagen.

Der Weg hin zur vollständigen Umstellung ist intensiv und das Verinnerlichen des Scrum-Mindsets geschieht nicht über Nacht. Transformation braucht Zeit. Aber: Es zeigt sich auch schnell, dass der Weg sich lohnt – innerhalb des Teams aber auch für unsere Kund*innen und Stakeholder. Ladet diese Personen ein, an eurem Change-Prozess und den neuen Arbeitsformaten teilzuhaben! Bei uns sind das z.B. oft Stakeholder*innen (wir haben bereits Reviews gemeinsam mit unserem Tech-Vorstand gemacht) – aber auch Kolleg*innen aus anderen Einheiten, die agiles Arbeiten einmal live erleben möchten.

Sich vorab ausreichend Gedanken machen

Agiles Arbeiten ist in aller Munde. Es ergibt in unterschiedlichsten Umgebungen Sinn und birgt enorme Potenziale. Agile Teams arbeiten am Puls der Zeit. Aber: Überlegt vorher gut, ob und warum es für euer Team sinnvoll ist, sich agil aufzustellen. Sind eure Aufgaben und täglichen To-dos dafür geeignet? Welchen Mehrwert erhofft ihr euch von der Umstellung? Nur agil zu arbeiten, um agil zu arbeiten, bringt nicht die erhofften Ergebnisse.

Welche Methode passt zu uns?

Welches Ziel verfolgt ihr mit der Umstellung? Welches Framework passt am besten zu euch und eurer Arbeitsweise? Diese Frage sind gar nicht so leicht zu beantworten. Uns hat unser interner Change Coach bei der Beantwortung dieser Fragen unterstützt. Wir haben gelernt: Es ist möglich, das Beste aus verschiedenen Welten zu vereinen. Scrum gibt uns den Rahmen und wir nutzen viele Vorteile, die das Framework mit sich bringt.

Scrum braucht Disziplin

Wie schon geschrieben: Scrum hat sehr viel mit Disziplin zu tun. Darauf muss man sich einlassen können und wollen. Es bedeutet z.B., jeden Morgen zur gleichen Zeit mit dem Daily zu starten. Hierfür räumen wir täglich bewusst Zeit und Struktur ein. Das Format bringt uns alle weiter und zeigt außerdem Hindernisse und Themen auf, die wir gemeinsam viel effizienter lösen können. Wichtig ist: Gebt der Methode die Chance, sich zu entwickeln. Und gleichzeitig: Sucht bei Schwierigkeiten den Fehler nicht nur bei ihr.

Unser Gesamtfazit also?
Die Umstellung unserer Arbeitsweise auf Scrum war ein voller Erfolg. Was an vielen Stellen als Buzzword gilt, wird bei uns im Team auch im Recruiting mit vollster Überzeugung gelebt. Darauf sind wir stolz.


Arbeiten auf Augenhöhe in einer Bank mit Haltung: Schau auf unserem Jobportal nach Jobs und Einstiegschancen bei der DKB. Oder erfahre mehr über die Arbeit im Tech-Team.