Klassisch, agil oder hybrid? — Methoden nicht nach Mode, sondern nach Projektlogik wählen

Projektmanagement-Diskussionen klingen erstaunlich oft wie Lagerkämpfe. Klassisches Projektmanagement gilt dann als schwerfällig, agil als modern, Scrum als professionell und Kanban als flexibel. Oder umgekehrt: Agil wird mit fehlender Planung verwechselt, während ein detaillierter Projektplan automatisch als Ausdruck von Kontrolle gilt.

Diese Gegenüberstellung führt in KI-Projekten besonders schnell in die Irre.

Denn die entscheidende Frage ist nicht, welche Methode moderner klingt. Entscheidend ist, welche Steuerungslogik zum Projekt passt.

Dieser Gedanke lässt sich im Unterricht über mehrere Tage aufbauen. Bereits zu Beginn sollten klassische und agile Projektmanagement-Ansätze nicht nur aufgezählt, sondern recherchiert und unterschieden werden. Später wurden Scrum und Kanban konkret gegenübergestellt, Rollen wie Scrum Master, Agile Coach und sogar die Kundenperspektive mit KI simuliert und daraus Hybridansätze entwickelt. Am Folgetag wurde ein realer Teilnehmeransatz diskutiert, der klassisches Projektmanagement bewusst mit agilen Elementen verband.

Das ist mehr als Methodenlehre. Dahinter steckt ein Grundprinzip:

Die Methode folgt der Unsicherheit, der Veränderungsdynamik und der Struktur des Projekts — nicht dem Trend.

Drei Steuerungslogiken statt drei Glaubensrichtungen

Klassisch, agil und hybrid lassen sich am besten nicht als Toolsets, sondern als unterschiedliche Antworten auf Unsicherheit verstehen.

Klassisch: zuerst Struktur, dann Ausführung

Eine klassische Logik ist stark, wenn ein Projekt früh relativ zuverlässig beschreibbar ist.

Das bedeutet nicht, dass alles unveränderlich sein muss. Es bedeutet, dass wesentliche Größen bereits vor der Umsetzung belastbar bestimmt werden können:

• das Ziel,

• der Scope,

• zentrale Anforderungen,

• wichtige Abhängigkeiten,

• Meilensteine,

• Ressourcen,

• Freigaben,

• Lieferobjekte.

Dann lohnt es sich, viel Struktur nach vorne zu verlagern. Entscheidungen werden früh getroffen, Arbeitspakete geplant und Abhängigkeiten sichtbar gemacht. Die Ausführung soll anschließend möglichst kontrolliert durch den vorbereiteten Pfad laufen.

Diese Logik ist besonders wertvoll, wenn spätere Änderungen teuer sind. Wenn beispielsweise Verträge, externe Produktion, Beschaffung, regulatorische Freigaben oder stark voneinander abhängige Lieferketten beteiligt sind, kann „wir schauen im Sprint, was wir lernen" eine sehr kostspielige Haltung werden.

Die Stärke klassischer Planung ist daher nicht Starrheit, sondern Vorab-Koordination.

Agil: ausführen, lernen, neu entscheiden

Eine agile Logik wird stark, wenn zentrale Informationen erst während der Arbeit entstehen.

Vielleicht ist das Ziel klar, aber noch nicht der beste Lösungsweg. Vielleicht kann ein Nutzerfeedback das Produkt fundamental verändern. Vielleicht liefert ein KI-Modell in der Praxis andere Ergebnisse als im Test. Vielleicht weiß das Team erst nach einem Prototyp, welche Architektur tragfähig ist.

Dann wäre ein sehr detaillierter Langfristplan keine zusätzliche Sicherheit. Er würde lediglich Unsicherheit in präzise klingende Annahmen übersetzen.

Agile Arbeit verschiebt deshalb einen Teil der Entscheidung bewusst nach hinten. Kleine Einheiten werden umgesetzt, geprüft und auf Basis neuer Evidenz angepasst.

Die Stärke liegt nicht darin, weniger zu planen. Die Stärke liegt darin, Planung und Lernen enger zu koppeln.

Hybrid: Stabilität außen, Anpassung innen

Viele reale KI-Projekte passen weder sauber in die eine noch in die andere Kategorie.

Das Budget kann fix sein, während die technische Umsetzung iterativ bleibt. Der Launchtermin kann feststehen, während Funktionen priorisiert werden. Compliance- oder Kundenanforderungen können verbindlich sein, während Modellwahl, Prompting, Datenaufbereitung und UX in Schleifen entwickelt werden.

Genau hier entsteht die hybride Logik.

Hybrid bedeutet nicht: „Wir nehmen einfach ein bisschen von allem."

Ein guter Hybridansatz trennt bewusst zwischen:

• stabilen Projektgrenzen, die früh entschieden werden,

• und adaptiven Arbeitsräumen, die innerhalb dieser Grenzen iterativ bearbeitet werden.

Die nützlichste Kurzform lautet:

Stabile Hülle, lernender Kern.

Der Unterricht ging bewusst über Definitionen hinaus

Guter Unterricht behandelt agile Methoden nicht nur als Begriffe für eine Prüfung.

Zunächst wird eine Recherchebasis aufgebaut: Welche Projektmanagementmethoden existieren, wie unterscheiden sich klassische und agile Ansätze, und welche davon sind für das eigene Projekt relevant?

Anschließend wird die Diskussion konkreter. Im Unterricht zu Scrum und Kanban geht es nicht nur um Boards. Die Logik der Methoden wird mit Rollen verbunden. Die KI kann beispielsweise als Scrum Master, Agile Coach oder Kunde eingesetzt werden. Dadurch lässt sich eine Methode nicht nur beschreiben, sondern durchspielen.

Das ist didaktisch wichtig.

Eine Methode versteht man nicht vollständig, wenn man ihre Definition kennt. Man versteht sie, wenn man erlebt:

• wann eine neue Anforderung aufgenommen werden darf,

• wann laufende Arbeit geschützt werden muss,

• wie Prioritäten verändert werden,

• wer Entscheidungen trifft,

• wie Feedback in die nächste Arbeitsphase gelangt,

• und welche Information ein Team braucht, um weiterarbeiten zu können.

Am Folgetag wird diese Theorie in Projektbeispiele überführt. Ein Teilnehmer hatte einen Hybridansatz aus klassischem Projektmanagement und agilen Elementen vorbereitet. Genau diese Übertragung vom Methodenwissen auf einen realen Projektkontext ist der entscheidende Schritt.

Die Frage lautet also nicht: „Kann ich Scrum erklären?"

Sondern:

„Welche Teile meines Projekts brauchen verbindliche Planung — und welche Teile brauchen bewusst kurze Lernschleifen?"

Projektlogik 1: Wie stabil ist das Problem selbst?

Der erste Entscheidungsfaktor ist nicht der Lösungsweg, sondern das Problem.

Wenn sich bereits die Problemdefinition häufig verändert, ist langfristige Detailplanung riskant. Das Team plant dann womöglich präzise auf ein Ziel zu, das wenige Wochen später anders formuliert wird.

Ist das Problem dagegen stabil und gut verstanden, kann mehr Vorarbeit sinnvoll sein.

Beispiel:

Ein Unternehmen möchte eine fest definierte interne Schulung zu einem bekannten KI-Workflow erstellen. Zielgruppe, Termin, Format, Lernziele und Freigabestruktur stehen. Hier kann ein großer Teil klassisch geplant werden.

Ein anderes Team möchte herausfinden, welches neue KI-Produkt Kunden überhaupt benötigen. Das Problem ist noch unscharf, Nutzerreaktionen sind entscheidend und technische Möglichkeiten verändern die Idee. Hier sollte die Projektlogik stärker explorativ und agil sein.

Projektlogik 2: Wie teuer ist Veränderung?

Nicht jede Unsicherheit muss agil behandelt werden.

Entscheidend ist auch, was eine spätere Änderung kostet.

Eine Textstruktur kann billig geändert werden. Eine neue Datenbankarchitektur kann bereits deutlich teurer sein. Ein vertraglich gebundener externer Produktionsschritt oder eine Hardwarebestellung kann sehr teuer rückgängig zu machen sein.

Je höher die Änderungskosten, desto mehr lohnt sich frühe Klärung.

Das führt zu einem wichtigen Hybridprinzip:

Plane irreversible Entscheidungen früher und reversible Entscheidungen später.

Damit wird Hybridität nicht zum Methodencocktail, sondern zu einer ökonomischen Steuerungslogik.

Projektlogik 3: Wie schnell bekommen wir echtes Feedback?

Agile Schleifen funktionieren nur, wenn sie tatsächlich lernen können.

Ein Sprint ohne relevantes Feedback ist nur ein kürzerer Planungsblock.

Ein Kanban-Board ohne Daten über Durchlauf, Blocker oder Priorität ist nur eine hübsche Aufgabenliste.

Die entscheidende Frage lautet deshalb:

Wie schnell erreicht uns neue Information, die eine Entscheidung verbessern kann?

Bei einem digitalen Prototyp kann das innerhalb von Stunden oder Tagen geschehen. Bei einer langfristigen Infrastrukturmaßnahme kann relevantes Feedback erst Wochen später entstehen.

Je kürzer die Feedback-Latenz, desto wertvoller werden iterative Arbeitsweisen.

Projektlogik 4: Wie viele Abhängigkeiten müssen synchron bleiben?

Agilität wird oft mit Flexibilität gleichgesetzt. Aber hohe Abhängigkeit kann Flexibilität begrenzen.

Wenn fünf Arbeitspakete unabhängig voneinander entwickelt werden können, lassen sie sich leicht neu priorisieren. Wenn dagegen Aufgabe B zwingend auf A wartet, C und D dieselbe Ressource benötigen und E erst nach externer Freigabe beginnen darf, entsteht eine stärkere Planungsnotwendigkeit.

Das bedeutet nicht automatisch „klassisch".

Es bedeutet: Der adaptive Teil des Projekts braucht eine stabile Koordinationsschicht.

Gerade KI-Projekte profitieren häufig davon, Experimentierarbeit agil auszuführen, während Ressourcen, Freigaben, Datenzugriffe und zentrale Abhängigkeiten verbindlich geplant werden.

Projektlogik 5: Was muss verbindlich sein — und was darf experimentell bleiben?

Diese Trennung ist für KI-Projekte besonders relevant.

Verbindlich können beispielsweise sein:

• Datenschutzgrenzen,

• Budgetobergrenzen,

• Liefertermine,

• Freigaberechte,

• Datenquellen,

• Qualitätskriterien,

• Sicherheitsregeln,

• vertraglich definierte Deliverables.

Experimentell können dagegen bleiben:

• Modellwahl,

• Promptstrategien,

• Varianten von Workflows,

• Interface-Lösungen,

• Agentenaufteilungen,

• Reihenfolge kleiner Optimierungen.

Ein guter Hybridansatz behandelt diese beiden Kategorien nicht gleich.

Er verhindert, dass verbindliche Grenzen „agil wegiteriert" werden — und ebenso, dass experimentelle Entscheidungen zu früh in einem starren Projektplan eingefroren werden.