Global menu

Our global pages

Close

Scrum unter Einbeziehung von Fremdkräften – wie agil kann das noch sein? (Teil 2)

  • Germany
  • Employment law

17-07-2019

Im ersten Teil dieses Beitrags wurde die Scrum-Methode an sich vorgestellt. Nachfolgend wird nun dargestellt, wie Fremdkräfte in diesen agilen Prozess eingebunden werden können:

II. Die Umsetzung der agilen Prozessschritte unter Einbindung eines externen Dienstleisters

Die arbeitsrechtlichen Herausforderungen beginnen, wenn ein Unternehmen (Auftraggeber) einen externen Dienstleister (Auftragnehmer) über einen Werk-/Dienstvertrag in die agilen Prozesse einbinden möchte. Zunächst ist es immer eine Option, das ganze Projekt outzusourcen. Dies ist oftmals aber nicht gewollt, denn die einzelnen Unternehmen sollen ihr jeweiliges Spezial-Know-how einbringen. Diese Unternehmen oder Einzelpersonen – speziell aus der IT-Branche – möchten zudem oftmals selbständig tätig bleiben. Aber auch in anderen Branchen ist es aus Kostengründen nicht unüblich, gewisse Arbeitsumfänge fremdzuvergeben.

Wie im ersten Teil dieses Beitrags beschrieben, finden einige Prozessschritte im agilen Arbeiten gemeinsam über alle Feature-Teams hinweg statt. Ein arbeitsteiliges Zusammenarbeiten ist aber zwischen eigenen Arbeitnehmern und Fremdkräften aufgrund der Gefahr einer Eingliederung mit allen ungeliebten Rechtsfolgen zu vermeiden. Insofern gilt es, die bisherigen arbeitsrechtlichen Prinzipien mit der agilen Arbeitswelt zu verknüpfen und neue Lösungsräume zu eröffnen:

1. Herausforderung – gemeinsame Erarbeitung von Aufträgen

Im Scrum-Modell sind die einzelnen Feature-Team-Mitglieder grundsätzlich entsprechend ihren Qualifikationen austauschbar und somit wechselseitig einsetzbar. Die Teams werden immer wieder neu zusammengesetzt, um insbesondere Spezial-Know-how in bestimmte Teams einzubringen. Dies ist mit den Fremdkräften in dieser Form nicht möglich. Da in den Teams während eines Sprints der tatsächliche Auftrag (Ticket) bearbeitet wird, läge ein erhebliches Indiz eines arbeitsteiligen Zusammenwirkens – und damit für eine Eingliederung – vor.

Der Auftragnehmer hat aber die Möglichkeit, komplett eigene Feature-Teams zu stellen und diese ausschließlich mit eigenen Arbeitnehmern zu besetzen. Diese Teams bearbeiten dann jeweils ihre eigenen Tickets. Ein Wechsel zu einem Team des Auftraggebers ist hierbei jedoch grundsätzlich nicht möglich.

2. Herausforderung – Weisungen durch den Product Owner

Die Funktion des Product Owner spielt ebenfalls eine wichtige Rolle. Sollte dieser den Fremdkräften konkrete arbeitsrechtliche Weisungen im Projekt erteilen können, läge ein deutliches Indiz für eine Eingliederung vor. Auf den ersten Blick wirkt der Product Owner auch wie ein Vorgesetzter aller am Projekt beteiligten Personen. Dies ist aber in der agilen Arbeitswelt gerade so nicht vorgesehen. Oftmals wird in der „realen Welt“ zwar auch eine Führungskraft des Auftraggebers als Product Owner eingesetzt sein, doch darf diese gerade keine Vorgesetztenfunktion, weder disziplinarisch noch fachlich, gegenüber den Feature-Team-Mitgliedern innehaben. Dies würde die Kreativität des agilen Modells deutlich hemmen.

Insofern ist hier das Scrum-Modell nicht das „Problem“, sondern sogar die Lösung. Die Herausforderung ist nicht die Anpassung des Modells, sondern die konsequente Umsetzung des Modells in der Praxis. Ein Monitoring dieser konsequenten Umsetzung – d.h. ohne Weisungen – sieht das Modell im Übrigen selbst vor: Die Scrum-Master prüfen in der Retrospektive die Einhaltung der Spielregeln. Insofern hat das agile Arbeitsmodell quasi seinen systemimmanenten Compliance Officer.

3. Herausforderung – gemeinsame Regel-Meetings

Im Backlog Refinement und im Sprint Planning müssen alle Personen gemeinsam die Anforderungen in Ticketgröße schneiden und anschließend ein entsprechendes Ticket „ziehen“. Im Sprint Review werden die Ergebnisse der Teams allen Personen gemeinsam vorgestellt – quasi wie auf einer Messe. Diese gemeinsamen Meetings von Mitarbeitern des Auftraggebers und des Auftragnehmers stellen jedoch ein Indiz einer Eingliederung dar, da alle Personen miteinander über einen längeren Zeitraum zusammenwirken – teilweise bis zu einem Tag pro Meeting. Darüber hinaus erarbeitet der Auftragnehmer seinen eigenen Auftrag, was einer im Werkvertrag ansonsten üblichen Leistungsbeschreibung widerspricht.

Um dieses Zusammenwirken und damit die Gefahr einer Eingliederung möglichst auszuschließen, kann ein Steuerungsteam als sogenannter „Brückenkopf“ eingesetzt werden. Dieses Team besteht aus Mitarbeitern des Auftraggebers und kann in allen Meetings vor Ort sein. So wählt es zum Beispiel im Sprint Planning die Tickets für die Feature-Teams des Auftragnehmers aus. In einem zweiten Schritt führt dieses Steuerungsteam gemeinsam mit den Feature-Teams des Auftragnehmers im Anschluss an die jeweiligen Regelmeetings des Scrum-Prozesses ein eigenes Backlog Refinement, Sprint Planning und Sprint Review durch, in denen nur Mitarbeiter des Auftragnehmers teilnehmen und die „üblichen“ Scrum-Prozesse durchführen. Hierdurch entsteht zwar ein zeitlicher Mehraufwand, der aber auch bei anderen Werkvertragskonstellationen nicht unüblich ist.

Risikoreicher, aber mit weniger Aufwand verbunden, ist es, wenn die Mitglieder des Steuerungsteams nicht vom Auftraggeber, sondern vom Auftragnehmer gestellt werden. Die Mitglieder dieses Teams nehmen an den Regelmeetings des Auftraggebers teil und definieren die Tickets gemeinsam mit den Mitarbeitern des Auftraggebers. Sollte diese risikoreichere Variante gewählt werden, sollten die Anzahl der Mitglieder des Steuerungsteams deutlich begrenzt werden. Unserer Ansicht nach ist diese Variante jedoch nur eingeschränkt zu empfehlen, insbesondere sollte das Scrum-Modell dann an weiteren Stellen modifiziert werden.

III. Weitere Gestaltungsmöglichkeiten

Eine weitere Option, mit anderen Unternehmen zusammenzuarbeiten, ist die Arbeitnehmerüberlassung. Hier können die Leiharbeitnehmer frei in den jeweiligen Feature-Teams eingesetzt werden und auch an allen Regelmeetings teilnehmen, da Leiharbeitnehmer grundsätzlich in die Organisation des Entleihers eingegliedert sein dürfen. Doch müssen dann auch alle Restriktionen des Arbeitnehmerüberlassungsgesetzes eingehalten werden. Dies ist teilweise aus Kostengründen nicht gewollt oder aufgrund der Laufzeit komplexer Entwicklungsprojekte nicht darstellbar. Insofern kann die Arbeitnehmerüberlassung jedoch beim Einkauf von zeitlich begrenzt nutzbarem Spezial-Know-how eine Lösung sein.

Wollen zwei Unternehmen langfristiger zusammenarbeiten, ist auch die Gründung eines Gemeinschaftsbetriebs eine Möglichkeit. Dabei muss beachtet werden, dass neben der agilen Struktur dann auch eine einheitliche Leitung mit fachlichen und disziplinarischen Befugnissen eingerichtet werden muss. Dabei hat die Gründung eines Gemeinschaftsbetriebes aber beispielsweise weitere, oftmals ungewünschte finanzielle Auswirkungen. Die kollektivrechtlichen Auswirkungen sind zudem gerade bei Unternehmen unter „ihresgleichen“ nicht gewollt – oder wer will auch schon fremde Arbeitnehmer in seinem Wirtschaftsausschuss sitzen haben?

Ein neuer Lösungsansatz ist jedoch auch die agile Projektentwicklung selbst. Wie im ersten Teil dargestellt, dürfen in agilen Arbeitsmethoden – anders als beim sogenannten Wasserfallmodell – keine disziplinarischen Weisungen erteilt werden. Insofern ist es im agilen Modell durchaus darstellbar, dass die Mitarbeiter sich unter einem „Dach“ zu den Regelmeetings treffen und anschließend aber wieder in den eigenen Betrieben die einzelnen Tickets abarbeiten. Diese Form des Zusammenwirkens empfiehlt sich gerade für Kooperation unter „Equal-Playern“, die schlussendlich am Ergebnis der Kooperation auch teilhaben. Hier gilt es dann jedoch – wie immer –, andere Spielregeln zu beachten.

Einen ausführlichen Beitrag zu diesem Thema finden Sie auch in der Schnellinformation für Personalmanagement und Arbeitsrecht (Nr. 7 / 2019).

For more information contact

< Go back

Print Friendly and PDF
Subscribe to e-briefings