Enterprise Awareness

Bild: Wikimedia Commons / José Sáez - CC BY-SA 3.0

Es ist ein häufig zu beobachtendes Phänomen: im Rahmen einer Umstellung auf agile Arbeitsweisen lernen die beteiligten Teams, dass sie ab jetzt autonom und selbstverantwortlich sind, treffen mutig erste Entscheidungen - und kollidieren heftig mit Notwendigkeiten der sie umgebenden Organisation. Je nach Kontext folgen Klärungen oder Eskalationen, die aber in der Regel das selbe Ergebnis haben: den Teams werden die Grenzen der Selbstorganisation aufgezeigt.

An dieser Stelle ergibt sich eine spannende (und leider zu selten gestellte) Frage: wie kann es dazu kommen? Oder präziser gefragt: ist derartig handelnden Team nicht bewusst, dass es Vorgaben oder Abhängigkeiten gibt und welche das sind? Die Antwort darauf ist erstaunlich häufig Nein. Die Gründe dafür können vielfältig sein und von fehlendem Interesse bis zu einem Herrschaftswissen hortenden Manager reichen, das Ergebnis ist aber immer ähnlich - die oben erwähnte unschöne Kollision.

Zur Vermeidung dieser Kollision haben die agilen Frameworks mit der Zeit verschiedene Ansätze entwickelt. Scrum (und davon abgeleitet Nexus und LeSS) gehen etwa davon aus, dass die Gesamt-Organisation sich an den Bedürfnissen der Teams ausrichten muss, was prinzipiell richtig, in der Realität aber schwer umzusetzen ist. SAFe stützt sich auf  Top-Down Vorgaben, was das Problem auf Kosten der Agilität löst. Und Flight Levels setzen einfach voraus, dass Abhängigkeiten irgendwie bekannt werden.

Den vermutlich pragmatischsten Weg hat ausgerechnet ein Framework gewählt, das bisher noch keine nennenswerten Impulse einbringen konnte: Disciplined Agile (DA), die "agile Tochter" des Project Management Institute (PMI). DA geht davon aus, dass agile Teams die in einem grösseren Umfeld eingebunden sind "Enterprise Awareness" entwickeln müssen, also ein Bewusstsein dafür, in welche Abhängigkeiten sie eingebunden sind und wo bereits Lösungen für ihre Probleme vorhanden sind.

Da dieses Bewusstsein nicht vom Himmel fällt wird von DA empfohlen, dass die Teams in einen engen Austausch mit Personen gehen die über eine ausreichende Übersicht verfügen und darauf aufmerksam machen können wo Team-übergreifende Zusammenhänge bestehen. Spezifisch genannt werden dafür Enterprise Architekten und Portfolio Manager, aber auch andere Rollen können in Frage kommen (je nach Einzelfall dürfte das unterschiedlich sein).

Natürlich ist auch dieser Ansatz nicht ohne Risiken. Zum einen müssen die Teams überhaupt wissen, dass es diese Ansprechpartner gibt, des weiteren müssen diese auch ausreichend freie Kapazität haben um im Zweifel kurzfristig ansprechbar zu sein und zuletzt müssen sie bereit sein ihre Rolle so auszuüben, dass sie eher beratend und weniger anweisend und kontrollieren ist (was umgekehrt natürlich voraussetzt, dass die Teams bereit sind sich beraten zu lassen).

Am Ende macht aber gerade diese Unklarheit diesen Weg zu einem den man als agil bezeichnen kann. Er gibt einen Rahmen vor, überlässt den Beteiligten wie sie ihn füllen und vertraut darauf, dass sie das entsprechende Verständnis haben um es auch in einer zielführenden Art tun zu können. Und für den Fall, dass die Beteiligten noch nicht das Gefühl haben von sich aus so weit zu sein, sieht auch DA die üblichen helfenden Rollen vor, den Scrum Master und den Agile Coach.