Herkunft: das Agile Manifest
Im Februar 2001 trafen sich 17 Softwareentwickler in einem Skigebiet in Utah. Sie vertraten unterschiedliche, damals „leichtgewichtig“ genannte Methoden – darunter Extreme Programming, Scrum, DSDM, Crystal und Feature-Driven Development – und suchten den gemeinsamen Nenner. Heraus kam das „Manifest für Agile Softwareentwicklung“ mit vier Werten und zwölf Prinzipien.
Sinngemäß stellen die vier Werte jeweils zwei Dinge gegenüber und gewichten das erste höher:
- Menschen und ihre Zusammenarbeit vor Prozessen und Werkzeugen
- Funktionierende Ergebnisse vor umfassender Dokumentation
- Zusammenarbeit mit Kund:innen vor Vertragsverhandlungen
- Auf Veränderung reagieren vor dem Abarbeiten eines Plans
Oft überlesen wird der Nachsatz des Manifests: Die jeweils zweite Seite bleibt wertvoll, sie zählt nur weniger. Agile Teams planen und dokumentieren also durchaus – nur so viel, wie tatsächlich weiterhilft.
Was agiles Arbeiten im Kern ausmacht
Methoden gibt es viele, die Grundmuster sind aber überall ähnlich. Statt eines großen Wurfs am Projektende entsteht das Ergebnis in Etappen, und nach jeder Etappe wird geprüft, ob die Richtung noch stimmt:
- Kurze Zyklen: Arbeit wird in Abschnitten von wenigen Wochen oder als fortlaufender Fluss erledigt, nicht in einem Block über Monate.
- Früh nutzbare Ergebnisse: Jede Etappe liefert etwas, das man ausprobieren kann – nicht nur einen Zwischenbericht.
- Rückmeldung von außen: Kund:innen oder Fachbereiche sehen Zwischenstände und können die Richtung beeinflussen.
- Selbstorganisierte Teams: Das Team entscheidet weitgehend selbst, wie es die Arbeit erledigt.
- Regelmäßige Reflexion: Das Team schaut in festen Abständen auf seine eigene Arbeitsweise und verbessert sie, etwa in einer Retrospektive.
Dahinter steht eine nüchterne Annahme: Bei komplexen Aufgaben weiß am Anfang niemand genau, was am Ende gebraucht wird. Dann ist es günstiger, früh zu lernen, als lange nach Plan in die falsche Richtung zu arbeiten.
Methoden und Rahmenwerke
„Agil“ ist keine Methode, sondern ein Sammelbegriff für Haltung und Prinzipien. Umgesetzt wird er mit konkreten Arbeitsweisen, die sich gut kombinieren lassen:
| Ansatz | Kern | Passt gut für |
|---|---|---|
| Scrum | feste Sprints von höchstens einem Monat, drei Verantwortlichkeiten, fünf Events | Produktentwicklung mit wechselnden Anforderungen |
| Kanban | Arbeit sichtbar machen, begonnene Arbeit begrenzen, Fluss verbessern | laufende Anfragen, Support, Redaktion, Verwaltung |
| Extreme Programming (XP) | technische Praktiken wie Paarprogrammierung und testgetriebene Entwicklung | Softwareteams mit hohem Qualitätsanspruch |
Für mehrere Teams an einem Produkt gibt es Skalierungsansätze wie SAFe oder LeSS. Und viele Organisationen arbeiten hybrid: grobe Phasen und Meilensteine wie im Wasserfallmodell, innerhalb davon kurze agile Zyklen.
Was agil nicht bedeutet
Agil heißt nicht planlos. Agile Teams planen sogar häufiger, nur mit kürzerem Horizont: genau für die nächsten Wochen, grob für die Monate danach. Agil heißt auch nicht „schneller um jeden Preis“ – das Manifest spricht ausdrücklich von einem gleichmäßigen Tempo, das sich dauerhaft halten lässt.
Im deutschsprachigen Personalwesen wird „agiles Arbeiten“ manchmal für Homeoffice, Desk-Sharing oder flexible Arbeitszeiten verwendet. Das ist eine andere Bedeutung: Wo jemand arbeitet, sagt nichts darüber aus, ob ein Team in kurzen Zyklen liefert und aus Rückmeldungen lernt.
Und agil ist nicht auf Software beschränkt. Marketing-, Personal- oder Verwaltungsteams nutzen dieselben Grundideen – mit dem Unterschied, dass ihr „Produkt“ eine Kampagne, ein Recruiting-Prozess oder ein Antragsformular ist.
Studio Berger soll die Website eines Tischlereibetriebs neu aufsetzen. Früher hätte das Team drei Monate konzipiert und dann alles auf einmal veröffentlicht.
Jetzt arbeitet es in Zwei-Wochen-Zyklen: Nach dem ersten Zyklus ist die neue Startseite mit Kontaktformular online. Die Rückmeldungen zeigen, dass Interessierte vor allem Referenzfotos suchen – also kommt die Referenzgalerie im nächsten Zyklus vor die geplanten Blogartikel.
Einmal im Monat nimmt sich das Team eine Stunde für die eigene Arbeitsweise und beschließt zum Beispiel, Texte künftig vor dem Layout freigeben zu lassen.
Dieser Eintrag dient der allgemeinen Information und ersetzt keine individuelle Beratung.