Home Blog Agile Methoden und Technische Dokumentation: Stolpersteine und Chancen

Agile Methoden und Technische Dokumentation: Stolpersteine und Chancen

„Funktionierende Software über umfassende Dokumentation“, so postuliert es das agile Manifest, und oft scheint es mir der Teil des Manifests zu sein, den man am liebsten erfüllt. Dokumentation? „Lästig, das liest doch eh keiner!“

Doch während die Projekt- bzw. Codedoku, also die Protokollierung von Prozessschritten, Zwischenständen und der fortlaufenden Arbeit, wohl tatsächlich weniger wichtig sein sollte als die Entwicklung des Produkt selbst, gibt es doch noch eine andere Art der Dokumentation: Die Produktdoku. Damit sind Bedienungsanleitungen der fertigen Soft- oder Hardware gemeint, ohne die manches komplexe Produkt de facto nicht nutzbar ist. Gerade hochspezifische Produkte im B2B-Bereich, vor allem wenn sicherheits- oder regresspflichtige Abläufe betroffen sind, kommen nicht ohne ein wie auch immer geartetes „Handbuch“ aus.  Bisweilen schreibt der Gesetzgeber, zumindest aber das Kundeninteresse dies sogar vor: Ohne Dokumentation kann das Werk dann nicht ausgeliefert werden. Die Dokumentation ist also Teil des fertigen, auszuliefernden Produktes und muss entsprechend behandelt werden.

Wie es ist.

So weit, so plausibel. Nur sieht die Praxis leider meist anders aus.

Bei meinem Workshop auf der tekom 2013, dem Fachkongress der technischen Dokumentation Anfang November in Wiesbaden, diskutierten wir die Erfahrungen und Möglichkeiten agiler Methoden für die technische Redaktion. Und während viele von agilen Methoden bisher erst aus der Ferne gehört hatten, sagten andere klar: „Für die Dokumentation ist Agil die Hölle!“

Oha. Das hört man ja nicht so gerne als agiler Coach. Und doch wurde schnell klar, wieso das eine durchaus verständliche Situationsbeschreibung ist: Weil die Dokumentation in der Praxis eben nicht als Teil der Produktentwicklung behandelt wird. Weil agile Ansätze in der IT eingeführt wurden, aber an deren Abteilungsgrenze auch wieder aufhören. Und weil die Redaktionen dann diejenigen sind, die ganz am Ende des Fahnenmastes hängen und verzweifelt nach irgendeinem verlässlichen Haltepunkt suchen, während man unten bei der IT gerade den Segen der Flexibilität entdeckt hat und sich freut, wie lustig man die Basis des Mastes hin und her schieben und im Kreise drehen kann.

Produktdokumentation – den Letzten beißen die Hunde

Während Wasserfall-Strukturen viele Nachteile hatten und haben, weil sie starr einem Plan folgen, auch wenn dessen Grundlagen nicht mehr aktuell sind, hat diese Vorgehensweise für die Dokumentation einen großen Vorteil: Man weiß schon ziemlich früh, was am Ende heraus kommen sollte, und entsprechend früh kann die Redaktion mit der Arbeit beginnen. In agilen Projekten dagegen weiß die Redaktion, wenn sie nicht eng in die Entwicklung eingebunden wird, nicht mehr auf was sie sich verlassen kann.  Als Lösung versucht sie dann entweder, on the fly mitzudokumentieren und generiert „Waste“, weil sich alles wieder ändert . Oder die Dokumentation wird erst ganz am Ende „noch schnell“ hintan geschoben, wenn die Entwicklung abgeschlossen und die Deadline eigentlich schon erreicht ist.

Bei klassischen Wasserfall-Projekten gehen, dem Plan sei dank, Entwicklungsprodukt und Doku also enger Hand in Hand bzw. laufen parallel und kämpfen so beide mit den gleichen Problemen. Die Kluft, oder oft genug die Mauer, steht dabei jedoch zwischen Produkt und Kunden. In agilen Projekten dagegen rücken Entwicklungsprodukt und Kundeninteresse enger zusammen. Wer aber vergisst, auch die übrigen, für das Endprodukt relevanten Akteure mit in den Prozess einzubeziehen, verlagert das Missverständnis oder das Unwissen an eine andere Stelle. In unserem Fall: Zwischen Entwicklung und Dokumentation.

Wasserfall--Prozesse: Die Mauer zwischen Kunde und Produktentwicklung.

Wasserfall–Prozesse: Die Mauer zwischen Kunde und Produktentwicklung.

Agile Produktentwicklung ohne Mitnahme aller Abteilungen: Die Kluft zur technischen Redaktion

Isolierte agile Produktentwicklung: Die Kluft zur technischen Redaktion

Wie es sein sollte.

Dies scheint, nach allen Gesprächen und Beobachtungen, leider ein weit verbreitetes Muster zu sein. Mitnichten aber ist das eine zwangsläufige Entwicklung!

Wer von Agilität profitieren will, muss sie ernst und für voll nehmen. Und das heißt: „Ein bisschen Agil“ kann es nicht geben. Auch in agilen Prozessen müssen alle am Endprodukt beteiligten Akteure bedacht werden. Genauso wie das User-Interface-Design und das Testen integriert werden müssen, muss dies auch mit der (notwendigen) Dokumentation passieren!

Im Idealfall heißt das: Technische Redaktion im Team. Gemäß der Idee, dass ein cross-funktionales Team alle Fähigkeiten besitzt, um ein lauffähiges Produkt fertig zu stellen, müsste also auch die technische Dokumentation, sofern sie für das Produkt nötig ist, in das Team integriert werden.

Leider geht diese Forderung meist an der Realität vorbei: Wenn ein Redakteur auf 10 bis manchmal gar 100 Entwickler kommt, ist diese direkte Zuordnung zu den Teams nicht möglich. Eine Alternative wäre der Brückenschlag zwischen Testen und Dokumentation. Im Sinne eines T-förmigen (oder Pilz-förmigen) Expertentyps durchaus wünschenswert, aber man kann kaum erwarten dass jeder Tester auch ein guter Redakteur ist und anders herum, und schon gar nicht von heute auf morgen. Diese Rechnung geht also auch nicht auf.

Möglichkeiten zum Austausch suchen und nutzen

Wenn die Dokumentation also nicht in die Teams selbst aufgenommen wird, so können und müssen auch team-externe Redakteure früher in den Entwicklungsprozess eingebunden werden. Scrum bietet mit den Reviews und den Backlog Refinements perfekte Plattformen, sich frühzeitig über das entstehende Produkt zu informieren – und auch Feedback zu geben. An diesem Einbezug sollten nicht nur die Redakteure, sondern auch Entwickler, Tester und vor allem Product Owner ein großes Interesse haben. Sieht man den Product Owner als Übersetzer der Kundenwünsche in Richtung der Entwicklung, ist der Redakteur derjenige, der das Produkt am Ende wieder zurück „übersetzt“. Beide, PO und Redakteur, sind damit wichtige Schnittstellen und Impulsgeber für das Kundeninteresse. Ob etwa Anordnung und Aufbau eines Produktes einer erklär- und verstehbaren Logik folgen oder auch nur alle Bezeichnungen einheitlich und stringent gewählt sind, haben insbesondere Redakteure in der Regel gut im Blick.

Die technische Redaktion kann, gerade in agilen Prozessen, weit mehr sein als ein „notwendiges Übel“ oder “teurer Rattenschwanz“, als das oder der sie bisweilen gesehen wird: Wer die Aufgabe und Fähigkeit hat, komplexe Sachverhalte so zu beschreiben, dass man sie versteht, kann auch dabei helfen, es von Anfang an so zu gestalten, dass dieses Verständnis noch leichter fällt.

Zudem führt eine in die Entwicklung integrierte Redaktion nicht nur dazu, im Unternehmen selbst ein Bewusstsein zu schaffen, was das Gesamtprodukt eigentlich ausmacht – nämlich Entwicklungsergebnis plus Dokumentation – , sondern auch den Kunden ein besseres, weil harmonischeres Gesamtprodukt zu liefern.

Gemeinsam Schritt für Schritt zum fertigen Gesamtprodukt

Zu guter Letzt können die Ansprüche der technischen Redaktion im Entwicklungsprozess sogar helfen, die Arbeit effizienter und agile Prinzipien konsequenter zu verfolgen: Weil nur fertige Features oder Teile dokumentiert werden können, provoziert eine ernst genommene, integrierte technische Redaktion innerhalb der Entwicklung automatisch, Dinge abzuschließen.

Es ist fast überall eine beliebte Unart, zehn Sachen gleichzeitig anzufangen, mit keinem fertig zu werden und zwischendrin beim hin und her Springen immer wieder den Faden zu verlieren. Genau dies aber hindert die Dokumentation an der Arbeit. Sie wird das Problem sichtbar machen und darauf pochen, dass Teile fertig gestellt werden. Oder um es mit einem unserer Aufkleber zu sagen: „Changing the world one story at a time“.

Der Beitrag zur agilen Mission

Wer also agile Prinzipien konsequent umsetzen und deren Vorteile wirklich nutzen will, sollte sich klar machen, dass dies eine Sache für das gesamte Unternehmen, für alle Abteilungen ist. Nicht für alle Abteilungen ist Scrum ein passendes Framework, darum geht es nicht. Die zugrunde liegenden Ideen von iterativem Arbeiten, kontinuierlicher Verbesserung und einer Transparenz aber können und sollen für alle gelten. Denn wenn agil für alle gilt, können auch alle den agilen Prozess unterstützen, dessen Stolpersteine einebnen und das gemeinsame Wachsen ermöglichen.

Wer dagegen das Schweigen, das in klassischen Strukturen oft zwischen Produktentwicklung und Kunden herrschte, nur in das Unternehmen hinein verlagert, und einzelne Abteilungen wie häufig die technische Dokumentation nicht in den Entwicklungsprozess einbezieht, verlagert auch nur den Schmerz und die Nachteile, anstatt diese zu bekämpfen. Das einfachste Heilmittel dagegen heißt ‚Transparenz’: Offen legen, wer nach welchen Spielregeln an welchen Themen arbeitet und mit welchem Ergebnissen.

Womit wir dann bei meinem liebsten Prinzip aus dem agilen Manifest wären: „Individuen und Interaktionen mehr als Prozesse und Werkzeuge.“ In diesem Sinne: Redet miteinander! Ja, genau: Auch und gerade mit euren technischen Redakteuren!


Newsletter_abo

Sie wollen regelmäßige Updates über neue Blog-Artikel?
Jetzt unseren Newsletter abonnieren!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

© by leanovate GmbH - Impressum