Über den Tellerrand

Bild: Max Pixel / Reinhard Thrainer - CC0 1.0

Zu den etwas irritierenden Momenten meines Jobs gehört im Augenblick, dass ich (der agile Coach) die Mitarbeiter eines Kunden bei ihren PMI-Weiterbildungen begleiten darf. Ich bin zwar alles andere als ein Fan, habe mich aber bereits vor einiger Zeit durch den dazugehörigen "Body of Knowledge" gearbeitet und kann daher aufzeigen wo er Schnittmengen mit agilen Vorgehensweisen hat (z.B. bei der Rolling Wave-Planung) und wo nicht. Und wenn es dazu beiträgt mehr Realitätsbezug und weniger Bürokratie in Projektplanungen einzubringen, dann hat es sich bereits gelohnt.

Bei einem anderen Kunden wurde ich vor einiger Zeit in Meetings gebeten in denen ein SAFe-Projekt aufgesetzt wurde. Auch davon bin ich kein besonderer Fan, hatte mich aber irgendwann eingearbeitet und konnte dadurch etwas beitragen: als ein Manager darauf bestehen wollte, dass man in dieser Methode möglich viel zentralisierte Planung haben will konnte ich belegen, dass (zumindest in der Theorie) das Gegenteil der Fall ist. Zentralisiert wurde später zwar trotzdem, allerdings zumindest ohne das Wort "Agile" dafür zu missbrauchen.

Im Umkehrschluss kenne ich eine ganze Reihe von Scrum Mastern und agile Coaches die in vergleichbaren Situationen aus Diskussionen aussteigen mussten, weil sie vom jeweiligen Thema keine Ahnung hatten. In einigen dieser Fälle waren Beschlüsse das Ergebnis, die nur mit Mühe oder gar nicht mehr zurückgedreht werden konnten. Hier hätte es geholfen zumindest ein Grundverständnis zu haben.

Genau dieses Grundverständnis ist auch der Punkt um den es geht. Natürlich kann niemand alles wissen, es ist aber auf jeden Fall sinnvoll bis zu einem gewissen Grad mitreden zu können, sei es in den genannten Beispielen zu PMI oder SAFe oder im Fall von ITIL, Prince2, ISTQB oder sonstigen Ansätzen mit kryptischen Abkürzungen. Den meisten überzeugten Agilisten macht das Beschäftigen mit diesen Themen zwar nur wenig Spass, dass es im Job vorteilhaft sein kann dürfte aber offensichtlich sein.

Ein häufiges Argument gegen die Einarbeitung in diese Wissensgebiete ist übrigens, dass das Zeit erfordert, die nicht zur Verfügung steht. Ironischerweise kommt es häufig von Menschen die nicht erklären können was ein Scrum Master/Agile Coach den ganzen Tag macht. Vielleicht besteht da ein Zusammenhang.