Dieses Jahr ist ein Jahr in dem ich immer öfter empfohlen habe nicht agil zu arbeiten. Obwohl ich absoluter Fan von agilen Arbeitsweisen bin.
Warum? Weil das Label agil zu oft verwendet wird, wenn das erwartete Feature-Set (Scope) nicht zum Budget passen will. Dann hat jemand was von doppelter Arbeit in der Hälfte der Zeit gelesen und schon denken alle, dass das Projekt so funktionieren wird. Ein anderer Grund ist, dass niemand den Kunden auf die agile Arbeitsweise vorbereitet und erst damit anfängt, wenn es ein Vrständnis dafür gibt. Oft gibt es keinen Product Owner auf Kundenseite, sondern nur eine projektverantwortliche Person, die vielleicht auch nur durch Zufall zu der Rolle kam. Stakeholder, die sich in ihrem Denken noch in Black Box Entwicklung befinden. Das heißt für mich, dass sich Menschen viel Mühe gegeben haben mit Pflichten- und Lastenheft aus vielen Meetings und Brainstormings rauszukommen. Das geben sie dann an Dienstleister und nach Zeit X kommen die mit einem Produkt, das gar nicht so richtig zu der Realität passt, die sich mittlerweile geändert haben kann.
Auftraggeber wollen den Tag X. Der eine Tag des Launch, an dem alles fertig ist und niemand sich mehr mit Entwicklung, Absprachen, Feedbackrunden und Testen beschäftigen muss. Endlich wieder in den normalen Arbeitsalltag, nur mit dem neuen Tool, das vielleicht nicht so funktioniert, wie die Vorstellung war, aber jetzt ist ja die Zeit und das Budget schon aufgebraucht. Deadlines sind im wahrsten Sinne des Wortes der Tod für agile Projekte. Wenn die Möglicheit für Iteration und Verbesserung zeitlich begrenzt wird, dann kann das agile System nicht zum Laufen kommen. Der Mut zu sagen: "Wir arbeiten jetzt daran, dass die Grundfunktion steht und dann erweitern wir die wertvollsten Funktionen." ist sehr selten vorhanden. Dabei ist das ein wichtiger Schritt. Auch mal mit einem nicht vollumfänglich durchentwickelten Produkt an den Markt zu gehen, Annahmen zu treffen, diese zu überprüfen und anzupassen.
Verwechslung von Komplexität und kompliziert. Ich denke darüber machen sich viele kaum Gedanken. Agile Arbeit ist für komplexe Aufgaben gedacht. Wenn in einem Projekt der Weg nicht bekannt ist, den es zu gehen gilt, weil das Umfeld sehr volatil ist und sich schnell ändern kann oder zum ersten Mal auch mit dem Feedback von Endbenutzern gearbeitet wird, dann gibt das ein Anzeichen dafür, dass agil geeignet ist. Ein Legoset oder ein Puzzle zu bauen braucht kein agil. Einem Rezept zu folgen, das viele Schritte enthält und eine gewisse Fertigkeit benötigt ist nur kompliziert, aber nicht komplex. Hier kann man mit einer anderen Methode arbeiten.
Das sind meine Hauptgründe in einem Projekt nicht agil zu empfehlen und lieber mit "klassischen" Methoden an das Projekt ranzugehen. Es ist natürlich trotzdem gut mit einem agilen Mindset an die Arbeit zu gehen, denn das agile Manifest hält auch viel für den Umgang in anderen Projekten bereit, denn auch dort arbeiten Menschen zusammen, die über eine gewisse Zeit miteinander auskommen müssen und mit der richtigen Einstellung funktioniert das am besten.