Ich habe lange gesucht, aber keine Definition von Agil bzw. von Agilität gefunden. Dabei redet die ganze Welt von Agilität — und viele meinen völlig unterschiedliche Dinge. Einige verstehen darunter Scrum, andere Kanban, einige Lean und viele einfach ad-hoc-Chaos. Deshalb ist es an der Zeit den Begriff Agilität zu definieren. Hier kommt die ultimative Definition (aktualisiert Dank der Diskussion mit Bruno Baketaric).
Agilität
Agilität ist schnelle Reaktionsfähigkeit in einer komplexen Welt. Agilität wird durch fünf Prinzipien charakterisiert:
- Ermächtigung und Selbstorganisation
- Frühe und regelmäßige Lieferungen
- Überprüfung und Anpassung
- Transparenz
- Nutzung eines Takts
Agilität ist mehr als IT
Agilität ist für die meisten ein Thema aus der IT. So spricht das Agile Manifest nur über “Software Development”. Auch Wikipedia spricht nur über Agile Softwareentwicklung.
Dabei ist Agilität ist nicht auf die IT beschränkt: Jede Art von Team, Einheit oder Organisation kann agil arbeiten. Das können Entwicklungsteams in der IT sein, aber auch Dienstleistungsteams usw. Gerade weil Agilität immer mehr verwendet wird — z.B. im Zusammenhang mit Organisation 2.0 — ist ein klares Verständnis wichtig, was Agilität ist und was nicht.
Agilität ist mehr als Scrum
Agilität ist mehr als Scrum. Scrum ist das am meisten verbreitete agile Framework für die Produktentwicklung, aber auch ein DevOps-Team mit Scrumban arbeitet agil. Ebenso ist ein Dienstleistungsteam mit Kanban agil unterwegs.
Die fünf Prinzipien im Detail
1. Ermächtigung und Selbstorganisation
Teams sind ermächtigt und verantwortlich, alle notwendigen Entscheidungen zur Lieferung des Ergebnisses zu treffen. Sie sind funktionsübergreifend. Teams planen ihre Arbeit selbst und entscheiden, wie sie sie am besten durchführen können. Sie können sich untereinander eigenständig und ohne Hindernisse verständigen.
2. Frühe und regelmäßige Lieferungen
Jeder Mitarbeiter fokussiert sich auf die Lieferung dessen, was für den Kunden Wert schafft. Frühe und regelmäßige Lieferungen stellen einen stetigen Fluss von Ergebnissen sicher. Das ermöglicht den Teams eine kontinuierliche Überprüfung und Anpassung.
3. Überprüfung und Anpassung
Teams reflektieren regelmäßig darüber, wie sie effektiver und effizienter werden können. Dies bezieht sich ebenso auf das Produkt wie auf die Arbeitsweise im Team. Eine solche Überprüfung und Anpassung findet auch auf der Organisationsebene statt, um Ergebnisse, Arbeitsweisen und Organisationsstrukturen zu hinterfragen und zu verbessern.
4. Transparenz
Teams tauschen zur Förderung der Zusammenarbeit Informationen und Wissen untereinander aus, damit jeder auf die bestmögliche Weise zur Zielerreichung beitragen kann. Der direkte persönliche Kontakt ist dabei für den Austausch von Informationen am effektivsten.
5. Nutzung eines Takts
Teams nutzen einen Takt (engl. „takt“ oder „cadence“), um ihrer Arbeit einen Rhythmus zu geben. Ein Takt sorgt für Regelmäßigkeit und Verlässlichkeit. Damit unterstützt er das Messen und Lernen. Ein gemeinsamer Takt mehrerer Teams ermöglicht es, diese zu synchronisieren und so die Arbeit auch über die Teams hinweg in Fluss zu bringen. So ist z.B. in Scrum der Takt der Sprint; dieser gibt Planung, Umsetzung, Review und Retrospektive einen gemeinsamen Rhythmus. In Kanban wird für unterschiedliche Ereignisse wie Queue Replenishment oder Lieferung jeweils ein eigener Takt (engl. cadence) genutzt.
That’s what our readers think
Wir dürfen Timeboxen (engl. Zeitfenster) nicht mit Meilensteinen verwechseln. Dies sind unterschiedliche Konzepte. Timeboxen in Agile sind ein Mittel, um einen Takt zu schaffen. Ein Takt ist ein wichtiges Element von Lean und Agile. Er schafft Fluss. Daher ist der Takt bzw. Timeboxing eine der drei Säulen der empirischen Prozesskontrolle. Mehr dazu hier: https://blog.wibas.com/warum-takt-und-zeitfenster-zu-agile-dazugehoeren/
Durchaus gute Punkte – einer jedoch ist mindestens diskutabel: Zeitfenster.
Einerseits stören jegliche Zeitfenster (potentiell) den Fluss der Arbeit und andererseits sind Zeitfenster nur hilfreich, wenn die vereinbarte (commitment) Arbeit in diesem Zeitfenster stabil ist und bleibt – was längst nicht in allen Umgebungen der Fall ist.
Agil schreibt keineswegs eine Timebox vor, Scrum natürlich schon – daher ist Scrum auch nicht immer die geeignete Methode.
Etwas umfangreicher habe ich das Thema Timebox in einem eigenen Artikel beleuchtet.