Wir lesen ständig, dass man die Transition hin zu Scrum oder Agilität im allgemeinen am besten mit einem Piloten beginnt, um daraus zu lernen und dann weiter in der Breite zu skalieren. Grundsätzlich stimme ich dem zu. Wie sieht es aber aus, wenn wir der Meinung sind, dass einzelne Bereiche einer Organisation agil arbeiten (z.B. in der Entwicklung), andere jedoch klassisch vorgehen, und dies ein Dauerzustand bleiben soll?
Wir haben noch immer mit dem Vorurteil zu kämpfen, dass Agilität nur für Entwicklungsprojekte gedacht ist und auch nur dort seinen Platz hat. Am besten auch nur in der Softwareentwicklung, weil man die »richtigen« Projekte mit seinen Gantt-Charts und den kritischen Pfaden und dem ganzen Zeug erstklassig planen könnte, wenn man nur alle Eventualitäten in seine Planung einbezieht und möglichst viele von ihnen sowieso eliminiert.
Lacht nicht! So denken tatsächlich viele Unternehmen, die in einer Abteilung mit sehr reifen agilen Teams arbeiten und zwei Türen weiter ein sehr klassisches Projektmanagement praktizieren.
Ich möchte nicht über innere Einstellung sprechen oder mich gar über »ewig Gestrige« lustig machen. Ganz im Gegenteil: auch klassisches Projektmanagement mit seinen Gantt-Charts und den kritischen Pfaden und dem ganzen Zeug kann hervorragend funktionieren, wenn es sich seiner Grenzen bewusst ist. Und es ist auch keinesfalls so, dass die Möglichkeiten der Agilität grenzenlos sind. Bleiben wir also in diesem alten Glaubenskrieg neutral.
Ich möchte mir lieber Gedanken darüber machen, ob Agilität in einem Bereich und klassische Management-Prinzipien in einem anderen Bereich einer Organisation miteinander funktionieren können.
Die Antwort ist recht einfach: Je mehr die beiden Bereiche miteinander zu tun haben, desto schwieriger wird es. Das wird niemanden überraschen, und man muss auch nicht Einstein heißen, um das zu verstehen.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Wenn zwei Teams (oder Bereiche oder Filialen oder sogar Organisationen) zusammenarbeiten, von denen eines sehr kurze Planungszyklen hat, also iterativ vorgeht, das andere jedoch längerfristig plant, ist das natürlich schwierig. Wie kommen die beiden zusammen? Ich kann von keiner Seite verlangen, dass sie sich vollständig der anderen anpasst. Wir können uns also nur von zwei Seiten annähern und Kompromisse finden, was immer die Arbeitsweise beider Teams negativ beeinflusst. Die Schnelleren müssen auf die Langsameren warten, die Langsamen kommen den Schnelleren nicht hinterher. Das ist für beide Seiten schwierig.
Wir können Missverständnisse nur langsam ausräumen, und auch das Prinzip des fail early greift nur bedingt, weil eine Seite einfach langsamer reagiert. Wenn wir die Langsameren zu einer schnelleren Reaktion zwingen, löst das Stress aus, womit ich nicht nur den psychischen meine, sondern auch den im System.
Wir holen uns also eine ganze Menge Probleme ins Boot.
Hier schauen wir auf eine recht enge und regelmäßige Zusammenarbeit, z.B. derjenigen zwischen Entwickler und Kunde, wobei wir recht schnell erkennen, dass wir schon allein durch die unterschiedlichen Planungs- und Reaktionsgeschwindigkeiten größere Reibungsverluste haben. Hinzu kommt meist noch ein unterschiedliches Denken und eine grundsätzlich verschiedene Herangehensweise.
Sprechen wir über Scrum, sprechen wir auch über einen Product Owner und ein selbstorganisiertes Team, das viele fachliche Entscheidungen selber treffen kann. Wenn das nicht der Fall ist, sprechen wir sehr wahrscheinlich nicht über eine agile Seite unserer zweiseitigen Medaille. Auf der anderen Seite haben wir jedoch ein fremdgesteuertes Team, in dem möglicherweise noch ein Vorgesetzter die fachlichen Entscheidungen trifft. Das bedeutet, dass auch die kurzen Wege entfallen, in denen sich aus beiden Teams zwei Leute an einen Tisch setzen, sich kurz besprechen und eine gemeinsame Entscheidung treffen.
Stattdessen muss der Fachbereichsleiter, Projektmanager oder wer auch immer miteinbezogen werden, damit dieser dann entscheiden kann. Das ist aber eine einzelne Person, an der von allen Seiten gezerrt und gezogen wird. Die muss erst einmal greifbar sein, dann muss sie schlau gemacht werden, dann muss sie eine Entscheidung treffen, die dann dem Team mitgeteilt werden muss. Für den Agilen Partner ist dieses Vorgehen äußerst frustrierend, für den klassischen Partner schwierig, weil vom Agilen Druck aufgebaut wird, endlich in die Puschen zu kommen.
Also kurz zusammengefasst: Je enger beide Einheiten zusammenarbeiten, desto schwieriger wird es, bis hin zum kompletten Stillstand. Aber auch bei einer sehr lockeren Kopplung treten Probleme auf, wenn ein Team z.B. Dienstleister für andere innerhalb der Organisation ist, was z.B. sehr oft auf die Admins zutrifft.
Der eine braucht etwas schnell, weil er kurzfristig plant, der andere will aber längerfristig planen oder hat zeitraubende Prozesse. Natürlich denkt ein Scrum Team auch über die zwei Wochen hinaus, dennoch wird es auch in diesen eher seltenen Zusammenarbeiten immer etwas schwer.
Es müssen nicht beide Seiten Scrum folgen. Das macht auch nicht in jedem Team Sinn. Gerade die Dienstleister in einem Unternehmen werden eher ein Flussmodell (also irgendwas mit Kanban) aufbauen. Das ist vollkommen in Ordnung, wenn es verlässliche SLAs gibt, mit denen das Scrum Team planen kann. In so einem Fall sollte es keine Schwierigkeiten geben.
Auch Teams, die als Partner an einem Projekt arbeiten, können sich trotz unterschiedlichen Vorgehens gut ergänzen, wenn beide dem Prinzip iterativ empirischen Vorgehens treu bleiben und befähigt sind, eigene Entscheidungen zu treffen. Da müssen wir uns nur um ein wenig Feintunig kümmern, und dann läuft das im allgemeinen.
Es ist wichtig, dass wir uns bewusst machen, dass alle Bereiche der Organisation zusammenhängen. Einige Teile stehen enger beieinander als andere, aber das Ganze ist immer ein miteinander verwobenes Netz. Es ist demnach völlig egal, wo ich eine Grenze zwischen Agiler und Klassischer Welt ziehen möchte, ich werde immer eine Grenze haben, die einige sehr deutlich und andere weniger deutlich betrifft.
Ich muss mir ebenfalls bewusst machen, dass diese Verwerfungen immer teuer sind. Sie erzeugen Missverständnisse, Wartezeiten, manchmal Streit und viele andere Dinge, die für die Organisation schädlich sind. Also sollte ich das Bestreben haben, die Skalierung Agilen Vorgehens auf die gesamte Organisation auszuweiten. Naturgemäß ist das am einfachsten, wenn ich das Netzwerk von meinem Piloten ausgehend aufrolle und nicht an mehreren Punkten solche Keimzellen aufbaue, weil ich damit diese Schwierigkeiten nur vervielfältigen würde.
Eine natürliche Grenze in einem Unternehmen habe ich gefühlt immer zwischen Leistungserbringung und Organisation (z.B.. Personal oder Controlling). In Teilen stimmt das auch, trotzdem spricht Vieles dafür, auch diese Bereiche bei einer Skalierung nicht auszusparen.
Bitte vergesst nicht, dass wir gerade bei diesen Organisationselementen Berührpunkte zu fast allen anderen Bereichen haben. Wenn wir dann jedes mal aneinander vorbei reden und uns nicht wirklich verstehen, warum welche Dinge wie gemacht werden, gibt das viel Konfliktpotential in das System, und wir werden uns in endlosen Diskussionen verlieren. Wenn Ihr irgendwie die Chance dazu habt, vermeidet das.
Dass ein agiles Vorgehen auch für diese Bereiche nutzbringend sein kann (und meistens auch ist), kommt noch hinzu.
Ich bin der Meinung, dass eine Organisation über alle Bereiche – horizontal wie vertikal – ähnlich denken sollte. Nur dann kann sie ihr gesamtes Potential ausschöpfen. Dieses ähnliche Denken wird sich immer auch in einem grundsätzlich ähnlichen Vorgehen äußern. Eine gesunde Organisation wird also auch aus eigenem Antrieb danach streben, ein über alle Bereiche ähnliches Vorgehen zu entwickeln. Wenn das nicht der Fall ist, haben wir viel grundsätzliche Arbeit vor uns.
Kernaussagen:
Agilität in einem einzelnen Bereich eines Unternehmens ist schwierig, weil es so in der Zusammenarbeit mit anderen Bereichen Missverständnisse und Abstimmungsprobleme gibt.
Das Unternehmen muss nicht komplett auf Scrum switchen, aber es sollte sich auf ein iteratives empirisches Vorgehen einigen, da sonst die Verwerfungen zwischen kurzer und langer Planung zu groß werden.
Dies gilt vor allem in der Leistungserbringung. Andere Bereiche wie z.B. Personal o.ä. können nachziehen, sollten aber nicht ewig anders vorgehen.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
