Auch wenn man mich vielleicht primär dem klassischen Projektmanagement zurechnen würde, so bin ich agilem Denken und agilen Methoden mehr als aufgeschlossen. Wer ein humanistisches Weltbild hat, hat auch mit den Idealen des Agilen Manifests kein Problem. Iterative Vorgehensweisen waren da, wo sie einsetzbar sind schon immer eine hervorragende Strategie um Risiken zu minimieren und Quick-Wins zu realisieren. An meine Grenzen stoße ich bei den verschiedenen agilen Frameworks aber an zwei Stellen:
- Ihrer Ideologisierung
- Der Formalisierung
Im ersten Punkt kommt es häufig zu dem Missverständnis, dass wer nicht „agil“ auf seinen Fahnen stehen hat, wohl auch agile Werte nicht teilt und unterstützt.
Im zweiten Punkt missfällt mir die idealtypische Formalisierung der Vorgehensweisen und Rollen in den agilen Frameworks. Wenn mein Kunde sich ebenfalls im Projektteam adäquat einbringt und idealerweise die Rolle des Product Owners einnimmt und ich eine offene und konstruktive Projektkultur habe, dann ist das ein Idealzustand, der in klassischen Szenarien ebenfalls hervorragend funktioniert, wenn dort die Rolle entsprechend beispielsweise im Anforderungsmanagement und in meinen Gremien besetzt ist und wahrgenommen wird. Erfolgsfaktor ist dann aber nicht das Framework, sondern die wahrgenommene Verantwortung und die gelebte (Projekt-)Kultur.
Ein Aha-Erlebnis hatte ich in der Lego for Scrum-Session von Tilman Moser auf dem PMCampRM. Tilman ließ uns in drei Scrum-Teams in drei Sprints an einer Lego-Stadt bauen. Ziel war Scrum „erfahrbar“ zu machen. Dadurch, dass das Spiel in einen Session-Slot gezwängt wurde, unterlag der Aufbau von Anfang an vielen Restriktionen und Abkürzungen. Schätzungen Retrospektiven kamen zu kurz und Tilman genoss es auch sichtlich seine Rolle als Product Owner in vollen Zügen auszureizen. Dieser nicht-ideale Aufbau mag Fehlentwicklungen im Verlauf erklären, ich halte ihn aber trotzdem für realistisch, weil wir auch in Scrum-Projekten nicht nur mit Gutmenschen zu tun habe, auch diese unter Stress und wandelnden Anforderungen, etc. stehen.
Bemerkenswert war, dass schon in diesem kleinen Aufbau die Gruppendynamik voll zuschlug und das leider nicht in dem Sinne, wie es Scrum vorsieht, sondern im schlimmsten tayloristischen Sinn. Dabei hatten wir zufällig sogar einen ausgebildeten Scrum Master an Board, aber die Denk- und Verhaltensweisen in unserem kleinen Team erinnerten mich eher an die aus den Modellen der Akkord-Arbeit bekannte Phänomene, als an agile Ideale. Nicht wissend, was wir zu erwarten hatten, waren wir in der ersten Sprint-Planung sehr zurückhaltend. Als wir dann noch die ersten Missverständnisse mit unserem Product Owner hatten und auch unsere Möglichkeiten zur Kommunikation mit ihm innerhalb der Sprints gar nicht genutzt haben (Es waren ja nur 5 Minuten je Sprint, aber trotzdem: Wir haben es nicht getan!). Als er uns dann – mit Genuss (Schweinebacke!) am Ende des ersten Sprints auflaufen ließ, schalteten wir sofort auf Abwehrverhalten um: Bloß keine Blöße geben, Preise nicht verderben,… Ganz 1.0 halt.
Jetzt war der ganze Aufbau „nur“ ein Spiel unter zugegeben ungünstigen Voraussetzungen, aber ich habe dabei mit Schrecken meine Vorurteile bestätigt gefunden. In einer nicht idealen Welt stoßen auch agile Frameworks an ihre Grenzen.