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, dass 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:
Wir sind Experten für 360° Feedback-Instrumente und für Mitarbeiterbefragungen, die wirklich etwas verändern. Unser erfahrenes Team unterstützt unsere Kunden in allen Projektphasen, also von der Konzeption über die Ein- und Durchführung bis hin zur Arbeit mit den Ergebnissen. Unsere innovativen Tools sind 'Made & hosted in Germany', werden inhouse entwickelt und ständig optimiert. Neugierig?
Zur Webseite...
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 Problem ist dann aber, dass die agilen Teams von der Bürokratie der „alten Organisation“ ausgebremst werden können.
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.
