Diese Woche war ich auf dem Scrum-Day (eigentlich Scrum-Days, denn es waren 2 Tage) inmitten der agilen Community. Entwickler, Produktmanager, Coaches, Berater – ein breites Spektrum, jedoch sehr viele Teilnehmer, die im eigenen Unternehmen nach Scrum arbeiten wollen. Ein Großteil der Workshops und Vorträge drehte sich jedoch nicht um die konkrete Anwendung der agilen Vorgehensweise, sondern darum, wie man die Integration in die Unternehmensprozesse und -entscheidungswege erreicht. Kurz: Wie sag ich es meinem Management und schaffe es, dass dies ebenfalls involviert und integriert ist.
Workshops zu den Themen „laterale Führung“ und „Scaled Agile Framework“ sorgten am ersten Tag für interessante Diskussionen. Was ist „gute“ Führung – und wer führt eigentlich? Auch bei Scrum gibt es einige Führungsrollen (Product Owner, Scrum Master) mit Verantwortung. Jedoch werden die Verantwortlichen nur sehr wenig auf ihre Führungsaufgabe vorbereitet, sondern sie sind sehr stark fachlich getrieben. Das ist kein Unterschied zum Projektgeschäft, bei dem der Projektleiter ebenfalls oft auf das technische und methodische reduziert wird. Die Awareness, in welchen Fällen man wie führen muss, ist ein erster Schritt zur bewussten Ausübung. Und laterale Führung, d.h. Führen ohne disziplinarische Weisungsbefugnis, ist sicher eine gute Möglichkeit, motivierte selbst verantwortliche Teams zu entwickeln.
Der 2. Workshop zum „Scaled Agile Framework“ zeigte den Weg auf, wie Programm- und Portfoliomanagement mit agilen Prozessen verknüpft werden kann. Top-Down-Ansätze sorgen für die Festlegung der Rahmenbedingungen und grundsätzlichen Vorgehensweisen, die eine gemeinsame Nutzung der agilen Ansätze sicherstellen. Dadurch können Teams, die an gleichen Produkten arbeiten, sich so abstimmen, dass sie weiter in Sprints unterwegs sind, das Große Ganze aber nicht aus den Augen verlieren. Und dass die Abhängigkeiten gemanagt werden – denn sonst entsteht aus agilen Ansätzen schnell Chaos. Das sind ähnliche Schwierigkeiten, die auch bei Multiprojektmanagement auftreten. Daher gaben die Ansätze noch einige Ideen, wie die Kategorisierung und Priorisierung, die auf Portfolio-Ebene gemanagt werden müssen, umgesetzt werden können.
Am 2. Tag wurde in den Vorträgen immer wieder das Thema angesprochen, wie man das Management am besten mit einbezieht. Und wie wichtig es ist, auch die agilen Prozesse bzgl. ihrer Zielführung zu hinterfragen und ggf. anzupassen. So wurden bei einem Unternehmen die Sprints aus den Zeitboxen genommen und die Features und User Stories sind maßgeblich zur Einteilung eines Sprints. Erfolgreich, wie wir hörten, mit einigen Handicaps, die ebenfalls deutlich gemacht wurden.
Entscheidend ist es, sich immer wieder die Frage zu stellen, ob die gewählte Methode der beste Weg ist. Hin und wieder muss man dazu aus der Detailebene der Sprints raus und auf eine höhere Ebene, um die Änderungen umzusetzen. Eine bewährte Technik dabei kenne ich aus dem Portfoliomanagement (aus MoP®): Das Champion-Challenger-Model: Es werden Prozesse zur Bearbeitung von Projekten festgelegt, die solange Champion bleiben, bis das Vorgehen eines Challengers als effektiver erkannt wird. Dann wird der Challenger der neue Champion-Prozess. Und vor allem heißt es: solange wir nichts besseres finden, arbeiten wir nach dem definierten Prozess. Wenn dieser nicht passt, sollte man einen neuen Prozess vorschlagen – dieses Vorgehen bietet sich für die Einführung von neuen Strukturen immer an, und ist insbesondere im Projektmanagement erfolgversprechend. Denn erst durch das Anwenden der Prozesse stellt man fest, wo das Konzept in der Praxis seine Schwächen hat und wie man diese beheben kann.