Auch wenn man mich vielleicht prim\u00e4r dem klassischen Projektmanagement zurechnen w\u00fcrde, 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\u00dfe ich bei den verschiedenen agilen Frameworks aber an zwei Stellen:<\/p>\n
Im ersten Punkt kommt es h\u00e4ufig zu dem Missverst\u00e4ndnis, dass wer nicht „agil“ auf seinen Fahnen stehen hat, wohl auch agile Werte nicht teilt und unterst\u00fctzt.<\/p>\n
Im zweiten Punkt missf\u00e4llt mir die idealtypische Formalisierung der Vorgehensweisen und Rollen in den agilen Frameworks. Wenn mein Kunde sich ebenfalls im Projektteam ad\u00e4quat 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.<\/p>\n
Ein Aha-Erlebnis hatte ich in der Lego for Scrum-Session von Tilman Moser auf dem PMCampRM. Tilman lie\u00df 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\u00e4ngt wurde, unterlag der Aufbau von Anfang an vielen Restriktionen und Abk\u00fcrzungen. Sch\u00e4tzungen Retrospektiven kamen zu kurz und Tilman genoss es auch sichtlich seine Rolle als Product Owner in vollen Z\u00fcgen auszureizen. Dieser nicht-ideale Aufbau mag Fehlentwicklungen im Verlauf erkl\u00e4ren, ich halte ihn aber trotzdem f\u00fcr realistisch, weil wir auch in Scrum-Projekten nicht nur mit Gutmenschen zu tun habe, auch diese unter Stress und wandelnden Anforderungen, etc. stehen.<\/p>\n
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\u00e4llig 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\u00e4nomene, als an agile Ideale. Nicht wissend, was wir zu erwarten hatten, waren wir in der ersten Sprint-Planung sehr zur\u00fcckhaltend. Als wir dann noch die ersten Missverst\u00e4ndnisse mit unserem Product Owner hatten und auch unsere M\u00f6glichkeiten 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\u00df, schalteten wir sofort auf Abwehrverhalten um: Blo\u00df keine Bl\u00f6\u00dfe geben, Preise nicht verderben,… Ganz 1.0 halt.<\/p>\n
Jetzt war der ganze Aufbau „nur“ ein Spiel unter zugegeben ung\u00fcnstigen Voraussetzungen, aber ich habe dabei mit Schrecken meine Vorurteile best\u00e4tigt gefunden. In einer nicht idealen Welt sto\u00dfen auch agile Frameworks an ihre Grenzen.<\/p>\n