Ist Agile effizienter als Wasserfall?
Einer der Scrum Master, den wir häufig coachen, ruft uns regelmäßig wegen Problemen an, mit denen er zu kämpfen hat. Er scherzte, wir sollten am besten „Agile Hotline, wie können wir Ihnen weiterhelfen?” sagen, wenn wir ans Telefon gehen. Wir fanden, dass das eine sehr gute Idee war und daher fangen wir nun mit einer Reihe von Blogbeiträgen mit dem Namen Agile Hotline an. Hier finden Sie unsere Antworten auf die Fragen, die wir von anderen zu Agile oder Scrum bekommen. Wir hoffen, dass auch Sie etwas davon lernen können.
Kürzlich wurde ich nach einem Rat zu einer Diskussion gefragt, die jemand mit einem Kollegen hatte. Es ging darum, ob Agile und Scrum in jedem Szenario, in dem Software entwickelt wird, funktionieren können. Der Kollege behauptete, das ginge nicht.
Das Szenario
Gehen wir davon aus, dass ein Softwareprodukt gebaut werden soll, welches es den Nutzern ermöglicht, Bewertungen vorzunehmen, wenn sie ein E-Book lesen. Es soll mindestens zwei verschiedene Arten dieser Bewertungen geben.
Bei Agile bzw. Scrum würde man versuchen, so früh wie möglich ein funktionierendes und wertvolles Produkt zu liefern – also ist das Ziel, nur eine der Bewertungsmöglichkeiten zu liefern, die aber schon früh von den Nutzern verwendet werden kann. Das wäre dann v1.0. Einige Sprints später versucht man dann, die zweite Bewertungsmöglichkeit als v2.0 zu implementieren.
Beim Wasserfallmodell würde man sich so lange Zeit nehmen, wie es eben dauert, um beide Bewertungen in der ersten Version zu liefern.
Der Kollege argumentierte in diesem Fall, dass Wasserfall sinnvoller sei, weil das Risiko sonst sehr hoch sei, den gesamten Code refaktorieren zu müssen, um die zweite Bewertungsmöglichkeit v2.0 unterstützen zu können. Mit Wasserfall würden beide Bewertungsarten jedoch zusammen entwickelt. Obwohl es länger dauern würde, die erste funktionierende Version zu liefern, hätte man weniger nachzuarbeiten.
Er ist der Meinung, die Wasserfallmethode spare Zeit und sei effizienter, weil man weniger refaktorieren muss, wenn man mit aktuellen und zukünftigen Anforderungen gleichzeitig mit der Entwicklung beginnt. Bei Agile liegt unser Fokus aber auf dem „Jetzt” und auf nur einer einzigen Bewertungsart.
Wie denken Sie darüber? Wie würden Sie mit einer Gruppe von Entwicklern umgehen, die denken, dass sie bei Agile später viel überarbeiten müssen, weil sie „nicht zu weit voraus planen durften”?
Was wir glauben
Es gibt drei Hauptpunkte, die man verstanden haben muss, um diese Frage zu beantworten:
Erstens: Agile und Wasserfall haben beide ihr jeweiliges Einsatzgebiet. Agile ist auf komplizierte/komplexe Systeme ausgelegt, z. B. wenn es ein gewisses Maß an Ungewissheit bei den Anforderungen und/oder der Technologie gibt. Wasserfall ist am besten für einfache Projekte geeignet, beispielsweise wenn es ein gutes Verständnis von Anforderungen und Technologie gibt und sich diese Dinge nicht verändern. Wir benutzen die Stacey Matrix, um zu klären, wann man worauf zurückgreifen sollte. Das Ding ist, dass Wasserfall in einer komplexen Umgebung komplett scheitert, wohingegen Agile in einem simplen Umfeld zwar mit mehr Aufwand verbunden ist aber trotzdem funktioniert. Unser liebstes Beispiel dafür ist das Organisieren einer Konferenz. Man kann Agile benutzen, auch wenn es eventuell nach unnötigem Aufwand aussieht.
Zweitens: Agile ist NICHT effizienter als Wasserfall. Es ist effektiver. Das bedeutet, dass man vielleicht mehr Personenstunden benötigt, um etwas mit Agile zu liefern, das Produkt aber sehr wahrscheinlich früher auf den Markt gebracht werden kann (weil es am Ende jedes Sprints ein Release geben sollte und nicht erst am Ende des Projekts). Außerdem sind die Gesamtbetriebskosten wahrscheinlich niedriger (weil Qualität und Design besser sind und das Wissen geteilt wird, weshalb die Wartung einfacher ist).
Drittens: Bei Agile geht es nicht darum, etwas Bestimmtes schneller zu entwickeln. Es geht um die Kunst, die Menge nicht getaner Arbeit zu maximieren. Die Chaos-Studie besagt, dass 65 % einer Software nie oder selten genutzt werden. Mit Agile versucht man, die restlichen 35 %, die am ehesten genutzt werden, zu identifizieren und zu entwickeln; danach hört man auf. Wenn es also auch vielleicht etwas länger dauert, die ersten 35 % zu entwickeln, haben wir uns doch gespart, die anderen 65 % zu entwickeln, die niemand nutzen wird.
Wie sieht das nun mit unserem Beispiel aus? Nun, zu allererst würde man nicht erst die gesamte erste Bewertung fertigstellen und danach die zweite. Man würde den wertvollsten Teil der Bewertung identifizieren. Das kann eine bestimmte Art von Frage sein (beispielsweise eine Multiple-Choice-Frage). Man würde also nur eine Frage in die Bewertung einbauen, sie von Nutzern testen lassen und herausfinden, ob sie funktioniert. Man könnte sogar die erste Bewertungsmöglichkeit nur mit Multiple-Choice-Fragen liefern. Danach würde man den nächstwichtigen Fragentyp einbauen. Oder man beschließt, dass es gut genug ist, und fängt mit einem neuen Projekt an.
Wenn der Umfang der Bewertungen wirklich festgelegt ist, man außerdem weiß, dass es tatsächlich für die Nutzer funktioniert, und es keine Ungewissheit bezüglich der Technologie gibt, kann Wasserfall die bessere Wahl für dieses Projekt sein. Agile würde auch funktionieren, nur nicht unbedingt Zeit sparen. Erfahrungsgemäß kann ich sagen, dass die meisten Leute denken, alle Anforderungen zu kennen und verstanden zu haben – das stimmt aber normalerweise nicht. Der Mehraufwand bei Agile zahlt sich also meistens aus.
Dieser Text stammt aus dem Blog von Growing Agile und wurde von uns ins Deutsche übersetzt.