Rank und schlank

Jochen Gürtler ist studierter Informatiker, Gestalttherapeut, Business Coach und Lehrbeauftragter an der School of Design Thinking am Hasso-Plattner-Institut in Potsdam sowie an der Universität Mannheim. In seiner Rolle innerhalb des Design and Co-Innovation Centers der SAP plant und moderiert er Design-Thinking-Workshops und -Trainings, begleitet Kunden bei der Einführung von Design Thinking und unterstützt Co-Innovations-Projekte.
 

Herr Gürtler, Design Thinking und Scrum würde man eher bei kleineren Unternehmen erwarten. Sie verwenden beide Methoden bei SAP. Wie kam es dazu? 

Ich kann natürlich nicht für die ganze SAP sprechen, sondern nur basierend auf den Erfahrungen, die ich in den letzten Jahren gemacht habe.
Die Ausgangsfrage war: Wie lässt sich Effizienz mit einem globalen Entwicklungsteam realisieren? Mit mehreren Tausend Leuten weltweit an einem Softwareprojekt zu arbeiten, ist mit klassischen Planungsmethoden wie dem Wasserfallmodell nicht mehr effizient möglich. Bei SAP hat man daher angefangen, sich mit Lean, Scrum und agilen Methoden der Softwareentwicklung zu beschäftigen. Man hat dies Stück für Stück eingeführt und hat gelernt, diese Ansätze nicht nur mit einem, sondern mit vielen (Scrum-)Teams zu praktizieren, die sich untereinander zuarbeiten und die gemeinsam an größeren Entwicklungsthemen arbeiten.
Die Abläufe in der Entwicklung wurden dadurch letztendlich wesentlich effizienter - es war wieder möglich, verlässlich, in einem regelmäßigen Turnus und in ausreichender Qualität Software zu liefern.
 

Und Design Thinking? 

Da war die Frage nach dem nächsten Produkt, der nächsten Innovation. Hierfür reichten Lean und Scrum nicht aus, da brauchte es mehr: einen Kreativitäts-, einen Innovationssprung.
Da kam Design Thinking ins Spiel. Interessanterweise war das auch ein Schritt zurück zu den Ursprüngen der Firma, denn SAP war ja quasi als Design-Thinking-Firma gestartet, indem man direkt beim Kunden zusammen mit den Endanwendern entwickelt hat. Dieser Kontakt zum Endnutzer ist über die Jahre leider ein wenig verloren gegangen, weil die Firma größer und größer wurde.
Mit Design Thinking intensivieren wir die Nähe zum Kunden und stärken zudem Kreativität und die viel zitierte innovative Kultur. Die Folge ist ein besseres Verständnis unserer Kunden und deren Bedürfnisse - und damit letztendlich bessere, weil nutzerzentriertere Produkte. Wir haben übrigens festgestellt, dass Design Thinking und Lean wunderbar zusammenpassen.
 

Inwiefern? 

Bei Lean ist die Frage: Wie kann ich etwas effizient implementieren? Design Thinking fragt: Wie komme ich zu Ideen, zum Prototyp, zur Vision? Beide Fragen sind offensichtlich wichtig. Und beide müssen beantwortet sein, um erfolgreich zu sein.
 

Wenn Sie eben sagten, dass es wieder möglich wurde, termingerecht Software zu liefern, dann klingt das so, als sei SAP nicht mehr dazu in der Lage gewesen. Stimmt der Eindruck? 

Ich kann natürlich nur für die Bereiche sprechen, in denen ich direkt beteiligt war, aber dort hatten wir in der Tat mit solchen Problemen zu kämpfen.
 

Woran lag das? War es die Größe des Unternehmens? Oder lag es an der Planung?  

Die Größe der Firma war sicher ein Problem, es war aber auch ein Planungsproblem. Man hat versucht, etwas zu entwickeln, das man in einem Jahr oder zwei Jahren braucht, hat dabei aber den Kunden, den Anwender aus dem Blick verloren oder ihn gar nie im Fokus gehabt. Durch diesen langen Zyklus, eine Software zu planen, umzusetzen, zu testen, dann aber erst zu sehen, ob sie Sinn macht, ist zu viel Zeit vergangen. Als die Produkte beim Kunden ankamen, waren sie oft nicht mehr marktgerecht.
 

Die Kombination von Design Thinking und Scrum hat diese Probleme aus der Welt geschafft?  

Ich würde nicht sagen, dass wir eine Kombination von Design Thinking und Scrum haben. Sondern Scrum ist das darunter liegende Modell, die Arbeit zu planen und zu strukturieren. Es ist das Prozessmodell, das alles zusammenhält. Es bewährt sich sowohl bei der Arbeit an bestehenden Produkten wie auch bei der Entwicklung von neuen - von klassischer Produktentwicklung bis hin zu Research-Projekten. Die iterative Planung innerhalb des Scrum-Modells hat sich aus meiner Sicht einfach bewährt.
 

Iterative Planung heißt, das Projekt wird nicht mehr wie früher von Wasserbecken zu Wasserbecken durchgeplant, sondern das Team geht in einzelnen Schritten vor?  

Iterative Planung meint, dass man eben nicht die Arbeit für ein ganzes Jahr im Detail im Voraus plant, sondern dies vielleicht für ein oder zwei Sprints tut. Damit spart man einerseits Zeit und bleibt damit natürlich auch wesentlich agiler, weil man nach jedem Sprint die Planung anpassen und ändern kann.
 

Wie sieht die Organisation der Scrum-Projekte konkret aus?  

Aufgrund der Vielzahl von Scrum-Teams entstand in vielen Bereichen der SAP eine mehrstufige Organisation. Es gibt den Chief Product Owner, der ein Produkt verantwortet, an dem teilweise mehrere Hundert Entwickler arbeiten. Darunter gibt es oft mehrere Area Product Owner, die jeweils für einen Teilaspekt des Produkts zuständig sind. Pro Area Product Owner gibt es dann mehrere Scrum-Teams, die in diesem Bereich entwickeln. Auf der Ebene der einzelnen Scrum-Teams gibt es den Product Owner, der die Sprints und die User Stories, also die Anforderungen aus Anwendersicht, definiert und im Backlog festhält.
 

Was gibt es darüber hinaus an Organisations- und Managementstrukturen? 

Daneben gibt es die Linienorganisation, also die People Manager. Früher war der Development Manager oft beides, er war Product Owner und People Manager. Das wurde im Rahmen der Lean-Einführung aber oft getrennt.
Es gibt also gewissermaßen eine Doppelstruktur: einmal die Organisation für das Produkt, angefangen von dem Chief Product Owner bis hin zu den Scrum-Teams. Und es gibt die Linie, wo People Manager die Leute aus den unterschiedlichen Scrum-Teams betreuen. Diese Zweiteilung gab es so vorher nicht. Aus meiner Sicht hat sich diese Aufteilung aber nach anfänglichen Problemen bewährt.
 

Und was heißt People Management konkret? Sie sprechen von Betreuen, was passiert da? 

Es geht um die gezielte Förderung und Entwicklung der Mitarbeiter, also konkret um Weiterbildungen und Trainings. Dies wird in der Regel in Mitarbeitergesprächen festgelegt. Hierfür ist der People Manager verantwortlich: Er muss dafür sorgen, dass die Mitarbeiter ihnen entsprechende Fortbildungen erhalten, dass Mitarbeiter mit spezifischen Kenntnissen zur Verfügung stehen - und natürlich auch dafür, dass die Mitarbeiter diese Optionen mit Motivation und Freude wahrnehmen.
 

Ist Weisung und Kontrolle, dieses alte mit der Linie verbundene Modell, damit komplett aus der Firma verschwunden?  

Von Weisung und Kontrolle im strengen Sinne kann nicht mehr die Rede sein: Wir haben Teams, die selbständig entscheiden sollen und dies auch tun. Mittlerweile reden wir hier von Lean Leadership: Es geht nicht mehr darum, Dinge vorzugeben und Ergebnisse zu kontrollieren, sondern es geht darum, die Teams in die Lage zu versetzen, eigenständig und sinnvoll zu agieren.
Am Anfang gab es gewisse Schwierigkeiten, die Zuständigkeiten genau zu definieren. Beispielsweise obliegt es dem Manager, Zielvereinbarungen zu treffen und die Ergebnisse zu bewerten. Andererseits ist der Product Owner derjenige, der im Team vorgibt, was gemacht werden soll; er steht somit einer sinnvollen Bewertung des Teams oder auch einzelner Teammitglieder näher. Mittlerweile gibt es da auch, denke ich, einen sehr guten Austausch zwischen dem People Manager und dem Product Owner.
 

Bei Scrum gilt das Prinzip, dass das Team selbst entscheidet, was es bis zu welchem Termin liefern kann. Das aber immer im Rahmen des definierten Gesamtziels. 

Das ist richtig. Es gibt den Product Backlog, eine priorisierte Liste, die alles enthält, was das Produkt später an Eigenschaften besitzen sollte. Natürlich kann das Team nicht beliebige Dinge aus dem Backlog herausnehmen. Und natürlich kann der Product Owner sagen, meine Prioritäten sind: eins, zwei, drei, vier, fünf ... Liegt ein Dissens vor, muss dieser diskutiert werden, und es muss eine Lösung gefunden werden. Von einer freien, beliebigen Entscheidung auf Teamebene kann also keine Rede sein. Aber das Team hat sicherlich mehr Rechte als früher, keine Frage.
 

Wie verhält es sich mit der Hierarchie. Gibt es die noch? 

Sicher gibt es die noch, und das ist, denke ich, auch gut so. Was sich aber in der Tat wirklich geändert hat, das ist, dass sich ein Team viel mehr als früher einbringen kann und (mit)entscheiden kann, was gebaut wird. Das Wie obliegt den Experten in den Teams.
 

Zusammenfassend: Ist Scrum eine Methode oder ein Modell, Prozesse zu organisieren?  

... ja, ein Modell, um Prozesse und Arbeit in Teams zu organisieren.
 

... und was ist dann Design Thinking? Sie sprechen in Ihrem Buch von einer Arbeits- oder Problemlösungskultur. 

Mit Design Thinking möchte man - salopp gesagt - Lösungen für Probleme finden, die sich mit analytischem Denken oder mit klassischen Methoden nicht leicht lösen lassen. Im Ansatz beruht Design Thinking auf der Arbeitsweise von Designern. Man hat das strukturelle Moment übernommen, die Arbeit in gemischten Teams: Unterschiedliche Leute mit unterschiedlicher Expertise bringen sich ein. Auch Leute, die von Software gar keine Ahnung haben. Ein solches Team braucht eine gewisse Kultur und idealerweise einen eigenen (Arbeits-)Raum, in dem es arbeiten, den es frei gestalten kann und den es zur ständigen Verfügung hat.
Für die Arbeitsweise ist entscheidend, dass zu Beginn das Problemverständnis und nicht bereits die Lösung im Fokus steht. Das Problem darf nicht zu schwammig sein, sollte aber auch nicht schon einen Lösungsvorschlag implizieren. Erst nachdem das Problem klar umrissen und verstanden ist, geht es um Lösungsansätze. Und mit diesen wird dann ganz konkret gearbeitet: Man baut Prototypen aus Papier, Pappe und Styropor und durchdenkt Anforderungen und Ergebnisse in vielen und möglichst kurzen Feedbackschleifen.
 

Was zeichnet die von Ihnen angesprochene Arbeitskultur aus? 

Zunächst sollte man sehr offen und neugierig sein und wirklich lernen wollen. Man sollte ernsthaft bereit sein, sich in die Lage des Benutzers zu versetzen, um das Problem aus seiner Perspektive zu betrachten - und nicht vorher schon zu meinen, man wüsste bereits alles. Weiter geht es darum, Dinge sehr schnell auszuprobieren. Dazu gehört auch, dass vieles nicht funktioniert; dann muss man immer wieder neu ansetzen. Scheitern gehört dazu, man darf nur nicht versäumen, aus den Fehlern zu lernen. Kurz: Es hat etwas Spielerisches. Bedingung für diese Arbeitsweise ist natürlich eine vertrauensvolle Atmosphäre. Denn die Erkenntnis ist einfach die: Wenn ich im Team nicht das Vertrauen habe, Dinge einfach ausprobieren zu können, dann würde ich eine zunächst verrückte, vielleicht letztlich aber zielführende Idee, die ich gerade im Kopf habe, nicht sagen. Ganz einfach, weil ich Angst habe, ausgelacht zu werden.
 

... oder etwas Unfertiges rausgeben ... 

... ganz genau, man könnte sich blamieren. Diese vertrauensvolle, offene Kultur im Team und in der Organisation ist ganz wichtig: eine Kultur, in der es erlaubt ist, Unfertiges zu zeigen.
 

Design Thinking kümmert sich explizit um die Bedingungen, unter denen ein Team gut arbeiten kann? 

Vor allem um die Bedingungen, unter denen ein Team kreativ arbeiten kann. Drei Dinge sind dabei wichtig: das interdisziplinäre Team, der eigene, flexible Raum und eine sehr iterative Herangehensweise. Alle drei zusammen. Keines ist wichtiger als das andere. Die Gesamtheit zählt.
 

Was setzt das organisationsseitig voraus? Wie muss eine Organisation beschaffen sein, um mit Design Thinking sinnvoll arbeiten zu können? 

Die Kultur, die ich gerade beschrieben habe, muss natürlich entstehen oder entstehen können. Und auch gelebt werden. Allerdings muss auch die Bereitschaft für diese Arbeitsweise vorliegen. Menschen müssen bereit sein, neu zu denken, auszuprobieren und ausgetretene Pfade zu verlassen. Jemanden zu zwingen, anders zu arbeiten als bisher, ist sehr schwierig - und hat zudem nie richtig funktioniert.
Aus meiner Sicht ist es wichtig, die Mitarbeiter zu finden, die die gerade beschriebene Offenheit und Experimentierfreude mitbringen. Mit diesen Mitarbeitern sollte man anfangen, Design Thinking auszuprobieren. Wenn möglich mit konkreten und relevanten Fragestellungen. Idealerweise dienen dann solche Projekte als eine Art "Leuchtturm" und motivieren andere dazu, es auch einmal auszuprobieren.
 

Ihr Autorenkollege Jürgen Erbeldinger hat in dem annähernd zeitgleich erschienenen Buch Durch die Decke denken die These formuliert, Design Thinking habe das Zeug, das Management zu verändern, es fit für das 21. Jahrhundert zu machen. Unterschreiben Sie das? 

Ja und nein. Kritisch sehe ich, dass Design Thinking aktuell ein Hype-Thema ist: eine Methode, mit der man - scheinbar! - alles lösen kann.
Es gibt die Erwartungshaltung, man brauche nur mal eine Stunde oder einen Tag Design Thinking zu machen (was immer dann unter Design Thinking verstanden wird), und schon sei das Problem aus dem Weg. Dabei wird übersehen, dass auch Design Thinking zunächst erlernt werden will und dass es letztendlich Arbeit bleibt. Auch mit Design Thinking fällt nichts vom Himmel. Design Thinking ist keine Zauberei und kein Innovationsallheilmittel. Man muss aufpassen, dass das Thema nicht verbrannt wird.
Andererseits birgt die Methode in der Tat sehr viel Potenzial für positive Veränderungen: Zum Beispiel ist es für einen Manager eine Chance, wieder näher zu seinen Leuten zu kommen, an Zukunftsfragen zu arbeiten oder herauszufinden, welches die entscheidenden Probleme sind, die das Unternehmen lösen muss, um erfolgreich zu sein. Design Thinking kann somit auch für Problemstellungen im Management hilfreich sein, ist aber eben keine Zauberei und auch keine Allzweckwaffe. Sondern zuerst einmal "nur" eine Methode beziehungsweise ein Methodenbaukasten.
 

Worin liegt der spezielle Reiz für Sie? 

Dass man in einem Design-Thinking-Projekt Teamentwicklung und Organisationsentwicklung wunderbar mit der eigentlichen Entwicklungsarbeit kombinieren kann. Man arbeitet einerseits an einem konkreten (Software-)Produkt, investiert zugleich aber in die Weiterentwicklung von Team und Mitarbeitern. Also nicht eine Woche Teambuilding mit Zeltlager im Wald, und danach ist alles wie vorher. Sondern diese Entwicklungsaspekte in die eigentliche Arbeit zu integrieren, das finde ich persönlich sehr spannend.
In den Projekten, die wir im Design and Co-Innovation Center der SAP mit unseren Kunden machen, versuchen wir im Übrigen genau diese Aspekte zu kombinieren: einerseits die Arbeit an innovativen Produktideen, die wir gemeinsam mit unseren Kunden entwickeln, aber auch Unterstützung und Motivation auf dem Weg hin zu einer innovativeren Unternehmenskultur.
 

Wenn ich Ihre Xing-Meldung neulich richtig verstanden habe, spielen Sie in einer Jazz-Band? 

Ja, ich spiele Trompete. Kürzlich haben wir in Paris ein eher klassisches Big-Band-Programm auf einem Jazz-Festival präsentiert, zusammen mit einem Kirchenchor und einem Stepptänzer aber auch Duke Ellingtons "Sacred Concert" aufgeführt, in dem er Kirchenmusik ganz wunderbar mit swingendem Big-Band-Sound kombiniert hat. Ein echtes Erlebnis sowohl für die Musiker als auch für das Publikum.
 

Und sehen Sie einen Zusammenhang zwischen dem Spiel in einer Big Band und einem Team? 

Da gibt es aus meiner Sicht eindeutig Gemeinsamkeiten. Im Team habe ich Mitarbeiter mit unterschiedlichem Profil und in einer Big Band eben die verschiedenen Instrumentalisten. Jedes Instrument hat wie jeder Mitarbeiter seinen eigenen Charme, seine Stärken und Schwächen. In der Big Band gibt es beispielsweise die Trompeten, die meist über den anderen strahlen, aber auch die tiefen Posaunen, die den Sound-Teppich legen, oder die Saxofone, die die Melodie führen. Und es gibt den Bassisten und den Schlagzeuger, die zusammen für Groove und das Timing zuständig sind.
Der typische Big-Band-Sound gelingt nur im Zusammenspiel, genauso wie ein Team dann am besten funktioniert, wenn aus der Summe der Einzelnen ein Ganzes wird, in dem man sich ergänzt und unterstützt. Idealerweise hört man in einer Big Band sehr aufeinander; vor allem bei den improvisierten Solostellen: Vielleicht reagiert der Schlagzeuger auf etwas, was die Trompete spielt und umgekehrt. Es geht dann darum, einander zuzuhören, auf den Ideen der Mitmusiker aufzubauen. Diese weiterzuentwickeln, auch mal auszuprobieren und zu experimentieren. Da sind wir dann schon wieder beim Design Thinking gelandet.
 

Zum Thema: Tobias Hildenbrand, Jochen Gürtler, Martin Fassunge: "Scrum als Framework für die Produktinnovation", in: Hans-Peter Korn, Jean Pierre Berchez (Hrsg.): Agiles IT-Management in großen Unternehmen, Symposion Publishing, Düsseldorf 2013, S. 191-211