Das kleine „Was ist Was“ der Leiharbeit – und warum wir völlig neue Konzepte brauchen

Es klingt so verlockend: Du hast ein Software-Entwicklungsprojekt, aber nicht die entsprechende Personaldecke – und statt nun den Kickoff einmal mehr ins nächste Quartal zu verschieben, holst du dir einfach Unterstützung von außen. Was aber führt am besten, was am kosteneffektivsten und was am nachhaltigsten zum Ziel? Arbeitnehmerüberlassung oder Zeitarbeit? Agenturunterstützung, Auftragsentwicklung oder Personaldienstleister?

Psssst, kleiner Spoiler: keines der Genannten.

Investition und Aufwand, um neue Arbeitskräfte oder externe Agenturen zu briefen, sind immens hoch – aber das lässt sich, sofern die Not groß genug ist, alles noch irgendwie vertreten. Das viel größere Problem wird hingegen oft ausgeblendet: In gängigen Auftraggeber-Dienstleister-Verhältnissen schneiden sich Dienstleister ins eigene Fleisch, wenn sie ihre Arbeit zu gut erledigen. Oder, anders ausgedrückt: Schlechter Code ist ein Geschäftsmodell. Solange die Mindestanforderungen auf dem Papier erfüllt werden, führt minderwertige Software-Entwicklung letztendlich zu mehr beauftragten Arbeitsstunden, und womöglich sogar zu teuren Anschlussverträgen. Versteh mich bitte nicht falsch: Die wenigsten agieren hier böswillig, das Problem schlummert bereits im Konzept. Gute Code-Dokumentation und Test-Abdeckung stehen eben oft nicht mit entsprechender Priorität im Lastenheft.

Klingt deprimierend? Ziemlich. Kann das nicht vielleicht auch anders gehen? Definitiv!

Ein kurzer Exkurs zu den Begrifflichkeiten

• Zeitarbeit: Bei Zeitarbeit wird Arbeitskraft über einen spezialisierten Vermittler für einen befristeten Zeitraum vermittelt. Arbeitnehmende unterzeichnen Arbeitsverträge bei der Verleihfirma, die dann im Rahmen einer „Arbeitnehmerüberlassung“ Angestellte als Dienstleistung vermittelt. Die Agentur für Arbeit sagt: „Zeitarbeit (Arbeitnehmerüberlassung) ist eine Möglichkeit, die Zeit zur nächsten Festanstellung zu überbrücken“. Auch wenn es Zeitarbeit in allen Farben und Formen gibt, sind fast 50 Prozent der vermittelten Tätigkeiten einfache Hilfsarbeiten.
• Mitarbeiterüberlassung: Bei der Mitarbeiter- oder Arbeitnehmerüberlassung werden Angestellte für einen festgelegten Zeitraum an anderes Unternehmen vermittelt. Der Verleiher wird damit faktisch zum Vermittler – und hier liegt auch der Unterschied zur Zeitarbeit, wo üblicherweise drei Parteien involviert sind.
• Personalleasing/Leasingarbeit: Diese Begriffe werden in der Regel synonym mit „Zeitarbeit“ verwedet.
• Temporärarbeit: Der Begriff ist ebenfalls gleichbedeutend mit Zeitarbeit – wenn auch üblicherweise eher in der Schweiz und in Liechtenstein.
• Leiharbeit: Große Überraschung – auch diese Bezeichnung wird meist synonym mit „Zeitarbeit“ verwendet. Der Begriff „Leihe“ ist jedoch an dieser Stelle nicht ideal. Denn: „Leihe“ bezeichnet üblicherweise eine kostenlose, zeitweise Überlassung von Sachen, die im gleichen Zustand dann auch wieder zurückgegeben werden.

Die Alternative? Teams as a Service!

In unserer Software-Entwicklungs-Branche sind klassische Zeitarbeitsmodelle vielleicht nicht so üblich wie anderswo. Auftragsentwicklungen, Arbeitnehmenden-Überlassungen und Beauftragungen von Freelancern sind es dafür umso mehr – mitsamt den oben beschriebenen (und noch einigen anderen) Herausforderungen.

Bei BRANDAD gehen wir einen anderen Weg, weil wir gelernt haben, was Unternehmen wirklich brauchen, wenn sie sich externe Entwicklungsunterstützung ins Haus holen: Flexibilität. Qualität. Ein Team, das wie ein internes Team funktioniert und arbeitet. Und das im Dreieck aus Kosten, Zeit und Qualität hart auf Qualität und Zeit hin optimiert. Das mag in Folge (augenscheinlich) nicht die günstigste Variante sein, um externe Entwicklungspower ins Haus zu holen. Die Rechnung sieht unterm Strich und mit allen Folgekosten in der Regel aber recht positiv aus.

Das reicht vielleicht schon als Argument für Teams as a Service, aber da ist noch mehr: Wir haben gelernt, wie agile Entwicklungsteams ticken, und was jede und jeden Einzelnen darin motiviert. Kurz- und langfristig. Wir setzen dabei auf Selbstorganisation, Weiterbildung, auf widerstandsbasierte Konsensfindung ... vor allem aber auf Menschen. Wir bauen Teams nicht projekt- oder auftragsweise. Wir sind überzeugt, dass Menschen am besten und effektivsten in Umgebungen arbeiten, in denen zwar Projekte und Tools regelmäßig wechseln, nicht aber die unmittelbaren Kolleginnen und Kollegen.

Motivierte Entwicklerinnen und Entwickler, perfekt aufeinander abgestimmt – das zahlt sich für unsere Kunden aus, und dafür nehmen wir gerne eine große Anfangsinvestition in Kauf: Wir machen die Teammitglieder vor dem ersten Projekt mehrere Monate lang miteinander vertraut und schwören sie aufeinander ein. Wir entwickeln sie fortlaufend weiter. Und wir binden sie stark in ihren eigenen Wachstumsprozess mit ein.

Was aber hält nun ein solches Team davon ab, dir mit schlechtem Code unzählige abrechenbare Arbeitsstunden oder teure Wartungsverträge aus den Rippen zu leiern? Zum Beispiel Tatsache, dass du es dabei nicht mit Keyaccountern oder Vertrieblern zu tun hast. Dass es nicht die Schlussrechnung, sondern dein Projekterfolg ist, woran wir uns am Ende messen lassen. Dass das Team sich in deine Organisation einfügt, als wäre es dein internes Team. Mit viel Selbstreflektion und noch mehr Selbstorganisation schauen wir konsequent nach innen – um nach außen für dich bestmöglich zu wirken. Weil die Teammitglieder motiviert sind und darauf brennen, geile Arbeit abzulieferen, und es auch zu schätzen wissen, nach einem sauber abgeschlossenen Projekt zur nächsten Herausforderung weiterzuziehen.

Kurzum: Mit Teams as a Service vermieten wir dir keine Software-Entwickelnden – wir verkaufen dir Flexibilität.

Geht es noch etwas konkreter? Was ist „Teams as a Service“ genau?

Teams as a Service ist unser erprobter Ansatz, um Entwicklungspower zeitweise ins andere Unternehmen zu bringen – so weit nicht ungewöhnlich. Warum es dann aber am Ende doch nicht viel mit Leiharbeitsmodellen gemein hat, lässt sich gar nicht in einem Punkt zusammenbringen; also versuchen wir's mit vier:

• Das Dev-Team ist bereits kampferprobt. Die Mitglieder haben in der Regel bereits mehrere interne und externe Projekte gemeinsam bestritten.
• Das Team ist crossfunktional und ideal aufeinander abgestimmt. Dank hohem Grad an Selbstorganisation und „Lernen“ als wichtigem Grundpfeiler in unserem DevOS identifiziert das Team etwaige Lücken selbst – und schließt sie entweder durch vorausschauende Weiterbildung oder durch Aufstocken.
• Das Team kommt exklusiv(!) zu dir, und arbeitet für dich wie deine internen Teams: Es bleibt dein Prozess, dein Sprint, deine Backlogs, deine Tickets. Volle Transparenz, volle Integration. So geht kein Wissen verloren. So fällt nichts zwischen die Ritzen. Plus: Wir arbeiten agil, jedoch nicht dogmatisch – wir verstehen es nicht als unsere Aufgabe, Andere zu bekehren. Agilität ist für uns ein Werkzeug, keine Religion.
• Das Team hat Corporate-Erfahrung. BRANDAD mag ein IT-Mittelständler sein, aber wir kennen die Großen aus dem Automotive-, Industrie-, Versicherungs- und Steuerumfeld. Wir wissen, was interne Organisationsanweisungen sind. Wir wissen, welche Strukturen in Konzernen wie starr sind. Und wir bringen immer wieder respektvolle Impulse, wie Entwicklung in einem solchen Kontext trotzdem leichtfüßig, agil und lösungsorientiert sein kann.

Um dir einen Zahn gleich zu ziehen: Steht dein Projekt kurz vor der Deadline und ist aufgrund von Ressourcenmangel zum Scheitern verurteilt, kann dich Teams as a Service (wahrscheinlich) auch nicht mehr retten. Wir sind keine Projektfeuerwehr. Aber wir können mit dir gemeinsam verhindern, dass es im nächsten Projekt soweit kommt – oder dass dein Projekt bereits vor dem Startschuss in die Keine-Ressourcen-Falle schlittert. Let's talk!

Und falls du als Software-Entwicklerin oder Scrum-Master das hier liest und dir denkst „Hey, das klingt wie ein Umfeld, in dem ich gerne arbeiten möchte!“ – let's talk, too.