take home lessons

Write the docs Vorträge im Sketchnotes-Format für alle, die nicht online dabei sein konnten:

https://writethedocs.threadless.com/collections/wtd-portland-2021-sketchnotes

Meine persönliche Super-Kurz-Zusammenfassung
Tagged with: ,
Posted in Wissen

Scrum4One

Christine Hennig

Kurzfassung

Selbst im Vollzeit-Homeoffice unter Corona-Lockdown Bedingungen kann ich eine agile Methode auf meine individuelle Situation anpassen und agil arbeiten.

Was ist eigentlich Scrum?

Gedränge versus Abstand?

Scrum kommt aus dem Rugby und bedeutet Gedränge. Das Team trift sich unmittelbar vor dem Spiel, steckt die Köpfe zusammen und kungelt eine Strategie für das bevorstehende Match aus.

Gedränge in Zeiten der Pandemie? Die informellen Gespräche unter Kollegen fallen weg. Die Kaffeemaschine steht zuhause in der Küche und ich treffe maximal die Katze dort. Wir alle spüren die Vereinsamung und vermissen Sozialkontakte.

In der Vergangenheit hatte ich gute Erfahrungen mit Scrum im Team und als Scrum Master gesammelt. Das ist ein reichhaltiges Reservoir an agiler Erfahrung. Ich werde die Team-Scrum Methode also nur ein wenig auf meine aktuellen Verhältnisse anpassen. Scrum für mich selbst als Einzelperson zu adaptieren ist mein individueller Versuch, dem Corona-Blues Einhalt zu gewähren.

Ich beginne wie üblich zu recherchieren, ob jemand schon die gleiche Idee hatte. In meinen Notizen findet sich “SoloScrum”, “Scrum of One” und “Scrum4One” als potentielle Suchworte. Ich werde fündig, z.B. bei [1], ein sehr lesenswerter Artikel. Diese Idee ist also definitiv nicht (nur) von mir.

Die Rollen im Scrum bestreite ich alle selbst.
Ich bin also meine eigene Scrum Expertin ebenso wie meine eigene Product Ownerin.

Worum es bei Scrum geht

  • Tue, was Du kannst mit dem, was Du hast.
  • Sorge für fortlaufende Selbstreflektion.
  • Arbeite auf klar definierte, kurzfristige Ziele hin.
  • Plane und arbeite in Sprints (kurzen Zyklen).

Frei übersetzt aus [2]

Retro- und Per-Spektiven

Ich liebe Retrospektiven – der berühmte Blick zurück nach vorn. Ziel ist, bisherige Erfahrungen praktisch zu nutzen. Dazu sind in regelmässigen Intervallen folgende Leitfragen zu beantworten.

  • Was lief gut?
  • Was war nicht so gut?
  • Welche Maßnahmen ergreife ich für die Zeit bis zur nächsten Retro?
  • Welche Maßnahme vom letzten Mal lasse ich lieber wieder bleiben? (Ab der zweiten Retro)

Visuelle Unterstützung

Eine kurze Bilder-Recherche nach Retrospektive liefert einen ganzen Strauß an Methoden, um die Antworten auf obige Fragen hervorzuholen.

Positiv/Negativ

Der Klassiker

  • ‘:-)’ gut
  • ‘:-(‘ nicht so gut
  • Läßt sich noch erweitern durch: Schlussfolgerungen aus den Erkenntnissen ziehen

continue, start, stop

Hat mir besonders gut gefallen

  • ‘>’ Anfangen (Start / Add)
  • ‘»’ Weitermachen (Continue / Keep)
  • ‘|’ Aufhören (Stop / Drop)
  • Läßt sich noch würzen mittels: Verbessern (Improve)

Starfish Game

Habe ich erfolgreich probiert. Dabei werden sechs Positionen auf einem Rad platziert.

  • Weiter so
  • Danke sagen
  • Nicht mehr machen
  • Mehr davon
  • Weniger davon
  • Anfangen zu machen

Starfish Game ist eine gute Abwandlung, damit es nicht so langweilig wird, sich jede Woche exakt die gleichen Fragen zu stellen.

Nimm Zwei

Gefällt mir gut, es ist eine positiv und in die Zukunft formulierte Abwandlung des Klassikers für Einzelpersonen.

  • One to make me happy
  • One to make me more productive

Nimm Zwei zielt auf ein positives Ergebnis und sollte schnell gemacht sein. Dabei wird weniger in die Vergangenheit geblickt, als auf die Zukunft fokussiert.

maßgeschneidert maß-nehmen

Zwei Veränderungen sollen in die neue Woche mitgenommen werden. Das ist für eine Person realistisch und kann im Alltag dennoch eine Herausforderung darstellen. Immerhin gilt es, Gewohnheiten zu verändern, um bessere Gewohnheiten einzuüben.

Als Scrum Master im Team hatte ich wochenweise Freiwillige gebeten, eine einzelne Maßnahme vorübergehend zu adoptieren und in der kommenden Woche besonderes Augenmerk darauf zu richten. Die Person darf sich die Maßnahme selbstverständlich aussuchen. Die Idee stammte von einem Team-Mitglied. Das funktioniert auch prima mit der Adoption der agilen Prinzipien. [3]

Play the Planning Game again

Mich selbst agil planen – dazu gehört erst einmal ganz viel Luft:

  • Spielraum für Unvorhergesehenes.
  • Spielraum für Kundenwünsche, Tagesgeschäft, unerwartete Termine.

Wichtig: Die Planung selbst benötigt zwischen 10 und 30% der Gesamtzeit.

Granularität der Planung

Meine Sprints dauern eine Woche. Ich plane gern in Einheiten von maximal halben Tagen.
Für eine gute Planung muss ich die Aufgaben mindestens auf eine solche Größe herunterbrechen.

Das klassische Projektmanagement kennt dafür den Begriff Work-Breakdown-Structure.
Im Scrum gibt es 3 bzw. 4 Hierarchien:

  • Epos / Story / Task
  • Theme / Epos / Story / Task

Detaillierung der Planung

Je dichter ich fachlich an der Abarbeitung einer konkreten Arbeitseinheit bin, desto präziser kann ich sie formulieren und ihre Dauer schätzen.

Eine Präzise Formulierung hilft mir, die Arbeit konkret abzugrenzen.

  • Was gehört dazu? => Umfang der Arbeit skizzieren
  • Was gehört nicht dazu? => ggf. weitere Tickets schreiben
  • Wann ist diese Arbeit fertig? => Definition of Done

Bin ich nicht in der Lage, zu formulieren, wann die Arbeit erledigt ist, bekomme ich ein Problem in der Abarbeitung. Ich werde “nie” fertig. Darum ist es so wichtig, sich darüber klar zu werden, was genau eine Arbeitseinheit umfassen soll. Diese Detail-Planung ist fachlich-inhaltlich. Niemand kann sie mir abnehmen, denn ich bin die Expertin für die zu planende und durchzuführende Tätigkeit. Ich empfinde die Feinplanung nicht als lästig, sondern als geeignet, mir selbst klar zu werden, was genau ich da eigentlich tun möchte.
Die Detailplanung ist einer der Gründe, warum so viel Zeit mit der Planung draufgeht. Sie zahlt sich immer aus, denn sie bewahrt mich auch davor, mich zu verrennen und dadurch u.U. viel mehr Zeit zu verbrennen.

Schätzen

Keine Zeit-Planung ohne Schätzen.

Leichter als absolutes Schätzen ist relatives Schätzen: Aufgabe A benötigt mehr Zeit als Aufgabe B.
Oder Schätzen mit Fehlerbalken: Aufgabe A benötigt mindestens 2h, im Worst Case jedoch 6h.
Hier zahlt sich aus, dass die Arbeiten möglichst konkret definiert sind. Ich kann nur Arbeiten schätzen, deren Umfang einigermaßen klar umrissen ist. Story Points für eine Person benutze ich nicht.

Halbgares

Trotz sorgfältiger Planung gibt es immer mal wieder Tickets, die sich einfach nicht abarbeiten lassen wollen, weil zu viele Unklarheiten bestehen. Wenn ich immer alles schon vorher wüßte …
Dann helfen mir folgende Strategien:

  • Aufteilen: Kann ich Teile der Arbeit in eigenen Tickets auslagern?
  • Spike: Kann ich eine Spike-Story definieren, deren Ziel lediglich darin besteht, die weitere Vorgehensweise zu klären?
  • Timeboxing: Kann ich mich für einen fest vorgegebenen Zeitraum in das Thema vertiefen und dann hoffentlich mit Zwischenergebnissen wieder auftauchen?
    • nächste mögliche Schritte (bilden Erinnerungshaken, wenn ich später wieder dort aufsetzen will, wo ich aufgehört habe)
    • weiterhin zu klärende Aspekte
    • K.O.-Kriterium für Abarbeitung gefunden

Dies alles wird natürlich (in den Tickets) dokumentiert.

SMARTes INVESTment

Stories sollten “invest” sein:

  • I – Independent
  • N – Negotiable
  • V – Valuable
  • E – Estimable
  • S – Small
  • T – Testable

Tasks sollten “smart” sein:

  • S – Specific
  • M – Measurable
  • A – Achievable
  • R – Relevant
  • T – Time-boxed

Zahlreiche Tipps dazu finden sich in der Grafik in [4], die sich in vielen Varianten im WWW findet. Ich empfehle, unbedingt einen intensiven Blick darauf zu werfen. Definitiv einen eigenen Artikel wert.

Ticketsystem

Ich mag das haptische Element.
Mein Ticketsystem für die Wochen-Planung ist daher analog:

  • Ein Stapel Papier-Zettel + Stifte
  • Eine Pinnwand + Pins

Die Pinnwand ist in Wochentage eingeteilt. Mein “Burndown Chart” ist ersetzt durch einen Nagel in einem Brett, auf den ich die abgearbeiteten Zettel aufspieße. Das macht Spaß und der Stapel wächst. Meine Pinnwand hängt so, dass ich jederzeit zu ihr rübersehen kann, sie jedoch normalerweise ausblende.

Daily Standup

Die eigenen Arbeiten hängen von anderen Arbeiten, Personen, Ressourcen o.ä. ab. Der Management-Klassiker schlechthin. Das ist einer der wesentlichen Gründe, warum Arbeiten auf Vorrat geplant werden müssen und nicht einfach losgelegt wird.
Zum Glück haben wir tägliche Video-Sitzungen. Dort kommen diese Dinge zur Sprache, um:

  • direkt geklärt zu werden
  • auf einen bestimmten Zeitpunkt verschoben zu werden
  • die zugehörige Arbeit zurück auf den Stapel (ins Scrum Backlog) zu verschieben

Rückblick

Im Dezember 2020 habe ich mit Scrum4One begonnen. Ich bin seitdem sehr zufrieden mit meiner Selbst-Führung. Der Corona-Blues zu Beginn des 2. Lockdowns mit Vollzeit-Homeoffice ist in weiten Teilen einer inneren Ausgeglichenheit gewichen. Die Arbeitszufriedenheit ist gewachsen und stabiler. Ich mache dann mal so weiter von Woche zu Woche.

Referenzen

[1] https://www.raywenderlich.com/585-scrum-of-one-how-to-bring-scrum-into-your-one-person-operation

[2] https://www.infoq.com/news/2015/02/personal-scrum/

[3] https://agilemanifesto.org/principles.html

[4] https://agileforall.com/how-to-split-a-user-story/

Tagged with: ,
Posted in Agile

IT Frauen Berlin und anderswo

Beiträge im Magazin “Frauen machen Informatik Heft 44 (Schwerpunkt Medizininformatik)

Hannover goes Online

Berlin goes IT-Frauen

GI Interview

Tagged with:
Posted in GI

20 Jahre Wissenschaftsjahre

Dank meinem Engagement in der Gesellschaft für Informatik wurde ich (neben vielen anderen Menschen) für einen Video-Beitrag zum 20-jährigen Jubiläum des Wissenschaftsjahres angefragt, dem ich sehr gern nachgekommen bin.

Hier der Link zum Beitrag:

https://www.wissenschaftsjahr.de/2020-21/das-wissenschaftsjahr/20-jahre-wissenschaftsjahre

Tagged with:
Posted in Wissen

The power of pairing

Paar-Dokumentation bei einem Übergabe-Projekt

Christine Hennig, Wolfram Eifler

  1. September 2020

Einführung

Pair documentation sollte doch keine neue Idee gegenüber Pair programming sein – dachten wir.
Die Internet-Recherche zum Thema “pair documentation” lieferte ein mageres Ergebnis.

  • Einen Praxisbericht über 50 Stunden gemeinsame Dokumentation in der Open Source Community ([1]).
  • Eine empirische Studie über die Erstellung einer SRS (software/system requirements specification) als Einzelperson versus als Team ([2])

Hier unsere eigenen Erfahrungen mit dem Thema.

Anlaß war die Arbeits-Übergabe eines Mitarbeiters bei Verlassen des Unternehmens und die Sicherung des erarbeiteten Wissensstandes. Bestandteil der Übergabe war ein Prototyp bzw. Referenz-Implementierung in einem fortgeschrittenen Stadium. Er umfasste mehrere umfangreiche Technologie-Stacks.

Zur Verfügung stand ein Dokumentations-System im Intranet mit einer MediaWiki-Installation. Alle Dokumente sind als einzelne oder Verbund mehrerer Wiki-Seiten im System abgelegt.
Jedes Thema befindet sich in einem definierten Zustand, der von “Inkubator” bis “Freigabe” über mehrere Review-Zyklen läuft. Die Arbeiten fanden während der Corona-Pandemie im Homeoffice statt.

Beschrieben ist zum einen unser initialer Plan und zum anderen unsere Erfahrungen.

Hier der Plan

Ausgangslage:

  • Ein Mitarbeiter verlässt die Firma.
  • Mit den verbleibenden Arbeitsstunden ist eine möglichst vollständige Übergabe zu bewerkstelligen.

Lösungsansatz:

  • Pingpong zwischen Mitarbeiter (Contentproduktion / MA) und Redakteurin (Qualitätssicherung / QS).
  • Der redaktionelle Ablauf ist frei von Loops. So wird ein unnötiges Abgleiten in Details vermieden.
  • Die einzelnen Arbeitsschritte sind mit einem geschätzten Zeitkontingent hinterlegt.

Planung:

  • Die dokumentarisch zu bearbeitenden Themen werden im Vorfeld aufgelistet.
  • Jedes Thema durchläuft den nachfolgend genannten Arbeitsfluss.
  • Zu Beginn ist die Anzahl der zu bearbeitenden Themen mit der noch zur Verfügung stehenden Zeit abzustimmen.
  • Die verfügbare Zeit wird zu Beginn realistisch auf die Themen verteilt. Die Freiheitsgrade sind Detailtiefe, Markierung als optional und ggf. Streichung des jeweiligen Themas.

Arbeitsfluss je Thema:

NummerStundenWerZustandWas
1.01QSInkubatorSeite im System anlegen, (ggf. vorläufigen) Titel vergeben
1.11MASammelnMaterial sammeln
1.21MAOrdnenBezug zu existierender Dokumentation herstellen
1.33MAOrdnenStrukturieren/Gliedern
2.01QSPreviewStruktur auf Plausibilität kontrollieren
3.010MAAngefangenschreiben, schreiben schreiben
4.05QSReview1Inhaltlich, strukturell, Korrektheit, Konsistenz, Aktualität
5.03QS + MAHands-On Doku gegen techn. System halten, Lücken aufspüren usw.
6.04MAErgänzen1Vervollständigen, ggf. Struktur verbessern
7.03QSReview2Inhalt, Struktur
8.03MAErgänzen2Vervollständigen, ggf. Struktur verbessern
9.02QSReview3Rechtschreibung, Grammatik, tote Links
10.01QSFreigabeFertig

Ergebnis:

  • Alle geplanten Themen sind grundsätzlich bearbeitet.
  • Kein Thema ist wegen Detailversessenheit untergegangen.
  • Es ergibt sich eine Dokumentation, die Nachfolgern einen sinnvollen Ansatzpunkt liefert, um am Thema weiterzuarbeiten.

Dort die Realität

Wie immer kommt es (ein wenig) anders. Zu Beginn implementierten wir einen Backup-Mechanismus zur Sicherung der Doku-Zwischenstände.

Nach unserer Planung erfordert Punkt 3 (Schreiben, schreiben, schreiben) knapp die Hälfte der Zeit. Das entsprach der Realität.

Ab Punkt 5 (Hands-On) arbeiteten wir dann fast nur noch gemeinsam an der Doku. Die geplante Zeit wurde dazu in etwa wie erwartet benötigt, jedoch ergab sich häufig parallele Arbeit im selben Ablaufpunkt an mehreren miteinander verknüpften Themen. Außerdem justierten wir regelmäßig die verbleibenden Arbeiten nach Priorität und Zeitkontingent, teilweise auch in ihrer Struktur.

Die Reviewerin / QS-Verantwortliche hatte natürlich viele Fragen, das ist schließlich ihr Job. Die Fragen führten dazu, dass die Doku viel verständlicher und besser strukturiert wurde. Jede Rückfrage wurde genutzt, um Form und Struktur der Beschreibung zu optimieren. Die Zielvorstellung dabei war, den hinterfragten Sachverhalt noch klarer zu beschreiben.

Wir arbeiteten die Änderungen abwechselnd ein. Die Hands-On Sitzungen wurden mal von der QS, mal vom Mitarbeiter durchgeführt. Die zweite Person passte jeweils auf, dass alles richtig getippt wird und bei jedem Kommandobeispiel klar ist, was damit bezweckt wird und ob dies auch angemessen aus der Doku hervorgeht.

Dabei ging es dann direkt an den Prototyp, ohne ihn kaputtzumachen. Natürlich hatten wir ein Backup für den Notfall.

Aufkommende weitere Themen, Anmerkungen und Wünsche, die den aktuellen Rahmen sprengten, wurden fortlaufend an das Ende einer ToDo Liste angehängt.
Diese Abgrenzung entlastete den Mitarbeiter von Unterbrechungen beim Schreiben, ohne dass Thematiken verlorengingen. Die Liste wurde wöchentlich priorisiert (must, should, could, won’t [3]) sowie mit dem erreichten Fortschritt und Zeitplan abgeglichen.

Gemeinsam kamen wir in gute Energie und der Flow ([4]) ließ nicht lange auf sich warten. Die Zeit verging wie im Flug.
So zogen sich unsere Video-Meetings meist so lange hin, bis eine Person von uns beiden Hunger bekam.

Alles in allem hatten wir viel Spass und ein gutes Gewissen, den Job unter den gegebenen Bedingungen so gut abgeliefert zu haben.

Persönliches Fazit

Paar-Dokumentation

  • ist produktiv
  • verbessert die Qualität der Dokumentation
  • sorgt für Wissens-Weitergabe
  • macht Spaß
  • funktioniert auch im Homeoffice

Gemeinsame Planung ist hilfreich, um den Fokus zu halten und in jeder Phase Wichtiges von Unwichtigem zu unterscheiden.

Referenzen

Tagged with: , , , ,
Posted in IT allgemein, Organisationsentwicklung, Wissen

Was clean code und effiziente Wissens-Strukturierung gemeinsam haben

Wenn ich ein komplexes Thema inhaltlich beschreibe, stellt es mich vor vielfältige Herausforderungen.

Eine übliche Art der Bearbeitung ist die Aufteilung des Inhalts in sog. Topics, die spezielle Aspekte dieses Inhalts beschreiben.
Diese Topics können mit Assoziationen, also Beziehungen untereinander, versehen werden.

Eine Topic Map dient dazu, den Überblick über alle Topics zu erhalten. Sie ist die “Landkarte”, auf der alle Topics und deren Beziehungen verzeichnet sind.
In ihr kann navigiert werden und auch auf die einzelnen Topics über einen Index zugegriffen.

Hierbei stellt sich die Frage, wie umfangreich die einzelnen Topics erstellt werden und welche Aspekte in welchem Topic dokumentiert werden.

Dabei helfen mir die Regeln der Clean Code Developer [1].
Was für Entwickelnde gut ist, kann für Dokumentierende nicht falsch sein.
Im Orangenen Grad sollen folgende Prinzipien eingehalten werden, die ich gleich auf Topics abbilde:

  • Single Level of Abstraction: Die Einhaltung eines Abstraktionsniveaus fördert die Lesbarkeit.
  • Single Responsibility Principle: Fokus erleichtert das Verständnis. Ein Topic mit genau einer Aufgabe ist verständlicher als ein Gemischtwarenladen.
  • Separation of Concerns: Wenn ein Topic keine klare Aufgabe hat, ist es schwer ihn zu verstehen und ggf. zu korrigieren oder zu erweitern.
  • (Source Code) Konventionen: Topics werden häufiger gelesen und recherchiert als geschrieben. Daher sind (Dokumentations-)Konventionen wichtig, die ein schnelles Lesen und Erfassen des Topics unterstützen.

Die Herausforderungen guter Software-Entwicklung und guter technischer Dokumentation ähneln sich also verblüffend.

[1] https://clean-code-developer.de/die-grade/orangener-grad/

Tagged with: , , ,
Posted in Wissensmanagement

Informationsqualität

Diesmal als MindMap:

Informationsqualität

Aus dem Klassiker
“Developing Quality Technical Information”
von Hargis, Carey, Hernandez, Hughes, Longo, Rouiller, Wilder

Download in voller Auflösung:

Tagged with: ,
Posted in Wissensmanagement

Einführung eines maßgeschneiderten Wissensmanagements bei einem IT-Dienstleister

Vortragsfolien

Einführung Wissensmanagement

Tagged with: , ,
Posted in GI, Wissensmanagement

Frauen in der Tech-Szene

Dank meinem Engagement in der Gesellschaft für Informatik wurde ich für eine Podiumsdiskussion angefragt. Es ging um die Frage, warum der Frauenanteil in der IT und den technischen Berufen immer noch so gering ist.

Hier der Link zum Beitrag:

https://www.wissenschaftsjahr.de/2018/neues-aus-den-arbeitswelten/alle-aktuellen-meldungen/oktober-2018/frauen-in-der-tech-szene-wird-die-ausnahme-je-zum-alltag/

Tagged with: , , , , , , ,
Posted in GI, IT allgemein

Die 4 Arten von technischer Dokumentation am Beispiel eines Zitronenkuchens

Am Wochenende war ich in Prag. Die WriteTheDocs Community hatte ihre EU Konferenz und ich, neu in Tech Docs, war zum ersten Mal dabei:

http://www.writethedocs.org/conf/eu/2017/

Den Eröffungs-Vortrag hielt Daniele Procida mit dem Titel
“The four kinds of documentation, and why you need to understand what they are”

Und das sind sie, die vier Arten der Dokumentation:

  • klassifiziert mit ihrem Fokus
  • gruppiert nach
    • lernen oder tun
    • Theorie oder Praxis
TUTORIAL learning studying practice
HOW-TO problem-solving doing practice
EXPLANATION understanding studying theory
REFERENCE information doing theory

Ich habe nun auch den Unterschied zwischen einem Tutorial und einem How-To verstanden, die ich übrigens beide als “Anleitung” übersetzt bekomme.

Das Tutorial lehrt, wie es prinzipiell geht. Dies gern an einem Beispiel. Es geht aber um das Lernen. “Wir lernen einen Kuchen backen.”

Das How-To erklärt ein konkretes Thema. Das Thema ist eben gerade kein Beispiel, sondern das, worum es geht. Sie setzt ein gewisses Grundverständnis voraus, zum Beispiel wie man einen Kuchen backt und wie man ein Rezept liest. “Wir backen einen Zitronenkuchen.” wird dann das Zitronenkuchenrezept.

In der Referenz kann ich nachschlagen, welche Backeigenschaften das Mehl hat und was eine Kastenform ist.

Eine Erklärung kann die Vor- und Nachteile des Genusses eines Stück Zitronenkuchens für die menschliche Ernährung darstellen.

Tagged with:
Posted in Wissensmanagement