Vertrauen und Kontrolle - Freunde oder Feinde?

Von Mathias Fuchs

 

Vor zwei Wochen hatte ich vor, einen Beitrag zum Thema "Vertrauen" zu verfassen. Vor allem aus zwei Gründen:

  1. "Vertrauen ist ein zentrales Element aller agilen Ansätze und damit auch der Agilen Validierung".
  2. Zum anderen ist "Vertrauen" einer der Begriffe, die derzeit im Kontext von Implementierungen agiler Methoden fast inflationär verwendet werden. (Ich bin mir sicher, Sie haben dutzende von Beiträgen gelesen wie: "Command & Control war gestern, vertrauensbasierte Zusammenarbeit ist die Zukunft".

Ich habe mich also hingesetzt und angefangen, meine Gedanken zu diesem Thema zu sortieren. Das Ergebnis hat mich verblüfft. Dieses Wort, das gerne schnell und leichtfertig verwendet wird - und da schliesse ich mich selber ausdrücklich nicht aus - hat eine unglaubliche Tiefe und Auswirkung auf ganz unterschiedliche Aspekte, sowohl im privaten als auch im beruflichen Leben. Es ist unmöglich, in einem kleinen Beitrag auch nur annähernd ausreichend darauf einzugehen. Als ich darüber nachdachte, stiess ich auf Fragen wie:

  • Was bedeutet der Begriff "Vertrauen" eigentlich für mich?
  • Wem vertraue ich und in welchem Maße, einerseits privat und andererseits beruflich (gibt es da Unterschiede?)?
  • Kann ich als Scrum Master Vertrauen in einem Team einfordern?
  • Wie erreiche ich, dass sich ein Team gegenseitig vertraut?
  • Wer geht wann in den Vertrauensvorschuss und welche Auswirkungen hat das?
  • Indem ich konsequent vertraue, mache ich mich angreifbar. Ist das allen bewusst und wie wird damit im Team umgegangen?
  • Ist Kontrolle der Tod des Vertrauens, oder der Anfang?

Uff! Viel zu viele verschiedene Themen. Ich habe mich entschlossen, über die beiden Begriffe Vertrauen und Kontrolle für mich selbst ein wenig mehr nachzudenken. Für mich persönlich, ohne Literaturrecherche, ohne wissenschaftliche Untermauerung.

Nehmen wir das Beispiel von Scrum: Im Scrum Guide kommt das Wort Vertrauen genau einmal vor. Und zwar im Abschnitt Scrum Values. Wir erinnern uns, die Werte, die Scrum propagiert, sind:

Commitment, Focus, Openness, Respect, and Courage, also Selbstverpflichtung, Fokussierung, Respekt und Mut

Im Scrum-Leitfaden heisst es:

"Die Mitglieder des Scrum-Teams lernen und erforschen die Werte, während sie mit den Scrum-Ereignissen und Artefakten arbeiten. Wenn diese Werte vom Scrum Team und den Menschen, mit denen sie arbeiten, verkörpert werden, werden die empirischen Scrum-Säulen Transparenz, Kontrolle und Anpassung lebendig und schaffen Vertrauen."

That's it. Klingt gut. Aber wie sieht die Realität aus? Vor allem, wenn die Sprint-Ziele nicht erreicht werden oder die Schätzungen in der Sprint-Planung mal wieder sehr optimistisch waren und nur ein Teil der Stories fertiggestellt wurde? - Das soll ja in Zeiten von Scrum-Teams, die meist remote arbeiten, vorkommen 🙂

Dann ertappe ich mich immer wieder dabei, wie die Saat des Misstrauens zu spriessen beginnt: Hat wirklich jeder sein Bestes gegeben? Was der PO denkt, der den Produktwert maximieren soll, kann man nur vermuten. Jetzt wird es kritisch, denn sobald dieser Keim zu spriessen beginnt, ist es mit dem Vertrauen eigentlich längst vorbei. Und dieser Keim ist ziemlich resistent. Er keimt noch nach Jahren und wächst recht schnell.

Für mich hat das Ganze auch etwas mit der gegenseitigen Erwartungshaltung zu tun: Wenn ich mir nicht sicher bin, dass ein Teammitglied sein Bestes gibt, kommt schnell die Frage auf: Was macht er/sie eigentlich den ganzen Tag? Ich hätte das viel schneller machen können. Und genau das ist für mich die falsche Frage. Es geht vielmehr darum, dass ein bestimmtes Team mit bestimmten Fähigkeiten und Erfahrungen die optimale Liefergeschwindigkeit (Velocity) für dieses Team findet. Und diese im Idealfall im Laufe der Zeit durch Prozessoptimierung zu erhöhen. Und nicht zu vergessen: Die Geschwindigkeit ist die Geschwindigkeit, die sie langfristig halten können, unabhängig von irgendwelchen anfänglich festgelegten Projektmeilensteinen, die in einem sehr frühen Stadium des empirischen Entwicklungsprozesses definiert wurden und typischerweise nie angepasst werden 🙂 .

Zurück zum Vertrauen: Wirkliches Vertrauen kann meiner Meinung nach nur durch die Einführung von Kontrollmechanismen erreicht werden. Aber nicht nur durch von aussen auferlegte Kontrollen (Sprint Burndowns, Dailys, Sprint Reviews), sondern vor allem durch die Einführung von Kontrollen, die von innen kommen, aus dem Team selbst. Stellen Sie die Frage im Daily: Waren Sie alle zufrieden mit dem, was Sie gestern getan haben? Wenn dann (hoffentlich) die Aussage kommt: "Nein, gestern hatte ich keine gute Laune und habe herumgepfuscht. Ich bin nicht zufrieden", dann sind Sie meiner Meinung nach schon einen guten Schritt weiter in Richtung nachhaltig vertrauensvoller Teamzusammenarbeit.

Kontrolle, oder besser Selbstkontrolle, ist also nicht der Feind des Vertrauens, sondern eine Grundvoraussetzung dafür, dass Vertrauen auf Dauer bestehen kann.

Das gilt in vielen Bereichen, aber besonders dann, wenn viele verschiedene Kompetenzen zusammenarbeiten, wie z.B. bei der Agilen Validierung, bei der Business, IT und QA gemeinsam an einem validierten Produkt arbeiten.

Was denken Sie darüber? Ich bin neugierig.

Wenn Sie mehr über unseren Ansatz der Agilen Validierung wissen wollen, kontaktieren Sie uns gerne kontaktieren: