Teams as a Service

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.

Wir wissen es und du weißt es auch: Ein neues Entwicklungsteam aufzubauen ist hart. Der Personalmarkt ist leergefegt, Wechselwillige schwer zu finden, und professionelle Recruiter können daran auch nicht viel ändern. Dabei hättest du ein spannendes Projekt, könntest gleich mehreren Talenten langfristige Perspektiven bieten und wärst bereit, Himmel, Hölle und Obstkörbe in Bewegung zu setzen, damit das neue Team sich in seiner Umgebung wohlfühlt.

Mag sein, dass das etwas zu schwarz gemalt ist – aber ich bin sicher, viele Unternehmerinnen und Unternehmer im IT-Bereich kennen diese Herausforderung so oder so ähnlich.

Aber kennen sie auch die Lösung für das Problem?

Geld allein ist noch keine Lösung

Freilich kannst du viel Geld auf dein Problem werfen. Damit kaufst du vielleicht kurzfristig ein paar Entwicklerinnen und Entwickler ein. Eventuell strengen sich auch die Recruiter mit steigenden Prämien proportional mehr an. Per Arbeitnehmerüberlassung findest du unter Umständen sogar noch ganz andere Wege, um Talente zumindest mal für eine Übergangszeit zu verpflichten.

Das alles kann eine Lösung sein. Es kann sogar deine Lösung sein. Am Ende hast du aber noch lange kein Team, sondern eine Handvoll Arbeitsverträge mit Ablaufdatum – und Angestellte, die ihr Hauptaugenmerk aufs Gehalt richten. Solange das für dich okay ist, super! Ich mach' dir aber einen noch viel besseren Vorschlag: Teams as a Service.

Was genau ist ein „Team as a Service“?

Wir bieten dir als Teams as a Service ein fertig zusammengestelltes Team an Entwicklerinnen und Entwicklern, das optimal aufeinander eingestellt ist und crossfunktional von Frontend und UX bis Backend und KI alle Bereiche abdeckt, die für dich relevant sind. Es ist ab Tag 1 startklar und kann sofort die Arbeit aufnehmen. Wichtig zu verstehen: Ein solches Team ist weder Auftragsdienstleister, noch kommt es per Arbeitnehmerüberlassung zu dir. Nein, es nimmt dein Projekt wie ein eigenes an – und integriert sich so in dein Unternehmen, als wäre es ein natürlicher Teil davon.

Klingt vielleicht im ersten Moment nach schön formulierten Worten aus der Marketingabteilung, aber darin stecken eine Menge Vorteile für dich, dein Projekt und dein Unternehmen – und sogar für die Menschen in einem solchen Team:

• Keine langen Einarbeitungszeiten – alle neuen Teams durchlaufen einen mehrere Monate andauernden Kennenlern- und Einarbeitungsprozess. Wann ist das Team ein Team? Danach!
• Keine Ablenkungen – ein „as a Service“-Team kümmert sich um exakt eine Aufgabe: dich. Fokus? Könnte größer kaum sein!
• Kein „Hallo, bist du neu hier?“ – unsere Teams as a Service bleiben über mehrere Projekte hinweg langfristig bestehen. Motivation und Harmonie? Check.
• Kein „Das haben wir immer schon so gemacht!“ – ein Team as a Service arbeitet selbstorganisiert und agil; und auch wenn das manchmal unbequem scheint: Die Entwicklerinnen und Entwickler darin verstehen es als eine ihrer Kernaufgaben, deine Vorgaben zu challengen. Software Craftsmanship ist für sie kein Modewort, sie alle halten Clean Code wenn schon nicht für die schnellste, mittel- und langfristig aber immer für die wirtschaftlichste Art zu entwickeln. Bedeutet für dich? Bestmögliches Ergebnis.

Wer steckt hinter dem Angebot?

Was befähigt uns, dir ein so unverschämt gut klingendes Angebot zu machen, woher kommt die Expertise? Gut, dass du diese Fragen stellst – ich würde mir sonst ernsthaft Sorgen machen! BRANDAD ist ein mittelständisches Unternehmen mit fast 25 Jahren Erfahrung in Sachen Software-Entwicklung. Seit 2010 arbeiten wir agil, seit 2020 gibt es unser Teams-as-a-Service-Angebot, seit 2022 ist BRANDAD eine Unternehmensgruppe mit einer übergeordneten Aktiengesellschaft und zwei Unternehmenstöchtern. Wir sind eine lernende Organisation mit einer gesunden Fehlerkultur, mit ganz wenig Hierarchien und umso mehr Selbstorganisation, mit viel „Wir wollen!“ und fast ohne „Ihr müsst!“

Unsere Teams arbeiten sehr selbstständig und mit engem Kundenkontakt. Sie treffen alle wichtigen Entscheidungen selbst. Damit das funktioniert, geben wir den einzelnen Menschen viele Freiräume, einschließlich fester Lernzeiten, festem Budget für die Weiterentwicklung, einer ausgiebigen Teamfindungs- und Einarbeitungsphase vor dem ersten Kundenprojekt. Die Investition in Mensch und Team zahlt sich für uns aus, weil die Teams auch nach Ende von Projekten weiter zusammenbleiben. Für die Auftraggebenden bedeutet das: Mit „Teams as a Service“ erhalten sie Zugriff auf top motivierte Coderinnen und Coder, die sich mit Eifer und ganz viel Expertise auf deine Entwicklungsaufgaben stürzen.

Klingt spannend? Dann sag gerne einfach mal „Hallo“. Oder du lernst Team High Five in unserer „Teams as a Service“-Videoreihe kennen:

Erinnert ihr euch noch, als vor wenigen Monaten KI noch keine Erdbeeren zählen, keine ganz gefüllten Rotweingläser und Menschen nur mit einer Fingeranzahl ungleich 10 darstellen konnte? Those were the times! Irgendwie wussten damals alle, dass KI unser Geschäft mal noch richtig aufmischen würde ... aber wie genau, das wusste noch niemand. Und heute? Sieht es auch noch nicht viel besser aus. 

Aber.

Uns war früh schon klar: Wir müssen KI-Expertise aufbauen. Oder ins Haus holen. Uns war aber auch klar: KI-Expertise ist auf dem Arbeitsmarkt so etwas wie die blaue Mauritius. Der weiße Wal. Seltener als eine Woche ohne „Trump hat etwas Dummes gesagt!“-Nachrichten. So rar wie ein Cybertruck ohne Produktionsmängel.

Also waren wir selbst gefragt, die Weichen für die Zukunft zu stellen. Und unterwegs wollten wir möglichst viel Erfahrung mit KI sammeln, dabei aber so nahe wie möglich an der Forschung und Entwicklung dranbleiben. Gleichzeitig standen und stehen wir als Dienstleister unter Druck zu beweisen, dass wir KI-Projekte umsetzen können. Geht nicht, ohne tiefgehende KI-Expertise? Geht wohl! Zumindest wenn wir uns nicht auf die Innerein der LLM & Co. fokussieren, sondern auf den Part, mit dem wir uns bestens auskennen: Web-App-Projekte mit Front- und Backend.

Okay, Moment mal! Das Klingt ja voll nach: Die haben überhaupt keine Ahnung, machen aber trotzdem irgendwas mit KI ... so wie alle Anderen halt auch, oder?

Eben nicht.

Was uns fundamental von den Heerscharen an KI-Goldgräbern unterscheidet, die in den vergangenen 12 Monaten auf den Markt gestürmt sind: Wir haben das AN[ki]T im Rücken – den KI-Lehrstuhl der Fachhochschule Ansbach. Und als deren Projektpartner haben wir gemeinsam mit und für den Lehrstuhl ein komplettes KI-Projekt umgesetzt. Mit LLM, Servern und Ressourcen direkt aus dem FH-Rechenzentrum sowie Frontend-, Backend-, UX-, RE-, QA- und Testing-Know-how von einem unseren crossfunktionalen BRANDAD-Teams.

Vorhang auf für Vectorsphere!

Die Idee zu Vectorsphere entstand in der KI-Fachschaft in Ansbach aus dem Wunsch heraus, übliche Arbeitsschritte beim Vermarkten des (großartigen!) hauseigenen Knowledge Science-Podcasts mit KI zu automatisieren oder wenigstens stark zu vereinfachen. In der Regel ist nach der Aufnahme ja bereits guter Content vorhanden, liegt jedoch für die Massenvermarktung im einem unpassenden Medium vor (Audio) und eignet sich so auch nur für einen von vielen möglichen Kanälen (Podcast-Feed). KI to the rescue!

Unser Team hat Frontend und Backend um bestehende Transkriptions- und Such-API herum gebaut. Also einerseits eine ansehnliche, robuste, gut bedienbare Oberfläche – andererseits die Datenströme von und zum Rechenzentrum der FH, wo dann teilweise lang laufende Hintergrundprozesse angestoßen wurden. Im Gespann haben wir also ein Tool entwickelt, das erst mal ganz simpel klingt: Du suchst nach einem Podcast und markierst einige Episoden, die transkribiert werden sollen; als Antwort liefert Vectorsphere nach einer Weile dann handliche Content-Schnipsel, um das Marketing für diese Episoden zu vereinfachen. Darunter beispielsweise Postvorlagen für einen LinkedIn-Beitrag. Und wie bei allem, was zum Schluss simpel klingt und anmutet, war hierfür eine Menge Planungs- und Umsetzungsarbeit notwendig!

Wir werden doch noch zu einer KI-Bude!

Von null auf KI in Rekordzeit – dabei haben wir viel gelernt. Wir kamen ja ohne viel KI-Domänenwissen, dafür mit ordentlich Neugier, Entschlossenheit und Erfahrung in komplexen Webprojekten.

Unsere stärksten Aha-Momente:

• Kooperation rockt: Das AN[ki]T hat uns nicht nur Server und KI-Wissen geliefert, sondern als Auftraggeber die unterschiedlichen Kernkompetenzen unseres Teams sehr gut gemanaged.
• KI ist kein Hexenwerk, wenn man die richtigen API nutzt. Die Magie passiert zwar im Hintergrund – für uns hieß das aber vor allem, zu verstehen, welche Bausteine es gibt und wie sie zusammenspielen ... und trotzdem nebenher eine Menge über KI zu lernen.
• Frontend ist nicht nur Fassade. Usability ist mehr als ein paar Buttons, die wir am Ende der App-Entwicklung auf eine Backend-API werfen. Ist die Führung der Nutzenden durch die Anwendung nicht straight und durchdacht, interessiert es auch niemanden, wie smart die KI ist, die im Backend die Grafikkarten zum Schmelzen bringt.
• Kommunikation und Learning by Doing: Um aus einem Prototypen eine funktionierende Lösung zu entwickeln, ist viel Abstimmung, Fragen, Rückfragen, Fehlversuche, Communityeinbindung und noch mehr Abstimmung notwendig. Software-Projekte mit und ohne KI sind am Ende auch immer Kommunikationsprojekte.

Warum Vectorsphere nicht öffentlich, doch aber mehr ist als nur ein Prototyp.

Es steckt viel Arbeit in Vectorsphere, und es ist schon ein bisschen schade, dass daraus am Ende kein Produkt für die breite Öffentlichkeit geworden ist. Was uns aber persönlich so stolz macht: Wir haben gezeigt, dass man mit guter Teamstruktur, klarer Rollenverteilung und dem Willen, Neues zu lernen, Projekte auch mit (noch) unbekannten Technologien gut stemmen kann. Die Schlussfolgerung: Solange der Kunde mit dem Technologie- und Domänenwissen eng mit uns im Team arbeitet, lässt sich das alles lösen, Selbstorganisation sei dank. Denn: Hätten wir alle Anforderungen, Aufgaben, Pakete et cetera auch noch intern abstimmen müssen, wäre das Projekt sicher auf der Strecke irgendwo verhungert. So aber haben wir es innerhalb eines Jahres erfolgreich zum Abschluss gebracht.

Und das bringt uns zurück zum Podcast-Hören: Vielleicht steckt in eurem Lieblingspodcast ja viel mehr als nur Blabla – und Vectorsphere ist nur der Anfang, um das Hörbare auch sichtbar(er) werden zu lassen.

Klonkrieger schießen immer daneben und Begeisterungsfähigkeit wird überschätzt – was wir daraus über moderne Teamarbeit lernen, erfahrt ihr in Folge 2 von ZUSAMMEN WACHSEN.

In dieser Episode dreht sich alles um die Essenz von Teamarbeit. Wir beleuchten die verschiedenen Rollen, die Teammitglieder einnehmen können, und diskutieren, wie individuelle Stärken und Schwächen zu einer harmonischen Zusammenarbeit beitragen. Dabei reflektieren wir vor allem auch über die Bedeutung von Humor, Entscheidungsfreude und Sozialkompetenz im Teamkontext.

Hier ist Christians Fragebogen: 

Alle Episoden von ZUSAMMEN WACHSEN findet ihr in den üblichen Podcast-Verzeichnissen, direkt im Feed, oder hier bei uns im Blog.