Die vier Agile-Werte
Verstehen, was wir mehr schätzen und was wir immer noch schätzen (nur weniger).
1Das Manifest richtig lesen
Das Agile Manifest formuliert vier Präferenzen, keine Absolute:
„Wir haben gelernt, X mehr zu schätzen als Y. Das heißt, obwohl die Punkte auf der rechten Seite Wert haben, schätzen wir die Punkte auf der linken Seite mehr."
Das ist entscheidend. Es heißt nicht „X gut, Y schlecht". Es heißt „wenn du wählen musst, bevorzuge X".
Häufiges Missverständnis
„Wir brauchen keine Dokumentation, weil wir agil sind" ist NICHT das, was das Manifest sagt. Dokumentation hat Wert; sie steht nur nicht im Mittelpunkt.
2Individuen und Interaktionen über Prozesse und Werkzeuge
Großartige Werkzeuge und Prozesse können ein dysfunktionales Team nicht retten. Aber ein großartiges Team kann mit mittelmäßigen Werkzeugen erfolgreich sein.
Was das in der Praxis bedeutet:
- Stelle für Zusammenarbeit ein, nicht nur für technische Fähigkeiten
- Wähle Prozesse, die dem Team dienen, nicht umgekehrt
- Wenn der Prozess Reibung erzeugt, repariere den Prozess
- Persönliches Gespräch schlägt E-Mail-Threads
Was das nicht bedeutet:
- Chaos ohne Prozess
- Nützliche Werkzeuge ignorieren
- Undokumentiertes Stammwissen
Das Team bemerkt, dass ihr Daily Standup zu einem Statusbericht an den Manager geworden ist. Sie diskutieren und ändern das Format, um sich auf Zusammenarbeit zu konzentrieren.
Ein Team nutzt Jira genau so, wie es das Unternehmen vorschreibt, obwohl der Workflow nicht zu ihrer tatsächlichen Arbeitsweise passt. Sie pflegen zwei Systeme.
3Funktionierende Software über umfassende Dokumentation
Die beste Dokumentation dessen, was ein System tut, ist das System selbst. Code, der läuft, schlägt Spezifikationen, die beschreiben, was Code eines Tages tun könnte.
Was das in der Praxis bedeutet:
- Liefere früh und oft
- Miss den Fortschritt an funktionierenden Features, nicht an fertigen Dokumenten
- Schreibe gerade genug Dokumentation, zum richtigen Zeitpunkt
- Halte Dokumentation nah am Code, damit sie aktuell bleibt
Was das nicht bedeutet:
- Niemals Dokumentation
- Unlesbarer Code ohne Kommentare
- Keine Design-Diskussionen vor dem Programmieren
4Zusammenarbeit mit dem Kunden über Vertragsverhandlung
Verträge gehen davon aus, dass man alles im Voraus spezifizieren kann. Zusammenarbeit geht davon aus, dass man gemeinsam lernt. In einer Welt der Unsicherheit gewinnt Zusammenarbeit.
Was das in der Praxis bedeutet:
- Beziehe Stakeholder in regelmäßige Reviews ein
- Hole Feedback früh ein, nicht erst am Ende
- Passe den Umfang basierend auf Erkenntnissen an
- Baue Vertrauen durch Transparenz auf
Was das nicht bedeutet:
- Keine Verträge oder Vereinbarungen
- Unbegrenzte Scope Creep
- Der Kunde hat immer recht (er weiß oft nicht, was er braucht)
5Reagieren auf Veränderung über das Befolgen eines Plans
Pläne sind nützlich. An veralteten Plänen festzuhalten ist schädlich. Das Ziel ist nicht, Planung zu vermeiden – es geht darum, so zu planen, dass Anpassung möglich ist.
Was das in der Praxis bedeutet:
- Kurze Iterationen mit Möglichkeiten zur Neuplanung
- Begrüße sich ändernde Anforderungen, auch spät in der Entwicklung
- Verfolge die Velocity, um zukünftige Schätzungen zu verbessern
- Beende Projekte früh, wenn sie nicht funktionieren
Was das nicht bedeutet:
- Keine Planung
- Jeden Tag die Richtung ändern
- Entwickler ignorieren die Roadmap
Das Planungsparadoxon
In Agile planen wir tatsächlich HÄUFIGER als im Wasserfall – nur in kleineren Portionen. „Auf Veränderung reagieren" erfordert ständige Neuplanung.
- Das Manifest formuliert Präferenzen, keine Absolute – der Kontext ist wichtig
- Die Punkte auf der rechten Seite haben immer noch Wert
- Jeder Wert adressiert einen spezifischen Fehlermodus der traditionellen Entwicklung
- Agil sein bedeutet, diese Werte zu verinnerlichen, nicht nur Regeln zu befolgen