klassisch vs. agile

Klassisch vs. Agile – ein Vergleich

Klassisch vs. agile ist wohl eines der am häufigst diskutierten Themen in meinen ​Trainings zu Scrum und agilen Grundlagen. Gern diskutiere ich in diesem Artikel mit meinen Lesern einmal die Erfahrungen und Ergebnisse, damit Sie sich ebenso ein Bild machen können.

Klassisch vs. agile

klassisch vs. agile

Was bedeutet "klassisch"?

Wenn wir den Begriff von "klassisch" in der Entwicklung von Produkten nutzen, dann fällt oft ein weiterer Begriff: Wasserfall bzw. Wasserfallmodell. Ich bin kein Freund von diesem Begriff, denn das durch den Begriff beschreibende Modell ist der in der Realität so gut wie nie wirklich genau so eingesetzt worden.

Es gibt allerdings starke Ähnlichkeiten mit einer Art und Weise aktuell zu arbeiten, weshalb 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.

Hinweis Zur Bedeutung

Jetzt ist das Leben nun mal nicht schwarz weiß und auch der klassisch vs. agile Betrachtung ist es nicht so. Es gibt durchaus Mischformen, die aber immer wieder einzelne der oben genannten Symptome aufzeigen.

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 inkrementellen und iterativen Ansatz, der leichtgewichtig ist auf Prinzipien und Werten beruht. Typisch sind dabei:

  • Kurze Iterationen, in denen entwickelt wird.
  • Ein Iteratives 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.

Hinweis Zur Bedeutung

Es gibt unterschiedliche Ansätze, die zu "Agile" hinzugerehnet werden. So gibt es Scrum, Frameworks zur Skalierung (LeSS, SAFe), Ansätze wie Lean Startup und Design Thinking. Mittlerweile findet sich auch immer häufiger etwas, wie "agiles Arbeiten". Dadurch existieren auch unterschiedliche Prägungen der oben genannten Punkte.

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 zwischen einer agile und klassischen Betrachtung, liegt darin, das Projektdreieck ​umzudrehen.
  • klassisch vs. agile bedeutet zudem, dass andere Eigenschaften im Projekt fix bzw. variabel sind.

​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

​Folgende Annahmen treffen wir, wenn wir uns ein klassisches, sequentielles, plangetriebenes Vorgehen ansehen.

  • ​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.
  • 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.

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 gibt es immer Iterationen fester Länge, die es erlauben eine Aussage für einen bestimmten Zeitabschnitt zu treffen
  • Das Budget ist auch fix. Wenn wir einen Betrag von 200.000 Euro für das Projekt haben, dann werden wir auch diesen Betrag halten wollen.

Natürlich wird schnell klar, auch wir brauchen 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 nicht. Auch wenn es im Gegensatz zu einem sequentiellen, plangetriebenen Vorgehen keinen detaillierten Plan über das ganze Projekt mit allen Anforderungen gibt, haben wir im agilen das Product Backlog.

Das Product Backlog ist immer D.E.E.P. und ist relativ nach Wichtigkeit priorisiert. Das, was im Backlog oben steht, wird sehr, sehr wahrscheinlich bald auch 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 Ihnen in diesem Artikel keine allgemeingültige Antwort geben. Ich gebe Ihnen aber eine Möglichkeit, dass Thema klassisch vs. agile für sich zu bestimmen. Dazu müssen wir uns anschauen, wann sich welcher Ansatz lohnt, also wo lohnt es sich diese Einzusetzen.

Wann lohnt sich "klassisch"?

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

Diese Rahmenbedingungen (die wir als einfach / kompliziert; vgl. Stacey unten) benennen, treten aus meiner Sicht nicht mehr so oft auf.

Peter Drucker sagte schon "The greatest danger in times of turbulence is not the turbulence; it is to act with yesterday's logic." und das trifft es auch sehr gut. Wenn Ihr Geschäft, Ihr Business in einem ohne "Turbulenzen" ist, dann ist alles einfach und überschaubar.

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 Richtung, mit der Sie arbeiten können.

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%)

Leave a Reply 0 comments

Leave a Reply:







>
close

Der neue Online Scrum Kurs!

Der Online Scrum Kurs