Zur Geschichte der „Vasa“

Der schwedische König Gustav II. Adolf von Schweden gab 1625 den Auftrag das zu damaliger Zeit größte Kriegsschiff zu bauen, welches schon nach nur 1300 m auf seiner Jungfernfahrt sank, wobei 50 der ca. 200 Seeleute ertranken.

Ein Hauptgrund für die Instabilität war sicherlich der Wunsch (Befehl) des Königs, nach Beginn des Baus die Anzahl der Kanonen durch Ausbau eines zweiten Batteriedecks zu verdoppeln, die Hauptabmessungen ließ man dabei aber unverändert. Zu großer Tiefgang, erhöhter Schwerpunkt und offene Luken beendeten die Fahrt schon nach 20 Minuten.

Was kann man also daraus lernen?

Viele Parallelen entstehen, wenn man die Planung und Durchführung des Vasa-Projektes und herkömmliche Fehler sieht, die ein Scrum-Team bei der Entwicklung von neuer Software plagen.

Die Ähnlichkeiten findet man unter anderem, wenn man die Sammlung an Risikofaktoren, wie

• häufige Änderungen der Anforderungen
• veränderte Zielsetzung
• Fehlkommunikation zwischen Team-Mitgliedern

vergleicht. Diese oder ähnliche Fehler tragen zur Instabilität eines jeden Projekts bei und sollten tunlichst vermieden werden.

‚Agile‘ unterstützt (strategische) Faulheit

‚Agile‘-Richtlinien sollen Überlastung verhindern. Es würde heutzutage in Frage stellen, warum 64 Kanonen eingebaut wurden, wenn eigentlich nur 54 vorgesehen waren?

Vergleicht man also den König mit einem heutigen wichtigen Auftraggeber, entstehen neue Parallelen.

Der König (Kunde) kam ständig mit neuen Forderungen, wodurch sich aber leider die Segeleigenschaften und die Seetüchtigkeit verschlechterten.

Wenn man nun im Nachhinein einen Sündenbock sucht, hat man die Auswahl zwischen:

• dem König, der unbedingt zwei Kanonendecks wollte
• dem Schiffsbauer, der diesen Forderungen nachkam, anstatt zu intervenieren (im IT-Bereich würde man von einem gewissenhaften Anbieter erwarten, dass er warnend hinweist)
• dem Vize-Admiral, der den Befehl zum Auslaufen gab, obwohl er wusste, dass das Schiff nicht mehr seetüchtig war
• der Mannschaft, die die Segel setzte und leider die Kanonenluken offen ließen.

In der Agilen Softwareentwicklung sollen kurzfristige Änderungen und inkorrekte Vorgaben früh erkannt und entsprechend behandelt werden.  Der Fokus liegt auf:

• der Zeit,
• dem End-User,
• dem System als Ganzes und
• dem Unternehmen bzw. dem Einsatzbereich.

Sechs katastrophale Auslöser, die Ihr Software-Projekt zum „Sinken“ bringen

1. Ein unmöglicher Zeitplan
   Je mehr Druck Sie auf Ihre Mitarbeiter ausüben, desto eher werden diese Fehler begehen.
2. Vorgaben, die zu schnell geändert werden
   Vorgaben in der Mitte eines Projekts zu ändern, garantieren fast die nächsten Fehler.
3. Mangel an detaillierter Planung
   Software-Projekte wachsen manchmal wie Schneebälle. Leider wächst die Planung nicht immer gleichzeitig mit.
4. Mit Innovationen über Bord gehen
   Der Versuchung neue Features einzubinden, um einen kreativen Impuls zu befriedigen, sollte unter allen Umständen widerstanden werden.
5. Zu viele Anforderungen in ein Projekt pumpen
   Dieser recht häufig auftretende Fehler passiert, wenn ältere Regeln nicht aktualisiert oder neuere nicht richtig angepasst werden.
6. Das Ignorieren offensichtlicher Probleme
   Es gehört zur Verantwortung eines jeden Testers auf eventuelle Fehler rechtzeitig hinzuweisen, damit nicht erst die Endnutzer diese Erfahrung machen müssen. 

Menschliche Fehlbarkeit ist der siebte Auslöser, der eigentlich nie ganz verhindert werden kann. Deshalb sollte immer wieder darauf hingewiesen werden, dass mit äußerster Sorgfalt und Gewissenhaftigkeit gearbeitet werden muss, um diesen Punkt weitgehend auszuschließen.

Den Originaltext (in Englisch) finden Sie in der TestHuddle.

Mehr zur Vasa können Sie in Wikipedia entdecken.