+43-676-330-4803KontaktImpressum en de

Blog

Crossfunktionalität ist keine Sache der Teamaufstellung

Seit mein neues Buch Agilität neu denken erschienen ist, posten Leserinnen und Leser immer wieder Auszüge daraus. Mir ist aufgefallen, dass vor allem das Thema Crossfunktionalität bei vielen einen Nerv trifft. Crossfunktionale Teams gehören nämlich – ähnlich wie das Spotify-Modell – zum Inventar des agilen Reliquienschreins: Ihre Existenz wird meistens unreflektiert angebetet, doch oft sind sie nichts anderes als Silos, deren Wände neu gestrichen wurden. Ich bin der Meinung: Echte Crossfunktionalität entsteht nicht dadurch, dass man einfach Menschen aus unterschiedlichen Disziplinen in einem Team zusammenwürfelt. Für alle, die Agilität neu denken noch nicht gelesen haben: Hier ist der Abschnitt aus dem Buch, der sich damit beschäftigt.

Crossfunktionalität ist keine Sache der Teamaufstellung

Klingt alles ganz romantisch, oder? Tatsache ist, dass es sich hier um einen riesigen Change handelt. Denn warum sollten die Fachbereiche einfach so mitmachen? Die Abgrenzung zwischen „wir“ und „die“ ist ein grundlegendes, historisch gewachsenes Problem in den meisten Organisationen, egal welcher Art. Das liegt an den spezialisierten Splittergruppen, die sich bezeichnenderweise oft in Abteilungen organisieren: Sie teilen sich voneinander und vom Ganzen ab. Anforderungen und Ergebnisse werden in der Regel an andere Einheiten „übergeben“ (quasi hinübergekotzt), deren Sichtweisen und Ansprüche womöglich ganz andere sind als die der eigenen Abteilung. Für die Produktentwicklung sind die Fachbereiche ein rotes Tuch, Softwareentwickler sind was Besseres als Softwaretester, die Fachbereiche betrachten alle anderen ohnehin als Lieferanten und so weiter und so weiter.

Durch den Versuch, ein Unternehmen zu agilisieren, wird das nicht zwangsläufig besser. Crossfunktionale Teams sind super und wichtig. Es bedeutet aber nicht zwangsläufig, dass alte Muster verschwinden. Nun hat man halt das crossfunktionale Team A, das besser performt als das crossfunktionale Team B. Statt funktionaler Silos hat man jetzt crossfunktionale Silos. Gratulation! Reduziert man die Abhängigkeiten und fasst Teams zu Produkten zusammen, ist Produkt Y natürlich blöder als Produkt Z. Und aus der Sicht des Portfolios betrachtet, sitzen an der Spitze ohnehin nur Volltrottel. Mit Boni kann man die Animositäten wunderbar zementieren oder sogar verschärfen. Dadurch werden lediglich Einzelteile einer Organisation optimiert, nicht aber die Wertgenerierung für den Kunden.

Dieses Gegeneinander muss erst überwunden werden, und es funktioniert sicher nicht so easy, wie ich das anhand dieses Unternehmens dargestellt habe. Es ist ein kultureller Prozess, der schon im Recruitment beginnt: „Don’t hire skills, hire attitude“ sollte man als Maxime fordern. Klar, fachliche Expertise ist wichtig, aber es ist viel leichter, sich fachliche Kompetenzen anzueignen, als eine Einstellung zu verändern. Crossfunktionale Teams sind keineswegs der heilige Gral der Agilität, durch den auf magische Weise alle sozialen Reibungspunkte zwischen den Leistungseinheiten eines Wertstroms verschwinden – sie verlagern sich manchmal fürs Erste nur. Verschiedene Denkansätze in einem Team zusammenzuführen, ist jedoch zumindest schon einmal besser als der Fokus auf Einzelleistungen bzw. auf die einzelne Leistung in einzelnen Spezialistensilos. Im Sinne der kundenorientierten, integrierten Wertgenerierung ist es nur ein sehr kleiner Tropfen auf einem sehr heißen Stein.

Crossfunktionalität ist eine Unternehmensmentalität und keine Organisationsaufstellung für Teams. Es geht darum, eine Umgebung zu schaffen, in der es in Ordnung und sogar gewünscht ist, lokal schlechte Performance zu liefern, wenn es der Gesamtperformance der Organisation nützt. Es reicht also nicht aus, wenn alle Mitarbeiter am selben Seil ziehen – sie müssen auch in dieselbe Richtung ziehen.

–> #asareminder Bild als PDF Download <–

TWiG spricht Portugiesisch

TWiG ist wieder um eine Sprache reicher: Portugiesisch. Vielen Dank an Wellington Tonquelski Ferreira and Wilhelm Meier für die Übersetzung!   

Wir haben auch eine paar kleine Fehler in der italienischen Version behoben.

Also auf zur TWiG-Page und herunterladen!

Flight Levels und Business-Agilität in Bangkok

Zunächst ticken in Bangkok einmal die Uhren anders – der Jetlag hat mir ordentlich zugesetzt. Abgesehen davon hat mich aber die Begeisterung umgehauen, die ich bei einem Premieren- und einem Zusatz-Flight-Level-Training, einem Topmanagement-Workshop, einem Kanban-anwenden-Training und einem Vortrag in 12 Tagen Bangkok erlebt habe. Meine beiden Flight-Level-Trainings hatten drei spezielle Merkmale:

  • Fast Consultant-free. Es waren – außer mir und Organisator Kulawat Wongsaroj von Lean in Consulting – fast keine Consultants dabei. Trotzdem war das erste Training binnen kürzester Zeit ausverkauft und wir mussten einen zweiten Termin ansetzen, weil vor allem viele Manager mehr über die Flight Levels wissen wollten. Ich finde es bei so intensiven Trainings ja optimal, nicht mehr als 15 Leute zu haben. Egal, wir haben es auch mit einmal 18 und einmal 23 gut hinbekommen. Dass die Flight-Level-Trainings die Teilnehmergrenze gesprengt haben, hatte auch mit meinem Vortrag zur Business-Agilität zu tun. 150 Leute waren im Rahmen des Agile Bangkok Meetup im Saal, was ich aber nicht wusste: Über 1000 weitere haben über den Facebook-Livestream zugesehen!
  • Fast Tech-free. Wir haben uns hauptsächlich Gedanken über die Flight-Level-Idee in recht untechnischen Aufgabenbereichen gemacht: Marketing für Beauty-Produkte, medizinisches Supply-Management für Spitäler, Immobilienentwicklung und Großhandel mit sexy Unterwäsche. Eine Versicherung und eine Bank waren auch noch dabei.
  • C-levelig. Erstaunlich viele Vertreter aus dem C-Level haben sich in die Flight-Level-Trainings verirrt und festgestellt, dass sie dort genau richtig waren. Viele haben nach dem Training gesagt, dass sie nun endlich etwas total Praktisches in der Hand haben. In „Kanban anwenden“ oder auch in Scrum-Trainings lernt man, wie man Boards baut – damit können vor allem Topmanager aber meistens wenig anfangen. Durch das Flight-Level-Training wissen sie jetzt, welche Boards in der Organisation überhaupt gebraucht werden, denn der Trick ist ja nicht, die Organisationsstruktur zu optimieren, sondern die Wertgenerierung für die Kunden. Ihnen sei jetzt klar, wie diese Boards miteinander verbunden sind und wer sich in der Organisation wie über welche Boards koordinieren sollte, gaben die meisten von ihnen als Feedback. Wie das in der Praxis funktioniert, haben wir anhand von drei Beispielen aus völlig unterschiedlichen Bereichen ausprobiert.

Es darf gelacht werden – möglichst laut!

Wer jemals die Möglichkeit hat, das Schiffefalten oder TWiG mit einer Gruppe von Thailändern zu spielen, sollte das unbedingt tun. So viel positive Energie erlebe ich nur sehr selten – die Leute haben sich gebogen vor lauthalsem Lachen, Diskutieren und Argumentieren. Leider habe ich das nicht mitgefilmt, es war ein echtes Highlight für mich. Wie ich aus den Rückmeldungen entnehmen konnte, hat ihnen vor allem TWiG so viel Spaß gemacht, weil dabei noch einmal alles zusammengefasst wurde, was sie in den zwei Tagen gelernt hatten. Thailänder sind echt das beste Beispiel für Spaß am Lernen und deswegen freue ich mich jetzt schon, dass ich dieses Jahr zumindest noch ein weiteres Mal in Bangkok sein werde.

Danke Kulawat für die coolen Bilder…

Business-Agilität im Passionate Teams Podcast

Als ich den Titel vom Blog-Post tippte, musste ich schmunzeln. Business-Agilität im Passionate Teams Podcast klingt jetzt schon recht ähnlich wie Business Agilität im Das Perfekte Team Podcast, wie ein Eintrag vom 21.11. lautet. Aber ja, es sind zwei verschiedene Podcasts und der Inhalt unterscheidet sich auch. Diesmal wurde ich von Marc Löffler für seinen Podcast Passionate Teams interviewt. Inhaltlich sind wir vor allem darauf eingegangen, dass Team-Agilität alleine nicht zu Business-Agilität führt. Es ist vor allem wichtig ist, dass die Interaktionen zwischen den Teams agilisiert werden müssen. Aber hört einfach selbst rein…