5 häufige Planungsfehler in der Softwareentwicklung

Es ist schwer, die Zukunft vorauszusagen, auch wenn es genau dafür bestimmte Methoden gibt. Die Realität ist, dass selbst die Planung eines einfachen Projekts bei der Softwareentwicklung eine Herausforderung ist. Es gibt viele Dinge, die beachtet werden müssen und genau so viele Dinge, die falsch laufen können. Es ist erwiesen, dass es oft schief geht, wenn Software nur anhand von Prognosen ausgeliefert wird. Leider ist das aber immer noch eine feste Gewohnheit.

Die häufigsten Fehler, die bei der Softwareentwicklung gemacht werden:

1. Die Komplexität der Softwareentwicklung wird oft unterschätzt

Softwareentwicklung wird oft mit dem Bau eines Hauses verglichen. Das scheint ein guter Vergleich zu sein, denn dem ersten Anschein nach “bauen” Softwareentwickler etwas. Leider unterscheidet sich Softwareentwicklung aber grundlegend vom traditionellen Hausbau. Wenn solche Planungsmethoden angewendet werden, kann es also zu Problemen kommen.

Nassim Nicholas Taleb beschreibt in seinem Buch, “The Black Swan” zwei verschiedene Welten, “Mediocristan” und “Extremistan”. Beide Welten repräsentieren zwei unterschiedliche Arten von Ungewissheit.

Um diesen Unterschied zu demonstrieren, schlägt Taleb folgendes Experiment vor:
Man wählt 1.000 unterschiedliche Personen aus der Bevölkerung. Diese Personen legen sich dann Kopf an Fuß hintereinander, so dass sie eine lange Linie bilden.

Gehen wir davon aus, dass die Durchschnittsgröße einer Person bei 1,68 cm liegt. Die Linie wäre somit ungefähr 1.680 Meter lang. Eine doppelt so lange Linie (3.360 m), müsste dann aus etwa 2.000 Personen bestehen (die auch eine Durchschnittsgröße von 1,68 cm haben).

Was würde passieren, wenn sich weitere 1.000 Personen an die bisher vorhandene Linie legen? Allerdings würde man dieses Mal den größten Mann der Welt (Sultan Kösen, 2,51 cm) einbeziehen. In diesem Fall bräuchte man nur 1.999 Personen. Selbst nachdem ein solches Worst-Case Szenario in die Planung einbezogen wurde, besteht also kein großer Unterschied zu unserer Ausgangsberechnung.

Nun versuchen wir das gleiche Experiment noch einmal – aber mit einer anderen Berechnung:

Diesmal werden 1.000 unterschiedliche Personen aus der Bevölkerung ausgewählt und das Vermögen der jeweiligen Familien erfasst. Das Durchschnittsvermögen einer Familie in den USA beträgt beispielsweise 110.000 Dollar. Für diese Gruppe wäre das eine Gesamtsumme von 110.000,000 Dollar. Als nächstes schätzt man die benötigte Größe eines Tresorraumes, um das Gesamtvermögen von 2.000 Personen unterzubringen. Man kann die Größe relativ einfach berechnen, indem man die benötigte Größe für das Vermögen von 1.000 Personen herausfindet und dann verdoppelt.

Nun nehmen wir wieder 1.000 Personen aber beziehen Bill Gates mit ein. Was könnte nun passieren? Die ursprüngliche Schätzung war für einen Tresor, in dem man 220.000.000 Dollar aufbewahren kann. Jetzt benötigt man jedoch einen für 77.500.000.000,00 Dollar. Welchen Unterschied macht hier ein Worst-Case Szenario?

Was haben diese Experimente mit Softwareentwicklung zu tun?
Falls Sie bereits Erfahrung mit Softwareentwicklung haben, ist Ihnen sicher das eine oder andere Problem über den Weg gelaufen, dass Sie nicht lösen konnten. Vielleicht ist es ein Bug, welcher sehr schwer zu fixen ist. Oder es ist ein technisches Problem, dass Sie mit den vorhandenen Tools nicht lösen können. Die ursprüngliche Schätzung war nicht nur ein wenig ungenau, sondern weist eine Abweichung von 10%, 20% oder 500% auf. Das ist die Welt der Softwareentwicklung. Das ist “Extremistan” (zweites Experiment), bei dem ein Vorfall oder ein Element einen großen Einfluss auf das Ergebnis haben kann.

Die meisten Bauprojekte sind aus der Welt von “Mediocristan” (das erste Experiment), in der Abweichungen im Ganzen ausgeglichen werden. Wiederholen wir das Experiment mit zufällig ausgewählten Hochhäusern und legen diese Gebäude wie Dominosteine aneinander. Nun kommt das höchste Gebäude der Welt, das Burj Khalifa mit ins Spiel. Ist das Ergebnis am Ende das gleiche wie bei dem Beispiel mit der Größe der Personen oder dem Beispiel mit dem Vermögen?

Wie kann man nun verhindern “Extremistan” mit “Mediocristan” zu verwechseln? Es ist wichtig, die Art der Aufgabe, die man plant, bis ins kleinste Detail zu verstehen. Wenn der Arbeitsaufwand eines einzelnen Items potentiell stark von dem anderer Items abweichen kann, ist es ratsam, angemesse Planungsmethoden zu nutzen. Daher sind empirische Planungsmethoden, die in Scrum eingesetzt werden, geeigneter für Projekte aus “Extremistan”.

2. Das Unvorhersehbare planen wir nicht

Komplexe Aufgaben benötigen eine andere Art von Risikomanagement. In der üblichen Projektplanung werden Puffer für unvorhersehbare Zwischenfälle eingesetzt. Es herrscht oft der Glaube, dass Unvorhersehbares ausgeglichen wird, indem verlorene Zeit mit gewonnener Zeit wieder aufgeholt wird. Leider funktioniert das im Fall von komplexer Arbeit nicht.

Bei diesem Projekt sind wir zuversichtlich, dass wir zu dem geplanten Termin liefern können. Aber nehmen wir einmal an, die Hintergrundfakten wären die folgenden:

• Sie sind ein Truthahn
• Der Fortschritt, der verfolgt wird, ist Ihr Gewicht
• Keiner hat Ihnen von Thanksgiving erzählt. Was passiert mit Truthähnen an Thanksgiving?
  Wie fühlen Sie sich jetzt?

Nassim Nicholas Taleb nutzt diese Metapher in seinem Buch “The Black Swan”, um die Auswirkung von unvorhersehbaren Vorfällen darzustellen. Der Truthahn hat noch nie von Thanksgiving gehört und es ist auch kein Puffer einkalkuliert. Unvorhersehbare Vorfälle sind in herkömmlicher Planung nicht vorgesehen. Aber in der Softwareentwicklung kommen diese häufig vor.

Wie kann man diesen Fehler vermeiden? Das Rahmenkonzept von Scrum sieht vor, dass in regelmäßigen Abständen einzelne Teile von Software geliefert werden. Das Risiko wird verringert, indem früh und oft geliefert wird – und nicht durch eingeplante Puffer. Wenn es zu unvorhersehbaren Vorfällen kommt, gibt es die Möglichkeit, auf das zurückzugreifen, was bisher gebaut wurde.

3. Oft wird den Stakeholdern ein Versprechen gegeben, dass nicht eingehalten werden kann

Wenn wir doch wissen, dass Softwareentwicklung komplex und riskant ist, warum können wir das nicht einfach den Stakeholdern mitteilen? Warum machen wir Versprechen, die wir nicht einhalten können? Die Antwort darauf ist, dass Führungskräfte Gewissheit benötigen. Sie legen das Budget fest, sie müssen sicher sein, dass alle Tätigkeiten geplant sind, sie wollen eine Deadline und sie wollen natürlich alle gewünschten Features.

Aber sind in Stein gemeißelte Zusagen erforderlich?
Die meisten Fachleute aus der Branche verstehen das Risiko. Sie verstehen auch, dass sie oft ein Risiko eingehen müssen, um Rendite und Gewinne zu erzielen. Sehr oft ist die Höhe des Risikos direkt mit der potentiellen Rendite verbunden. Die meisten Unternehmen würden eine garantierte Rendite bevorzugen. Sie wissen aber, dass der Gewinn aus solchen Investitionen so niedrig ist, dass es sich häufig überhaupt nicht lohnt zu investieren. Wenn das doch jeder weiß, warum macht es dann nicht jeder?

Wenn Stakeholder das Verhältnis von Risiko und Belohnung (Gewinn) verstehen, warum folgt man in der Softwareentwicklung nicht dem gleichen Prinzip? Bei jedem neuen Release gibt es ein Element der Belohnung. In jedem guten Projekt gibt es eine Berechnung der Rentabilität (Return on Investment (ROI)). Wenn mit einer bedeutenden Rentabilität in einem Projekt zu rechnen ist, dann müssen die Stakeholder ein gewisses Risiko erwarten. Sprechen Sie also mit Ihren Stakeholdern darüber. Machen Sie sie darauf aufmerksam, dass sie vielleicht nicht alles bekommen werden, was zum Zeitpunkt der Planung erwartet wurde. Das ist das Risiko in der Softwareentwicklung. Es bedeutet nicht, dass man das Risiko nicht einschränken kann. Eine ehrliche Diskussion sollte aber auf jeden Fall geführt werden.

Wenn Stakeholder verbindliche Zusagen von Ihnen haben wollen, dann sollten Sie nur solche machen, die Sie auch einhalten können. Verpflichten Sie sich zur Zusammenarbeit. Verpflichten Sie sich dazu, sich an den abgemachten Ablauf zu halten. Verpflichten Sie sich, qualitätsorientiert zu arbeiten. Verpflichten Sie sich zu kontinuerlicher Prüfung und Adaption. Verpflichten Sie sich, Transparenz zu gewährleisten.

Sprechen Sie mit den Stakeholdern über Risiko und Belohnung und erklären Sie Ihnen, dass das Bauen einer neuen Software dem gleichen Prinzip folgt. Diskutieren Sie darüber, welche Maßnahmen zur Risikominderung angewendet werden können. Und verpflichten Sie sich nur zu dem, was Sie wirklich leisten können.

4. Wir geben Stakeholdern oft den Anschein, dass manche Arbeiten kostenlos sind

Wenn wir unseren Stakeholdern gewisse Features zu einem bestimmten Zeitpunkt und für ein bestimmtes Budget versprechen, dann denken sie, dass sie diese Features bezahlt und gekauft haben. Als Entwickler hat man sich verpflichtet, die Features auch zu liefern. Das Risiko ist nun, dass die Stakeholder denken, dass keine Mehrkosten auf sie zukommen. Sie haben schließlich schon bezahlt und glauben, dass alle zusätzlichen Features im Preis inbegriffen sind. Das Einzige, worüber sie sich Gedanken machen, sind die Kosten für eventuelle Änderungen. In seinem Buch “Predictably Irrational” beschreibt Dan Ariely die Veränderung menschlichen Verhaltens, wenn etwas kostenlos ist:

“Überall gibt es Vorteile und Nachteile, aber wenn etwas kostenlos ist, vergisst man die Nachteile.”
Wenn Ihre Stakeholder verstehen, dass kein Feature garantiert ist, bis es fertiggestellt ist, werden sie sich öfter beteiligen, Entscheidungen treffen und Kompromisse eingehen. Sie werden darauf bestehen, dass zuerst wichtige Features fertig gestellt werden und dann weniger wichtige. Sie werden seltener dazu bereit sein, viel Aufwand für Features zu betreiben, die nicht so wichtig sind.

Daher sollte man seine Stakeholder regelmäßig daran erinnern, dass es keine Garantie dafür gibt, dass ein Feature nach Plan geliefert wird, ehe es tatsächlich ausgeliefert wurde.

Zwecks Prioritätensetzung sollte während des Projektes permanent mit den Stakeholdern zusammengearbeitet werden. Scrum Sprint Reviews geben den Stakeholdern regelmäßig die Möglichkeit, den Fortschritt des Prozesses zu überprüfen, die anstehenden Arbeiten zu besprechen und Prioritäten zu setzen.

5. Wir agieren nicht professionell

Stellen Sie sich vor, Sie hätten eine Augen-OP. Der Augenarzt weiß, dass bei dieser Operation ein Risiko von 10% besteht, dass es zu Komplikationen kommen könnte und dass statt einer Verbesserung eine Erblindung die Folge sein könnte. Der Arzt entscheidet sich nun dafür, Ihnen diese Information vorzuenthalten. Er glaubt, er könne sonst Ihren Auftrag verlieren. Stellen Sie sich nun vor, Sie lassen die OP durchführen und verlieren Ihr Augenlicht. Dann finden Sie heraus, dass der Augenarzt dieses Risiko kannte, Sie aber nicht darüber in Kenntnis gesetzt hat. Er müsste mit ernsten Konsequenzen rechnen. Das ist mit Sicherheit nicht die Vorgehensweise, die man von einem Profi erwarten würde.

Wäre es besser, wenn der Augenarzt vor dem Risiko warnen würde aber dann sagen würde: “Machen Sie sich keine Sorgen, ich bin ein sehr guter Augenarzt und ich garantiere Ihnen, dass nichts passiert.” Wäre das professioneller?

Dieses Szenario wiederholt sich ständig in Softwareentwicklungsprojekten. Wir lügen unsere Stakeholder an. Der Grund, warum wir lügen kann schlecht (die Stakeholder dazu zu bewegen, den Vertrag zu unterzeichnen) oder gut sein (den Stakeholdern die Angst zu nehmen) oder wir lügen uns einfach nur selbst an. Das Ergebnis bleibt das gleiche: es ist äußerst unprofessionell!

Um diesen Fehler zu vermeiden, muss man ehrlich sein, auch wenn es schwer fällt. Damit gibt man den Stakeholdern nämlich die Möglichkeit, die Risiken zu erkennen und dementsprechend zu planen. Ein Profi nutzt und fördert die empirischen Grundlagen in Scrum und hilft damit den Stakeholdern, besser mit Risiken umzugehen.

Zusammenfassung: Planungsfehler in der Softwareentwicklung

Es ist schwer die Zukunft vorauszusagen. Wenn wir komplexe Softwareentwicklung planen, machen wir viele Fehler, die häufig zu einer niedrigen Erfolgsquote führen. Durch die Nutzung von Scrum werden solche Fehler vermieden.

Dieser Text stammt aus dem Blog von Steve Porter und wurde von uns ins Deutsche übersetzt.

Was macht ein Product Owner?

=> Lerne mehr über die Aufgaben und Pflichten von Product Ownern.

Product Owner Zertifizierung

=> Finde ein Certified Scrum Product Owner Training bei der Agile Academy.

Das Sprint Planning Meeting

=> Ablauf und wichtige Tipps für Product Owner zum Sprint Planning