Das agile Wertesystem

Der Kern des Manifests vergleicht mit vier Aussagen jeweils zwei Werte und argumentiert, obwohl jeder dieser Werte generell als wertvoll erachtet wird, dass der erste im Sinne von Agilität größeres Gewicht hat als der zweite.

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.

Diese Aussage respektiert die Tatsache, dass die wichtigsten Kriterien für einen Projekterfolg oder -misserfolg die an dem Projekt beteiligten Menschen und die Art ihrer Zusammenarbeit sind. Prozesse und Werkzeuge werden zwar als wertvoll erachtet - ansonsten würden wir gar nicht über (agile) Prozesse diskutieren, und die agile Gemeinschaft hätte wohl nicht so viele Werkzeuge erfunden (Frameworks für Unit Tests, Integrations- und Konfigurationswerkzeuge etc.). Aber wenn die Projektmitglieder im Team nicht gut zusammenarbeiten, helfen die besten Prozesse und Werkzeuge auch nicht viel.

• Lauffähige Software ist wichtiger als umfangreiche Dokumentation.

Diese Aussage wird vermutlich am häufigsten missverstanden. Menschen, die mit der agilen Entwicklung nicht vertraut sind, verstehen sie oft dahingehend, dass es in agilen Projekten keine Dokumentation gibt. Aber in der gleichen Weise, wie Prozesse und Werkzeuge eine wichtige Rolle spielen, gilt dies auch für die Dokumentation. Allerdings drückt dieser Wertevergleich aus, dass lauffähige Software der kritische Erfolgsfaktor für die Entwicklung ist. Dokumentation kann zur Unterstützung oder zum besseren Verständnis der lauffähigen Software notwendig sein, aber sie kann und sollte nicht als Selbstzweck dienen.

• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.

Obwohl ein Vertrag benötigt wird, unterstreicht diese Aussage, dass der Vertrag nie ein Ersatz für eine gute Beziehung zum Kunden sein kann. Um ein Produkt erfolgreich zu entwickeln, ist ein regelmäßiger Austausch mit dem Kunden unabdingbar.

• Auf Änderungen reagieren ist wichtiger, als einem Plan zu folgen.

Diese Aussage weist darauf hin, dass es wichtiger ist, mögliche Änderungen in Kauf zu nehmen, speziell in Form von Anforderungsänderungen, als stur einen Plan zu verfolgen, den man vor einiger Zeit entworfen hat. Wir akzeptieren, dass sowohl der Kunde als auch das Projektteam über die Zeit dazulernen werden, und wir wollen dieses Gelernte berücksichtigen, indem wir es in die weitere Entwicklung einfließen lassen. Wenn in dem fertigen Produkt all das umgesetzt wurde, was der Kunde und wir am Anfang geplant haben, nicht aber das, was wir später herausgefunden haben und was wirklich benötigt wird, dann ist das Produkt mit Sicherheit ein Fehlschlag.