Insbesondere in der Softwareentwicklung setzen sich agile Vorgehensmodelle wie Scrum immer mehr durch. Der Grundgedanke hinter dem agilen Ansatz – den Projektfokus immer auf den Anwendernutzen zu legen – ist für reine Entwicklerteams allerdings nicht immer leicht umzusetzen. Ein Scrum-Team mit Product Owner und Entwicklern hat einen ganz anderen Blick auf die eigene Software als deren Anwender. Man kennt deren Innenleben und tut sich mit diesem Zusatzwissen oft schwer, mit den Augen eines Außenstehenden darauf zu blicken.
In der agilen Theorie sollen Anwender zumindest regelmäßig punktuell in den Entwicklungsprozess einbezogen werden. In der Praxis wird das leider nicht immer ausgelebt und ist in dieser Form auch oft nicht praktisch umsetzbar.
Doch auch wenn Anwender direkt einbezogen werden: ihre Anwesenheit z.B. im Rahmen eines Sprint Reviews, also beim Überprüfen der Sprint-Ergebnisse, ermöglicht immer nur ein nachträgliches, korrigierendes Eingreifen am Ende eines Wochen dauernden Sprint-Zyklus. Der Gestaltungsprozess selbst bleibt auch in diesem Fall ohne aktive Mitwirkung der Anwenderseite.
Scrum: Vorgehensmodell v.a. zur agilen Softwareentwicklung, das auf iterative Zyklen (Sprints) mit Zwischenergebnissen statt auf vollumfängliche Planung setzt.
Sprint: Arbeitsabschnitt, in dem eine Anforderung umgesetzt wird.
Ein neuer Blickwinkel durch Technische Redakteure
An dieser Stelle kommen technische Redakteure ins Spiel, die die Anleitung für den Anwender in Form von Online-Hilfe, Handbuch oder Tutorial verfassen. Wie der Anwender betrachten sie die Software hauptsächlich von außen. Sie befassen sich intensiv mit allen Belangen der Bedienung, da sie diese ja umfassend erklären und beschreiben können müssen (andere Vertreter der Anwenderseite können Analysten oder UX-Experten sein, die weitere eigene Blickwinkel ins Projekt einbringen – in diesem Beitrag fokussieren wir uns auf die technische Redaktion).
Im Rahmen der notwendigen Recherche entstehen Rückfragen an die Entwickler vor allem dann, wenn sich ein Aspekt der Software nicht von selbst erschließt. Das mag im Einzelfall an der Komplexität des Programms liegen, kann aber genauso gut ein Indiz für den einen oder anderen Verbesserungsbedarf sein und sollte deshalb als Feedback wahrgenommen werden.
Im Gegensatz zu den prospektiven Endanwendern, die wenn überhaupt nur punktuell mit Zwischenständen der Software in Berührung kommen, können technische Redakteure in der Regel ins Scrum-Team und damit täglich in die Abstimmung eingebunden werden. Das ist in vielen Projekten nicht der Fall, kann aber einiges bewegen. Beispielsweise sieht die Definition of Done, die Liste der Fertigstellungskriterien, möglicherweise nur Ziele der eigentlichen Entwicklung vor. Da sie vom Entwickler-Team ausgeht, findet die Anwender-Dokumentation dort nicht immer einen angemessenen Platz – auch wenn der theoretisch vorgesehen ist. Im Ernstfall kann das dazu führt, dass die Doku am Ende unter erheblichem Zeitdruck entsteht und, bildlich gesprochen, an das fertiggestellte Produkt irgendwie drangeklebt wird.
Gehen wir also davon aus, dass die technische Redaktion von Beginn an in den agilen Entwicklungsprozess integriert würde. Welche Vorteile könnte das bedeuten?
Vorteile im agilen Entwicklungsprozess
Mehrwert für das Scrum-Team
Das Team erzielt bessere Ergebnisse durch die intensivere Einbindung der Anwendersicht im Entwicklungsprozess. Der Input seitens der Redaktion kann sofort mit in die Gestaltung der Software einfließen. Typische Beispiele für Fehler, die technischen RedakteurInnen sofort auffallen bzw. die mit deren Mitwirkung von vorneherein vermieden werden können, sind unter anderem:
- unverständliche Dialoge und Bedienabläufe,
- uneinheitliche oder missverständliche Terminologie der Oberflächentexte,
- nichtssagende, wenig hilfreiche Fehlermeldungen.
Für den Product Owner bedeutet die Anwesenheit von technischen RedakteurInnen im Team eine professionelle Unterstützung, um die Sicht der Anwender effizient ins Team und in das Produkt hineinzutragen und dabei Korrekturaufwände zu vermeiden und eine höhere Ergebnisqualität zu erreichen.
Mehrwert für die Technische Redaktion
Technische Redakteure und Redakteurinnen, die im agilen Prozess direkt eingebunden sind, können zeigen, dass sie aktiv zur Verbesserung der Entwicklungsergebnisse beitragen können. Das ist allemal besser als die ungeliebte, aber so allgegenwärtige Rolle als letztes Glied in der Kette die fertigen Ergebnisse anderer zu dokumentieren – ohne noch irgend etwas ändern zu können. Viel Energie wird dann oft aufgewendet, um die schlimmsten Ungereimtheiten durch umständliche Erklärungen doch noch irgendwie abzumildern. Unter Zeitdruck, mit dem Release in den Startlöchern, klappt das nicht immer gut. Es ist kein Hinterfragen mehr möglich, das Verständnis der Black Box ist schwierig, was wieder zu vielen Rückfragen führt und Frust bei allen Beteiligten zeitigt. Von dokumentationsrelevanten Last-Minute-Änderungen wollen wir an der Stelle gar nicht mehr anfangen.
Es wäre unrealistisch zu behaupten, die Integration ins Scrum-Team würde die Rolle als Flaschenhals am Ende des Prozesses für die Technische Redaktion beenden. Schließlich kann man erst mit dem Dokumentieren beginnen, wenn etwas feststeht, das man beschreiben kann. Aber zumindest ein Teil der genannten Probleme ließe sich erheblich abmildern, und das sollte als Motivation bereits mehr als ausreichen.
Mehrwert für den Anwender
Für den Anwender springt eine bessere, auch besser dokumentierte Software-Oberfläche heraus, die vielleicht sogar schneller fertig wird.
Richtig gut kann es werden, wenn Gelegenheiten geschaffen werden, bei der sich technische Redaktion und Anwender austauschen können. Aber das ist noch einmal ein anderes Thema.
Fazit
Um am Ende noch ein bisschen grundsätzlich zu werden: Nimmt man die Kultur, die Werte von Agilität ernst, bedeutet das unter anderem Transparenz für alle Beteiligten. Wirft man den RedakteurInnen am Ende des Sprints bzw. des Entwicklungsprozesses eine fertige Black Box hin, die sie bitte dokumentieren sollen, ist das auf keinen Fall im Sinne des Erfinders.
Kommunikation ist hier der Schlüssel und Redakteure sind gerade da normalerweise ziemlich gut. Agilität ist eine langfristige Verhaltensweise, die man annehmen und üben muss. Wenn man das ernst nehmen will, sollte man die Dokumentierenden von Beginn an in den Prozess integrieren.
Also: Alle gewinnen!
Sind Sie Product Owner? Holen Sie sich die Technische Redaktion ins Team, zumindest ins Daily.
Gehören Sie zur Technischen Redaktion? Sprechen Sie mit den Scrum-Leuten.
Vergessen Sie nicht: Die Idee von Scrum ist, sich durch ständiges Feedback immer wieder zu verbessern. Und alles zu tun, um dem Anwender zu nutzen.
Welche Erfahrungen haben Sie mit dem Thema gemacht? Wird Ihre Redaktion in agile Prozesse eingebunden? Berichten Sie gerne in den Kommentaren!
