In meiner Ausbildung zum lösungsfokussierten Coach habe ich Denken in Lösungen gelernt. Es hilft! Es ist motivierend, sich vorzustellen, wie es sein wird, wenn das Ziel erreicht und das Problem Vergangenheit ist. Daran zu denken, was gut funktioniert und wie man mehr davon machen könnte, eröffnet neue Perspektiven und setzt emotionale Kraft frei.
Auf der anderen Seite kenne ich die Vorteile einer strukturierten Problemanalyse. Ich setze Techniken wie die Root Cause Analyse ein, mit denen ich den Problemen auf den Grund gehe. Wenn ich die tieferliegenden Ursachen kenne, kann ich Maßnahmen entwickeln, die das Übel an der Wurzel packen und nicht nur Symptome kurieren. Tabletten bekämpfen mein Kopfweh, aber genau das hindert mich daran, mir die Mühe zu machen, mit einem Kopfschmerzkalender die Ursachen für die Schmerzen herauszufinden.
Schauen wir uns ein anderes Beispiel an. Das Entwicklerteam hat wieder mal nicht alles geschafft, was es sich für den Sprint vorgenommen hat. Der problemorientierte ScrumMaster fragt in der Retrospektive: „Warum haben wir das Commitment nicht geschafft?“ Es kommen Antworten wie „Weil wir uns verschätzt haben“, „Weil der Product Owner mitten im Sprint mit neuen Anforderungen gekommen ist“, „Weil Peter eine Woche krank war“. Das beharrliche Weiterbohren des problemorientierten ScrumMasters fördert die Ursachen zu Tage: „Der Product Owner ist gewohnt, dass seine Wünsche sofort berücksichtigt werden, und möchte das weiter so haben“, „Das Commitment wird doch von niemandem ernst genommen und ist daher eigentlich überflüssig“, „Peter mag sein Wissen nicht teilen“.
Der lösungorientierte ScrumMaster fragt: „Stellt euch vor, wir sind im Review des nächsten Sprints und haben unser Commitment geschafft. Wie haben wir das hinbekommen?“ oder „Im vorletzten Sprint haben wir unser Commitment geschafft. Was war da anders?“ Das Team antwortet: „Wir haben einen Puffer in die Planung eingebaut“, „Wir haben Überstunden gemacht“, „Wir haben die neuen Wünsche des Product Owners ignoriert“.
In welchen der beiden Retrospektiven ist die Stimmung besser? Wahrscheinlich in der zweiten. Welche führt zu den besseren Lösungsansätzen? Wahrscheinlich die erste. Die Problemanalyse bringt uns vielleicht darauf, über den Sinn eines Commitments nachzudenken, anstatt zu überlegen, wie wir es erfüllen.
Komme ich mit Problemanalysen immer weiter? Nein – manche Probleme sind zu schwer zu durchschauen, zu komplex, ohne erkennbaren Zusammenhang zwischen Ursache und Wirkung. Oder die Ursachen entziehen sich meinem Einflussbereich. Ich werde die Haltung des Product Owners oder von Peter vielleicht nicht ändern können. Gerade in solchen Fällen hilft das Bauchgefühl, die Intuition, die das lösungsfokussierte Vorgehen auszeichnen. Sie erleichtern mir den Umgang mit dem Problem – auch wenn ich es gar nicht komplett verstanden habe. Lösungsfokus geht schneller, ist dafür aber weniger gründlich.
Wenn wir Problemanalyse einsetzen, müssen wir uns vor Schuldzuweisungen in Acht nehmen. Edward Deming, der „Erfinder“ des kontinuierlichen Verbesserungsprozesses, hat gesagt, dass 85 Prozent aller Fehler von einem mangelhaften System und nicht von den Mitarbeitern verursacht werden. Nicht Peter ist Schuld, wenn er sein Wissen nicht teilen will – das System honoriert Expertenteam mehr als Teamgeist. Nicht der Product Owner ist Schuld, dass er schnelle Reaktionen auf seine Anforderungen erwartet – seine Kunden erwarten auch schnelle Reaktionen von ihm, und die Auswirkungen solcher ad hoc Unterbrechungen auf das Team sind ihnen nicht ausreichend bewusst. Mit dem Team über Probleme zu diskutieren und ihnen auf den Grund zu gehen, kann Spaß machen – wenn das notwendige Vertrauensverhältnis dazu da ist, alle an einem Strang ziehen und Probleme als Chance für die gemeinsame Verbesserung behandelt werden.
Letztendlich hängt es an einzelnen Menschen, welche Vorgehensweise sie bevorzugen. Manche von uns sind her kopfgesteuert und analytisch, andere eher bauchgesteuert und emotional. Dementsprechend werden wir auch eine Vorliebe für eine der beiden Vorgehensweisen haben. Es ist hilfreich, beide im persönlichen Methodenkoffer zu haben, um sie je nach Situation anwenden zu können.
Probleme sind nicht das Problem – sie bringen uns dazu, uns weiterzuentwickeln. Langfristige und tiefgreifende Verhaltensänderungen sind dann nötig und möglich, wenn das bisherige Verhalten zu Problemen führt. Deswegen bin ich dafür, das Kind beim Namen zu nennen und nicht als „Herausforderung“ oder „Verbesserungspotenzial“ zu verklausulieren – und schon gar nicht unter den Teppich zu kehren. Also her mit den Problemen!
