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. Die Welt dreht sich auch im Projekt weiter - in jedem Sprint können die Prioritäten aufs Neue festgelegt werden. Das Geld wird dort investiert, wo es das Meiste bringt.
Sprint Plannings: Das Business entscheidet und verhandelt direkt mit der Realisierung. Kurze Wege statt stiller Post. Ich halte viel davon, auch die Nutzer im Planning zu haben - schneller und sicherer kann man alternative Lösungsmöglichkeiten nicht verhandeln.
Iterationen: Regelmäßige ehrliche Konfrontation mit dem eigenen Tun. Volle Transparenz über den Stand der Dinge. Frühe Verfügbarkeit von Features, vielleicht schon ab dem ersten Sprint. Volle Konzentration auf wenige Dinge.
Eingebaute Retrospektiven: Regelmäßige Reflexion über das, was gut läuft und das, was Anschub braucht. Während das Projekt läuft und ihm nützt, nicht als Post Mortem.

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 will.
Dokumentation: Das Projekt geht, das Team macht etwas anderes, das Produkt bleibt. Nicht mehr Doku als nötig, aber ganz sicher auch nicht weniger als erforderlich.

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.
Handwerkliches Können: Scrum und Kanban organisieren die Arbeit. Die Qualität von Code und Architektur ist dennoch von zentraler Bedeutung.

Agile