Global menu

Our global pages

Close

Agiles Arbeiten und Fremdkräfte - Ist das überhaupt möglich? (Teil 1)

  • Germany
  • Employment law

15-05-2019

Agiles Arbeiten ist in aller Munde. Während diese Arbeitsweise früher vor allem in der IT genutzt wurde, bedienen sich mittlerweile immer mehr Unternehmen verschiedenster Branchen dieser Form der Zusammenarbeit. Aus arbeitsrechtlicher Sicht wird es gerade dann spannend, wenn in diesen Prozess auch noch andere Unternehmen oder Selbständige eingebunden werden sollen. Denn Kern der agilen Arbeitsweise ist das zwar strukturierte, im Wesentlichen aber kreative und nur schwer abgrenzbare Zusammenwirken aller Beteiligten. Insofern muss es klare Spielregeln geben, um die Risiken einer Scheinselbständigkeit oder einer verdeckten Arbeitnehmerüberlassung zu minimieren.

I. Die Scrum-Methode

Scrum ist einer der agilen Prozesse für Softwareentwicklung und wird mittlerweile auch für das Projektmanagement im Allgemeinen genutzt. Der Scrum Prozess kenn drei wesentliche Rollen: den Product Owner, den Scrum Master und die Feature-Teams. Der Arbeitszyklus an sich, der sog. Sprint, wiederholt sich alle vier Wochen. Der Ablauf des Sprints ist durch immer wiederkehrende Regeltermine geprägt.

1. Der generelle Ablauf:

In einer Liste (Product Backlog) werden Anforderungen des späteren Produkts aufgenommen, ergänzt und priorisiert, d.h. die Eigenschaften des zu entwickelnden Produkts werden aufgelistet. Dabei können alte Anforderungen entfernt und neue hinzugefügt werden.

Diese Anforderungen werden in einem ersten Schritt in größere Themen (Epics oder User Storys) und diese dann wiederum in einzelne, kleinere Tickets “geschnitten“. Das Herunterbrechen und das Abarbeiten dieser Tickets erfolgt in einem fest definierten Zyklus- dem sog. Sprint. Dieser wiederum ist klar strukturiert und gliedert sich in folgende Schritte: das Product Backlog Refinement, das Sprint Planning, das Sprint Review, die Retrospective und den eigentlichen Entwicklungsprozess, d.h. die Ticketbearbeitung an sich.

2. Die einzelnen Arbeitsschritte:

Am Anfang eines Sprints muss das Produkt im Product Backlog Refinement gepflegt und weiterentwickelt werden. In diesem Schritt bringen der Product Owner, die Scrum Master und alle Feature-Teams gemeinsam das Backlog auf den aktuellen Stand. Zweck des Backlog Refinements ist, die Anforderungen so weit herunterzubrechen, dass sog. Tickets entstehen, die möglichst in einem Sprint abschließend bearbeitet werden können. Aus klassischer Sicht kann man hier davon sprechen, dass die einzelnen Aufträge entstehen.

Wurden die Tickets, d.h. Aufträge definiert, findet das Sprint Planning statt. In diesem Schritt, der ebenfalls gemeinsam zwischen dem Product Owner, den Scrum Mastern und über alle Feature-Teams hinweg gemeinsam stattfindet, wird entschieden, welche der im Product Backlog Refinement erstellten Tickets aus dem Product Backlog im Sprint bearbeitet werden sollen. Jedes Feature-Team übernimmt die Bearbeitung einer vorher definierten Anzahl an Tickets, was auch im Product Backlog festgehalten wird. Hierin kann man wiederum die klassische Auftragsvergabe sehen.

Der Product Owner „entscheidet“ hier allein, welche konkreten Tickets im Sprint bearbeitet werden, d.h. er legt die Reihenfolge nach deren Wichtigkeit fest. Das jeweilige Feature-Team entscheidet aber, welche konkreten Tickets von ihm bearbeitet werden, d.h. jedes Team „zieht seine Tickets“ selbständig. Eigenständig (ohne äußere Einflüsse z.B. des Product Owners) planen die Teams unter sich sodann, wie die von ihnen gezogenen Tickets bearbeitet werden.

In den darauffolgenden Tagen eines Sprints werden die Tickets von den Teams selbständig bearbeitet. Im sog. Daily Scrum, einem täglichen Teammeeting von ca. 15 Minuten, werden die aktuellen Arbeitsstände innerhalb eines Teams ausgetauscht. Dabei geht es vor allem darum sich darüber auszutauschen, wie der aktuelle Bearbeitungsstand der Tickets ist.

Am Ende des Sprints steht das Sprint Review. In diesem Treffen stellen die Feature Teams dem Product Owner die bearbeiteten Tickets vor. Dieser prüft, welche Tickets tatsächlich erfüllt wurden und setzt diese auf „done“– in klassischer Hinsicht handelt es sich damit um die Abnahme. Tickets, die nicht vollständig bearbeitet werden konnten oder die geändert werden mussten, werden wieder in das Product Backlog aufgenommen. Am Ende des Meetings können anwesende Stakeholder bzw. der Product Owner ihr Feedback zum Zwischenprodukt einbringen. Daraus entstehen ggf. neue Tickets, die wiederum in das Product Backlog eingespeist werden.

Die Sprint Retrospective schließt den Zyklus ab. In dieser Besprechung steht nicht, wie in den vorherigen Meetings, das Produkt im Vordergrund, sondern die eigentliche Arbeitsweise der Teams. Es wird ausschließlich besprochen, was während des Sprints in arbeitstechnischer Hinsicht positiv verlief und was ggf. verbessert werden kann. Hierdurch soll die agile Arbeitsweise kontinuierlich verbessert werden.

3. Die verschiedenen Aufgaben:

Der Product Owner ist für den Erfolg und die Erreichung der wirtschaftlichen Ziele des Projekts verantwortlich. Er repräsentiert, bündelt und priorisiert die Items, um am Ende das Projekt zum Erfolg zu führen. Er ist verantwortlich für die ständige Aktualisierung der Anforderungen und Priorisierungen im Product Backlog und nimmt beim Sprint Review das Entwicklungsergebnis ab. Wichtig ist, dass der Product Owner in die eigentliche Bearbeitung der Tickets durch die Feature-Teams nicht eingreift; er steht an zentraler Stelle, um den Projekterfolg zu sichern, greift in die tatsächlichen Arbeitsprozesse jedoch - anders als eine Führungskraft im Wasserfallmodell - nicht ein.

Das Feature-Team ist für die Bearbeitung der Tickets zuständig. Dabei besteht ein solches Team aus mehreren, beispielsweise sieben Personen. Die Organisation des Teams erfolgt „aus sich selbst heraus“. Es bestimmt während des Sprint Plannings, wie viele Tickets aus dem Product Backlog entnommen werden, ermittelt die dazu notwendigen Aktivitäten/Aufgaben und schätzt den Aufwand ab. Dabei gibt es innerhalb der Teams keine Hierarchie.

Jedem Feature Team gehört ein Scrum Master an. Er ist Moderator und Coach und sollte möglichst keine Personalverantwortung für die Feature-Team Mitglieder innehaben. Er fördert Prozesse, moderiert Besprechungen und unterstützt das Team. Ihm kommt aber keine Steuerungsfunktion in disziplinarischer Hinsicht zu, d.h. er soll ausschließlich Hilfestellungen leisten.

In Teil 2 dieses Beitrags stellen wir - aufbauend auf den gerade dargestellten Grundsätzen der Scrum-Methode - die Einbindung von Fremdkräften in diese agile Arbeitsweise dar. Einen ausführlichen Beitrag zu diesem Thema finden Sie schon jetzt in der Schnellinformation für Personalmanagement und Arbeitsrecht (Nr. 7 / 2019) https://beck-online.beck.de/?vpath=bibdata%2fzeits%2fSPA%2f2019%2fcont%2fSPA%2e2019%2e53%2e1%2ehtm

For more information contact

< Go back

Print Friendly and PDF
Subscribe to e-briefings