workshop auf der uig Tagung "UX and beyond: Digitalisierung menschzentriert gestalten"
Die KomMunikationskultur als Schlüssel zum Digital Experience Design
Sieben Thesen zur Praxis der digitalen Produktentwicklung
Usability und User Experience Design sind heute als Expertengebiet an der Seite des Software Engineerings fest etabliert. Es hat sich herumgesprochen, dass es nicht nur technischer Expertise bedarf, um erfolgreiche Software zu entwickeln, sondern auch eines Zugangs zu den Gewohnheiten und Bedürfnissen der Nutzer. Treiber des Paradigmenwechsels ist die Digitalisierung, die als gestaltende Kraft in allen Lebensbereichen wirkt. Digitale Applikationen mit visuellen Interfaces sind heute allgegenwärtig, und neue technologische Durchbrüche heizen die Nachfrage nach smarter Software immer mehr an. Neu ist, dass die Nutzer bereits als digitale Subjekte sozialisiert sind. In der Folge verlangen sie, im Unterschied zu früher, mehr als nur "gebrauchstaugliche" Software; sie erwarten smarte und attraktive Applikationen, die zu den Ansprüchen ihres digitalen Lebensstils passen. In diesem Kontext sprechen wir heute über eine "menschenzentrierte" Gestaltung von Software für alle Lebenslagen. Dass dies derzeit eine große Konjunktur hat, ist kein Zufall, denn: Strategen, Designer und Software Developer gestalten nicht nur die nächste Generation technischer Artefakte, sondern den Raum einer ganzen digitalen Gesellschaft.
In der Praxis erleben wir einen großen Boom in der Entwicklung von digitalen Produkten und Services. Es werden Strategien entwickelt und Investitionen geplant, und parallel dazu schreitet die Professionalisierung der digitalen Produktentwicklung voran. Agiles Arbeiten in interdisziplinären Teams ist das Gebot der Stunde. Dabei bleibt der Prozess jedoch oft hinter seinen Ansprüchen zurück: Die Protagonisten bekennen sich zu neuen Methoden und Arbeitsweisen, setzen diese aber nicht konsequent genug um. In der Praxis kann man häufig beobachten, dass unter der Oberfläche neuer Methoden die alten Muster in der Zusammenarbeit weiterleben. Es gibt einen blinden Fleck, der mit der Qualität der Kommunikation in der Produktentwicklung zu tun hat. Zugespitzt könnte man sagen: Ein Methodentraining und eine Zertifizierung reichen nicht aus, um in den Modus der agilen und interdisziplinären Kooperation zu kommen. Menschenzentrierte Gestaltung braucht Empathie im Prozess, und dies nicht nur gegenüber den Endnutzern des späteren Produkts, sondern gegenüber allen Beteiligten im Projekt. Dies muss geübt und gelernt werden. Dieser Geist fehlt heute noch in vielen Projekten, die sich der Entwicklung innovativer Produkte verschrieben haben. So können sich die Potentiale des Digital Experience Design nicht voll entfalten.
Um das Neue fruchtbar zu machen, braucht es mehr Aufmerksamkeit für den Prozess. Agile Arbeitsweisen in der Softwareentwicklung versprechen mehr als eine effizientere Abwicklung unter neuen methodischen Vorzeichen. Sie etablieren ein neues Kräfteverhältnis und Beziehungsnetz zwischen allen Beteiligten: Zwischen den Nutzern, Kreativen und Programmiern, bis hin zu den Entscheidern im Projekt. Ein verbundenes Zusammenwirken und gemeinsame getragene Verantwortung versprechen eine neue Qualität der Lösungen. Der Schlüssel dazu ist ein neues Verständnis der Kommunikation, die im System der Softwareentwicklung wirkt.
In diesem Feld bewegen sich unsere 7 Thesen zur Praxis der digitalen Produktentwicklung, die wir bei der Tagung "Usability in Germany" im November 2020 zur Diskussion gestellt haben. "Menschenzentrierte Gestaltung" spielt sich nicht nur auf Sachebene, sondern wesentlich auch auf der Beziehungsebene ab. Diesem Gedanken möchten wir gemeinsam nachgehen.
Idee des Workshops
Wir erforschen die Realität der Kommunikation im Prozess der digitalen Produktentwicklung. Wo stehen wir heute? Was bedarf es, um eine neue Kultur der Kommunikation zu schaffen?
Inhalt
1 | Sieben Thesen
2 | Break-out-Sessions
3 | Wrap-up
1 | Sieben Thesen
1
Good News. Nicht nur die digitalen
Produkte, sondern auch die Prozesse haben sich enorm weiterentwickelt.
Kein Zweifel: In den letzten Jahren hat sich in der Softwareentwicklung viel getan. Dabei sind es nicht nur digitalen Produkte, die smarter und leistungsfähiger geworden sind. Auch die dazugehörigen Prozesse haben sich stark verändert. Den komplexer gewordenen Anforderungen versucht man heute mit agilen Methoden und interdisziplinärer Teamarbeit zu begegnen. User Experience Design und Software Development arbeiten Hand in Hand.
Aber was genau hat sich verändert?
Im Zentrum von Projekten stand bei der klassischen Softwareentwicklung die Programmierung. Dies zeigte sich bereits in der Angebotslegung und der in ihr sichtbaren Logik von Lastenheft und Pflichtenheft: Das technische Produkt und sein Funktionieren standen im Fokus der Aufmerksamkeit. Die User Experience war demgegenüber keine zwingende Perspektive und tauchte in den Angeboten und der Planung eher am Rande auf. In der agilen Entwicklung hat sich die Gewichtung verschoben. Prototypen sind in den Mittelpunkt des Projektgeschehens gerückt, und an ihnen arbeiten sich UX Designer und Software Developer gleichermaßen ab. Die Nutzer, ihre Erfahrung und Schnittstelle zum technischen Produkt sind dabei von Anfang an gegenwärtig. Die Programmierung erscheint als notwendige, aber nicht mehr allein entscheidende Dimension, und umgekehrt wird sichtbar, wie relevant das kognitive, emotionale und soziale "Andocken" des Nutzers für den Erfolg des Produkts ist. Die Arbeit mit Prototypen macht für die Projektbeteiligten direkt spürbar, was es für das "Funktionieren" einer Software alles bedarf. Das funktional Mögliche und das für den Menschen Sinnhafte müssen eine gute "Passung" finden: Hier zeigt sich der Übergang von der reinen Technik- zur Menschenzentrierung in der Softwareentwicklung.
In der Praxis führt dies dazu, dass in einem Softwareprojekt heute alle Vertreter der technischen und der konzeptionellen Disziplinen von Anfang an gleichberechtigt “an einem Tisch” sitzen. Sie repräsentieren unterschiedliche Perspektiven auf das Produkt und haben den Auftrag, diese im interdisziplinären Austausch zu vermitteln. Schon im Kickoff-Workshop begegnet man einem selbstorganisierten Team von Beratern, Kreativen und Entwicklern. Vorbei die Zeiten, in denen Projektmanager die Hüter eines sequentiellen Prozesses waren und darüber bestimmten, welche Experten zu welchem Zeitpunkt involviert wurden und mit anderen Experten in Kontakt zu treten hatten. War der Projektmanager früher der “Flaschenhals” und hatte eine unangefochtene Hoheit über die Planung und Verteilung von Informationen, so ist der Prozess heute von größerer Offenheit geprägt. Mit dem Entwicklungsteam wird ein gemeinsamer Raum geschaffen, in dem jeder den gleichen Einblick in den Prozess hat. Die Erwartung ist nun, dass sich die Experten mit ihren heterogenen Kompetenzen aneinander abarbeiten und sich auf das gemeinsame Ziel hin organisieren.
2
Not so Good News. Unter der Oberfläche lebt das Alte weiter. Es kommt zum Rückfall in bekannte Muster.
Im Prozess ihrer digitalen Transformation entdecken immer mehr Unternehmen solche agile und interdisziplinären Arbeitsweisen. Eine neue Generation von Entscheidern treibt die neuen Entwicklungen aktiv voran. Aber das Neue ist kein Selbstläufer. Aller Aufbruchstimmung zum Trotz kommt es immer wieder vor, dass sich Organisationen zwar zu neuen Ansätzen und Methoden bekennen, sich dann aber schwer tun, den Anspruch in der Praxis einzulösen. Auf dem Weg der Umsetzung tauchen plötzlich unerwartete Probleme auf und Projekte bleiben stecken. Statt einer gezielten Problembehandlung kommt es dann, unter dem Druck der äußeren Rahmenbedingungen, zum reflexhaften Rückgriff auf alte Lösungen.
Ein typisches Muster ist, dass sich in agilen Projekten wieder Elemente des alten "Wasserfallprozesses” einschleichen. Dieser steht für ein sequentielles Vorgehen, einer strengen Planung in der Abfolge von Arbeitsschritten und ein hohes Maß an Arbeitsteiligkeit. In Summe suggeriert das Modell, dass sich Ordnung, Sicherheit und Kontrolle über den Prozess herstellen lassen. Kommt ein agiles Projekt nun nicht wie gewünscht voran oder stellen sich Zweifel ein, ob das "Minimum Viable Product" in einer vertretbaren Anzahl von Sprints tatsächlich erreicht werden kann, so kann dies den Wunsch nach einem schnellen "Durchgreifen" befeuern. Das aufwändige Miteinander von Nutzern, Kreativen und Entwicklern gerät in Misskredit. Man hört dann zum Beispiel: “Brauchen wir wirklich User Research? Wir wissen doch, was unsere Kunden brauchen und wie die Lösung aussehen soll.” Oder: “Sind diese ganzen Workshops wirklich notwendig? Können wir nicht einfach einen Experten briefen, der die Lösung entwickelt?” Unter dem Druck von Zeitplänen und Budgetlimitationen wird die neue Arbeitsweise über den Haufen geworfen und durch eine vermeintlich effizientere ersetzt. Zwar ist den Protagonisten meist bekannt, dass es auch viele Beispiele und Gründe für das Scheitern von Wasserfallprozessen gibt. Wenn die Unsicherheiten im agilen Arbeiten aber noch größer sind, so wird der Wasserfall zur Projektionsfläche für den Wunsch nach einem kontrollierten und damit "sicheren" Durchgreifen im Projekt. Damit betritt man wieder bekanntes Terrain und glaubt die eigene Handlungsfähigkeit zurückgewinnen zu können.
Auch in der Teamarbeit gibt es solche Rückfälle in alte Muster. Die neue, agile Zusammenarbeit steht für aktive Selbstorganisation, bei der die Teammitglieder flexible Absprachen treffen und zu gemeinsamen Entscheidungen über die beste Lösung kommen. In einem Team mit wenig Erfahrung und schwacher Gruppenreife kann es aber vorkommen, dass es einzelnen Mitgliedern schwer fällt, diesen Entscheidungen zu vertrauen. Möglicherweise breitet sich im ganzen Team und auch beim Product Owner Unsicherheit aus, was nun wirklich die "beste" Lösung sei. In einer solchen Situation wird schnell der Ruf nach dem Experten laut. Aus Angst vor der Annahme der gemeinsamen Verantwortung grenzen die Teammitglieder ihren Entscheidungsraum selbst ein ("Dazu kann ich nichts sagen"). Anstatt dem Team zu vertrauen, rufen sie nach den vermeintlich allwissenden Experten und schiebt diesen die Verantwortung für die Lösung zu. Die Gerufenen nehmen diese oft auch an, wenn sie selbst Zweifel an der Lösung hatten, aber vielleicht zögerten, diese im Team zu artikulieren. Im Wunsch nach Absicherung, aber auch nach einem schnelleren Fortkommen vollzieht sich so ein geordneter Rückzug in die "Expertensilos": Jeder macht, was er am besten kann, und man reduziert die gemeinsamen Schnittstellen. Dann zieht die gewohnte Arbeitsteiligkeit und Abgrenzung wieder in das Team ein, und die Idee der Interdisziplinarität wird geschwächt.
3
Digitale Produkte und Prozesse sind anspruchsvoller geworden. Mit steigender Komplexität wächst die Verantwortung des Einzelnen.
Allen Anlaufschwierigkeiten zum Trotz ist die Entwicklung neuer Arbeitsweisen alternativlos. Die anspruchsvoller gewordenen Problemstellungen lassen ein Verharren in den alten Mustern nicht mehr zu. Wenn nichttriviale Probleme auf der Tagesordnung. stehen, stoßen vorhandene Konzepte zur Problemlösung schnell an Grenzen. Wir müssen wir uns auf die entstandene Komplexität einlassen und in unseren Arbeitsweisen flexibler werden. Dies bedeutet auch, sich mit der höheren Intensität der Kommunikation zu arrangieren. Im agilen Arbeiten gibt es viel mehr Schnittellen und Abstimmungsbedarfe als zuvor. Gemeinsam eine Lösung für ein komplexes Problem zu entwickeln, ist ein kommunikativer Kraftakt. Oft haben Kreative oder Entwickler das Gefühl, nun die Hälfte der Zeit in Meetings zu verbringen anstatt zu gestalten oder zu programmieren. Dies erzeugt Widerstände und den Wunsch nach Rückzug. Sich einfach davon zu distanzieren, geht heute aber nicht mehr.
Die neu entstandene Kommunikationssituation erinnert an einen Kreisverkehr: Viele Kommunikationsteilnehmer treten in einen Prozess ein, der fortlaufend Iterationen und Inkremente produziert und dabei nie zum Stillstand kommt. War das sequentielle Arbeiten im Unterschied dazu eher ein geordnetes Nacheinander mit geplanten Übergaben zwischen den Experten, so muss nun jeder auf die Anderen achten und dabei die gesamte Situation im Auge behalten. Es entsteht ein anspruchsvoller Kommunikationsprozess, in dem es situativer Aufmerksamkeit und eines funktionierenden Zusammenspiels bedarf. Im Unterschied zu früher sind die Beteiligten dabei in der Breite des gesamten Produkts und in der Tiefe seiner User Stories involviert. Es entsteht ein System der Zusammenarbeit, in dem sich das Produkt aus den vielfältigen Interaktionen der Beteiligten formt: Innerhalb des Entwicklungsteams, aber auch durch Impulse und Interventionen von außen; im Kontakt mit Endnutzern im Markt und den Entscheidern in der eigenen Organisation.
Jeder Einzelne ist ein verantwortliches Mitglied des Systems und trägt mit seinem Handeln zum Systemerhalt bei. Für die Beteiligten im Entwicklungsteam ist dies Belastung und Chance zugleich. Statt nur eine eingegrenzte Aufgabe zu bearbeiten, müssen sie nun auch das "Big Picture" des Projekts im Auge behalten. Sie haben eine größere Perspektive und mehr Informationen, müssen aber auch Stellung beziehen und am Ende ein Ergebnis liefern. Agile Methoden wie Scrum helfen insofern, als sie einen engen Rahmen von Rollen und Routinen vorgeben und das Team davon entlasten, über das "Wie" im Prozess nachdenken zu müssen. Gleichzeitig will das Arbeiten in diesem Setup aber erst einmal gelernt sein. Gelingt es einem Team, in den neuen Rhythmus der Zusammenarbeit zu kommen, wird der Gewinn durch die größere Teilhabe am System schnell spürbar. Wer mehr Verantwortung hat, kann mehr gestalten. Und wer seinen Beitrag zum Gelingen des Ganzen spürt, ist in der Regel motivierter.
4
Die Nutzer bringen Input und Ideen, sind aber nicht allwissend. Im Prozess sind sie zugleich Partner und Störer.
Potentielle Nutzer bei der Entwicklung eines digitalen Produkts einzubeziehen, ist über die letzten Jahre immer mehr zum Standard geworden. In vielen Softwareprojekten ist es mittlerweile selbstverständlich, über den gesamten Prozess hinweg immer wieder die Interaktion mit Nutzern zu suchen. Diese werden dabei zu Partnern und entwickeln das Produkt durch ihre Rückmeldungen mit. Wenn von Nutzer"zentrierung" gesprochen wird, lädt dies allerdings zu Missverständnissen ein. Es sollte keineswegs darum gehen, die Nutzer zum "Maß aller Dinge" zu machen. Wer die Hoffnung hegt, man könne Nutzer einfach zu einem Problem befragen und diese würden dann die Lösung "verraten", wird mit hoher Wahrscheinlichkeit enttäuscht werden. Nutzer bringen zusätzliche Perspektiven in das System ein und ergänzen die Sicht der Experten, sind aber nicht allwissend. Sie haben eine Stimme in der Verhandlung um die bestmögliche Lösung, sind aber auch Ursache von Konflikten.
Von den Experten im Entwicklungsteam wird der Input von Nutzern immer wieder als "schwierig" erlebt. Dies passiert zum Beispiel, wenn die Nutzer unbequeme Perspektiven einbringen, die den Prozess verlangsamen oder neue Problemschleifen in Gang setzen. Es gibt Nutzer, die im Umgang mit Software geübt sind und klare Meinungen zu einer Lösung haben, aber auch solche, die mit ihrer Unsicherheit jede Lösung in Frage stellen. Alle Nutzer haben positive und negative Erfahrungen im Gepäck. In ihre Rückmeldungen fließen Emotionen ein, die von Euphorie über vorsichtige Bestätigung bis hin zu Ärger oder Aggression reichen können. Es kommt auch vor, dass Nutzer eine weit fortgeschrittene Lösung in Frage stellen. Aktive Nutzer sind nicht nur Partner und Helfer, sondern auch Störer im Prozess. Sie bringen Einschätzungen ein, sind aber keine willfährigen Erfüllungsgehilfen des Entwicklungsteams. Ihre Perspektiven können mehr oder weniger reflektiert sein, sind dabei immer subjektiv geprägt. Am Ende ist jeder Nutzer auch nur ein Mensch, in seinen Reaktionen nicht steuerbar und immer für eine Überraschung gut. Für das Entwicklungsteam ist entscheidend, den richtigen Umgang damit zu finden.
Jede Art von Rückmeldung liefert Informationen, die die Experten in Bezug auf das Problem und seine möglichen Lösung interpretieren müssen. Wer Nutzer befragt, muss mit den Antworten und Konsequenzen leben, auch wenn diese zu unerwünschten Komplikationen führen. Nutzerforschung ist kein "Wunschkonzert", bei dem das Entwicklungsteam Beifall für seine Arbeit erwarten darf. Die Experten sollten sich davor hüten, Nutzer mit eigenen Vorstellungen zu überfrachten. Hilfreich ist eine Haltung der Neugier und Offenheit gegenüber allen Perspektiven, die die Befragten anbieten. In der Nutzerforschung geht es darum, die Erfahrungswelt von Menschen zu erkunden, in die das digitale Produkt eingebettet sein wird. Was passiert an ihren Kontaktpunkten? Man arbeitet sich am Konkreten ab, forscht man nach Problemen und bildet Hypothesen, die zum Entwurf von Lösungen führen können. Dabei kann man manchmal Kausalzusammenhänge von Problemen und Lösungen entdecken, genauso oft wird man es aber mit Graustufen zu tun haben. Die forschenden Experten müssen versuchen, ein differenziertes Verständnis des Nutzungskontexts zu entwickeln; so können sie die Bedingungen für die bestmögliche Lösung verstehen lernen. Bei einer Software für Automechaniker geht es zum Beispiel nicht nur darum, die relevanten technischen Funktionen zur Verfügung zu stellen; sie muss auch auf die Interaktion in einer schmutzigen, lauten und hektischen Umgebung eingestellt sein. Um ein adäquates Verständnis der Nutzungssituation zu entwickeln, reicht es oft nicht aus, nur Fragen zum Interface zu stellen. Nutzerforscher müssen sich vielmehr mit allen Sinnen auf die Umgebung des Nutzers einlassen und dabei auch kreative Zugänge suchen, um die für die Konzeption relevanten Aspekte zu erfassen. Am Ende geht es darum, einen gemeinsamen Kommunikationsraum mit den Nutzern zu schaffen und dort jede Art von direkter und indirekter Information, jede Art von "Störung", aktiv zu suchen. Gelingende Kommunikation mit dem Nutzer bedeutet, die Differenz seiner Perspektiven für die Lösung fruchtbar zu machen.
5
Komplexe Probleme können nur im Team erfolgreich gelöst werden. Das Team ist mehr als die Summe seiner Teile.
Die Intensivierung der Kommunikation betrifft nicht nur Experten und Nutzer, sondern verändert auch die Beziehung der Experten untereinander. Bei der Entwicklung komplexer Produkte ist es wichtig, eine zu starke Arbeitsteiligkeit und Abgrenzung der Expertisen zu verhindern. User Experience Designer und Software Developer sollten von Anfang an auf Augenhöhe zusammenarbeiten, sich auf das Gebiet der jeweils Anderen einlassen und dabei über den eigenen Kompetenzbereich hinausdenken. Dies ist jedoch ungewohnt und leichter gesagt als getan. Wie fühlt sich zum Beispiel ein Interface Designer, wenn er im Planning die Implentierungsaufwände für eine Applikation schätzen soll? Was soll dabei herauskommen? Hier braucht es eine neue Haltung bei allen Beteiligten. Ziel ist nicht, dass alle "Experten für alles" werden. Vielmehr geht es darum, ein Problem oder eine Aufgabe aus unterschiedlichen Perspektiven zu betrachten und Erkenntnisse gleichsam "aufeinanderzulegen", im Sinne einer gemeinsamen Annäherung an die bestmögliche Antwort. Die Anforderungen, die an Experten gestellt werden, verändern sich dadurch signifikant. Sie müssen immer noch spezifisches Wissen und Erfahrungen einbringen, dies jedoch als Beitrag zu einem gemeinsamen Ergebnis. Nicht die einzelne Expertise ist der Schlüssel zur bestmöglichen Lösung, sondern das, was "zwischen" den verschiedenen Expertisen entsteht.
Bei der Interdisziplinarität geht es im Kern darum, diesen Bereich des Gemeinsamen zu suchen und zu erforschen. Dabei spielen die Sacheebene, aber auch die Beziehungsebene eine wichtige Rolle. In agilen Prozessen werden an verschiedenen Stellen Räume geschaffen, an denen sich Experten austauschen und als Team erleben können. Ein solcher Ort ist zum Beispiel die Retrospektive im Scrum-Projekten. Hier ist das Team aufgefordert, seine Zusammenarbeit mit dem Blick von außen zu betrachten. Gewinnbringend wird dieser Austausch dann, wenn es gelingt, über die reinen Sachfragen zu Strukturen und Prozessen hinauszukommen und ein echtes Interesse aneinander zu entwickeln. "Wie geht es meinem Teammitglied? Wie können wir uns gegenseitig helfen?" Für diese Art des Einlassens braucht es mehr als Sachkenntnis, es braucht ein Gespür für die Situation und Empathie gegenüber dem anderen Menschen. Ein tieferer Bezug zwischen den Beteiligten kann die Beziehungsqualität im ganzen Team spürbar verbessern. Die Mitglieder fühlen sich in "ihrem" Team dann aufgehoben und stark. Es gibt mehr Kreativität und Eigeninitiative. Plötzlich bringen Teammitglieder unaufgefordert eigene Ideen ein: "Wir haben schon mal ein Konzept gemacht”. Das Team als Ganzes entwickelt Ehrgeiz und beschleunigt aus sich selbst heraus, ohne Druck von außen. Was man aus dem Fußball als “Spielfreude” kennt, lässt sich auch auf das Feld der Softwareentwicklung übertragen. In einem verbundenen Team entsteht die Magie eines inspirierten Miteinanders. Es wird Energie freigesetzt, der Experimentiergeist nimmt zu - und am Ende auch der Erfolg.
Die höhere Effizienz eines eingespielten Teams ist nicht nur "gefühlte" Wahrheit, sondern kann auch gemessen werden. In Scrum-Prozessen wird das Tempo eines Entwicklungsteams bei der Bearbeitung von User Stories pro Sprint als "Velocity" beschrieben. Diese Art der Erfolgsmessung kann zwar die Qualität im Miteinander nicht abbilden, doch gibt sie Anhaltspunkte für die Entwicklung der Zusammenarbeit. Dabei sieht man auch: Es braucht Zeit, bis ein Team eingespielt ist. Das soziale Miteinander entsteht nicht "auf Knopfdruck"; die Menschen müssen ihre Art der Kommunikation untereinander erst finden. Jedes Team hat eine eigene "Seele", die sich in einem Prozess des gemeinsamen Machens, Beobachtens und Lernens entwickelt. Solche Reifungsprozesse lassen sich nicht beliebig beschleunigen, sondern haben ihr eigenes Tempo. Gemeinsame Fehler gehören genauso dazu wie eine kontinuierliche Teampflege, außerdem die Fähigkeit, mit Konflikten und Störungen im Teamsystem umzugehen. Damit sich dieser Lernprozess am Ende auch wirtschaftlich auszahlt, braucht es Projekte mit einer längeren Laufzeit; andernfalls stehen die Aufwände in keinem sinnvollen Verhältnis zum Ergebnis. Umgekehrt wird ein in der Kommunikation bereits eingespieltes Team bei Folgeprojekten schneller zu Ergebnissen kommen.
6
TEAMS VERMEIDEN DEN KONTAKT ZUR NÄCHSTEN HIERARCHIEEBENE. GEGENSEITIGES MISSTRAUEN BLOCKIERT DEN FORTSCHRITT DES GESAMTEN SYSTEMS.
Viele Entwicklungsteams haben eine problematische Schnittstelle nach außen: Das Verhältnis zur nächsten Hierarchieebene. Die Kommunikation zwischen “Oben” und “Unten” ist oft gestört, wird aber nur selten zum Thema gemacht.
Im Scrum-Setup wird die Führungsebene in der Regel durch einen Produktmanager repräsentiert, der die Gesamtverantwortung für das Produkt trägt, entlang des gesamten Lebenszyklus von der Planung bis zur Vermarktung. Mit ihm hat vor allem der Product Owner direkt zu tun und nicht das Entwicklungsteam. Dennoch kommt es immer wieder vor, dass das Management über den Product Owner hinweg in die Arbeit des Teams eingreift. Dabei werden zum Beispiel Entscheidungen zum Produkt in Frage gestellt oder Prioritäten umdefiniert. Solche Interventionen von außen haben das Potential, Unruhe und Unzufriedenheit im Team zu stiften, insbesondere dann, wenn sie überraschend kommen und nicht unmittelbar plausibel sind. Wenn das Management die entstehende Missstimmung dann, in Verkennung der Situation, auch noch als Symptom dafür deutet, dass es im Team "nicht rund läuft”, und zum Anlass für verstärkte Kontrollen nimmt, kann eine Abwärtsspirale in Gang gesetzt werden, die bis zur völligen Demotivation des Teams führt. Und zwar ohne dass dem Entscheider die Folgen seiner eigenen Intervention bewusst werden.
Dass Entscheider den Wunsch haben, in Kontakt zum Entwicklungsteam zu treten und dort auch eigene Positionen zu vertreten, ist sehr nachvollziehbar und nicht das Problem. Gerade in Unternehmen, in denen das agile Arbeiten noch nicht etabliert ist, steht das Management unter großem Erfolgsdruck. Die Entscheider müssen Investitionen in eine neue Methode rechtfertigen, ohne schon genau zu wissen, wie gut sich diese auszahlen wird. Dabei hatten sie vielleicht noch gar keine Chance, das Team kennenzulernen und Vertrauen in seine Leistungsfähigkeit zu entwickeln. Wenn der Druck und die Ungeduld im Management wachsen, kann dies zu Übersprungshandlungen führen. Entscheider glauben die beste Lösung oft schon zu kennen ("Es ist doch klar, auf was es ankommt!"), sie spüren Misstrauen (“Schaffen die das überhaupt?”) oder erliegen ihrem Wunsch nach schnellem Eingreifen ("Hier braucht es klare Ansagen"). Kritisch ist dies, wenn die Führungskraft nicht erkennt, dass sie mit dieser Intervention die Autonomie des Entwicklungsteams in Frage stellt und das Funktionieren des Systems empfindlich stört. Beim Team entsteht dann der Eindruck, in seiner Verantwortung nicht ernst genommen zu werden und nur eine "Scheinautonomie” zu haben. Auf solche Eingriffe bzw. Übergriffe reagieren Teams nicht nur mit Unzufriedenheit, sondern sie tendieren in der Folge auch dazu, den Kontakt zum Entscheider zu vermeiden. Weil man erneute Interventionen befürchtet, geht man auf Distanz oder greift zu zu subtilen Manipulationen ("Lasst uns das lieber nicht ansprechen"), um störenden Eingriffen vorzubeugen. Gleichzeitig wird das eigene Handeln durch ein entsprechendes Narrativ plausibilisiert ("Die haben doch eh keine Ahnung von der Lösung”). Solche Reaktionen sind ein Symptom dafür, dass es in der Kommunikaton an gegenseitigem Vertrauen fehlt. Man weiß nicht, was man von der anderen Seite halten soll oder fühlt sich von ihr latent bedroht. Eine solche Störung in der Beziehung zum Management kann die oben beschriebenen Produktivitätsgewinne eingespielter Teams schnell wieder zunichte machen.
Wie lässt sich eine derart verfahrene Situation wieder auflösen? Zunächst geht es darum, eine von Übergriff und Vermeidung geprägte Kommunikation als solche zu erkennen und zu thematisieren. Ob eine offene Aussprache zwischen den Beteiligten möglich ist oder es Hilfe von außen braucht, ist von der Kommunikationssituation im Unternehmen abhängig. In jedem Fall geht es darum, eine neue Art von Kontakt herzustellen. Dazu braucht es einen sicheren Raum und geregelte Kommunikationsbedingungen, die es beiden Seiten erlauben, ein Verständnis für die jeweils andere Perspektive zu gewinnen und Vertrauen aufzubauen. Wichtig ist auch die Kontinuität des Kontakts. Um eine neue Qualität in der Beziehung herzustellen, braucht es Zeit und Geduld, und dies gilt in besonderem Maße für Beziehungen über Hierarchiegrenzen hinweg. Die Vision ist, auch in dieser Konstellation zu einem offenen und respektvollen Miteinander zu finden. Das bedeutet, dass alle ihr Spielfeld, aber auch die Grenzen eigener Gestaltungsmacht kennen und bereit sind, "Grenzkonflikte" offen zu thematisieren. Wenn es gelingt, auf diesem Wege zu gegenseitiger Wertschätzung zu finden, so wird dies den Systemerhalt im Ganzen stärken.
7
OFFENE KOMMUNIKATION PRÄGT DIE KULTUR UND FÖRDERT INNOVATION. DAS KANN JEDER SCHAFFEN.
Halten wir noch einmal kurz inne. Wir haben nach der Kommunikationsrealität bei der digitalen Produktentwicklung gefragt und die Schnittstellen zwischen Nutzern, Experten und Führungskräften betrachtet. Dabei hat sich gezeigt, dass wir es mit einem komplexen Kommunikationssystem zu tun haben und die Grenzen zwischen seinen Teilsystemen oft problematisch sind. Gelingende Kommunikation ist in diesem Setup ein anspruchsvolles und in der Tendenz "unwahrscheinliches" Unterfangen. Gleichzeitig erleben wir aber auch, dass sich solche Kommunikationssysteme erfolgreich etablieren und erhalten. Der Schlüssel dazu ist eine aktive Gestaltung der Kommunikation mit allen Beteiligten. Wenn man eine vertrauensvolle, produktive und lernbereite Kommunikationskultur entwickeln möchte, so braucht es Spielräume für die Selbstorganisation. Es braucht ein verlässliches Miteinander auf Basis gemeinsamer Regeln und Werte, die in Ritualen immer wieder neu erzeugt und gefestigt werden. Hinter den "Buzzwords" der Agilität und Interdisziplinarität steht eine Kommunikation, die die Individuen und ihre Autonomie respektiert, sie aber im Kollektiv verbinden möchte. Sie herzustellen braucht nicht nur Entscheidungen, sondern Zeit und Übung.
Die lernende Organisation mit einer offenen Kommunikationskultur erscheint für viele Unternehmen als etwas "Großes" und unter Umständen kaum Erreichbares. Dies kann abschreckend wirken. Da hilft es zu sehen, dass auch kleine Schritte etwas Neues in Gang setzen und zu einer Verbesserung der Kommunikation führen können. Wenn man zum Beispiel neue Räume mit einer inspirierenden und kreativen“Werkstattatmosphäre” schafft, so hilft dies dem Team in einen anderen Arbeitsmodus hineinzufinden. Man braucht auch nicht gleich immer eine ganze Methode neu aufzusetzen, sondern kann auch einzelne Elemente (z.B. Reviews) herauslösen und damit anfangen zu arbeiten. Wenn man es mit ungewohnten Dingen zun tun hat (z.B. das Thematisieren der Beziehungsebene im Team) ist es hilfreich, sich spielerisch anzunähern. Bei der Interaktion zwischen Team und Management helfen informelle Gesprächsanlässe, um den Austausch überhaupt in Gang zu bringen und den "Muskel" des Dialogs nach und nach zu trainieren.
Die kleinen Schritte können am Ende auch zu größeren Veränderungen führen, zum Beispiel der Einrichtung eigener Abteilungen für das agile Arbeiten an digitalen Produkten. Besonders erfolgversprechend ist dies, wenn es gelingt, diese Bereiche ohne Einbindung in die Linienorganisation zu etablieren. Als "internes Startup" und eigene Organisationseinheit kann ein Team leichter Erfahrungen sammeln und Fehler machen. Wenn die neuen Strukturen und Prozesse sicherer geworden sind, lässt sich das Modell ggf. auf die gesamte Organisation übertragen. Je konsequenter man sich darauf einlässt, sich von Vorhandenem zu lösen und eigene Rahmenbedingungen für das Neue zu schaffen, je höher ist die Warscheinlichkeit, dass es auf lange Sicht funktioniert.
2 | BREAKOUT SESSIONS
DISKUSSION MIT ALLEN TEILNEHMERN IM WORKSHOP
Nach der Vorstellung der Thesen haben wir im Workshop um Feedback gebeten. In der anschließenden Diskussion kamen folgende Themen zur Sprache:
# Veränderung tut not
Es gibt ganz unterschiedliche Anlässe für Veränderung in den Arbeitsweisen, aber sie ist überall spürbar. In einem Fall mag es um Wachstum gehen, in einem anderen um Verschiebungen im Markt oder um eine Anpassung der Produkte oder des Geschäftsmodells. In jedem Fall ist es notwendig, eine höhere Flexibilität in der Organisation und ihren Arbeitsweisen zu ermöglichen. Um sich der Veränderung in den Umwelten zu stellen, braucht es mehr Beweglichkeit in den Methoden, Rollen und Prozessen.
# Keine neue Ideologien erzeugen
Mehr Flexibilität in der Zusammenarbeit heißt nicht, dass alle Unternehmen agil arbeiten müssen. Je mehr Rückenwind eine Methode erhält und je mehr Diskurs um sie entsteht, desto mehr läuft sie Gefahr, sich als neue Ideologie zu verfestigen. "Agil" hilft nicht überall; es gibt auch gegenläufige Trends zu hierarchischen Strukturen und linearen Prozessen. Wichtig ist, beim Vorgehen in Alternativen zu denken und zu sehen, dass es "immer auch anders geht".
# Sichtbarkeit der User Experience stärken
Immer mehr Unternehmen geben dem User Experience Design mehr Sichtbarkeit, indem sie eigene UX-Abteilungen oder Inseln für gemeinsames Arbeiten von Kreativen und Entwicklern schaffen. Diese erfahren Akzeptanz, aber auch Abwehr in den Organisationen. Es besteht die Gefahr, dass mit neuen Standards auch neue Silos geschaffen werden.
# Dem Druck standhalten
Ein weiteres Problem ist der Druck aus dem Business: Das Neue soll sich schnell auszahlen und Profit bringen. Interventionen und Ideen des Managements zielen darauf ab, Entwicklungen beschleunigen, bewirken dabei aber oft das Gegenteil. Das Neue muss wachsen, um zum Wachstum beitragen zu können.
# Den Glauben nicht verlieren
Erwartungen, Druck, Abwehr: Auf dem Weg zur Innovation gibt es viele Hindernisse zu meistern. Das Neue ist kein Selbstläufer. Es braucht Mut zum Experiment, einen langen Atem und Vertrauen in die eigene Lernfähigkeit. Dabei hilft die Energie, die aus dem Austausch mit Gleichgesinnten entsteht.
3 | WRAP-UP
Take-Away | Erfolgreiches Digital Experience Design braucht lebendige Kommunikation an allen Schnittstellen.
Das führt uns auf ungewohntes Terrain: Freud und Leid mit dem Nutzer, eine neue Tiefe in den Teambeziehungen und Kontakt über Hierarchiegrenzen hinweg. Das alles ist kein Selbstläufer, lohnt sich aber. Eine höhere Kommunikationsqualität in den Prozessen führt am Ende auch zu besseren Produkten.