Ü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.

Mit der „Rechtfertigung von politischer Autorität“ hat sich Bernd Krehoff in seiner Dissertation an der Universität Oxford auseinander gesetzt. Und das, obwohl er noch nicht wusste, dass er mit diesem Thema der praktischen Philosophie auch die alltäglichen Fragen der Führung in Scrum berühren würde.