AGIL? DOKUMENTATION? Ein Widerspruch in sich oder bereits erfolgreich etabliert?
Wenn man vom Thema Agilität spricht, befindet man sich meist im Umfeld der Softwareentwicklung: Kürzere Entwicklungszyklen und schnellere Markt-Veröffentlichungen, um Fehleranfälligkeiten zu minimieren und konkurrenzfähig zu bleiben. Was entwickelt wird, will am Ende auch dokumentiert
werden – oder sagen wir mal ‘sollte’, sofern das User Interface nicht schon so selbsterklärend daherkommt, dass User*innen nicht mehr auf Dokumentation zurückgreifen müssten. Aber sind wir mal ehrlich: So weit sind die wenigsten.
Wird agile Softwareentwicklung im Unternehmen gelebt, stellen sich der Technischen Dokumentation die Fragen: ‘Springen wir auf den Schnellzug auf? Können wir das überhaupt und wie sieht Dokumentation in solch einem Umfeld dann aus?’
Dazu muss man zunächst ein paar Hintergrundfakten recherchieren und analysieren. Das Grundprinzip nach dem in der agilen Softwareentwicklung gearbeitet wird, ist das schnelle und zyklische Bereitstellen eines funktionsfähigen Softwarepakets (mal grösser, mal weniger gross). Um diese Art der Auslieferung gewährleisten zu können, bewegt sich der gesamte Prozess von der Planung über die Entwicklung bis hin zum Release in immer wiederkehrenden sogenannten Program Iterations (kurz PI). Das PI bezeichnet einen Zyklus, in dem ein vorab definierter lieferbarer Softwarezustand entwickelt und den User*innen bereitgestellt wird. Und damit das Ganze noch flotter und mit möglichst wenigen Zwischenfällen über die Bühne geht, besteht das PI nochmals aus kleineren Sprints, die jeweils etwa 4 Wochen dauern und zu deren Ende immer wieder der aktuelle Entwicklungsstand überprüft wird. Kontrolle pur, oder?
Manchmal hört man die Technische Dokumentation leise aus der Ferne rufen ‘Halloooo?… ihr wisst schon, dass das dokumentiert werden muss?!’ Ich denke ja ohnehin, dass das Zeitalter bereits abgerissen ist, in dem die Dokumentation am Ende der Fahnenstange lethargisch vor sich hin flattert, bis die Entwicklung einem gnädigerweise ihren Informationsbrei reicht und man endlich arbeiten darf.
Technische Dokumentation kann und sollte in den agilen Prozess involviert werden. Und das nicht nur als Nebenprodukt, sondern als integrierter Teil der agilen Umgebung auf gleichem Level mit der Softwareentwicklung. Zu Beginn der PI-Planung wird festgelegt, was entwickelt wird und parallel hierzu analysiert, was entsprechend dokumentiert werden muss. Der Informationsfluss zwischen Entwicklung und Dokumentation muss hier bereits zwingend fliessen. Durch Dependenzen im Planungssystem, das für alle transparent ist, wird für die Beteiligten ersichtlich, dass das PI ohne die Dokumentation nicht einfach abgeschlossen werden kann. Spätestens hier wird klar: Die Entwicklung braucht die Dokumentation – die Dokumentation braucht die Entwicklung. Und tauchen Stolpersteine mitten im Projekt auf, ist das ebenfalls direkt sichtbar und man kann rechtzeitig darauf reagieren. Diese Art der Transparenz ermöglicht es, die Relevanz der Technischen Dokumentation im Unternehmen zu heben, die Notwendigkeit eines kontinuierlichen Informationsflusses zu
verdeutlichen und das Dokumentationsteam durch detaillierte Berechnungen zur Balance von Kapazität und Workload vor einer möglichen Überlast zu schützen.
Alle haben es gesehen, alle wissen Bescheid: Dokumentation ist wichtig UND kann agil sein. Könnt ihr das auch?