von INSPIRATION: Noch eine Anleitung, wie man in großen Unternehmen agile Teams einführt und koordiniert. Offenbar sind längst nicht mehr nur Software-Entwickler davon betroffen, sondern alle möglichen Funktionen. Entscheidend ist das Kundenerlebnis.
Soll heißen: Es werden meist dort die ersten agilen Teams gebildet, wo die Mitarbeiter direkt mit Kunden und für Kunden arbeiten. Ihnen werden die notwendigen Entscheidungsfreiheiten eingeräumt, damit sich die erwünschten Effekte (verbesserte Produktivität, kürzere Markteinführungszeiten, höhere Qualität, bessere Stimmung im Team und geringere Risiken) einstellen.
Anzeige:
Weiterbildung zur agilen Change Managerin für fundiertes Wissen und praktische Relevanz ohne Berater Bla-Bla. Lernen Sie klassische Change Methoden mit neuen agilen Praktiken zu verbinden. In Kooperation und mit CAS Zertifikat der Hochschule Bremen. Hybrides Lernkonzept, d.h. Präsenz- und Remote Module wechseln sich ab.
Infos und Buchung hier
Nun gibt es ja in Konzernen jede Menge Mitarbeiter, die gar keinen direkten Kundenkontakt haben. Und auch die Autoren im Harvard Business Manager gehen davon aus, dass nicht alle Funktionen nach den agilen Prinzipien organisiert werden können, weil nicht alle dafür geeignet sind (Das agile Unternehmen). Das Problem ist dann aber, dass die agilen Teams von der Bürokratie der „alten Organisation“ ausgebremst werden können.
Wenn agilen Teams ausgebremst werden
Es gibt Konzerne, die im Hauruck-Verfahren sofort große Teile des Unternehmens umgebaut haben (ING), aber das ist riskant. Andere haben mit dualen Organisationsformen experimentiert (Bosch), aber damit die angestrebten Ziele nicht erreicht. Es gibt offenbar ein grundlegendes Prinzip, das als Voraussetzung für den Erfolg angesehen werden sollte: Das Kundenerlebnis. Jede Einheit in einer Unternehmung sollte schließlich für den Kunden arbeiten. Also erscheint es sinnvoll, sich bei der Einrichtung agiler Teams immer zu überlegen: Wer sind ihre Kunden und was können sie für diese leisten?
Das fängt beim Führungskreis an, und hier wird es spannend. Bei Bosch hat man es zunächst auf die traditionelle Weise versucht: Es wurde ein Projektplan erstellt mit einem Lenkungsausschuss, der die Aktivitäten koordinieren sollte. Aber dann besann man sich eines Besseren: Der Lenkungsausschuss verstand sich nicht mehr als Gremium, das hin und wieder von den Projektmanagern informiert wird, sondern selbst als agiles Team, das für seine Kunden, die Einheiten vor Ort, tätig wird. Die Mitglieder erstellten eine Liste von Prioritäten, kümmerte sich darum, „Hindernisse für mehr Agilität aus dem Weg zu räumen,“ gingen hinaus in die Organisation und diskutierten mit den Leitern der Geschäftsbereiche. Aus dem Lenkungsausschuss wurde ein Arbeitsausschuss.
Die Autoren empfehlen, mit einem ersten Schwung agiler Teams zu starten, sich anzuschauen, ob der Nutzen größer als die Kosten ist. Und dann weitere Teams auch in anderen Bereichen zu etablieren, die dann die Teams vor Ort als ihre Kunden verstehen. Und selbst wenn es Bereiche gibt, die nicht agil agieren und nach klassisch hierarchischem Muster geführt werden, so kann man davon ausgehen, dass diese „eine agilere Einstellung entwickeln“. So dass es auch an den Schnittstellen funktioniert. Klingt verheißungsvoll.
