Wir sind komplett agil – in unserem Organisationskästchen

Agilität in monofunktionalen Teams ist maximal die halbe Miete

In Workshops, Trainings und Gesprächen rund um Agilität erlebe ich immer viel Interesse und Diskussionsfreude an dem Thema, aber auch eine ganze Reihe von Missverständnissen.

Der „klassische“ Weg, komplexe Produkte zu entwickeln und komplexe Projekte umzusetzen ist ja, dass notwendige Teilergebnisse für ein Projekt oder Produkt in einem Team entwickelt werden und dann an das Team weiter gereicht werden, das für den nächsten Umsetzungsschritt verantwortlich sind. Das ist eine Konsequenz der effizienzorientierten Arbeitsteilung in Organisationen und die daraus abgeleitete Aufteilung von Organisationen in Bereichen, Abteilungen und Teams. Die arbeitsteilige und hierarchische Pyramide eben, die wir heute in den meisten Unternehmen finden.

Häufig höre ich: „Ja, ja wir sind schon sehr weit. Wir arbeiten komplett agil. Unsere Teams in der Softwareentwicklung und im Engineering sind auf Scrum umgestiegen.“

Wenn ich Äußerungen dieser Art höre, werde ich aufmerksam und frage weiter nach. Oft stellt sich dann heraus, dass einzelne Teams jeweils für sich agile Arbeitsweisen anwenden oder mit ihnen experimentieren. Sie bleiben aber in ihrem klassischen Organisationskästchen von den anderen Projektbeteiligten isoliert organisiert.

Ich denke, dass dieser Weg ein guter erster Schritt in Richtung agilen Arbeitens sein kann, um erste Erfahrungen damit zu sammeln. Wenn an dieser Stelle dann aber stehen geblieben wird, wird das Potenzial agilen Arbeitens nicht gehoben und die Konsequenzen für die Teams und das Projekt können sogar negativ sein. So habe ich zum Beispiel festgestellt, dass der Zeitaufwand für Meetings in einem solchen Setup für Teams steigt: das agil arbeitende Team benötigt Zeit für die agilen Meetings (Planning, Daily, Review und Retrospektive) und darüber hinaus ist der Abstimmungsbedarf mit den anderen am Projekt beteiligten Teams weiterhin hoch. Kein gutes Ergebnis, wenn ich durch agile Arbeitsweisen den Zeitaufwand für Abstimmungen eigentlich reduzieren möchte.

Mich beschleicht dann oft das Gefühl, dass sich in Organisationen ein Dilemma einnistet: wir wollen etwas Neues machen (nämlich agil arbeiten), aber das Alte können oder wollen wir nicht lassen (nämlich in Organisationskästchen zu denken und handeln).

Agiles Arbeiten bietet zwei zentrale Vorteile: zum einen hilft es Unternehmen, kundenzentriert innovative Produkte zu entwickeln, die auf die Bedürfnisse der Nutzer zugeschnitten sind. Zum anderen können diese Produkte durch die Organisation von Arbeit mit viel dezentraler Entscheidungsmöglichkeit und direkter Kommunikation schnell entwickelt werden. Wenn diese Vorteile nutzbar gemacht werden sollen, ist es notwendig, „klassische“ Organisationskästchen und die Grenzen zwischen ihnen durchlässiger zu machen oder zu überwinden.

Das kann durch crossfunktionale Teams erreicht werden, in denen alle Kompetenzen gebündelt sind, die notwendig sind, um ein Projekt umzusetzen. Ein solches crossfunktionales Teams übernimmt dann umfassend Verantwortung für den gesamten Entwicklungsprozess („Ende zu Ende-Verantwortung“). Solche crossfunktionalen Teams bilden einen Querschnitt unterschiedlicher Unternehmensbereiche und die Teammitglieder arbeiten im Sinne eines gemeinsamen Projektziels zusammen und vertreten nicht primär die Interessen der Organisationseinheiten, aus denen sie kommen.

Agiles Arbeiten in monofunktionalen Teams kann also ein Anfang sein auf der Reise, als Organisation agiler zu werden. Es ist aber auch wirklich nur ein erster Schritt. Im nächsten ist es notwendig, das Denken in klassischen Organisationseinheiten aufzugeben und Projekte neu zu organisieren. Eben nicht nur das Neue zu tun, sondern auch Altes, das mit der neuen Arbeitsweise nicht kompatibel ist, konsequent zu lassen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.