Warum ich heute meinen Klienten von agiler Softwareentwicklung abrate 

Fast alle waren skeptisch, aber – Hochachtung – sie haben es trotzdem probiert. Zwei Jahre später gab es in diesem Unternehmen nur noch Scrum.

Zu Recht. Scrum und andere agile Methoden und Frameworks lösen nicht alle Probleme, aber einige wesentliche. In den meisten Projekten sind die agilen Ansätze dem traditionellen Wasserfall-Vorgehen deutlich überlegen. Würde ich heute eine Software entwickeln lassen, würde ich es auch agil machen.

Warum also rate ich meinen Klienten von agiler Softwareentwicklung ab?

Weil die Menschen, die ich heute betreue, keine Kunden von Software sind, sondern Anbieter von Software-Dienstleistungen.

Dass „agil“ als Softwareentwicklungsmethode meist überlegen ist, gilt nicht automatisch für das Geschäftsmodell drumherum.

Wenn mir IT-Unternehmerinnen oder IT-Unternehmer heute erzählen: „Wir bieten agile Softwareentwicklung als Dienstleistung an“ frage ich: „Bist du sicher, dass das eine gute Idee ist?“.

Die meisten sind sich sicher, dass es eine gute Idee ist und bleiben auch bei dieser Meinung, nachdem ich meine Argumente vorgebracht habe.

Das ist OK, denn tatsächlich hat das Geschäftsmodell „agile Softwareentwicklung als Dienstleistung“ viele Vorteile.

Wem diese Vorteile wichtiger sind als die Nachteile, ist mit dem Geschäftsmodell gut beraten und sollte dabei bleiben.

Die Vorteile:

• Es ist ein einfaches Geschäftsmodell (die meisten Kunden und Mitarbeiter verstehen es),
• es ist robust (weil es nicht sehr viele Rollen und Organisation im Unternehmen braucht),
• es ist sicher (solange man Kunden hat, ist es nicht schwer, Profite zu machen) und
• es ist effizient (kommt mit wenig „Overhead“ aus).

Aber das Modell hat auch Nachteile, aus Unternehmersicht sogar einige gravierende.

Am Ende muss jeder Gründer und Gründerin für sich selbst entscheiden, ob die Vor- oder Nachteile überwiegen und je nachdem, was einem persönlich besonders wichtig ist, fällt das Ergebnis so oder so aus.

Damit das Abwägen leichter fällt, hier die Nachteile des Geschäftsmodells „agile Softwareentwicklung als Dienstleistung“:

Nachteil #1: Es ist fast zwangsläufig ein Zeit-gegen-Geld-Geschäftsmodell

Wer agile Softwareentwicklung anbietet, verrechnet Stunden- oder Tagessätze. Alles andere braucht schon viel Fantasie und kommt mit der agilen Denkweise regelmäßig ins Stolpern.

Das Problem dabei: nichts skaliert schlechter als Zeit. Nachdem der Arbeitsmarkt es IT-Unternehmen derzeit sehr schwierig macht, die Skalierung mit immer mehr Mitarbeitern zu erledigen, stehen Unternehmen im Wachstum an. Wer große Pläne hat, tut sich mit diesem Geschäftsmodell schwer.

Außerdem erlauben Stunden- und Tagessätze zwar einfache und sichere Profite, aber selten besonders hohe.

Die meisten Software-Unternehmen können stolz davon erzählen, dass ihre Software einem Kunden jedes Jahr hilft, Millionen an Euro zu sparen. Verkauft wurde die Software allerdings für ein halbes Jahr Arbeit, also beispielsweise für 80.000 Euro. Dabei wäre der Kunde bei einem anderen – value-based – Geschäftsmodell sicher bereit gewesen 150.000 oder 200.000 Euro zu bezahlen – und das jedes Jahr.

Fast immer vervielfachen sich die Profite, wenn ein Software-Unternehmen von time&material auf value-based umsteigt. Aber Value Selling und ein Geschäftsmodell, das bevorzugt Scrum-Teams wochenweise verkauft, vertragen sich nicht gut.

Nachteil #2: Das Unternehmen besitzt … nichts

Das Wissen und die Fähigkeiten besitzen die Mitarbeiter und die arbeiten remote oder im Homeoffice – und morgen vielleicht bei einem anderen Unternehmen. Der Code gehört dem Kunden. Die Prozesse sind agil, also standardisiert und identisch mit denen aller anderen Software-Dienstleister. Die entwickelten Frameworks benutzen (und verstehen) nur jene Personen, die sie gebaut haben. Der Product Owner ist Mitarbeiter des Kunden, die Führung im Team selbstorganisiert, der Scrum Master ein Freelancer.

Was genau trägt denn das Software-Unternehmen überhaupt noch bei?

Oder anders gefragt: Sollte das Unternehmen heute seine Pforten schließen, was würde morgen fehlen? In nicht wenigen Fällen ist die Antwort: Nichts. Der Kunde würde „seine“ Mitarbeiter übernehmen und alles würde genauso weiterlaufen wie vorher.

Tatsächlich erfahre ich mittlerweile regelmäßig von Situationen, in denen Kunden und Mitarbeiter sich entschieden haben, direkt miteinander abzurechnen. Meist mit dem Argument: Der Dienstleister habe jetzt lange genug ohne sichtbare Leistung mitgeschnitten, ab jetzt gilt „cut the middleman“.

Nachteil #3: Es ist sehr schwer, sich von der Konkurrenz abzuheben

In Zeiten wie diesen, in denen die Nachfrage nach Softwareentwicklungskapazitäten größer ist als das Angebot, mag eine gute Positionierung ein entbehrlicher Luxus sein.

Möglicherweise kommen irgendwann aber wieder Situationen, in denen man sich um Kunden bemühen muss und die wollen dann gerne wissen, was einen denn gegenüber den anderen Anbietern auszeichnet.

Denn auch die haben tolle Entwickler, klasse Referenzen und gute Code-Qualität. Zumindest behaupten das alle und der Beweis ist schwer zu erbringen. Gearbeitet wird sowieso bei allen agil, sprich standardisiert.

Was genau bleibt als Unterscheidungsmerkmal dann noch außer der Stunden- oder Tagessatz?

Nachteil #4: What’s the point?

„He, wir haben nette Kollegen, Obstkorb und Tischkicker, alternativ 100% Homeoffice. Wir coden agil und verdienen dabei auch noch ganz passabel Geld. Was will man mehr?“

Nun, einige wollen schon mehr.

Man könnte auch sagen: Nach dem 60sten Sprint hast du alles gesehen. Der Kunde mag sich ändern und die App, die man baut, möglicherweise sogar die Technologien, die man dazu nutzt.

Aber die Vorstellung eines Arbeitslebens als endlose Kette von Sprints in der man unerschöpfliche Backlogs abarbeitet, motiviert dann doch nicht jede und jeden.

Wie ein befreundeter Entwickler in meinem Alter letztens meinte: „Noch 180 Retrospektiven bis zur Pension.“

Wer so anfängt zu rechnen, schielt dann vielleicht doch etwas neidisch auf die Kollegen, die in ihrem verrückten Startup irgendeinen geilen Sch**** bauen, in einer visionären Firma an der Weltverbesserung arbeiten oder in einem innovativen Laden ihr eigenes Produkt basteln.

Mit anderen Worten: Im Recruiting wird’s noch schwieriger.

Fazit

Natürlich gibt es zwischen den agilen Software-Dienstleistern große Unterschiede und auf viele mag nichts von beschriebenen Nachteilen zutreffen. In diesem Falle: Herzlichen Glückwunsch, Ihr Unternehmen ist ein Musterbeispiel der Branche.

Alle anderen haben vielleicht doch Lust, sich Gedanken über ihr Geschäftsmodell zu machen. Über Positionierung, Entwicklung eigener Assets und neuen Preismodellen. Operativ ändert sich dabei für die meisten Mitarbeiter wenig. Denn natürlich ist es eine gute Idee, weiterhin agil Software zu entwickeln.

Hinweise:

Alex Rammlmair beschreibt in seinem Buch „Das Ende der Tagessätze“ verschiedene Preisstrategien für IT-Unternehmen, die skalieren wollen. Hier finden Sie eine kurze Beschreibung des Buches und einen Hinweis, welche Zeit-Investition für IT Unternehmen besonders wertvoll sein könnte.

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Diesen Beitrag finden Sie auch im kostenlosen Blogpaper Scrum – Sieben Perspektiven zu Scrum.

Alex Rammlmair hat im t2informatik Blog zwei weitere Beiträge veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.