Klassisch vs. Agile – ein Vergleich

klassisch vs. agile
Von Sebastian Schneider // 27.06.2018 // 1 Kommentare

Klassisch vs. agile ist wohl eines der am häufigst diskutierten Themen in meinen Trainings zu Scrum und den agilen Grundlagen. In diesem Artikel zeige ich dir, was sowohl das eine, als auch das andere ist. Wir sehen uns zudem an, wie du mit dem Projektdreieck Klarheit für dich gewinnen kannst, ob etwas eher klassisch oder agil ist. Wir streifen dann noch das Stacey Landscape Diagram und das Cynefin Framework bevor wir mit dem schnellen Return of Invest (ROI) enden.

Klassisch vs. agile

klassisch vs. agile

Was bedeutet "klassisch"?

Wenn wir den Begriff "klassisch" in der Entwicklung von Produkten nutzen, dann dauert es nicht lange, bis auch der Begriff Wasserfall oder Wasserfallmodell fällt. Gemeint ist damit eine Entwicklung, die in aufeinanderfolgenden Stufen durchgeführt wird. Ist die erste Stufe (oder Phase) abgeschlossen, dann startet die nächste.

Hinweis zum Wasserfallmodell

Das Wasserfallmodell ist nie tatsächlich so eingesetzt worden und wenn man sich dessen Entstehung ansieht, dann findest du bereits dort Rückschlüsse auf kleine Schleifen innerhalb des Modells. Es wird aber gerne immer als "das Böse" angesehen, was es zunächst einmal gar nicht ist.

Es gibt allerdings starke Ähnlichkeiten mit einer Art und Weise, wie viele Unternehmen aktuell arbeiten. Scheinbar aus diesem Grunde hat sich der Begriff Wasserfallmodell für das, was wir im Allgemeinen unter "klassisch" verstehen, durchgesetzt hat. Im Kern meinen wir dabei oft die folgende Eigenschaften einer Entwicklung:

  • Eine langen Phase, um Anforderungen und damit den Umfang an ein Produkt zu beschreiben.
  • Phasen im Entwicklungsprozess, die sequentiell aufeinander folgend sind. So wird zuerst erst das eine gemacht und danach das andere. Dabei werden immer Informationen übergeben.
  • Mit einem Ergebnis, dass erst nach Abschluss des Entwicklungsprozesses zur Verfügung steht und mit dem Feedback vom Kunden eingeholt werden kann.
  • Es findet viel Planung statt, die oft für sehr lange Zeiträume in detaillierter Art und Weise durchgeführt wird.

Was bedeutet "agile"?

Agile (oder agil) bedeutet zunächst einmal flink und wendig. Bei der Entwicklung von Produkten meinen wir damit in der Regel einen leichtgewichtigen, inkrementellen und iterativen Ansatz, der auf Prinzipien und Werten beruht. Typisch sind dabei:

  • Kurze Iterationen, in denen entwickelt wird.
  • Ein inkrementelles Wachsen eines Produktes über die Zeit (die Iterationen).
  • Prinzipien und Werte als Basis.
  • Ein flexibler Umfang, der mit dem Kunden gemeinsam abgestimmt und festgelegt wird.

Aufpassen, "agil" ist heute alles!

Der Begriff agil wird heute für so ziemlich alles verwendet. Selbst Tools und Koffer sind heute agil, was als Eigenschaft dann doch eher Lebenwesen zugeschrieben werden sollte 😉

Merke dir für agil immer: leichtgewichtig, iterativ und inkrementelle Produktentwicklung

Das Projektdreieck

klassisch vs. agile - Projektdreieck

Das Projektdreieck besteht - wie der Name schon vermuten lässt - aus drei Ecken, die Eigenschaften eines Projektes beschreiben. Diese stelle ich gleich im Detail vor. Wichtig zu verstehen sind die folgenden Punkte

  • Die Qualität befindet sich in der Mitte des Dreiecks und ist eine nicht verhandelbare Größe. Wir nehmen Sie als fest an.
  • Der Unterschied in der Betrachtung eines klassischen und agilen Projektdreiecks liegt darin, das Projektdreieck umzudrehen.
  • Zudem sind bei einer klassischen und agilen Sichtweise jeweils andere Dinge in dem Projektdreieck variabel und andere fest.

Die drei Ecken des Dreiecks

Budget

Budget beschreibt die Eigenschaft Geld für das Projekt. Das ist in der Regel genau das zur Verfügung stehende Budget, das durch einen Kunden für die Entwicklung für ein Produkt bezahlt wird.

Zeit

Zeit beschreibt die zur Verfügung stehende zeitliche Komponente im Projekt. Oft wird dieses durch einen Kunden vorgegeben aufgrund von einer Messe, einem Serienstart oder ähnlichen Terminen.

Umfang

Umfang beschreibt was alles zu dem Projekt gehört. Das sind die Anforderungen, die der Kunde hat und die er sich wünscht, damit das fertige Produkt seinen Vorstellungen entspricht.

Die klassische Sicht auf das Projekt

Betrachten wir ein klassisches, sequentielles, plangetriebenes Vorgehen zur Produktentwicklung, dann finden wir die folgenden Parameter:

  • Der Umfang des Projektes wird zu Beginn mehr oder weniger vollumfänglich beschrieben. Auch wenn das keine 100% sein müssen, findet zu Beginn in der Regel eine recht lange Zeit statt, um Anforderungen aufzuschreiben und diese abzustimmen (mehrere Monate).
  • Die Eigenschaft Zeit - also wann etwas fertig sein soll - ist im Bereich der Wissensarbeit nicht einfach festzuhalten. Sie wissen schlicht nicht, wann Ihnen eine Idee kommt und können diese auch schlecht planen. Die Zeit wird häufig durch Projektleiter minutiös geplant und Menschen werden dann zu Arbeitspaketen zugewiesen. Eine trügerische Sicherheit, sich einen solchen Plan zu erstellen!
  • Das Budget ist eine Größe, die stark an dem Umfang ("ich will aber noch etwas mehr von dem Inhalt") und mit der Zeit ("noch ein Sprint und dann können wir das machen") verknüpft ist. In den meisten Projekten ist das Budget zusätzlich gerne eine feste Größe - "wir haben nur 120.000 Euro".

Die agile Sicht auf das Projekt

In agilen Frameworks treffen wir zwei wesentliche Änderungen zu sequentiellen Vorgehen:

  • Wir nehmen die Zeit als feste Größe an. Deshalb existieren immer Iterationen fester Länge, die es erlauben eine Aussage für einen bestimmten Zeitabschnitt zu treffen.
  • Das Budget ist ebenso festgelegt. Wenn wir einen Betrag von 120.000 Euro für das Projekt haben, dann werden wir auch diesen Betrag halten wollen.

Natürlich wird schnell klar, auch in diesem Setting brauchen wir eine Größe, über die wir Änderungen abfangen können und das ist im Agilen immer der Umfang.

Der Kunde gibt Geld und Zeit und weiß nicht was er bekommt?

Der beliebteste Einwand in Trainings ist oft, "ja sicher, der Kunden gibt Geld und wann es fertig sein soll und weiß nicht was er bekommt?! Im Leben nicht!".

Stimmt, das passiert nämlich auch nicht. Im Gegensatz zu einem sequentiellen, plangetriebenen Vorgehen gibt es keinen detaillierten Plan über das ganze Projekt mit allen Anforderungen bis zum Ende. Wir nutzen bei der agilen Produktentwicklung das Product Backlog.

Das Product Backlog ist immer D.E.E.P. und ist relativ nach Wichtigkeit sortiert. Das, was im Backlog oben steht, wird sehr, sehr wahrscheinlich bald verfügbar sein. Der Kunde bekommt eine Umsetzung mit dem Wichtigsten zuerst und das in der Regel schneller, als im sequentiellen plangetriebenen Vorgehen.

klassisch vs. agile 2

Einsatzmöglichkeiten

Über den Einsatzzweck werden häufig verbitterte Kämpfe gefochten, klassisch vs. agile findet sich sowohl in Gesprächen statt, als auch auf digitalen Plattformen. Ich möchte und kann dir in diesem Artikel keine allgemeingültige Antwort geben, was für dich besser ist. Ich möchte dir aber gerne eine Möglichkeit mitgeben, dass Thema klassisch vs. agile für dich zu bestimmen. Dazu müssen wir uns anschauen, wann sich welcher Ansatz lohnt einzusetzen.

Kein Richtig oder Falsch

Ob sich ein klassischer oder agiler Ansatz für dein Produkt eignet, kann pauschal nicht beantwortet werden und das ist die falsche Frage. Du musst dabei auf dein zu entwickelndes Produkt schauen, die Rahmenbedingungen und Möglichkeiten abwägen und dann auf Basis deiner Situation die Entscheidung treffen.

Wann lohnt sich "klassisch"?

Grundsätzlich ist ein klassischer, sequentieller und plangetriebener Ansatz - den viele Unternehmen schon lange machen - nicht schlecht. Wenn ich eine Umgebung habe, in der ich mit entsprechende Analyse etwas durchdringen kann, das Ergebnis dieser Analyse sich über die Zeit nicht oder nur sehr wenig ändert, dann kann ich einen Plan aufstellen und diesen recht gut abarbeiten, denn Änderungen daran finden wenig statt.

Jetzt kannst du dich selbst einfach fragen, ob solche Rahmenbedingungen bei dir herrschen. Aus meiner Sicht gibt es das noch, die immer komplexeren Rahmenbedingungen finden sich überall und immer verstärkter. Peter Drucker sagte einmal:


The greatest danger in times of turbulence is not the turbulence; it is to act with yesterday's logic.


Peter Drucker (Quelle)

Und mehr als dieses grandiose Zitat nutzen bleibt mir nicht über. Du musst in deiner Organisation wissen, wann es sich lohnt mit welchem Vorgehen (Logik) zu reagieren.

Wann lohnt sich "agile"?

Wenn wir der Diskussion klassisch vs. agile folgen, dann können wir das zum einem mit dem Stacey Landscape Diagram tun (siehe unten) oder mit dem Cynefin Framework, auf das ich hier nicht weiter eingehe, dass aber sehr interessante "Handlungsempfehlungen" ausspricht und diese möchte ich für das Verständnis kurz beschreiben.

Cynefin: Probe Sense Respond

Probe

Wir stellen jemanden auf Basis unserer bisherigen Erkenntnisse etwas vor.

Sense

Wir beobachten, wir lernen wie unser Gegenüber damit umgeht, was er will.

Respond

Wir können mit diesen Erfahrungen reagieren und den weiteren Weg bestimmen.

Stacey Landscape Diagram

Zwei Modelle haben sich in der Praxis behauptet, um den Einsatz von etwas "agilem" zu bestimmen. Diese beiden Modelle sind lediglich Denkmodelle und nicht exakt. Sie geben aber eine gute Richtung, mit der du arbeiten kannst.

Da ich das Stacey Landscape Diagram an anderer Stelle bereits besprochen habe, gehe ich hier nicht weiter darauf ein.

klassisch vs. agile - Stacey Landscape Diagram

Früher Return of Invest

Liefern wir früh Wert und kann ein Kunde damit etwas anfangen, haben wir die Chance das Richtige für den Kunden zu entwickeln. Wenn wir die Rahmenbedingungen von oben (schlecht planbar, wechselnde Anforderungen, Cynefin) mit einbeziehen, dann müssen wir in kleinen Schritten uns zum Ziel vorarbeiten und immer wieder überprüfen, ob wir auf dem richtigen Weg sind.

Einige wichtige Voraussetzungen

Product Owner

Wir brauchen eine Person, die in der Lage ist den Mehrwert für den Kunden zu erkennen und das Produkt auf maximalen Wert zu optimieren. Solche Personen heißen oft Product Owner (nicht nur in Scrum) und haben den Fokus auf dem Produkt.

Inkrementelle Entwicklung

Wir müssen in der Lage sein, inkrementell ein Produkt liefern zu können. Bei der Diskussion über klassisch vs. agile ist das häufig ein Punkt, der (noch) nicht durch alle Unternehmen erfolgen kann. Was und wie ein Inkrement in "nicht Software"-Bereichen aussieht, zum Beispiel bei Scrum in der Hardware, müssen Sie im konkreten Einzelfall erarbeiten.

Feedback und Raum zum Lernen

Wir müssen vom Kunden, vom System, von der entsprechenden Zielgruppe unseres Produktes ein Feedback bekommen. Nur wenn das erfolgt können wir von unserem "probe" zu einem "sense" übergehen und dann darauf reagieren ("respond").

Ein gutes Team

Ein Team ist in der Regel immer der Hauptpunkt, an dem die Probleme in Organisationen an die Oberfläche kommen. Dabei sind die wichtigen Punkte

  • Das Team ist konstant und arbeiten zusammen (möglichst an einem Ort)
  • Innerhalb des Teams existieren alle Fähigkeiten, die es benötigt, das Produkt zu entwickeln
  • Alle arbeiten Vollzeit in dem Team (mindest. ca. 80%)

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>