Suche
Softwareprojektunternehmen und Agilität

Das falsche Geschäftsmodell: Warum sich Unternehmen mit Agilität schwer tun

Gerrit Beine

©iStockphoto.com/mshch

Aus der Perspektive von Agilität haben Unternehmen, die individuelle Software als Projekte realisieren, seit Jahren das falsche Geschäftsmodell. Das Kuriose dabei ist, dass dieses Geschäftsmodell als völlig normal empfunden und so gut wie nie hinterfragt wird. Dieses fehlende Hinterfragen ist ein wesentlicher Grund, warum es oft so schwer ist, in diesen Unternehmen Agilität einzuführen.

Die Einführung von Agilität in der Softwareentwicklung erlebe ich in vielen Organisationen immer wieder als kein einfaches Unterfangen. Ein Aspekt, der häufig einen dramatischen Wandel erfordert, ist die Kultur der jeweiligen Organisation. Agile Organisationen folgen einem anderen Wertemodell als nicht agile, klassische Organisationen. Da ist es kaum ein Wunder, dass sich viele Menschen, die im Bereich der Agilität engagiert sind, sehr intensiv mit dem Verändern der Kultur beschäftigen. Cultural Change ist ein häufig anzutreffendes Thema auf einschlägigen Konferenzen, die Ratschläge und Case Studies sind zahlreich, ein intensiver Austausch findet statt.

Doch trotz all dieser Vorträge und des Austauschs droht der Wandel hin zur agilen Organisation oft an exakt den Veränderungen der Kultur zu scheitern. „Change is hard“ schreiben Mary Lynn Manns und Linda Rising [1]. Cultural Change ist doppelt schwer. Das betrifft insbesondere Unternehmen, die sich der Entwicklung von individueller Software verschrieben haben. Solche Unternehmen realisieren Softwareprojekte und tun sich mit dem Cultural Change hin zu mehr Agilität sehr schwer, und das, obwohl Agilität für Projekte geradezu ideal ist. Warum ist das so?

Über diese Frage habe ich einige Jahre nachgedacht und bei der Lektüre von Gunter Duecks neustem Buch „Schwardumm“ [2] kam mir die Erleuchtung. Agile Coaches – hier schließe ich mich ein – konzentrieren sich bei der Veränderung der Organisationen auf die Kultur, weil hier am deutlichsten spürbar wird, wie weit eine Organisation noch von den Werten des agilen Manifests entfernt agiert. Die Kultur ist im Wesentlichen das Resultat des Handelns der Menschen innerhalb der Organisation. Sie wird aber nicht nur durch die Menschen bestimmt, sondern noch durch etwas viel Grundlegenderes, das ein Unternehmen prägt: das Geschäftsmodell des Unternehmens. Und dieses Geschäftsmodell ist in solchen Softwareprojektunternehmen nicht für Agilität geeignet. Es ist mit Agilität inkompatibel – oder schlicht und einfach grundlegend falsch.

Komplexe Systeme und dumm-einfache Geschäftsmodelle

When we created Scrum, we did not talk about lean, we talked about complex adaptive systems“, sagt Jeff Sutherland und bringt damit die Essenz des Agilen Manifests auf den Punkt. Softwareprojekte sind wie alle Arten menschlicher Kollaboration komplexe adaptive Systeme. Als solche folgen sie bestimmten Regeln und sind hinsichtlich ihres Verhaltens nur bedingt vorhersagbar. Jurgen Appelo hat in seinem Buch „Management 3.0“ [3] wunderbar erklärt, was es für Führungskräfte bedeutet, in einem komplexen adaptiven System zu wirken.

Solche komplexen adaptiven Systeme funktionieren dann sehr gut, wenn es eine kleine Menge einfacher Regeln gibt, die sie lenken, und Vertrauen in die Fähigkeit des Systems existiert, sich selbst zu organisieren. Das Agile Manifest und eigentlich alle seine Inkarnationen – seien es Scrum, Extreme Programming oder die zahlreichen anderen Ideen – folgen dieser Erkenntnis und schaffen auf Basis weniger Regeln einen Raum, in dem sich das komplexe adaptive System selbstorganisiert hin zu einem optimalen Zustand entwickeln kann.

Solch ein optimaler Zustand ist natürlich für Unternehmen wünschenswert, und deshalb streben viele Unternehmen danach, agiler zu werden. Agilität wird in diesem Zusammenhang als Hilfsmittel betrachtet – häufig als Methode, Prozess oder gar Vorgehensmodell missverstanden –, diesen optimalen Zustand auf einem klaren und standardisierten Weg zu erreichen. Das klappt bei einigen Produkthäusern ganz gut, bei Projektunternehmen ist dieser Weg zum Scheitern verurteilt. Die Ursache liegt im konsequenten Ignorieren der Tatsache, dass Softwareprojekte komplexe adaptive Systeme sind. Diese Ignoranz wird durch das Geschäftsmodell vorgegeben.

Gunter Dueck unterscheidet zwischen zwei Möglichkeiten der Einfachheit. Etwas kann dumm-einfach sein oder genial-einfach. In seinem Buch „Schwarmdumm“ beschreibt er, dass Menschen aufgrund von Gruppendynamiken und externen Stressoren sehr schnell dazu neigen, etwas Komplexes in etwas Dumm-Einfaches zu überführen (Abb. 1). Das geht schneller und fühlt sich leichter an, als etwas Komplexes in etwas Genial-Einfaches zu verwandeln. Der Weg zum Dumm-Einfachen wurde auch schon von Jerry B. Harvey als Abilene-Paradox beschrieben: Alle glauben etwas zu tun, das die anderen von ihnen erwarten, und handeln deshalb zum eigenen Nachteil und zum Nachteil der Gemeinschaft [4].

Abb. 1: Gunter Duecks Einfachheitskurve – Gegenüberstellung der Kompliziertheit und Eleganz von Lösungen (© Campus Verlag [5])

Abb. 1: Gunter Duecks Einfachheitskurve – Gegenüberstellung der Kompliziertheit und Eleganz von Lösungen (© Campus Verlag [5])

Das übliche Geschäftsmodell der Softwareunternehmen ist denkbar trivial. Das Softwareunternehmen bekommt den Auftrag für die Entwicklung einer individuellen Software von einem Kunden. Die Bezahlung erfolgt auf Basis des geleisteten Aufwands. Es gibt von diesem Geschäftsmodell im Wesentlichen zwei Formen: Festpreisprojekte und Time and Materials. Beide sind in Duecks Darstellung mäßig elegante Lösungen, die sich eher auf der Seite des Dumm-Einfachen bewegen. Das eigentliche Problem ist aber: Sie fördern in einem komplexen adaptiven System Misstrauen und behindern gemeinsame Ziele.

Mit falschen Modellen gegen gemeinsame Ziele

Bei Festpreisprojekten wird in aller Regel ein Leistungsumfang vorab beschrieben, manchmal durch den Kunden, manchmal durch das Softwareunternehmen. Auf dieser Grundlage wird dann ein Projektumfang geschätzt. Die Schätzung bezieht sich dabei auf den Aufwand der Realisierung, also die Personentage, die vom Softwareunternehmen geleistet werden müssen, um die Software zu entwickeln. Der Kunde möchte natürlich möglichst viel Software für möglichst wenig Geld erhalten. Für ihn ist es also interessant, dass das Softwareunternehmen nur einen geringen Aufwand leisten muss. Das Softwareunternehmen verdient umso mehr Geld, je geringer der tatsächlich notwendige Aufwand gegenüber dem beauftragten Aufwand ausfällt. Das Softwareunternehmen würde also ganz klar davon profitieren, den Kunden durch die Schätzung des Aufwands zu übervorteilen. Weil das so offensichtlich ist, wird zwischen Kunde und Softwareunternehmen ein Vertrag auf der Grundlage des geschätzten Aufwands erstellt, mit dem das gesamte Projekt genauestens geregelt wird. Während des Projekts wird dann durch einen Lenkungsausschuss beständig überprüft, ob das Projekt „im Plan“ ist – was nichts anderes bedeutet, als dass exakt so viel Aufwand geleistet wurde wie hätte geleistet werden müssen. Dieser Lenkungsausschuss, der den Fortschritt des Projekts anhand des geleisteten Aufwands prüft, ist das menschgewordene Misstrauen, das aus dem viel zu komplexen Modell des Festpreisprojekts resultiert (Abb. 2).

Abb. 2: Festpreiswerkverträge sind in Duecks Modell der Lösungseleganz eher mäßig elegant, weil sich die Aufteilung von Verantwortung zu kompliziert gestaltet; Time and Materials ist allenfalls dumm-einfach, da es keine Lösung im Sinne gemeinsamer Verantwortung enthält

Abb. 2: Festpreiswerkverträge sind in Duecks Modell der Lösungseleganz eher mäßig elegant, weil sich die Aufteilung von Verantwortung zu kompliziert gestaltet; Time and Materials ist allenfalls dumm-einfach, da es keine Lösung im Sinne gemeinsamer Verantwortung enthält

Das Time-and-Materials-Projekt verläuft etwas anders, aber auch hier hat das Softwareunternehmen prinzipiell die Möglichkeit, den Kunden zu übervorteilen. Bei Time and Materials beauftragt der Kunde Personen für eine bestimmte Zeit, die seine Wünsche erfüllen. Hier wird dann nach Aufwand abgerechnet, ohne dass vorher ein fester Preis vereinbart war. Der Kunde kann sehr gut prüfen, dass die Menschen, die für ihn arbeiten, das auch effektiv tun. Was der Kunde in aller Regel nicht kann, ist sicherstellen, dass diese Menschen effizient arbeiten. Und hier liegt die Möglichkeit des Softwareunternehmens, den Kunden zu übervorteilen: Wenn die Menschen etwas langsamer programmieren, erhöht das den Aufwand und damit den Gewinn des Softwareunternehmens. Auch das ist wieder offensichtlich, also wird die effiziente Tätigkeit der Menschen beständig dadurch gesichert, dass sie berichten müssen, was sie getan haben. Das kann zwar niemand wirklich auswerten, aber die Tätigkeitsnachweise bauen einen permanenten Druck bei den Menschen auf, beschäftigt zu erscheinen. Und wer beschäftigt erscheint, so glaubt man, ist das in der Regel auch. Der Stundenzettel ist das papiergewordene Misstrauen, das aus dem dumm-einfachen Time-and-Materials-Modell resultiert (Abb. 3).

Abb. 3: Adaptionen von agilen Methoden innerhalb des Geschäftsmodells resultieren in einer Tendenz zum Dumm-Einfachen

Abb. 3: Adaptionen von agilen Methoden innerhalb des Geschäftsmodells resultieren in einer Tendenz zum Dumm-Einfachen

Beide Modelle funktionieren gut, wenn man einen Klempner beauftragt, eine neue Badewanne einzubauen. Der Einbau ist ein Projekt von überschaubarer Komplexität, und beim Klempner hat man auch als Laie eine gute Chance zu prüfen, ob er effizient und effektiv arbeitet. Deshalb kommt vermutlich auch niemand auf die Idee, den Einbau einer Badewanne als agiles Projekt durchzuführen. Softwareprojekte sind aber, wie weiter oben schon erwähnt, komplexe Systeme und benötigen Vertrauen, um erfolgreich zu verlaufen.

Dieses Vertrauen kann entstehen, wenn der Kunde und das Softwareunternehmen gemeinsame Ziele verfolgen. Genau das wird aber von beiden Formen des Geschäftsmodells verhindert. Das Ziel des Kunden besteht in beiden Fällen darin, den Aufwand auf Seiten des Softwareunternehmens möglichst gering zu halten, sonst besteht die Gefahr, dass das Projekt mehr Kosten verursacht als geplant. Das Softwareunternehmen verfolgt bei Festpreisprojekten das Ziel, das Projekt mit weniger Aufwand zu realisieren als geplant, weil dadurch der Gewinn aus dem Projekt steigt. Im Falle eines Time-and-Materials-Projekts hat es das Ziel, möglichst viel Aufwand nachweisen zu können. Jede geleistete Stunde bedeutet mehr Geld.

Diese unterschiedlichen Ziele sind die Ursache für eine antiagile Grundhaltung im Projekt, die am besten durch das Adenauer-Syndrom beschrieben wird: keine Experimente. Im Festpreisprojekt sind Experimente nicht möglich, weil jedes Experiment die Konsequenz haben könnte, dass die Aufwände steigen. In Time-and-Materials-Projekten ist es schwierig, die Stunden für ein fehlgeschlagenes Experiment abzurechnen – und der Kunde wird die Mitarbeiter nicht anweisen, Experimente zu machen, denn wenn er das tut, müsste er den Aufwand dafür bezahlen.

Experimente sind aber fundamentaler Bestandteil von Selbstorganisation. Finden sie nicht statt, kann in einem komplexen adaptiven System keine Selbstorganisation stattfinden und somit auch keine Optimierung des Systems hin zu einem globalen Optimum erfolgen. An dieser Stelle wird deutlich, dass es nicht die Kultur ist, die die Agilität im Kontext der Individualsoftwareprojekte blockiert, sondern das Geschäftsmodell der Softwareprojektunternehmen.

Agilität ist genial-einfach

Wie kann man diesem Dilemma entkommen? Wie müsste ein Geschäftsmodell für Softwareprojektunternehmen ausschauen, das eine Kultur der Agilität zulässt?

Zunächst muss klar sein: Eigentlich sind dem Kunden die Aufwände des Softwareunternehmens völlig egal. Er verfolgt nämlich ein ganz anderes Ziel: Durch das Softwareprojekt soll ein geschäftlicher Mehrwert realisiert werden. Für diesen Mehrwert ist der Kunde zu einer Investition bereit. Die Frage, die sich der Kunde beantworten muss, lautet nun: Wie viel Mehrwert kann ich mit dieser Software schaffen, und wie viel davon möchte ich in ihre Entwicklung investieren? Das ist eine Betrachtung im Sinne des Agilen Manifests und – Achtung! – Kunden machen diese Betrachtung bereits. Wie sonst könnte ein Festpreisprojekt beauftragt, wie könnte das Budget für ein Time-and-Materials-Projekt genehmigt werden, wenn nicht auf Grundlage der Bereitschaft des Kunden eine bestimmte Menge Geld zu investieren.

Aber warum arbeiten Softwareunternehmen dann mit einem Geschäftsmodell, das auf der Abrechnung von Aufwand basiert? Die Antwort auf diese Frage ist sehr einfach: Weil niemand das Geschäftsmodell des Klempners in Frage stellt. Das Geschäftsmodell der Softwareprojektunternehmen ist zu einer Zeit entstanden, als Projekte noch überschaubar waren – sie waren nie so trivial wie der Einbau einer Badewanne, aber deutlich einfacher als heute. Und weil in diesen ersten Tagen der Softwareentwicklung noch nicht agil gearbeitet wurde, gab es nie eine Retrospektive, in der reflektiert wurde, was einer Optimierung bedarf.

Wie muss nun aber die Veränderung des Geschäftsmodells ausschauen, sodass es eine Optimierung erfährt und agile Methoden erfolgreich darin angewendet werden können?

Denkanstöße

Wie bereits beschrieben, ist einer der Grundpfeiler von Agilität das Vorhandensein gemeinsamer Ziele. Eben diese gemeinsamen Ziele benötigen Kunde und Softwareprojektunternehmen für jedes Projekt. Das gemeinsame Ziel kann aber praktisch immer nur das Ziel des Kunden sein – ein Softwareprojektunternehmen existiert nur, solange seine Kunden Ziele haben. Softwareprojekte sind kein Selbstzweck, das ist schon fast eine Binsenweisheit. Softwareprojektunternehmen, die agil sein wollen, müssen also einen Weg finden, wie sie ihren Projekterfolg an den ihrer Kunden koppeln können. Die üblichen agilen Vertragsmodelle, seien es Time-and-Material-orientierte wie Time and Materials on Steroids oder agile Festpreismodelle bewegen sich alle innerhalb des üblichen Geschäftsmodells und versuchen somit das Problem innerhalb eines Systems zu lösen, das keine Lösung erlaubt. Welche Konzepte kann es aber außerhalb des gewohnten Geschäftsmodells geben?

Vor einiger Zeit erschien ein Buch von Boris Gloger zum Thema Personalmanagement in agilen Organisationen [6]. In diesem Buch werden Softwareprojektunternehmen mit Professional Service Firms verglichen. Dieser Vergleich ist im Kontext der Personalführung durchaus valide. Er funktioniert aber nicht mehr, sobald es um die Frage des Geschäftsmodells geht. Klassische Professional Service Firms sind Steuerkanzleien, Anwaltskanzleien, Notare oder Architekturbüros. Deren Geschäftsmodell basiert darauf, dass eine Vergütung der Kerntätigkeit nicht anhand des geleisteten Aufwands erfolgt, sondern abhängig vom Wert der zu bearbeitenden Sache ist. In Deutschland sind diese Vergütungen gesetzlich geregelt. Wer schon einmal einen Vertrag mit einem Bauingenieur geschlossen hat, weiß, dass dieser seine Hauptaufgabe nicht nach Stunden abrechnet. Prinzipiell wäre dieses Modell natürlich auch auf Softwareprojekte übertragbar. Allerdings klingt eine „Honoraranordnung für Softwareentwickler“ erst mal wenig agil und passt nicht so recht zum Selbstverständnis der IT-Branche.

Eine andere Idee, die schon wesentlich mehr an Agilität erinnert, ist das gemeinsame Betreiben eines Projekts als Joint Venture nach einem Modell wie dem Lean Startup. Bei solch einem Modell sitzen Kunde und Softwareprojektunternehmen tatsächlich in einem Boot und profitieren gleichermaßen vom Projekterfolg – oder leiden gemeinsam unter einem Misserfolg. Ein solches Modell ist natürlich nicht für alle Projekte geeignet. Es erfordert auch ein starkes Vertrauensverhältnis zwischen Kunde und Softwareprojektunternehmen in die Qualität der Fähigkeiten des jeweiligen Partners. Und es greift sehr stark in das Geschäftsmodell der Softwareprojektunternehmen ein, denn ein solches Modell zwingt sie in die Rolle eines Venture-Capital-Gebers, auch wenn dies nur in Form von geleistetem Aufwand erfolgt. Praktisch profitieren aber beide Seiten in diesem Modell von einem hohen Maß an Agilität.

Neben diesen beiden Modellen gibt es noch das Konzept von Teaminkubatoren. Hier besinnt sich das Softwareprojektunternehmen auf eine wesentliche Fähigkeit, die seine Kunden üblicherweise nicht haben: In kurzer Zeit Teams aufzubauen, die ein Projekt großartig umsetzen können. Das Interessante dabei ist, dass der Kunde nicht für das Projekt zahlt, sondern für das Team. Beim Teaminkubator wird nicht die realisierte Software als das Asset betrachtet, das im Projekt entsteht, sondern das Team, das sich geformt hat. Dieses Team geht de facto in den Besitz des Kunden über, und dafür erhält das Softwareprojektunternehmen seine Vergütung. Die Schwierigkeit hierbei ist, dass ein solches Modell viel von den Arbeitnehmern verlangt. Die Projektbeteiligten identifizieren sich nicht mit dem Unternehmen für das sie arbeiten, sondern mit ihrem Projekt. Das führt innerhalb des Softwareprojektunternehmens zu ganz neuen Herausforderungen, die zu zahlreich sind, um sie hier alle zu beschreiben. Es mag aber durchaus Projekte geben, in denen ein solches Vorgehen sinnvoll ist.

Als letztes mögliches Modell soll hier noch eine Adaption aus der Freelancer- und Start-up-Szene beleuchtet werden: Guru Coworking. Hier ändert sich die Rolle des Softwareprojektunternehmens komplett, denn es realisiert keine Projekte mehr. Stattdessen stellt es Räumlichkeiten und Infrastrukturen für optimale Projektverläufe zur Verfügung. Das Softwareprojektunternehmen schickt keine Mitarbeiter mehr zum Kunden, um dort Softwareprojekte unter zweitklassigen Bedingungen durchzuführen. Vielmehr schickt der Kunde seine Projektteams in die entgegengesetzte Richtung, wo diese Teams perfekte Umgebungen finden, die sich sonst nur Produktunternehmen leisten, gemeinsam mit einer Reihe Gurus für all die komplizierten Themen wie Softwarearchitektur, Testautomatisierung oder auch agile Methoden. Diese Gurus sorgen dafür, dass die Bedingungen für die Projekte optimal sind, und stehen den Kunden mit Rat und Tat zur Seite.

Einfachheit wäre das Resultat der Reife

Ob eines der vorgestellten Geschäftsmodelle den Anforderungen genial-einfach zu sein genügt, kann heute niemand beantworten. Fakt ist aber, dass sich das Softwareprojektgeschäft wandeln muss, weg von einer Betrachtung der Realisierungsaufwände, hin zu einer Betrachtung der geschaffenen Werte und zu gemeinsamen Zielen. Diese gemeinsamen Ziele ermöglichen die Anwendung agiler Methoden im Softwareprojektgeschäft, und deren Anwendung führt zu Optimierungen, die Kunden und Softwareprojektunternehmen nutzen.

Agilität ist sinnvoll, um Projekte erfolgreich zu realisieren, das bestreitet heute kaum noch jemand. Aber um sie dort, wo die meisten Projekte passieren, erfolgreich anzuwenden, muss man sich auch der betriebswirtschaftlichen Wirklichkeit stellen – und diese auch in Frage stellen.

Geschrieben von
Gerrit Beine
Gerrit Beine
Gerrit Beine ist Managing Consultant bei der adesso AG mit den Schwerpunkten Agilität und Softwarearchitektur. Er ist regelmäßig als Sprecher auf Konferenzen zu treffen und beschäftigt sich gerne mit außergewöhnlichen Fragestellungen zur Softwareentwicklung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.