In der Software-Entwicklung arbeiten Menschen sehr intensiv zusammen. Über kurz oder lang entstehen in jedem Team Konflikte. Provozierte Konflikte sollten allerdings die Ausnahme sein. Provokation ist sehr häufig negativ belegt, man spricht von bewusstem oder unbewusstem Fehlverhalten und sozialer Inkompetenz. „provokare“ heißt „hervorrufen“, d.h. Provokation macht aufmerksam. Eine Provokation ist dann erfolgreich, wenn der Provozierte zu einer Reaktion genötigt worden ist. In diesem Beitrag möchte ich zeigen, wie die Veröffentlichung von Wissen in einem Wiki als eine Art Provokation einen positiven Effekt auf die Qualität einer Produktdokumentation erzielen kann.

Nehmen wir an, es gibt eine Person in einer Projektorganisation, die ihr Wissen nur dann weitergibt, wenn sie explizit dazu aufgefordert wird. Nennen wir sie der Einfachheit halber Irene, die Friedfertige. Irene gilt im Team als introvertierte Person. Sie ist in Meetings in der Regel stiller Zuhörer. Im Daily sagt sie wenig, nur das Notwendige, ganz professionell. In Retrospektiven ist sie eine Herausforderung für den Scrum-Master. Es ist schwer, an ihr Feedback zu gelangen. Unter der ruhigen Oberfläche von Irene verbirgt sich ein Ausmaß an Ehrgeiz, Disziplin und Kreativität. Weil sie nicht die Führungsrolle in ihrem Team anstrebt, reibt sie sich nicht permanent im Tagesgeschäft agiler Entwicklung mit anderen Personen. Sie hat nicht den Anspruch, alles verbessern zu wollen, ist mit der Gesamtsituation im Team zufrieden.

Mahatma Gandhi gilt als introvertierter, zugleich aber erfolgreicher Führer. Auch Bill Gates schreibt man diese Eigenschaft zu. Vermutlich ist aber die Liste introvertierter Top-Manager eher kurz. Bei Introvertierten denkt man vorzugsweise an schüchterne, ängstliche, verschlossene Menschen. Vorurteile gibt es viele, die meisten davon negativ. Introvertierte Menschen spielen sich weniger in den Vordergrund. Ganz im Gegenteil. Patrick Hundt hat sich in seinem Blog die Mühe gemacht, ganze 92 Eigenschaften von Introvertierten in den Kategorien “positiv assoziiert, “neutral bewertet” und “negativ assoziiert”.

Weiterlesen auf introvertiert.org

Irene baute ungestört und über lange Zeit enormes Wissen auf. Aber es ist so schwierig, an ihr Wissen heranzukommen. Und das ist sehr schade. Irenes Wissen ist wertvoll. Ein Verlust, aus welchen Gründen auch immer, kann nur verhindert werden, indem wir Irene zur Weitergabe ihres Wissens entweder motivieren oder provozieren.

Motivation reicht bei Irene in der Regel nicht. Sie weiß, dass es wichtig ist, Wissen weiterzugeben, mit anderen zu teilen. Sie ist in vielen Situationen aber gehemmt, vor allem in größeren Gruppen oder wenn sie sich öffnen soll. In hitzigen Diskussionen zieht sie sich sofort zurück. Viele Gelegenheiten zum Austausch von Wissen verstreichen ungenutzt.

Mit Provokation können wir eine Reaktion erwirken. Konfrontieren wir Irene in einem Wiki mit dem Wissen anderer und geben ihr Zeit, die Informationen in Ruhe und in ihrem Tempo zu verarbeiten, dann wird sie aufgrund ihres eigenen Wissens Fehler in den Seiten finden oder Lücken in der Dokumentation identifizieren. Im Wiki gibt sie Feedback dazu. Ganz entspannt als Kommentar, aber trotzdem für alle anderen sichtbar.

Die notwendigen Voraussetzungen für so eine positiv wirkende Provokation sind schnell aufgezählt:

  1. Jeder kennt die Dokumentation und ihre Struktur.
  2. Die Dokumentation wird von allen verwendet.
  3. Die Dokumentation wird von allen verbessert.

Mit dem Einsatz von CARDS+ erfüllen wir die Voraussetzung für Punkt 1 der Liste. Die Bausteine und die fixe Seitenstruktur stellen zusammen mit den Möglichkeiten von Confluence sicher, dass jeder weiß, wo wichtige Informationen zu finden sind. Mit Verlinkung führen wir Leser durch die Dokumentation. Die Suchfunktion erlaubt flexible Recherchen. Die konsequente Nutzung von Stichworten (bzw. Schlagworten) in den Seiten macht Zusammenhänge mit einem Klick sichtbar.

Punkt 2 der Liste ist Teil der Kultur der Projektorganisation. Das Wiki ist ein akzeptiertes Werkzeug der Kommunikation im Team. Es dient in verteilten Teams vor allem, Missverständnisse zu vermeiden. Ganz wichtig ist, dass die Produktdokumentation als Wahrheit gilt. Sie beschreibt das Produkt, wie es tatsächlich realisiert wurde. Darum ist eine klare Abgrenzung zur Projektdokumentation so wichtig.

Mit Punkt 3 der Liste ist der Prozess für kontinuierliche Verbesserung gemeint. Bewährte Prinzipien und Praktiken von CARDS+ unterstützen diesen Prozess und führen zu einer korrekten, angemessenen und prüfbaren Dokumentation mit hoher Qualität.

Vollständigkeit ist keine Voraussetzung, die wollen wir neben Korrektheit durch das provozierte Feedback erreichen. Mit CARDS+ schaffen wir eine Produktdokumentation, die das Wissen der Entwickler sichtbar macht. Die Idee von “collective code ownership”, wie sie beispielsweise Martin Fowler in seinem Bliki beschreibt, lässt sich so ganz leicht auf eine Produktdokumentation erweitern. Jeder ist Autor und veröffentlicht sein Wissen im Wiki. Jeder ist Leser und profitiert vom Wissen Anderer. Die Qualität der Inhalte ist das Ergebnis der Gemeinschaft, getrieben durch Feedback. Und keinen Leser lässt es kalt, wenn in “seiner” Produktdokumentation ein offensichtlicher Fehler steckt.