Also musste schnell gehandelt werden, und es wurde sofort eine Taskforce aus Managern und externen Beratern gebildet, die sich des Themas annahmen. Sie erarbeiteten eine Qualitätsinitiative, deren erster Schritt in der Schulung der Mitarbeiter bestand. Jeder Softwareentwickler und jeder Tester musste an einem speziell entwickelten Training teilnehmen, in dem ihnen erklärt wurde, warum Qualität so wichtig für das Unternehmen ist. Parallel erarbeitete die Marketingabteilung eine interne Kampagne, so dass wenig später in jeder Kaffeeküche und in jedem Meetingraum Poster hingen, auf denen Sprüche wie „Do it right the first time!“ oder „Never compromise quality!“ zu lesen waren.

Verstehen

Diese kleine Geschichte demonstriert eines der größten Probleme, das wir in der Wissensarbeit haben: Ein Mangel an Verstehen! Wenn es darum geht, Probleme zu lösen, gibt es in der Praxis ein fürchterliches Durcheinander aus Symptomen eines Problems, tiefer liegenden Ursachen und möglichen Lösungen.

Trommeln sie einmal ein Team zusammen, um über ein Problem zu sprechen und bitten Sie jedes Teammitglied, einen Zettel zu schreiben zum Thema: „Was genau ist das Problem?“ Sie können sicher sein, dass auf einigen Zetteln „Wir brauchen mehr X“, oder „Wir müssen aufhören mit Y“ steht.

Dies sind mögliche Lösungen – und vielleicht sind sie sogar sinnvoll. Aber im ersten Schritt tun wir gut daran, das eigentliche Problem etwas genauer zu verstehen. Solange wir dies nicht tun, werden wir oft so enden wie die Taskforce in unserem Beispiel: Im Besten Fall bleibt das Problem bestehen, aber oft werden wir das Problem noch verschärfen.

Annahmen überprüfen

Sehen wir uns das Szenario noch einmal etwas genauer an: Ausgangspunkt der ganzen Initiative waren zwei Beobachtungen: 1) Es wurden mehr Fehler gemessen als vorher, und 2) Die Kundenzufriedenheit sank. Was die Taskforce nun getan hat, ist im Englischen unter dem Begriff „Jumping to conclusions“ bekannt. Dies ist vergleichbar mit einer Gruppe von Menschen, die in einem Ruderboot sitzen und merken, dass ihre Füße immer nasser werden. Nun schnappen sie sich Töpfe und Becher und fangen an, das Wasser aus dem Boot zu schöpfen. Das ist vielleicht sinnvoll, wenn Regen der Grund für die nassen Füße ist. Aber was, wenn das Boot ein Leck hat? Wäre es dann nicht besser, erst einmal das Leck zu finden und abzudichten?

Die Maßnahmen der Taskfoce implizieren mehrere Annahmen:

Annahme 1: Die Messungen belegen, dass es tatsächlich mehr Fehler gibt als vorher. Aber es kann ebenso gut sein, dass plötzlich mehr Fehler gemessen werden, weil sich das Messverfahren oder die Defintion von „Fehler“ geändert haben.

Annahme 2: Es gibt einen kausalen Zusammenhang zwischen mehr (gemessenen) Fehlern und sinkender Kundenzufriedenheit. Auch diese Annahme muss keinesfalls stimmen. Es könnte nämlich auch sein, dass die Kunden aus einem ganz anderen Grund unzufrieden sind, etwa weil sich das Interface der Software geändert hat und viele Funktionen jetzt nur noch umständlich zu erreichen sind; oder weil gerade der Kundenservice nach Asien ausgelagert wurde und die Kunden nun sehr lange warten müssen, bis ihre Fragen beantwortet werden.

Annahme 3: Die Entwickler und Tester liefern das Produkt in schlechter Qualität aus, weil ihnen die Qualität nicht wichtig ist bzw. weil sie nicht verstehen, warum die Qualität wichtig für das Unternehmen ist. Auch hier gibt es aber andere Möglichkeiten: Vielleicht gibt es keine gemeinsame Vorstellung, was Qualität in diesem Unternehmen überhaupt bedeutet. Oder vielleicht fehlte schlichtweg die Zeit, um für die nötige Qualität zu sorgen.

Das wirkliche Problem verstehen

Die Maßnahmen, die ergriffen wurden, sind durchaus sinnvoll - wenn alle drei Annahmen (und einige weitere) zutreffen. Wenn man jedoch direkt mit der Umsetzung der Maßnahmen beginnt, ohne vorher die Annahmen zu evaluieren, dann gleicht die Initiative einer Lotterie. Deshalb ist es so wichtig, dass wir uns die nötige Zeit nehmen und mit geeigneten Modellen (z. B. A3 Thinking oder die 5 Phasen einer agilen Retrospektive) arbeiten, um erst einmal zu verstehen, was wirklich das Problem ist. Und meiner Erfahrung nach gilt: Das Problem ist nicht das Problem!

Gemeint ist, dass wir im ersten Moment fast immer etwas für das Problem halten, das sich bei genauerem Hinsehen als zweitrangig entpuppt. Um sich dem wirklichen Problem zu nähern, brauchen wir erst einmal unterschiedliche Hypothesen, was wirklich der Kern des Problems ist, auch wenn sie uns erst mal abwegig erscheinen (denn wir meinen ja schon zu wissen, was das Problem ist). Hierfür finde ich die „Rule of Three“ hilfreich, die von Jerry Weinberg stammt und sinngemäß lautet: „Wenn dir nicht mindestens drei unterschiedliche Gründe für etwas einfallen, dann hast du noch nicht genug nachgedacht.“

Das System verändern

Um die Geschichte vom Anfang zu Ende zu erzählen: Die Unzufriedenheit der Kunden lag tatsächlich in der steigenden Anzahl der Fehler begründet. Annahmen 1) und 2) stimmten also. Aber in ihrer Annahme 3) hatte sich die Taskforce fundamental geirrt! Den Entwicklern und Testern war vollkommen klar, wie wichtig Qualität ist. Ihnen war nicht nur bewusst, dass sie Software auslieferten, die ihren eigenen Qualitätsansprüchen nicht genügte, sondern dies war ihnen auch sichtbar unangenehm.

Warum taten sie es dennoch? Weil sie immer wieder unrealistische Deadlines für die nächsten Releases vorgegeben bekamen und der Scope unter keinen Umständen reduziert werden durfte. Damit die Deadlines auch wirklich gehalten wurden, wurden individuelle Prämien ausgesetzt. Die Entwickler und Tester taten das, was wohl jeder andere auch getan hätte: Sie opferten sehenden Auges die Qualität, um Scope und Deadline halten zu können (und ihre Prämie nicht zu gefährden). Dies war keine böse Absicht, Unwissenheit oder Faulheit, sondern eine systemische Notwendigkeit.

Der eigentliche Kern

Und was änderte sich jetzt mit der Qualitätsinitiative? Nur eine Sache: Die Teams gerieten unter noch mehr Zeitdruck, weil sie kostbare Zeit in (in diesem Fall nutzlosen) Qualitätsschulungen sitzen mussten. Um diese Zeit wieder aufzuholen, blieb ihnen kaum etwas anderes übrig, als die Qualität noch weiter herunterzuschrauben.

Hätte die Taskforce diese Zusammenhänge besser verstanden, dann wäre sie zum eigentlichen Kern des Problems vorgestoßen: Die Art des Projektmanagements und das Bonus-System. Diese zu ändern, ist zweifellos eine große Aufgabe. Aber nur, weil eine sinnvolle Aufgabe uns zu schwierig erscheint, sollten wir uns ja nicht mit einer leichteren, aber sinnlosen Aufgabe abgeben.