Ich wollte bereits seit längerem auch über meine Erfahrungen in der IT schreiben, nun also ein paar erste Gedanken.
Für viele Leute ist agiles Projektmanagement in der Software Entwicklung der heilige Gral und mit agilen Methoden kann nichts mehr schiefgehen. Dann wundert man sich, warum das Projekt trotzdem scheitert. Hierfür kann es verschiedene Gründe geben. Wir erinnern uns, das wichtigste ist das Kundenfeedback, Software wird in kleinen Stücken weiterentwickelt und neue Funktionen sofort mit den Kunden evaluiert. Hier ein paar mögliche Probleme:
- Es gibt noch gar keine so konkrete Vision wie das Produkt am Ende aussehen soll, ein Prototyp wird entwickelt und dann den Kunden vorgestellt. Das Feedback der Kunden ist positiv und schon wird der Prototyp Grundstein für die weitere Produktentwicklung. Dieses Vorgehen wird voraussichtlich scheitern. Wenn das Kundeninteresse da ist, dann sollte man mit der Produktentwicklung nochmal ganz von vorne beginnen, mit Entwurf und Systemarchitektur. Eine Weiterentwicklung des Prototypen wird vermutlich später dazu führen, dass wir ein Produkt haben, das nicht skaliert, eine schlechte Performance hat, schlecht erweiterbar ist usw. Agiles Entwickeln heißt nicht, dass man auf eine System Architektur verzichten kann, vor allem nicht, wenn wir uns im Enterprise Kontext bewegen.
- Ganz wichtig in der agilen Entwicklung ist das Kriterium für „completeness“, also wann ist eine Funktion fertig und ich darf die Story Points im Projektplan abhaken? In größeren Projekten werden System Test und Dokumentation leider meist von unabhängigen Teams gemacht, die nicht immer zeitnah verfügbar sind. D.h. entweder ich habe lauter Teile im Projekt, die praktisch nie in einem Sprint fertig werden oder ich klammere System Test und Dokumentation aus, erkläre die Funktionen also als fertig und gehe davon aus, dass der System Test später erfolgreich läuft und dass die Dokumentation am Ende in guter Qualität erstellt wird. Man wird hier einen pragmatischen Ansatz wählen müssen, aber man sollte dringend einen Risk Management Plan haben. Sollte sich spät im Projekt herausstellen, dass z.B. die Performance der Software nicht passt, dann sind die ganzen Story Points plötzlich wieder offen und der Projektplan ist tief rot.
- Dann haben wir noch die menschlichen Probleme….es werden burn up und burn down Charts erstellt, schöne Kurven gemalt und Vorhersagen getroffen. Die Vorhersagen ergeben, dass der Projektplan nicht funktioniert. Jetzt sollte man die Planung anpassen, stattdessen wird entschieden, dass die Teams das bisher immer hinbekommen haben, man einfach die Velocity erhöht und das Enddatum noch einhalten wird. Das Schöne bei der agilen Entwicklung ist, wenn es nicht funktioniert, dann schiebt man einfach ein paar Funktionen in die Zukunft. Vorsicht, das Produkt wird regelmäßig Lücken aufweisen und irgendwie unvollständig sein, die Kunden werden vermutlich nicht begeistert sein. Ein Erfolgskriterium für agile Projekte ist Ehrlichkeit, Probleme ehrlich eingestehen und gemeinsam an einer Lösung arbeiten. Als Lektüre empfehle ich Voltaires „Candide oder der Optimismus“ oder auch unter dem Titel „Candide oder die beste aller Welten“ bekannt.
Das Thema ist genau so unerschöpflich wie die Ausbildungsangebote zum Thema „Agile Software Entwicklung“. Vielleicht gibt dieser kleine Artikel ein paar Denkanstöße. Ich freue mich über Feedback.