Wer gewinnt das Seifenkisten-Rennen?
Wenn nun also unsere Seifenkiste gut betankt ist, wie ich es in meinem Blogpost zu Motivations-Sprit beschrieben habe, kann die Sause losgehen, oder? Fast. Erst sollten wir noch sicherstellen, dass die Handbremse gelöst ist. Und wir sollten dafür sorgen, dass während der Fahrt keiner damit rumspielt, das würde uns nämlich nicht nur verlangsamen, sondern könnte uns auch im hohen Bogen aus dem Rennen werfen, blaue Flecke inbegriffen.
Was heißt das im Klartext? Wir müssen für psychologische Sicherheit im Team sorgen. Das bedeutet, dass alle im Team das Gefühl haben, sie könnten authentisch sein, also sich zeigen, wie sie sind, ohne dafür negative Konsequenzen zu erfahren. Mit all ihrer Interdisziplinarität und Diversity. Das gibt Raum für Ideen und Fragen, für gemeinsames Lernen und Explorieren. Die Teammitglieder fühlen sich angenommen und respektiert, und zwar so sehr, dass sie auch unangenehme Dinge adressieren können. Auf konstruktive Weise, natürlich. Das bedeutet, dass Fehler angesprochen und damit aufgearbeitet werden, Zweifel geäußert werden und so Risiken und deren Auswirkungen minimiert werden können
Ein solch sicheres Klima findet sich sowohl in einer gesunden Innovationskultur als auch in funktionierenden agilen Teams. Es fördert das Wohlbefinden der Menschen und steigert den Erfolg von Projekten, weil es Arbeit effektiver macht. Effektiver besonders in Umgebungen und Kulturen, die sich schwer damit tun, Unsicherheit auszuhalten. Allerdings können wir genau davon hier in Deutschland leider ein lautes Liedchen singen… Wir haben heute mehr denn je mit Anforderungsänderungen zu kämpfen, bzw. sollen sie sogar noch willkommen heißen – das ist für den prototypischen, auf Verlässlichkeit gepolten Arbeitnehmer echt eine Herausforderung. Wir sind also immer mehr auf gute Kollaboration angewiesen und auf Selbstreflexion, um uns zu verbessern. Und das nicht nur, weil es im agilen Manifest steht. Hier braucht’s demnach noch mehr psychologische Sicherheit, als anderswo. Und wir können uns nicht darauf verlassen, dass „das Management“ die schon herbeizaubern wird. Wir müssen sie selbst herstellen. Im Team.
Erst die Handbremse lösen, dann den Gang einlegen!
Widmen wir uns also dem Lösen der Handbremse. In ihrem Artikel zum Erfolg von furchtlosen Organisationen beschreibt Amy Edmondson drei Aufgaben von Leaders, die psychologische Sicherheit ermöglichen wollen. Aus meiner Sicht müssen aber eben nicht nur Führungskräfte, sondern auch Product Owner diese Aufgaben erfüllen, wenn sie zu einem erfolgreichen Produkt kommen wollen [1]. Manche Teile davon sicherlich im Tandem mit den Agile Mastern, aber den Großteil beeinflussen sie über die inhaltliche Arbeit am Produkt
Um die Handbremse zu lösen, sollten Product Owner also die richtigen Voraussetzungen schaffen („setting the stage“), Beteiligung ermöglichen („inviting participation“) und zielführend reagieren („responding productively“).
Richtige Voraussetzungen durch die Produktvision
Um die Voraussetzungen zu schaffen, müssen Product Owner konkret den Rahmen setzen, dass sich das Team in einem komplexen Umfeld bewegt und daher Unklarheiten begegnen wird, die nur gemeistert werden können, wenn sie explizit gemacht werden. Um dabei nicht die Orientierung zu verlieren, müssen alle das Warum kennen. Die Produktvision verdeutlicht also nicht das Ziel oder gar den Weg dahin, sondern wirklich das „why“ dahinter. Und lässt den Weg dahin offen – der muss sich ja erst durch die gemeinsame Arbeit des Teams herauskristallisieren. Hier wird also seitens der Product Owner auch offenbart, welches Menschenbild sie gegenüber dem Team haben: ernstzunehmende, mündige Partner, Experten für ihr Feld, die besser selbstgesteuert arbeiten oder doch eher das Bild der ausführenden Kraft, die noch Anleitung benötigt und detaillierte Vorgaben braucht?
Beteiligung wird letztendlich durch offene Kommunikation ermöglicht
Product Owner müssen klarstellen, dass sie nicht alle Antworten haben. Sonst gäbe es ja eine Liste an Aufgaben, die von einem Umsetzungsteam abgearbeitet werden könnte. Natürlich müssen Product Owner Fragen nach dem Warum beantworten können. Das geht nicht immer sofort, denn manchmal ist Rücksprache mit Kunden oder Stakeholdern nötig, aber prinzipiell sollte die Produktvision genau diese Fragen klären. Antworten zu dem Wie und dem Was hingegen muss das Team (das ja auch den/die Product OwnerIn miteinschließt) gemeinsam finden. Und diese Antworten ergeben sich häufig erst auf dem Weg – schließlich bewegt sich das Produkt in einem komplexen Umfeld. Dafür ist es wichtig, dass Product Owner nicht vorgeben, alles zu wissen. Wichtiger ist, dass sie gute Fragen stellen und aufmerksam zuhören. Das gilt sowohl in Richtung der Kunden und Stakeholder, aber auch in Richtung des restlichen Teams: Menschen möchten gehört werden. Nur wenn sie sich wertgeschätzt fühlen, werden sie sich einbringen.
Zielführend reagieren mit einem agilen Mindset
Es liegt auf der Hand, dass Schuldzuweisungen nicht helfen, wenn es mal nicht optimal läuft – und dass sie für schlechte Stimmung im Team sorgen, wissen wir alle. Und doch tappen wir häufig genug in die Falle, dass wir Fehler brandmarken und damit den Fokus von der Lösung zu sehr auf das Problem lenken. Dabei wussten wir doch von vorne herein, dass wir es mit Experimenten mit ungewissem Ausgang zu tun haben würden.
Was hilft, ist ein wertschätzender Umgang. Einander zuhören, den erbrachten Einsatz von Teammitgliedern würdigen, sich gegenseitig unterstützen, konstruktives Brainstorming bei Problemen… Und das fördert nicht nur die Qualität der Ergebnisse und die Erfahrungskurve im Team, sondern auch die Zufriedenheit der Teammitglieder. Mit einem agilen Mindset, das auf Wachstum und Lernen setzt, werden Fehler auch schneller erkannt und vor allem benannt.
Psychologische Sicherheit ist notwendige Voraussetzung für agiles Arbeiten
Wenn man keine Fehler macht, kann man nicht die volle Bandbreite des innovativen Potenzials einer Situation explorieren, weil man immer versucht, sich auf der sicheren Seite zu bewegen. Selbst in einfachen Kontexten kann es auf Dauer gefährlich sein, zu sehr auf das Vermeiden von Risiken zu fokussieren, weil man dann blind für sich verändernde Rahmenbedingungen werden kann. Das kann im schlimmsten Fall zu bösen Überraschungen führen, wenn man dann unerwartet in komplexen Umfeldern landet, nur weil man die Zeichen der Zeit verschlafen hat. Und in solchen komplexen Kontexten sind wir auf emergent practices angewiesen, die sich daraus ergeben, dass wir ausprobieren, erkennen, reagieren[2]. Wir müssen agil sein. Daher sind reflexartige Fehlervermeidungsstrategien und Problemvertuschungsmanöver regelrecht gefährlich, egal wie schwer wir uns damit tun, Unsicherheit auszuhalten. Erstere engen den Lösungsraum künstlich ein, letztere führen zu falsch positiven Ergebnissen, an die dann Ressourcen verschwendet werden.
Es braucht eine Basis, bevor man bauen kann
Eine Produktvision oder Teamvision ist m.E. essentiell, um als Team zusammen nach vorne zu schauen – sonst entstehen im schlimmsten Falle Missverständnisse darüber, wo den „vorne“ überhaupt ist. Um aber eine solche Vision kann ein Team erst entwickeln, wenn es eine gemeinsame Vertrauensbasis hat. In Workshops erlebe ich immer wieder, dass Teams erst einmal grundsätzlich sicherstellen müssen, dass sie miteinander reden können, bevor sie über die Vision sprechen. Das heißt nicht, dass sie nicht schon vorher gut kommunizieren konnten. Aber es hilft, sich darauf zu besinnen, dass Offenheit ein wichtiges Gut ist und dass man in einem interdisziplinären Team nicht nur unterschiedliche Experten, sondern auch verschiedene Menschen integrieren muss. Wenn ich als Moderatorin dann einmal einen psychologisch sicheren Rahmen im Workshop geschaffen habe, geht der Rest oft von ganz alleine. Und dafür muss auch ich dann eine klare Vision für den Workshop formulieren, offene Kommunikation vorleben und fördern und ein agiles Mindset praktizieren. Und dann: Auf die Plätze, fertig, los!
[1] Im Vergleich zu ihrem Buch „Teaming“ führt Edmondson in diesem Artikel ihren Ansatz zur Förderung von psychologischer Sicherheit noch weiter aus. Die ursprünglichen Faktoren habe ich in „Think BIC: Resilienz für das Handeln“ genauer beschrieben.
[2] Wie der Begründer des Cynefin Frameworks Dave Snowden es mit Mary Boone in seinem Artikel „A Leader’s Framework for Decision Making“ beschreibt.
Neueste Kommentare