Der Change von klassischen Vorgehensweisen zum Agilen

Warum ändert man die Vorgehensweise in der Softwareentwicklung? Warum wird man agil, wenn man vorher klassisch Software erstellt hat? Na klar. Man möchte die Qualität erhöhen. Bezüglich der Kundenanforderungen. Bezüglich der Stabilität. Und auch bei den weiteren Qualitätsfaktoren.
Doch die agilen Projekte liefern in der Regel keine besseren Ergebnisse als klassische Vorgehensweisen, wie die Umfrage Softwaretest ermittelt hat.

Doch was sind die Ursachen? Die Diskussionen mit Experten im letzten Seminar haben dabei folgende mögliche Gründe zu Tage gebracht:

• Alle Beteiligten benötigen einen Mindshift von klassisch zu agil. Teilweise geht nicht.
• "no test - no code"
  Wer den Code nicht richtig gut getestet hat, darf diesen nicht einchecken. Sonst läuft es niemals.
• "Agilität ohne Test Driven Development geht gar nicht" (Zitat Prof. Dr. Mario Winter)
• Ohne testgetriebene Ansätze (TDD, XP, Pairing etc.) sind agile Vorgehensweisen absolut fragwürdig. Das ist dann nur "Hacken".
• Ohne eine Definition of Done wird auch keine Qualität herauskommen
• Planning Poker ohne Berücksichtigung der Testing Tasks (oder der jeweiligen Testaufwände in den user stories) ist nur Selbstbetrug

Halbe Sachen gehen also gar nicht. Ein Change-Prozess braucht viele Coaches und eine Basis, die für Veränderung bereit ist. Sonst wird aus einem Wasserfall nur ein "agiler Wasserfall"...