Unkompliziert und leicht in agiles Projektvorgehen starten

Mit dem So-Wie-Beim-Letzten-Mal-Projektmethode klappt es nur bedingt. Die Schuldzuweisung ist klar: die Wasserfall-Methode macht träge. Aber der Start ins agile Projektvorgehen verläuft ähnlich zäh. Warum?

Es gibt zwei wesentliche Gründe, ins agile Projektvorgehen zu wechseln:

1. Die aktuell gelebte Projektwelt ist SWBLM ("So wie beim letzten Mal"). Das Team sucht durch den Wechsel nach klaren Rollen, Aufgaben und Riten.
2. Die aktuelle Projektwelt entspricht nicht den Grundwerten im Team. Alle Beteiligten wünschen eine engere Verzahnung der beteiligten Personen & Disziplinen.

Der erste Fall ist in vielen Teams nicht offen artikuliert, in vielen Fällen nicht einmal gedacht. Das Nicht-Vorliegen einer Projektmethodik wird nicht wahrgenommen. Wechselt das Team aus diesem Stand in den vollen Projektmodus, wird die Umstellung sehr schwer fallen, wenn nicht scheitern. Gerade auf den SCRUM-Master und den PO kommen viele Aufgaben zu, die in der SWBLM-Projektmethode nicht explizit getan wurden.

"Bei uns scheitert SCRUM. Der PO kann das nicht." heißt es dann. Dieses Fingerpointing ist kontraproduktiv - verstärkt es doch alte Rollenbilder - und trainiert eine nicht offene Fehlerkultur. Und es ist nicht ehrlich. Denn das gesamte Team kämpft mit neuen Regeln und Ansprüchen.

Eine Regel der Retrospektive ist es, maximal zwei Anliegen in der jeweils kommenden Iteration zu verändern. Veränderung braucht Zeit. Und deswegen sollten nicht zu viele Dinge auf einmal geändert werden. So hilft es dem Team womöglich, wenn die agile Methodik nach und nach eingeführt wird. 

Eine gute Möglichkeit ist es, möglichst früh eine Wandzeitung einzuführen. Diese stellt sofortTransparenz über die Aufgabenstellung und den Ist-Stand des Projekts her. Vor der Wandzeitung beginnen dann die "Daily StandUps". Der erste Schritt in Richtung Verbindlichkeit und Fehlerkultur ist getan. Der schrittweise Einstieg in eine definierte Projektmethode ist für das Team leichter zu bewerkstelligen.

Während des schrittweisen Einstiegs definieren die Team-Mitglieder die Aufgaben und Riten der einzelnen beteiligten Rollen. 

"Wer ist eigentlich das Team?" fragen sich die Beteiligten. Und wäre es nicht besser, wenn wir XYZ sehr früh im Projekt integrierten? Vielleicht auch "Ich bin dieses Fingerpointing leid. Hätten wir früher geredet, wären wir da gar nicht reingetappt." Hinter diesen Anmerkungen steckt ein interdisziplinärer, im Fehlerumgang offener Ansatz. Aus diesem Ansatz heraus wechseln Teams die Projektmethodik. Und wundern sich, dass manch anderes nicht mehr so gut geht. 

Beim Wechsel einer Projektmethodik, die auf einer definierten Projektmethodik aufsetzt, ist darauf zu achten, dass erfolgsbringende Faktoren nicht untergehen. Deswegen braucht's eine Meta-Diskussion:

• Woran glauben wir?
• Worin sind wir jetzt besonders gut?
• Was möchten wir behalten? Was ändern?

Auch hier empfiehlt sich das ruhige, schrittweise Umstellen, so dass das Team in Ruhe und mit Gelassenheit neue Wege gehen kann.

Bei der Einführung von Projektmethoden ist es nicht wichtig, dass die Lehrbuch-Meinung zu SCRUM, Kanban oder XP erfüllt ist. Und wenn ein Methodenbaustein eher aus der XP-Methodik zum Team passt, während der Rest sich wie SCRUM anfühlt, dann ist das so.

Wichtig ist, dass die Art der Umstellung und die gefundene Methodik zum Team passen und sich in deren Wertewelt einfinden. Es soll schließlich funktionieren ;-)