Agile (Scrum, Kanban)

Was mir an Agilität seit 2003 gefällt:

Business-getriebenes Backlog: Das, was für das Geschäft das Wichtigste ist, kommt zuerst dran. In jedem Sprint können die Prioritäten aufs Neue festgelegt werden.
Sprint Plannings: Das Business entscheidet und verhandelt direkt mit der Realisierung. Kurze Wege statt stiller Post.
Iterationen: Regelmäßige ehrliche Konfrontation mit dem eigenen Tun. Frühe Verfügbarkeit von Features, vielleicht schon ab dem ersten Sprint. Volle Transparenz über den Stand der Dinge.
Eingebaute Retrospektiven: Regelmäßige Reflexion über das, was gut läuft und was Anschub braucht. Nicht als Post Mortem, sondern während das Projekt läuft.

Was ich dabei nicht über Bord werfe:

Architektur: Zu einem gewissen Grad lohnt es sich vorab zu überdenken, wohin die Reise geht. Und festzulegen, was einem wichtig ist, und nach welchen Kriterien man verschiedene mögliche Lösungen bewerten möchte.
Dokumentation: Das Projekt geht, das Team macht etwas anderes, das Produkt bleibt. Nicht mehr Doku als nötig, aber ganz sicher auch nicht weniger.

Was ich weiter für wichtig halte:

Requirements Engineering: Das Problem zu verstehen ist die Basis für erfolgreiche Software-Vorhaben. Dem Produkt Owner und dem Team werden von Scrum implizit eine Menge Fähigkeiten und Aktivitäten zugedacht, die aus guten Gründen Gegenstand einer eigenen Disziplin sind.
Handwerkliche Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung.

Agile