Einführung von agilen Prozessen

"Wie wird man agil?" ist die Frage, an der sich Jutta Eckstein in ihrem Talk entlanghangelt. Interessante Frage, weil die Einführung doch immer wieder ein schwieriger Prozess ist. Im übrigen: Veränderung ist immer ein schwieriger Prozess, warum sollte die Veränderung zu einem agilen Vorgehen also leichter gehen. Nach der "klassischen" Unterscheidung in bottom-up und top-down (heißt hier "guerilla tactics" und "command and control", aber die Begriffe sind mir persönlich zu kriegerisch) konstatiert Jutta Eckstein, dass idealerweise alle am gleichen Strang ziehen - Managment, Kunde, Entwickler... Naja, wann passiert das in der Realität schon? In meiner jedenfalls nicht. Aber genau darum geht es ja Jutta Eckstein. Wie führt man agiles Vorgehen trotzdem erfolgreich ein?

Folgende Punkte sind demnach wichtig:
In einer Reihe von Retrospektiven sammelt man zuerst mal die Erfahrungen vergangener Projekte oder des aktuellen Projekts. Das Statement von Jutta Eckstein ist, dass als Ergebnis dieser Reflexion über das eigene Vorgehen und das gewünschte Vorgehen in der Regel etwas agiles hervorgeht.

Readiness / Enabling Workshops schaffen - meistens mit den Entscheidern, weniger mit den Entwicklern - das Verständnis und legen den Grundstein für das weitere Vorgehen. Wichtige Fragen dabei sind "Was machen wir schon?", "Was ist einfach umzusetzen?", "Was ist wirklich schwierig?" und "Was ist unmöglich?". Klar, raus kommt die Entscheidung, ob man überhaupt agil vorgehen kann und was man gegebenfalls noch zu tun hat.

Wenn man die Entscheidung hat, dann kann man loslegen. Hier kommt der Consultant durch - verkaufen, verkaufen, verkaufen. Mindestens hier kann man Schulungen verkaufen. Was sollte man aber zum loslegen machen? Training und Coaching sollte hier einfach die ersten Schritte begleiten, also einfach mal die ersten Iterationen planen etc. Gleichzeitig braucht man einen, wie Jutta Eckstein das ausdrückt, "Passionate change agent", also jemand, der mit Leidenschaft für die Einführung der Agilität einsteht. Ich fühle mich angesprochen.

Leider geht Jutta Eckstein nicht (direkt) darauf ein, wie man das Team dazu bringt, im Verlauf des Prozesses immer mehr Verantwortung von sich aus zu übernehmen. Sie sagt nur, dass der Erfolg der Einführung von drei Rollen entscheident abhängt: Dem project lead, dem passionate change agent und dem technical leader.

Um dauerhaften Erfolg zu haben, muss man den Spagat zwischen "Anfängern" auf der einen Seite und "Agilen" auf der anderen Seite schaffen. Geht nur mit Rezept für die Anfänger, auch wenn das der Agilität eigentlich widerspricht. Natürlich sind immer wiederkehrende Retrospektiven hilfreich, um die eigenen Erfahrungen zur reflektieren und den Prozess an die eigenen Bedürfnisse anzupassen. Wirklich hilfreich ist es natürlich, wenn der Leidenschaftliche im Laufe des Projekts auf die anderen Teammitglieder abfärbt.

Damit sind wir durch den Talk durch. Wenn ich jetzt mal eine Retrospektive mache, dann hoffe ich mal, dass das nur die erste Iteration im Projekt "Agile Day" war, denn bisher kamen für mich keine brandneuen Erkenntnisse durch. An den wirklichen Knackpunkten hat sich Jutta Eckstein - natürlich auch durch die Kürze der Zeit gebremst - ausgeschwiegen. Für mich sind die Knackpunkte auf diesem Feld nämlich die Unterstützung des agilen Prozesses durch die Entwickler auf der einen Seite (der Veränderungsprozess ist in der Regel doch extrem von einzelnen Personen abhängig) und durch die übrigen an einem Projekt beteiligten andererseits. Insbesondere Vertrieb, Mitarbeiter-Plaung und Controlling sehe ich da als interessante Faktoren: Der Vertieb meint, agiles Vorgehen schlechter verkaufen zu können als ein Festpreisprojekt. Für die Mitarbeitereinsatzplaung ist es nötig, nicht nur genaue "Schätzungen" abzugeben - die natürlich keiner als Schätzungen anerkennt, aber das ist ein anderes Thema - die Mitarbeiter machen ja in der Regel nicht nur dieses eine (agile) Projekt, sondern auch noch andere Projekte, und so weiter und so fort.
Das Controlling kann naturgemäß mit Agilität nur sehr schwer umgehen - wie soll man beispielsweise den Fertigstellungsgrad bei etwas messen, das einfach per Definition nie fertig ist, sondern sich ständig in einem Prozess der Änderung befindet.

Ich hoffe, der Tag erhellt noch ein paar von diesen Fragen. Die Titel klingen ja interessant.