10 Gründe, warum agile Projekte schief gehen

Wenn ein agiles Softwarentwicklungsprojekt schief geht, ist in erster Line immer die Methode schuld, nicht die Personen, die die agile Methode eingeführt bzw. umgesetzt haben. Oft eine falsche Annahme. 10 Gründe, warum agile Projekte scheitern:

#10 Gerüchten glauben, z.B.

• agile ist besonders gut für kleine Projekte
• totale Kostenkontrolle
• Dokumentation ist nicht notwendig
• agile Vorgehensweise braucht keine Analysten und Tester
• "jeder" kann "alles" Grundsatz
  
• wir machen Scrum, wir sind agile!
  

#9 Widersprüchliche Terminologie

Wir sagen - der Kunde versteht/interpretiert:

• extreme - riskant
• agile - ungenau, unbestimmt, locker
• pair programming - doppelte Kosten
• refactor - unnötiger Code
• unit testing - extra Code
  

Wenn man es nicht erwähnt, hat man es nicht gehört - jetzt ist man agile!

# 8 Keine Schlüsselfiguren

man fokussiert auf die Entwicklung von Features, ABER es braucht einen

• Sprint Manger
• (Business) Analysten
• Tester
• Designer
• WAI Experten
  

#7 Übertreibung

Beispiele:

• Sicherstellen, das Dokumente für jemanden bestimmt sind
• Sicherstellen, dass jede Implementierung ein Problem löst
• Alles weglassen, was keinen Business-Value hat
• Kein Micromanagement
• Keine Statusdiagramme oder ähnliches

#6 Spitzfindigkeiten

• Man braucht ne Menge Erfahrung
  
• Entscheidungsträger sind nur involvierte Personen
• "Nach Lehrbuch" Vorgehensweise
• Alles mindestens 3 Interationen ausprobieren
• Jede Änderung min. 3 Interationen verifizieren
• Keine Angst, Änderungen rückgängig zu machen

#5 Mangelnde Disziplin & Schleifen lassen

• Angst Dinge zu ändern oder Änderungen einzufordern
• Tun und Handeln wird unterschieden - ist man wirklich agile?
• Rituale vernachlässigen

#4 Nicht das richtige Team

• es braucht erfahrene Führungspersonen
• es braucht ein erfahrenes Team
  
• es braucht erfahrene Mentoren für jede Rolle
• man braucht mehr als einen "Plan"
• Externe Epertentips einholen - und zuhören!

#3 Zu lange Interationen

• nicht länger als 2 Wochen
• klarer Rythmus ist erwünscht -> Dienstag -> Dienstag
• Schneller Teams sollten kürzere Zyklen haben
• Keine Zeit verliehren

#2 Kein guter "Sponsor"

• der Kunde muss zum agilen Prozess passen
• man braucht jemanden, der genug politischen Einfluss ausüben kann, um agile ein Chance zu geben
• Überzeugung und Begeisterung für agile schaffen
• Aus Fehlern lernen

#1 Dem Team keine Erholen lassen

• das Team gewinnt oder verliehrt das Projekt
• die Führungsperson ist ein wunder Punkt
  
• die Umgebung/Arbeitsumfeld ist ein wunder Punkt
• die (externe) Unterstütztung ist ein wunder Punkt
• Personalfluktion ist ein wunder Punkt