Der Erfolg von agilen Projekten hängt unmittelbar mit der Art und Weise, wie in den Projekten kommuniziert wird, zusammen.
Viele Teams und Projekte identifizieren hier die größten Probleme, ohne sie präzise artikulieren zu können. Das größte Problem jedoch ist, dass jeder zu wissen glaubt, was Kommunikation ist und daher darüber nicht tiefer nachgedacht werden muss.
Diesem Missverständnis und der beeindruckenden Macht der Kommunikation ist dieser Artikel gewidmet.
Lasst das Abenteuer beginnen
Ja, wir haben es alle natürlich schon gehört: Scrum als Methodik setzt mehr auf direkte Kommunikation, denn auf lange Dokumentationen und Spezifikationen. Aber was genau ist eigentlich Kommunikation und wie wird sie im Scrum-Kontext richtig eingesetzt.
Der Ansatz klingt ziemlich trocken, aber es wird hier keine pseudo-akademische Diskussion, vielmehr ein Abenteuer, denn …
Wir wollen nichts weniger als „Inception“.
Leonardo Di Caprio in seiner coolen Rolle des gleichnamigen Hollywood Blockbusters ist heute unser Scrum-Coach. Das garantiert schon mal gute Unterhaltung.
Was erwarten wir von Scrum-Teams?
Doch nichts weniger, als unmittelbar und ohne große Spezifikation atemberaubende Software zu entwickeln.
Keine leichte Übung. Immer mehr Komplexität in immer kürzerer Zeit (time-to-market): Willkommen im 21. Jahrhundert.
Stellen wir uns kurz vor, Inception würde tatsächlich funktionieren. Ich bin Kunde, Product Owner oder Stakeholder, habe eine Produktvision im Kopf und treffe nun auf ein Entwicklerteam.
Wäre doch fantastisch, wenn ich meine Vision einfach in die Gehirne der Entwickler einpflanzen könnte und sie komplett meine Perspektive übernehmen könnten.
Zusammen mit ihren technischen Fähigkeiten wäre es wesentlich leichter das Produkt zu implementieren.
Das wollen wir auch!
Und wir können es haben.
Der Schlüssel dazu ist Kommunikation.
Aber nicht in dem Sinne, dass wir viel und direkt kommunizieren, oder besonders nett, respektvoll und wertschätzend miteinander umgehen. Das sollen wir auch, aber das genügt nicht. Wir müssen Kommunikation als ein viel weitergehendes Konzept fassen, damit wir wirklich etwas wie „Inception“ erreichen. Und das tun wir jetzt.
Inception im Einsatz
Ich frage in meinen Trainings regelmäßig die Leute, was Kommunikation ganz im Allgemeinen ist. In der Regel bekomme ich als Antwort „Kommunikation ist der Austausch von Informationen zwischen einem Sender und einem Empfänger“.
Die Antwort ist zweifellos richtig. Aber gleichzeitig greift sie für unseren Zweck bei Weitem zu kurz. Mit dem Sender/Empfänger Prinzip schaffen wir es einfach nicht zur „Inception“.
Oder anders ausgedrückt, die Definition ist zwar richtig, aber man hätte es unromantischer gar nicht ausdrücken können. Ja, sie haben richtig gelesen. Wir brauchen tatsächlich eine romantische Bestimmung des Begriffs, die uns aber sehr viel dichter an unser Ziel führt. Hier ist eine:
Kommunikation ist die wechselseitige Einladung in meine Wirklichkeit zu kommen.
Kunden oder Stakeholder leben in ihrer Wirklichkeit. Eine Wirklichkeit, die eher fachlich geprägt ist.
Entwickler wiederum leben ebenfalls in ihrer Wirklichkeit, die im Gegensatz zur fachlichen Wirklichkeit der Kunden und Stakeholder eher technischer Natur ist.
So prallen sie nun aufeinander und haben nicht viel Zeit (time-to-market) den Gegenstand der Entwicklung so zu beschreiben, dass die Beschreibung nicht zu einer sehr teuren Wette in die Zukunft wird, sondern hinreichend ist, um jede Art von Software zu entwickeln.
Eine Wette in die Zukunft wird eine Spezifikation nämlich dann, wenn ich darauf vertrauen muss, dass die Spezifikation gut war, ich das aber erst relativ spät am Gegenstand, quasi nach der Denkmalenthüllung überprüfen kann.
„Komm in meine Wirklichkeit“
Kommunikation in Scrum hat definitiv das Ziel, diese Barriere der unterschiedlichen Wirklichkeiten zwischen den Rollen so schnell wie möglich zu überwinden. Es ist ein viel mehr kulturelles Konzept, denn ein technisches.
Es geht nicht um das Viel und Direkt, sondern um das Wie. Wir brauchen eine Kultur, die den Perspektivwechsel zwischen Kunden oder Stakeholdern und Entwicklungsteam so schnell wie möglich in Gang bringt, damit beide wechselseitig die Wirklichkeit des anderen verstehen.
Das beschreibt die eigentliche Rolle des Product Owners.
Er übersetzt nicht nur Fachlichkeit in Funktionalität (was übrigens nicht das Gleiche ist), definiert nicht nur aus einem Geschäftsprozess ein Produkt, sondern vor allem fördert für beide Seiten diesen Perspektivwechsel.
Aber wie macht er das. Eigentlich schreibt er ja nur Storys.
Und genau das könnte reichen.
Die Frage ist nur, wie diese Storys geschrieben werden und warum sie genügen, um Inception zu iniziieren.
Dort habe ich beschrieben, dass eine gute Story aus vier Teilen bestehen sollte:
Die Motivation: beschreibt aus PO Perspektive warum er diese Story braucht
Die Description: beschreibt aus der User-Perspektive den Scope („als Anwender möchte ich das und das. Zu diesem Zweck steht mir das und das zur Verfügung. Wenn ich das und das mache, passiert das und das“ – so oder ähnlich)
Die Acceptance Criteria: beschreiben „Wann ist es gut?“ also unter welchen Umständen wird der PO die Implementierung der Story akzeptieren
Die Testfälle nehmen noch einmal einen Perspektivwechsel vor. Sie repräsentieren nicht wie viele meinen die Perspektive der Anwender, sondern die Perspektive der Anwendung selbst
Damit haben wir mindestens drei Perspektiven, also nahezu eine 360 Grad Sicht auf das zu implementierende Feature. Das hilft schon mal sehr.
Der Schlüssel zur Inception ist allerdings der erste und zweifellos wichtigste Teil:
Die Motivation
Denn der Prozess des Kennenlernens funktioniert immer über Motivationen. Wenn ich weiß, warum jemand so und so handelt, dann weiß ich auch was vermutlich als nächstes kommt.
Kinder wechseln im Alter zwischen 3 und 4 Jahren radikal ihre Kommunikationsstrategie. Bis dahin fragen sie immer nach den Bezeichnungen von Gegenständen.
Das reicht dann aber nicht mehr aus und sie beginnen mit ihren nervtötenden Warum-Fragen. Die ganze Autofahrt von Hamburg nach Frankfurt diese Warum-Fragen, endlos, scheinbar ziellos oder nur um uns arme Eltern zu nerven.
Aber in diesem Alter suchen sie ihren Platz in der Welt und versuchen die Zusammenhänge zwischen den Dingen, die sie nun bezeichnen können, herzustellen. Das geht nur über die Motivationen, also die Warum-Fragen. Das ist ihr Schlüssel zur Welt.
Und genau so verhält es sich auch im Verhältnis zwischen Stakeholder, Product Owner und Entwicklungs-Team.
Eine Kommunikation, welche die Motivationen aufdeckt, schafft diesen Perspektivwechsel, eine Kultur, die Transparenz auf allen Ebenen schafft, kann das. Das bloße Austauschen von Informationen vermag das nicht.
