Das Anti-agile Manifest

Das Agile Manifest und seine agilen Prinzipien sind die Basis agiler Software-Entwicklung. An diesen Leitplanken (nicht ehernen Gesetzen) orientieren sich viele moderne Entwickler-Teams.

Wie klingt es, wenn man das agile Manifest umkehrt?

Das Anti-agile Manifest

Wir haben feste Prozesse und Werkzeuge. Das wird nicht einfach umgeworfen für kurze Dienstwege und direkte Absprachen.

Dokumentation sagt uns was die Software tut. Der super-clevere Quellcode ist eh nicht lesbar.

Schriftliches geht über Kunden-Absprachen.

Pläne werden befolgt und nicht einfach umgeworfen, nur weil es neue Fragen und Erkenntnisse gibt.

Zwölf Prinzipien Anti-agiler Softwareentwicklung

Wir sollten nicht ständig kleinteiligen Code releasen, sondern große Würfe in großen Release-Paketen abliefern.

Während der Entwicklung möchten wir keine Änderungen an der Anforderung mehr sehen. Was einmal festgeschrieben wurde, soll dann auch gelten. Selbst Schuld, wenn nicht alles bedacht wurde.

Ein Feature ist fertig, wenn der Code lokal läuft. Das geht dann auch auf produktiven Systemen. Falls nicht, merkt das jemand im Testsystem. Dafür ist genug Zeit, weil nicht so oft released wird (siehe auch "große Würfe").

Everyone, please leave me alone. Die tägliche Zusammenarbeit stört. Alle wichtigen Infos sind in der User Story zusammengefasst. Nachfragen können so erst gar nicht entstehen. Falls doch, lässt sich das auch noch in der Review klären ("ich konnte nicht, weil...").

Errichte Projekte rund um unmotivierte Gruppen. Wirf ihnen regelmäßig Aufgaben zu. Wenn die abgehakt sind, wirf neue nach. Wenn nicht, siehe "Leave me alone".

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist schriftlich und allumfassend im Vorfeld (siehe auch "Leave me alone").

Beschäftigtgewesensein ist das wichtigste Fortschrittsmaß.

Agil sein bedeutet, wechselweise sprinten und spurten zu können. Wir springen flexibel zwischen dringenden Deadlines, akuten Notfällen und wichtigen Bugs.

Lieber schnelles Mittelmaß ("reicht doch so") als sinnloser Perfektionismus. Denn Code wird nicht gelesen, kopiert oder erweitert. Falls doch, kann man sich dann die Zeit zum refactorieren nehmen (siehe auch "sprinten und spurten").

Lines of Code und Features pro Sprint sind der beste Indikator für hochwertige Arbeit.

Die besten Architekturen, Anforderungen und Entwürfe entstehen außerhalb des ausführenden Teams. Sie fallen dann in Stein gemeißelt auf das Team herab.

Team-interne Meetings sind zu vermeiden (siehe auch "Leave me alone"). Wird dennoch hin und wieder eine Retrospektive erzwungen, lässt man die still über sich ergehen und macht weiter wie zuvor.