von Das ist ein dickes Brett, das man bei BMW bohrte. Die IT-Gruppe mit 4.700 Mitarbeitern wurde auf eine agile Organisation umgestellt. Die Mitarbeiter bzw. die Teams sollten „End-To-End-Verantwortung“ übernehmen. Die Erkenntnis zuvor: Das klassische „Wasserfall-Modell“ mit den typischen Hierarchien als auch die Projektorganisation genügten nicht mehr den Anforderungen. Die Geschichte der „agilen BizDevOps-Transformation“ wird in der OrganisationsEntwicklung erzählt (Radikale Neuerung).
Spätestens seit der Lektüre des Beitrags von Stefan Kühl im ersten OE-Heft dieses Jahres (Die Schauseite von Veränderungsprojekten) wird man als Leser vorsichtig, wenn Unternehmen mit „Klarnamen“ über Veränderungsprojekte berichten. Zu vermuten ist, dass wir nur das erfahren, was die internen Organisationsentwickler und Berater uns wissen lassen wollen. Aber schauen wir genauer hin:
Anzeige:
Mit dem Coaching-Magazin und dem Coaching-Newsletter informieren wir Coaches, Führungskräfte, Personalverantwortliche und Coaching-Interessierte umfassend und regelmäßig über das Thema Coaching und die Coaching-Branche. Neben Brancheninfos und Hintergründen lesen Sie Konzepte und Praxisberichte, Tools sowie Interviews und sind über aktuelle Trends informiert. Zur Webseite...
Die Gruppe hatte in einigen Teams erste positive Erfahrungen mit der agilen Arbeitsweise gemacht. Und stellte sich kritische Fragen: Liefern wir das, was (interne und externe) Kunden brauchen? Sind wir schnell genug? Passen wir uns geänderten Anforderungen flexibel an? Sind wir effizient und stimmt die Qualität? Die Antwort fiel wohl negativ aus, denn die Konsequenz war das besagte BizDevOps-Konzept. Das Konstrukt steht für „Business-Software Development und Operations“, soll heißen, dass hier IT und Operations in Teams zusammen arbeiten, die von der Entwicklung bis zur Umsetzung für ein „Produkt“ verantwortlich sind.
Hier besteht der entscheidende Unterschied zur Projektmanagement-Organisatinon. Deren Verantwortung endet nämlich dort, wo es für die Kunden interessant wird: Mit der Fertigstellung des Produktes. Es findet also ein „Verantwortungsübergang“ statt. In der neuen Organisation sollen die Teams für ihr Produkt im Extremfall bis zum „End-of-Life“ verantwortlich sein.
Der Rest klingt vertraut. Es gibt nun Product-Owner (die fachlich Zuständigen), Agile Master (die für die Team-Prozesse Zuständigen, eine Art interne Coachs) und die Teams (die für die Umsetzung Zuständigen). Und natürlich immer noch den Line-Manager (die für die Entwicklung der Mitarbeiter Zuständigen).
Was muss man sich bei BMW unter einem Produkt vorstellen – ein Auto? Das sicher nicht, aber irgendwie endet ja wohl alles beim Auto. Auf dem Weg dahin kann man sich viele „Produkte“ vorstellen, die zum Einsatz kommen, ganze 800 wurden identifziert. So viele Teams wurden nun doch nicht geblldet, zumal viele „Produkte“ sehr miteinander zusammenhängen. Also wurden einige Produkte zu Domains gebündelt, für diese gibt es nun auch noch den „Domain Owner“. Ganz interessant: Domain und Produkt-Owner-Rollen werden doppelt besetzt durch IT- und Operations-Vertreter.
Klingt komplex? Ist es auch ganz sicher. Klingt schwierig? Mit Sicherheit. Unter anderem stellt sich die Standard-Frage: Was wurde aus dem mittleren Management? Es gab ca. 200 Abteilungs- und Gruppenleiter, die nun nicht mehr die komplette Führungsrolle innehaben, sondern nur noch Teil-Führungsfunktionen. Angeblich waren 10 bis 20% von Anfang an von dem neuen Konzept überzeugt, ein Jahr später hatte man zwei Drittel gewonnen. Das letzte Drittel verhielt sich zum Zeitpunkt des Berichts (Herbst 2019) abwartend und passiv. Da ist von Angst vor Machtverlust die Rede, der Angst vor einem größeren persönlichen Risiko, aber auch von einer geringeren „Sichtbarkeit“ des Einzelnen, da jetzt die Teams im Vordergrund stehen.
Wie man dieses Thema angegangen ist und was aus den Mittelmanagern schließlich geworden ist, habe ich aus dem Beitrag nicht herausgelesen. Ein Hinweis findet sich zu den Agile Mastern – deren Rolle hat wohl noch nicht den erhofften Stellenwert innerhalb der Organisation. Zu ergänzen ist noch, dass es eine Menge Trainings und Workshops im Angebot für die Rolleninhaber gibt, dass die Umsetzung in den einzelnen Teams nicht nach einem strkten Muster durchgesetzt wird, sondern es viel Spielraum gibt. Einige Instrumente sind allerdings gesetzt, zum Beispiel die Planungstreffen und Retrospektiven. Alles andere wird den Teams als „Best Practices“ an die Hand gegegeben, nicht als Vorschrift. Ob etwa in Sprints gearbeitet wird oder nicht und wenn ja, wie lange diese dauern, das entscheiden die Teams.
Tipps der Autoren für alle, die etwas Ähnliches vorhaben: Fehlerkultur fördern, die Ängste der Mitarbeiter und Führungskräfte berücksichtigen, ausreichend in agilen Methoden qualifizieren, ausreichend Raum für agiles Arbeiten schaffen, für ein klares Commitment des Management sorgen und den Kick-Off Face-to-Face machen.
Man sei schon weit gekommen, heißt es im Fazit. Was auch immer das bedeuten mag…
