Agile Informationsentwicklung ISO-normiert – ist das so ne Art rundes Quadrat?
Das längliche Fazit vorab
Ich fall mal mit der Tür ins Haus: Ich schreibe der neuen ISO/IEC/IEEE 26515:2018 einen praktischen Nutzwert zu, der allerdings auch Eigeninitiative erfordert. Man kann die Norm als Hilfe zur Selbsthilfe verwenden, wenn es im Unternehmen freudig-dynamisch-amorph heißt „und wir entwickeln jetzt agil“. Da bleibt nämlich oft die Informationsentwicklung außen vor. Theorien dazu später.
Die Norm allein wirkt natürlich keine Wunder. Es reicht nicht, die Norm zu lesen, mit ihr in der Firma zu winken „da steht’s, ich bin Teil des agilen Teams“, und schon wuppt es mit der agilen (Informations)entwicklung. Wie auch sonst im Leben haben die Leute nicht unbedingt auf einen gewartet.
Ich seh’s so:
- Die ISO/IEC/IEEE 26515 fasst die Aufgaben und Herausforderungen der Informationsentwicklung im agilen Entwicklungsprozess solide zusammen. Das hilft, den eigenen Beitrag oder besser Mehrwert zu erkennen und auch wo’s hapert. (Das kann man natürlich auch ohne die Norm hinkriegen, aber die Norm bringt’s halt gut auf den Punkt.)
- Danach ist Eigeninitiative gefragt, diesen Beitrag bzw. Mehrwert im agilen Team, aber auch in der Firma zu verankern. Das Erste ist auf Grass-Root-Ebene, das andere ein Top-down-Ansatz, wo die Manager der Informationsentwicklungsabteilung gefragt sind. Vielleicht holt man sich auch ein Beratungsunternehmen an Bord oder klinkt sich zumindest beim „agile-Entwicklung-Einführungsprojekt“ ein. Dabei muss man sich auch Zeit geben, es muss sich einrütteln. Und eine gepflegte Success Story im Firmenportal oder eine Standardpräsentation zur agilen Informationsentwicklung schaden auch nie.
- Entgegen der derzeitigen Ankündigung auf der VDI-Webseite beschreibt die Richtlinie aber NICHT die standardisierte Beschaffenheit von Herstellerinformationen, sondern, wie diese abgeliefert werden sollen.
Was ist die Lücke im agilen Entwicklungsprozess? Warum bleibt die Informationsentwicklung oft außen vor?
Meine Theorie dazu hat zwei Elemente, die sich für die Informationsentwicklung ungünstig ergänzen:
(1) Agile Entwicklung wird gerne mit Software-Entwicklung bzw. -Entwicklern gleichgesetzt.
(2) Bei agiler Entwicklung braucht man keine Dokumentation mehr.
Zu (1): Die agile Literatur inkl. Internet liefert jede Menge Infos, wie agile Entwicklung an sich funktioniert: Das multifunktionale Team besteht vereinfacht gesagt aus Product Owner, Scrum Master und dem amorphen Team Member. Und selbiger wird meist automatisch gleichgesetzt mit Software-Entwickler, der Features entwickelt, selbige testet und sich auch um Quality Assurance kümmert. <polemisch> Danach kann man ja ins Wasserfallmodell zurückfallen und Specs übern Zaun an die Dokuabteilung werfen </polemisch>.
Es gibt also reichlich Informationen, um Informationsentwicklern das Agile nahezubringen. Was fehlt, ist, wie Informationsentwickler in agilen Teams zur Wertschöpfung beitragen und welchen Wert gute Benutzerinformationen im agilen Kontext für den Kunden haben.
Zu (2): Dann gibt es noch das weit verbreitete Missverständnis „bei agil braucht man keine Dokumentation mehr“. Ein klares Jein. Natürlich braucht man weiter Dokumentation oder genauer gesagt Informationen für den Benutzer (Oberflächentexte, Embedded Help, Dokumentation). Woher soll’s der Benutzer denn wissen? Was man weniger braucht, ist entwicklungsbegleitende Projektdokumentation wie Specs und Design. Denn das wird bei der agilen Entwicklung durch enge Kommunikation (z.B. Stand-up-Meetings) und andere Artefakte wie Backlog Items und User Stories abgefangen. Was umso mehr ein Grund ist, dass Informationsentwickler Teil des agilen Teams sind.
Jetzt mal konkret – was gibt ISO/IEC/IEEE 26515 einem an die Hand?
So weit, so Lücke. Also was tun? Die Norm hilft bei der eigenen Positionierung, vor allem wenn man bislang in einem Wasserfallmodus gearbeitet hat. Aber wie oben schon gesagt, da muss man noch Eigeninitiative draufpacken.
Die Botschaft der Norm ist meist in wunderbare shall-Formulierungen verpackt, die ich jetzt im Deutschen mal ignoriere:
Der Augenöffner: Weg von „Dokumentation“, hin zu „Informationen für Benutzer“
Natürlich gibt es weiterhin Dokumentation (z.B. Benutzerleitfaden, API-Dokumentation). Aber ISO/IEC/IEEE 26515 wie auch die ganze Normenreihe ISO/IEC/IEEE 265* sieht Dokumentation als eine Art von Benutzerinformationen. Die anderen sind Oberflächentexte (Feldbezeichner, Nachrichten usw.) und Embedded Help (Overlays, Mouseovers, eingeblendete Topics usw. auf dem Bildschirm). Da liest sich in der Norm locker drüber oder du denkst jetzt: „äh, is doch eh alles so ne Art Dokumentation, was soll das jetzt?“ Aber das ist die Schlüsselerkenntnis zur Selbstpositionierung und Verzahnung mit den anderen im agilen Team.
Benutzerinformation zu erstellen ist eine Aufgabe des agilen Teams. Besonders geeignet hierfür sind die Informationsentwickler. Konkret bedeutet dies:
- In der Definition of Done auch Kriterien zu Benutzerinformationen aufnehmen (z.B. Terminologie festgelegt, Oberflächentexte überarbeitet, Dokumentation aktualisiert)
- Benutzerinformationen anhand von User Stories als Teil des Backlogs planen und gegen die Definition of Done prüfen
- Benutzerinformationen pro Sprint planen und verfolgen (am besten in Oberflächentext und eigenständige Dokumentation aufteilen)
- Benutzerinformationen reviewen und testen (mit der Software, aber Dokumentation auch separat)
- Benutzerinformationen zeitgleich mit den entsprechenden Entwicklungen abnehmen
Informationsentwickler sind Mitglieder des agilen Teams:
- Sie nehmen als gleichwertige Mitglieder an Stand-up-Meetings teil.
- Sie erstellen und/oder überarbeiten Benutzerinformationen (grob: Terminologie, Oberflächentexte, Embedded Help, Dokumentation).
- Sie unterstützen das Team z.B. beim Oberflächendesign und Testen.
- Sie geben und bekommen Feedback in Sprints.
- Sie leiten andere Team-Mitglieder an, zu den Benutzerinformationen beizutragen.
Rolle des Informationsentwicklungsmanagers (Leiter der Technischen Redaktion)
Der Manager schafft die Voraussetzungen, dass die Informationsentwickler in einem agilen Team arbeiten können (Ressourcenplanung, Change Management, Positionierung im firmenweiten Prozess-Setup und beim höheren Management etc.).
Freies Zitieren aus ISO/IEC/IEEE 26515 – oder welche Themen greift die Norm auf?
Ich zitiere aus dem Inhaltsverzeichnis, was mich anspringt: Überblick agiler Informationsentwicklungsprozess, Change-Management-Aktivitäten, das agile Team mit Aufgaben/Rollen/Kommunikation, Herausforderungen bei verteilten Teams, Ressourcenplanung für Manager, Arbeitsaufteilung pro und über eine Iteration, Last-Minute-Changes, Stand-up-Meetings, sich ändernde Anforderungen, Ermittlung der Kundenzufriedenheit, Planung/Design/Erstellung der Benutzerinformationen und ihrer Formate anhand von Use Cases/Personas/User Stories, Reviews und Testen, Übersetzung, Produktion und sogar „continuous delivery“.
Oder schaut einfach selbst ins Inhaltsverzeichnis.
Welche Rolle spielt ISO/IEC/IEEE 26515 in meinem Arbeitsleben? Keine, es ist eher andersrum
Ich habe dieses Blog nicht ohne Grund mit „Agile (Informations)entwicklung normiert – ist das so ne Art rundes Quadrat?“ betitelt. Ganz einfach weil die agile Entwicklung nicht dafür bekannt ist, sich auf ISO/IEC/IEEE/etc.-Normen zu berufen, und auch weil ich das aus meinem agilen Arbeitsleben bei SAP nicht kenne.
Bei SAP wurde die agile Entwicklung 2010/2011 in einem firmenweiten Projekt eingeführt. Da war keine Rede von ISO/IEC/IEEE 26515 etc. Trotzdem war die Informationsentwicklung (Aufgaben, Personen) von Anfang an Teil des agilen Teams. Was wohl daran lag, dass es so auch schon zu Wasserfallentwicklungszeiten war und es sich bewährt hatte.
Auch heute spielt die ISO/IEC/IEEE 26515 keine Rolle bei SAP. Die agile (Informations)entwicklung ist etabliert und läuft. Da muss man nicht nachträglich in eine Norm schauen. Aber was ich guten Gewissens sagen kann, ist, dass die Aussagen der Norm bei SAP verwirklicht sind. Das ist ein gutes Gefühl. Und ein ebenso gutes Gefühl ist es, mit den Erfahrungen aus dem SAP-Arbeitsleben ein Stück zur 2018-Version der Norm beigetragen zu haben.
Noch nicht genug? Dann lies doch hier weiter:
- Agile Dokumentation – geht das? Ein Praxisbericht
- A common misunderstanding “agile does not need documentation”
Unsere Blogserie „10 Normen für die Technische Dokumentation“
