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

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:
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:
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

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 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:
Die agile Sicht auf das Projekt
In agilen Frameworks treffen wir zwei wesentliche Änderungen zu sequentiellen Vorgehen:
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.

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.

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.

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