Cross-funktionales Arbeiten - wie geht das?

Über Apple ist in den letzten Jahren so viel geschrieben worden, dass in der Flut an Informationen nur noch wenige wirklich neue Erkenntnisse aufwarten. Und doch: Auf der Webseite Co.Design ist kürzlich ein aufschlussreiches Kurzportrait über Apples Designkultur erschienen. Der Bericht stützt sich auf Mark Kawano, der sieben Jahre lang als Designer für Apple arbeitete.Die Kernaussage ist: Apples Designkultur ist nicht auf die Herrschaft besonders begabter Designer zurückzuführen. Sie beruht vielmehr auf einer Ausrichtung des gesamten Unternehmens auf gutes Produktdesign. Bei der Entwicklung neuer Produkte sind Designer und Entwickler so in der Lage, am gleichen Strang zu ziehen:"For the most part, Apple didn't employ specialist designers. Every designer could hold their own in both creating icons and new interfaces, for instance. And thanks to the fact that Apple hires design-centric engineers, the relatively skeleton design team could rely on engineers to begin the build process on a new app interface, rather than having to initiate their own mock-up first."In Scrum sprechen wir in diesem Zusammenhang von cross-funktionalem Arbeiten: Wie in einem Operationssaal arbeiten Spezialisten Hand in Hand. Jeder hat andere Aufgaben und auch Ziele - und trotzdem weiß jeder zu jedem Zeitpunkt, was der andere gerade macht und wo er welche Unterstützung braucht.In der Produktentwicklung gibt es diese Spezialisierung ebenfalls: Disziplinen wie Design, Konstruktion, Qualitätsmanagement, Einkauf, Marketing und Vertrieb sind normalerweise in verschiedenen Abteilungen untergebracht. Innerhalb von Produktentwicklungsprojekten kommen die Abteilungen zwar punktuell zusammen (etwa beim Erreichen von Meilensteinen), doch findet keine intensive Zusammenarbeit wie im OP-Saal statt. Das führt häufig dazu, dass jede Disziplin ihren eigenen Zielen folgt und sich nicht genügend austauscht:

  • Die Entwickler wollen anspruchsvolle und komplexe Funktionalitäten.
  • Die Designer wollen einen Benutzer, der zum Produkt eine positive Beziehung aufbauen kann.
  • Das Marketing will, dass sich das Produkt von der Konkurrenz abhebt.

Dass jede Disziplin ihren eigenen Zielen folgt, ist völlig normal. Doch führt ein Mangel an Zusammenarbeit dazu, dass aus Unkenntnis über die Ziele der anderen kein gemeinsamer Grund entstehen kann. So haben wir die berüchtigten Silos, in denen nur noch lokal optimiert wird.

Das Team als Keimzelle der cross-funktionalen Zusammenarbeit

Mit der Schaffung von Scrum-Entwicklungsteams ist formal eine Instanz geschaffen, in der die verschiedenen Spezialisten zusammen kommen. Und es gibt auch einen gemeinsamen Grund: Die Verantwortung des Entwicklungsteams ist die erfolgreiche (Aus-)lieferung des Produkts. Doch der erfolgreichen Zusammenarbeit stehen häufig Hindernisse im Weg. Die typischen Hindernisse sind:

  • Ressourcenengpässe: Wer für viele Projekte eingeplant ist, kann in keinem wirklich mitarbeiten.
  • Wissensmangel: Interdisziplinäre Zusammenarbeit erfordert genügend Wissen über die Arbeit der anderen, um von den gleichen Dingen sprechen zu können.
  • Unklare Rollenerwartung: Die Mitarbeit in interdisziplinären Teams braucht zunächst eine andere Haltung: nicht die des Experten, sondern die des lernenden Anfängers.

Organisationsveränderung will gelernt sein

Keines der drei Hindernisse ist prinzipieller Natur - alle sind sie überwindbar. Sie erfordern allerdings mutige Entscheidungen, die altbewährte Denkweisen und Paradigmen wie z.B. das der maximalen Auslastung und Effizienz in Frage stellen.Machen wir uns nichts vor: Der Weg zum cross-funktionalen Arbeiten ist für die meisten Unternehmen ein starker Veränderungsprozess, der zu Widerstand und tiefer Verunsicherung führen kann. Umso wichtiger ist das Design des Prozesses: Veränderungen, die von wenigen konzipiert und dann ausgerollt werden, haben meistens mit erheblichen Akzeptanzproblemen zu kämpfen. Man spart sich viele Grabenkämpfe und Umwege, wenn die Betroffenen von Anfang an zusammen kommen, damit sie selbst einen Lösungsvorschlag erarbeiten.Hierzu bietet sich das Format der Pilotgruppe an, die aus einem repräsentativen Querschnitt des Unternehmens besteht und damit beauftragt wird, Antworten auf die relevanten Fragestellungen zu finden. Wichtig ist, dass eben diese Fragestellungen und die dazu gehörigen Rahmenbedingungen im Vorfeld vom Management festgelegt werden. Wir haben am Beispiel Apple gesehen, wie ein Unternehmen seine Kernbotschaft (bei Apple ist es das Design) über einige wenige Spezialisten hinaus in der gesamte Unternehmenskultur verankern konnte.Was auch immer Ihre Kernbotschaft ist: Erlauben Sie nicht, dass sie von den Zwängen der Unternehmensprozesse und -strukturen verwässert wird.

Agile Toolbox
Team
bgloger-redakteur
August 21, 2014

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Der kybernetische Teamkollege
BG

Der kybernetische Teamkollege

Agile Strategie mit OKRs: Vom Denken ins Tun kommen
BG

Agile Strategie mit OKRs: Vom Denken ins Tun kommen

KI als Teammitglied - Wie Scrum Master von generativer KI profitieren können
BG

KI als Teammitglied - Wie Scrum Master von generativer KI profitieren können

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein
BG

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?
BG

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion
BG

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht
BG

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht

DeepWork für Autoren – Wie du dein Buch effizient schreibst
BG

DeepWork für Autoren – Wie du dein Buch effizient schreibst

Scrum ist tot, es lebe Scrum!
BG

Scrum ist tot, es lebe Scrum!

Agile Leadership ist nicht gleich agile Leadership
BG

Agile Leadership ist nicht gleich agile Leadership

Seth Godin über Strategie als Denkweise
BG

Seth Godin über Strategie als Denkweise

Die Essenz einer Erfolgreichen Geschäftsstrategie – Einsichten von Seth Godin 
BG

Die Essenz einer Erfolgreichen Geschäftsstrategie – Einsichten von Seth Godin