Agile
Statt ein Projekt von Anfang bis Ende durchzuplanen, arbeitet ein Team in kurzen Zyklen. Nach jeder Runde prüft es das Ergebnis, sammelt Rückmeldungen und passt den Kurs an. Diese Arbeitsweise heißt Agile.
Der Begriff geht auf das Agile Manifest zurück, das 2001 von 17 Softwareentwicklern veröffentlicht wurde. Es formuliert vier Leitsätze: Individuen und Interaktionen stehen über Prozessen und Werkzeugen. Funktionierende Software steht über umfassender Dokumentation. Zusammenarbeit mit dem Kunden steht über Vertragsverhandlung. Reagieren auf Veränderung steht über dem Befolgen eines Plans. Diese Sätze sind bewusst als Präferenzen formuliert: Die rechte Seite hat Wert, die linke Seite hat mehr Wert.
Kurze Zyklen statt langer Pläne
In klassischen Projektmodellen durchläuft ein Vorhaben nacheinander die Phasen Analyse, Entwurf, Umsetzung und Test. Erst am Ende zeigt sich, ob das Ergebnis den Anforderungen entspricht. Bei agiler Arbeit wird diese Abfolge in kurze Iterationen zerlegt. Jede Iteration dauert ein bis vier Wochen und liefert ein funktionsfähiges Teilergebnis.
Beispiel: Ein Team entwickelt eine Suchfunktion für eine interne Wissensdatenbank. Statt alle Anforderungen vorab zu spezifizieren, liefert es nach zwei Wochen eine Basissuche mit Volltextabgleich. In der nächsten Iteration kommen Filter hinzu. In der dritten folgt eine Relevanzsortierung. Nach jeder Iteration entscheiden die Nutzer, welche Verbesserung als nächstes den größten Unterschied macht.
Beispiel: Ein Machine-Learning-Projekt zur automatischen Klassifikation von Support-Tickets beginnt mit einem einfachen Regelwerk. Nach der ersten Iteration zeigt sich, dass 60 Prozent der Tickets korrekt zugeordnet werden. Die zweite Iteration ersetzt das Regelwerk durch ein trainiertes Modell und erreicht 82 Prozent. Ohne die frühe Messung hätte das Team möglicherweise Monate an einem überdimensionierten System gearbeitet.
Fachliche Einordnung: Die Zerlegung in kurze Zyklen basiert auf dem empirischen Prozesssteuerungsmodell. Statt auf Vorhersagen setzt es auf Transparenz, Überprüfung und Anpassung. In der Regelungstechnik entspricht das einem geschlossenen Regelkreis mit kurzer Abtastrate.
Scrum, Kanban und andere Rahmenwerke
Agile ist kein einzelnes Verfahren, sondern ein Oberbegriff. Die konkreten Rahmenwerke unterscheiden sich in ihrer Struktur erheblich.
Scrum definiert feste Rollen (Product Owner, Scrum Master, Entwicklungsteam), feste Ereignisse (Sprint Planning, Daily Standup, Sprint Review, Retrospektive) und feste Artefakte (Product Backlog, Sprint Backlog, Inkrement). Ein Sprint dauert maximal vier Wochen. Am Ende steht ein potenziell auslieferbares Produktinkrement.
Beispiel: Ein fünfköpfiges Team arbeitet in zweiwöchigen Sprints an einem Dashboard für Echtzeit-Monitoring. Der Product Owner priorisiert die Anforderungen: Zuerst Serverauslastung, dann Netzwerktraffic, dann Alarmierungen. Nach jedem Sprint begutachten die Stakeholder den Stand und können die Prioritäten ändern.
Kanban stammt ursprünglich aus der japanischen Fertigungsindustrie und begrenzt die Menge gleichzeitig laufender Aufgaben (Work in Progress). Ein Board visualisiert den Arbeitsfluss in Spalten wie "Bereit", "In Arbeit" und "Fertig". Wenn eine Spalte ihr Limit erreicht, darf keine neue Aufgabe hinein, bis eine bestehende weiterrückt.
Beispiel: Ein Datenteam setzt ein WIP-Limit von drei für die Spalte "In Arbeit". Als eine vierte Analyse-Anfrage eingeht, bleibt sie in der Warteschlange. Das zwingt das Team, laufende Aufgaben abzuschließen, bevor es neue beginnt. Die durchschnittliche Bearbeitungszeit sinkt von 14 auf 8 Tage.
Weitere Rahmenwerke sind Extreme Programming (XP) mit Schwerpunkt auf technischen Praktiken wie Paarprogrammierung und testgetriebener Entwicklung, Crystal mit Fokus auf Kommunikation in kleinen Teams und Feature-Driven Development (FDD) für modellgetriebene Vorgehensweisen.
Rollen und Verantwortlichkeiten
Agile Rahmenwerke verteilen Verantwortung anders als klassische Projektstrukturen. Statt einer einzelnen Projektleitung, die alle Entscheidungen trifft, gibt es spezialisierte Rollen mit klar abgegrenzten Befugnissen.
Der Product Owner vertritt die Perspektive der Nutzer und Stakeholder. Er pflegt das Product Backlog, eine geordnete Liste aller gewünschten Funktionen und Verbesserungen. Die Reihenfolge der Einträge bestimmt, woran das Team als nächstes arbeitet.
Beispiel: Ein Product Owner in einem NLP-Projekt entscheidet, ob das Team zuerst die Erkennungsgenauigkeit für deutsche Texte verbessert oder eine neue Sprache hinzufügt. Er stützt diese Entscheidung auf Nutzungsdaten und Feedback aus dem Support.
Das Entwicklungsteam organisiert sich selbst. Es entscheidet, wie die Arbeit innerhalb eines Sprints aufgeteilt wird. Selbstorganisation bedeutet nicht Regellosigkeit. Das Team einigt sich auf Arbeitspraktiken, Qualitätsstandards und die Definition of Done.
Beispiel: Ein Team legt als Definition of Done fest: Code ist geschrieben, automatisierte Tests laufen durch, die Änderung ist auf einer Testumgebung deployt und ein zweites Teammitglied hat den Code geprüft. Erst wenn alle Punkte erfüllt sind, gilt eine Aufgabe als abgeschlossen.
Agile Arbeitsweise in KI-Projekten
KI-Projekte unterscheiden sich von klassischen Softwareprojekten in mehreren Punkten: Die Ergebnisqualität hängt stark von den verfügbaren Daten ab. Modellverhalten ist nicht vollständig vorhersagbar. Experimentelle Phasen lassen sich schwer in feste Zeiträume pressen.
Trotzdem profitieren KI-Vorhaben von kurzen Iterationen. Frühe Prototypen zeigen, ob ein Ansatz grundsätzlich funktioniert, bevor umfangreiche Datenaufbereitung und Modelloptimierung beginnen.
Beispiel: Ein Team will automatisch Vertragsdokumente analysieren. In der ersten Iteration testet es ein vortrainiertes Transformer-Modell auf 200 Beispieldokumenten. Die Genauigkeit liegt bei 71 Prozent. Die Stakeholder entscheiden auf dieser Basis, ob sich eine Investition in manuell annotierte Trainingsdaten lohnt.
Beispiel: Ein Deep-Learning-Projekt zur Bilderkennung in der Qualitätskontrolle durchläuft drei Iterationen mit unterschiedlichen Modellarchitekturen. Nach jeder Iteration bewertet das Fachpersonal die Ergebnisse an realen Bauteilen. Die dritte Iteration trifft die geforderte Fehlerquote von unter 2 Prozent.
Allerdings passen manche Aspekte von KI-Projekten schlecht in starre Sprint-Grenzen. Das Training eines großen Modells kann Tage dauern und lässt sich nicht in eine zweiwöchige Iteration zwingen. Hier bieten sich Kanban-artige Ansätze mit flexiblen Zeiträumen an, die den Arbeitsfluss statt fester Termine in den Mittelpunkt stellen.
Fortschritt messen statt schätzen
Agile Teams messen den Projektfortschritt anhand tatsächlich gelieferter Ergebnisse, nicht anhand abgearbeiteter Planungsschritte. Drei Metriken haben sich etabliert:
Velocity misst die Menge an Arbeit, die ein Team pro Iteration abschließt, üblicherweise in Story Points oder Anzahl erledigter Aufgaben. Dieser Wert dient der Planung künftiger Iterationen, nicht der Leistungsbewertung einzelner Personen.
Lead Time misst die Dauer von der Anforderung bis zur Auslieferung. Cycle Time misst die Dauer von Arbeitsbeginn bis Fertigstellung. Die Differenz zwischen beiden zeigt Wartezeiten auf.
Beispiel: Ein Team stellt fest, dass seine Lead Time 18 Tage beträgt, die Cycle Time aber nur 4 Tage. 14 Tage verbringt eine Aufgabe in Warteschlangen. Die Ursache: zu viele parallele Projekte. Nach Einführung eines WIP-Limits sinkt die Lead Time auf 7 Tage.
Beispiel: Ein Team nutzt ein Burndown-Chart, das täglich anzeigt, wie viele Story Points im laufenden Sprint noch offen sind. Am siebten Tag eines 14-Tage-Sprints zeigt das Chart, dass noch 70 Prozent der geplanten Punkte offen sind. Das Team reduziert den Sprint-Umfang und verschiebt zwei Aufgaben in den nächsten Sprint.
Agile Prinzipien in größeren Organisationen
Die ursprünglichen agilen Methoden sind für kleine Teams von fünf bis neun Personen konzipiert. Wenn mehrere Teams an einem gemeinsamen Produkt arbeiten, entstehen Koordinationsprobleme: Abhängigkeiten zwischen Teams, widersprüchliche Prioritäten und divergierende technische Entscheidungen.
Skalierungsrahmenwerke wie SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum) und Nexus versuchen, agile Prinzipien auf Dutzende oder Hunderte von Teams auszuweiten. Sie führen zusätzliche Abstimmungsebenen ein: gemeinsame Planungsevents, übergreifende Backlogs und synchronisierte Iterationen.
Beispiel: Ein Unternehmen mit acht Entwicklungsteams führt ein quartalsweises PI-Planning (Program Increment Planning) ein. Alle Teams planen gleichzeitig die nächsten zehn Wochen und identifizieren Abhängigkeiten. Ein Team erkennt, dass es eine Schnittstelle benötigt, die ein anderes Team erst in Woche sechs liefern kann. Ohne diese synchronisierte Planung hätte das erste Team sechs Wochen auf ein blockierendes Element gewartet.
Die Spannung zwischen Agilität und Skalierung ist real. Mehr Koordination bedeutet mehr Meetings, mehr Rollen und mehr Overhead. Manche Organisationen verlieren dabei genau die Flexibilität, die agile Methoden versprechen. Der Widerspruch lässt sich nicht durch ein Rahmenwerk auflösen, sondern erfordert fortlaufende Reflexion über das Verhältnis von Struktur und Freiheit.
Grenzen und häufige Fehlschlüsse
Agile Methoden sind kein Universalwerkzeug. Sie setzen voraus, dass Anforderungen sich im Projektverlauf verändern und dass regelmäßiges Feedback möglich ist. Wo Anforderungen stabil und vollständig bekannt sind, etwa bei regulatorisch vorgeschriebenen Prozessen oder bei Bauprojekten mit festen Spezifikationen, bieten kurze Iterationen wenig Vorteil.
Beispiel: Die Entwicklung eines medizinischen Geräts unterliegt strengen Zulassungsvorschriften. Jede Änderung am Design erfordert eine neue Zertifizierung. Hier wäre ein iteratives Vorgehen mit häufigen Kursänderungen teurer als ein sequenzielles Modell mit ausführlicher Vorabplanung.
Ein verbreiteter Fehlschluss lautet: "Agile bedeutet keine Dokumentation." Das Agile Manifest bevorzugt funktionierende Software gegenüber umfassender Dokumentation. Das ist eine Präferenz, keine Abschaffung. Systeme mit langer Lebensdauer oder hoher Komplexität brauchen Dokumentation, um wartbar zu bleiben.
Ein weiterer Fehlschluss: "Agile Teams brauchen keine Planung." Agile Teams planen fortlaufend. Der Unterschied liegt im Zeithorizont: detailliert für die nächste Iteration, grob für das Quartal, richtungsweisend für das Jahr. Die Planung ist nicht abwesend, sondern anders verteilt.
Beispiel: Ein Team interpretiert "agil" als Freifahrtschein gegen Prozesse. Es gibt kein Backlog, keine Retrospektiven und keine Messung. Nach sechs Monaten kann niemand nachvollziehen, welche Entscheidungen wann getroffen wurden. Das Projekt wird gestoppt. Agilität ohne Disziplin ist Chaos.
Fachliche Einordnung: Die Kritik an agilen Methoden ist nicht neu. Bereits 2003 wies Alistair Cockburn darauf hin, dass agile Methoden ein bestimmtes Organisations- und Teamklima voraussetzen. Wo Vertrauen, Kommunikation und technische Kompetenz fehlen, scheitern agile Ansätze ebenso zuverlässig wie andere Methoden. Der Wert von Agile liegt nicht in den Zeremonien, sondern in der Bereitschaft, Annahmen frühzeitig zu überprüfen und daraus zu lernen.