Aber vielleicht erstmal von vorn. Wenn du heute den Fractional Developer buchen möchtest, dann geht das ganz einfach. Ein Kennenlerngespräch und Kapazitätscheck (Ein Platz ist stand heute noch frei). Danach bekommst du eine Rechnung für den bevorstehenden Monat, ein Trello-Board um deine Aufgaben an mich zu kommunizieren und dann geht’s schon los.

Easy.

Aber warte Mal: Fehlt da nicht etwas? Was ist denn mit Angebot, Bestätigung, Auftrag, Vertrag und. so. weiter.? Auf der Landing Page findest du auch keine AGB - was ist da los?

Ja, die gibt es nicht, und das ganz bewusst.

Ist das aber nicht sehr riskant?

Doch! Das ist auch das Thema, das unmittelbar nach der Vorstellung des Modells ausgiebig diskutiert wird. Aber das ganze hat einen ganz bewussten und bestimmten Grund.

Der Fractional Developer steht für Veränderung in vielerlei Hinsicht. In meinen vorherigen Beiträgen habe ich über Themen wie den Wandel am Arbeitsmarkt oder Effizienz vs. Effektivität geschrieben und angeschnitten wie der Fractional Developer hier frischen Wind reinbringt.

Heute tauchen wir tiefer in den Kern ein, genauer gesagt, in die gewünschte Auswirkung auf die Kultur bzw. die Entstehung einer neuen Kultur.

Der Haken: Kultur kann nicht "gebildet" werden. Sondern, bildet sich. Sie bildet sich durch Auseinandersetzungen und Diskussionen. Kultur ist ein Diskursprozess1.

Wo es aber einen festen Rahmen gibt, ist kein Raum für Diskurs. Wozu auch? Es wurde ja bereits über jede Kleinigkeit eine Einigung erzielt.

Ein Blick auf den Freelancer-Markt genügt, um dies zu verdeutlichen. Vermittlerfirmen sprießen aus jeder Ecke und jeder will ein Stück vom Kuchen abhaben. Unternehmen haben Richtlinien wie “Wir arbeiten nur mit Firmen ab Mio. Umsätze zusammen”. Möchte ein Freelancer Arbeit finden, so stehen ihm nur wenige Möglichkeiten offen. Entweder er geht das größtemögliche Verlusgeschäft ein (ANÜ) oder kämpft sich durch sämtliche Plattformen um ein Contracting Projekt zu kommen. Am Ende bekommt der Freelancer aber einen Vertrag (es wird eine Einigung erzielt), in dem alles schon geregelt ist und kann dann “endlich” loslegen.

Was aber in der Zwischenzeit passiert ist, ist stillstand. Stillstand weil dieser ganze Prozess von “Unternehmen muss eine Aufgabe erledigen” bis “Freelancer wird geeinigt” lange dauert. Es passiert das was wir in DE sehen können. Innovation bleibt aus, Bewegung findet nicht mehr statt und wir werden in allen möglichen Disziplinen abgehängt.

Wir befinden uns also mit dem Markt in einer Abwärtsspirale2.

Wenn wir uns also strategisch in einer Abwärtsspirale befinden und Kultur immer Strategie schlägt, dann kann eine neue Kultur die Lösung sein um wieder hochzukommen. Wenn Kultur nicht gebildet werden kann sondern sich nur über Diskurs bildet, dann braucht es Freiraum. Wenn AGB und Verträge Rahmen bilden, dann darf der Fractional Developer keine haben, denn sonst kann er nicht in Austausch mit seinen Abonnenten gehen, neue Rahmen bilden und eine neue Kultur bilden lassen.

Aber so ganz im freien Raum? Wirklich?

Jetzt abonnieren

Nein, natürlich ist das nicht der Fall. Am Ende des Tages haben wir das BGB - da ist schon sehr viel geregelt. Aber kann das das Ziel des Fractional Developers sein? Bei jeder Sache erstmal sich auf fundamentale Gesetze zu berufen und vielleicht sogar Anwälte beschäftigen? Nein, natürlich nicht! Das BGB gilt hier als Boden, die Luft die Abonnent und der Fractional Developer brauchen um nämlich folgedendes zu tun:

Über einen Handschlag (wenn auch Virtuell), mündlich einen Vertrag mit einander eingehen. Sich auf Augenhöhe begegnen und gemeinsam einen Rahmen bilden. Immer wieder diesen Rahmen überprüfen, anpassen und verfeinern. Oder auch grob lassen, weil grob an bestimmten Stellen, gut genug ist.

Also gilt für den Rahmen: So lose wie möglich und so spezifisch wie nötig.

An dieser Stelle bewährt sich das Agile Manifest wieder einmal und gilt als Inspiration. Gepaart mit den am Anfang erwähnten Diskussionen über das Geschäftsmodell nehme ich folgende Punkte mit für den Fractional Developer als Rahmen:

Deins und Dein Allein: Alles, was ich im Rahmen dieses Projekts kreiere, gehört dir.

Deine Geheimnisse sind bei mir sicher: Ich verspreche, alle geteilten Informationen streng unter Verschluss zu halten.

Solange es Spaß macht: Die Zusammenarbeit dauert an, solange sie für beide Seiten zufriedenstellend ist. Ja, das Abo kann jederzeit gekündigt werden. Bei Unzufriedenheit würde ich ein vorheriges Gespräch sehr schätzen, kurzfristig ist das auch möglich. Wenn die Kündigung planbar ist, weil dein Produkt einen gewünschten Stand erreicht hat, schätze ich eine langfristigere Ankündigung, um entsprechend planen zu können. Technisch gesehen läuft das Abo weiter, bis es gekündigt wird.

Kontinuierliches Feedback: Ich gebe stets mein Bestes, um einen zufriedenstellenden Zustand zu hinterlassen, mit dem jeder jederzeit weiterarbeiten kann. Doch deine Rückmeldung ist entscheidend. Wenn etwas mit der Dokumentation, der Code-Qualität oder irgendetwas anderem nicht stimmt, sag mir einfach Bescheid. Ich bin hier, um zu lernen und zu verbessern.

Zusammenfassend bedeutet das: Wir nützen uns immer. Wenn wir uns nicht mehr nützen und nicht mehr mögen, dann trennen wir uns. Aber das wichtigste: Wir reden immer miteinander.

Meine Beobachtung: Das Thema Effizienz vs. Effektivität hat eine riesige Auswirkung auf das ganze Purpose Thema. Heute spricht ja jeder und überall von Purpose. Klar, es ist eine andere Generation in der Mitte des Arbeitsmarktes und der aktuellen Generation ist das Thema Purpose sehr wichtig. Also Fragen wie “hat das was ich tagtäglich mache einen Sinn?”, “Stifte ich damit was gutes?” oder vielleicht eine Nummer kleiner “bekommt der Kunde denn überhaupt mit dass ich heute Code geschrieben habe?”

Man könnte jetzt argumentieren, “Blödsinn!” das muss doch nicht immer sein.

OK, aber wenn nicht immer, wieviel Purpose sollte es dann sein? Bzw. wieviel Sinnlosigkeit erträgt ein Entwickler? Aber in jedem Fall kann ich sagen, dass Entwickler sehr wohl mitbekommen wenn ihre Arbeit nicht effektiv ist. Wenn ihre Arbeit nicht beim Kunden ankommt.

Was darauf folgt, ist eine Negativspirale.

Entwickler entwickelt an Story X. Story X ist nichts effektives. Am Ende gibt es ein Button, der die Augen des Hundes der PM schont. Entwickler ist null motiviert. Entwickler hat bisher schon Buttons für alle Haustiere vom PM entwickelt und trödelt jetzt mit der Aufgabe. Daher kriegt Entwickler die Aufgabe zum Sprintende nicht fertig. Bei der Retrospektive heißt es dann natürlich “Wie können wir effizienter werden?” und damit geht die Spirale weiter.

Das Backlog - der Selbstzweck

In einem effizientem System gibt es ein Backlog. In diesem Backlog sind genügend Aufgaben für die nächsten drei Jahrzehnt. Viele von diesen Aufgaben sind auch ausdefiniert. Klar, muss ja effizient sein. Dazu gab es in der Vergangenheit Grooming 1-16 damit immer Arbeit vorbereitet ist.

Das Problem hier: Keine Aufgabe ist dringend. Denn ich würde argumentieren, dass wenn eine Aufgabe aus dem Backlog dringend wäre, entweder die Kunden “die Bude einrennen” würden oder die Aufgabe wäre schon längst erledigt.

Dieses Problem wird noch schlimmer, weil sich unsere Welt so schnell ändert.

Der nächste Punkt: Bis eine Aufgabe aus dem Backlog dran kommt um abgearbeitet zu werden, hat sich unsere aktuelle VUCA Welt ohnehin geändert oder der Kunde ist schon längst weitergezogen.

Also ist das Backlog per definition ein Parade Beispiel für Effizienz, jedoch nie für Effektivität. Weil das so ist, müssen wir anders über die Dinge nachdenken. Und es gibt schon ein paar gute Ideen dafür.

Es ist wahr. Irgendwo sind wir falsch abgebogen. Nicht Effizienz ist die Lösung, sondern Effektivität. Ja, so wie es auch Uwe sagt, es muss ein Umdenken stattfinden und ja, ich befürchte auch dass es ein weiter Weg ist. Aber es gibt Lösungsansätze. z.B. spricht von “Burn the Backlog”. Wie ich finde, ein echt zielführender Ansatz. Weil man dann immer wieder “raus” gehen muss und mit den Kunden sprechen muss um etwas zu bauen, was dann wieder aktuell, dringlich und zielführend für den Kunden ist.

Der Fractional Developer

Dann gibt es noch den "Fractional Developer". Der "FracDev" ist bis ins Mark effektiv.

Das fängt schon bei der Zielgruppe des "FracDev" an. Denn diese sind genau diejenigen, die Effektivität brauchen anstatt Effizienz. Der ideale Abonnent will die richtigen Ergebnisse, hat selbst keine Zeit, hat begrenzte Ressourcen und kann daher noch nicht wachsen. Ein Dienstleister kommt aber nicht in Frage, da zu teuer. Am liebsten würde der Abonnent die Aufgaben selbst erledigen.

Wenn dieser Abonnent und der "FracDev" erstmal zusammengekommen sind, geht die nächste Phase der Effektivität los. Denn der "FracDev" ist so unwissend wie möglich! Er macht keine Annahmen, um eine Zeile Code zu schreiben. Er erfindet nicht Anforderungen und er kann auch nicht ohne klare Anforderungen arbeiten, denn sonst müsste er ja wieder Annahmen treffen. Das heißt, der "FracDev" wird bei jeder Unklarheit wieder zum Abonnenten "laufen" und um Klarheit bitten. Das ist seine Stärke! Der "FracDev" erkennt Unklarheiten und weiß, dass das Ergebnis durch die kleinste Unklarheit völlig daneben gehen kann. Vor allem kann aber auch der Abonnent bei jeder Feedbackschleife nicht nur Unklarheiten lösen, sondern hat immer wieder die Möglichkeit, seine Kunden genauer kennenzulernen. Das löst der "Fractional Developer" aus. Bewusstsein über die Anforderungen und Wünsche des Kunden.

WIP=1

Was auf dem ersten Blick danach aussieht, dass sich da jemand Arbeit sparen will und nicht effizient ist, ist genau das, womit der "Fractional Developer" Effektivität erzwingt!

Denn mit WIP=1 kommt nicht nur weniger Arbeit, sondern auch zuallererst eine Priorisierung. Eine Priorisierung, bei der der Abonnent wieder an seine Kunden denken muss. Denn ist erstmal eine Aufgabe angefangen, wird sie auch zu Ende gebracht. Solange wird an nichts anderem gearbeitet bzw. an Effizienz geschraubt. Das erzwingt und erzielt Effektivität und genau das sind die Rahmenbedingungen, um mit dem "Fractional Developer" zu arbeiten.

Fazit

Es reicht nicht, nur an der Oberfläche zu kratzen. Vielleicht müssen wir die Rahmenbedingungen ändern, um wieder effektiv statt nur effizient zu sein. So finden wir Lösungen, die wirklich zeitgemäß sind.

Wir stehen vor einem massiven Fachkräftemangel in der Softwareentwicklung, und die Prognosen sind düster. Der Mangel wird in den nächsten Jahren weiter ansteigen. Warum? Weil Deutschland in Sachen Digitalisierung noch einiges nachzuholen hat. Wir sind bei weitem nicht da, wo wir sein sollten. Der Bedarf an Softwareentwicklern wird also unaufhaltsam steigen.

Der Engpass und die klassische Denkweise: Ein untauglicher Ansatz

In der klassischen Denkweise sehen wir einen Engpass bei den Softwareentwicklern und denken, wir könnten dieses Problem einfach lösen, indem wir mehr Softwareentwickler ausbilden, Quereinsteiger rekrutieren und die Einwanderung fördern. Aber ist das wirklich zielführend? Ich meine, nein! Die Dimensionen stimmen einfach nicht überein. Wir können nicht einfach mehr Ressourcen hinzufügen und erwarten, dass das Problem verschwindet. Das ist so, als würde man versuchen, einen brennenden Wald mit einem Eimer Wasser zu löschen.

Die versteckte Ineffizienz des Angestelltenverhältnisses: Der Fall Sophia

Nehmen wir Softwareentwicklerin Sophia als Beispiel. Sie wird von der Firma Future GmbH eingestellt und bleibt für die nächsten drei Jahre. Wird Sophia in dieser Zeit durchgehend mit wichtigen Aufgaben ausgelastet? Ich bezweifle es. Meine Erfahrung zeigt, dass Sophia unmöglich die ganze Zeit mit Aufgaben beschäftigt ist, die tatsächlich einen Nutzen für die Gesellschaft haben. Sie verbringt viel Zeit in Meetings, klärt Anforderungen und Aufgaben und ist in kulturellen Geschichten des Unternehmens involviert.

Der Kern des Problems: Die Ineffizienz des Exklusivvertrags

Das Problem ist, dass ein Softwareentwickler, der exklusiv bei einem Unternehmen unter Vertrag steht, generell und aus Prinzip schon eine Ineffizienz darstellt. Das Angestelltenverhältnis sollte im Fall der Softwareentwicklung bis zu einem gewissen Punkt, an dem vielleicht nicht mehr so ein riesen Bedarf herrscht, einfach aufgelöst werden.

Die Lösung: Mehrere Firmen, ein Entwickler

Wie wäre es, wenn ein Softwareentwickler mehreren Firmen gleichzeitig zur Verfügung steht? Denn wie weiter oben erwähnt, wird eine Sophia ohnehin nicht die ganze Zeit durchgehend effizient an Software arbeitet. Was, wenn man das alles weglässt? Was, wenn Sophia mit den heutigen Mitteln - verteilte und dauerhaft erreichbare Systeme, Asynchronität und KI - nur noch effizient Aufgaben erledigt? Und nur noch an den wichtigsten Aufgaben eines Unternehmens arbeitet? Dabei sogar mehrere Unternehmen voran bringen kann. Was wenn diese Ansätze direkt in die Rahmenbedingungen einer Zusammenarbeit gegossen werden, anstatt des Angestelltenverhältnisses?

Das Modell des Fractional Developers ist eine wohlüberlegte Reaktion auf die vielschichtigen Herausforderungen, die wir heute in der Softwareentwicklung sehen. In diesem Blog werde ich Details und Teilaspekte des Fractional Developers näher beleuchten und hoffe so eventuelle Stirnrunzler in Aha-Momente zu verwandeln.

Das klassische Angestelltenverhältnis ist in der aktuellen Marktlage nicht nur unpassend, sondern schädlich. Es ist Zeit, dass wir als Gesellschaft von innovativen Modellen profitieren, die uns als Ganzes voranbringen.