Frequency + Impact = FRIM

Bei der Suche nach neuen Methoden um den Gather Data-Teil meiner nächsten Retrospektive zu bestücken über die FRIM-Methode von Diana Larsen gestolpert.

Ich wollte eine Möglichkeit um über einen längeren Zeitraum zurückzublicken und insbesondere über unseren doch sehr angepassten Prozess nachzudenken (und mit angepasst meine ich eigentlich, dass wir alles sehr schleifen lassen haben).

Der Klassiker für so einen Fall ist natürlich die Timeline, die mich aber bisher nicht überzeugen konnte, da sich dabei alle Teilnehmer, fast ausschließlich Entwickler,  sehr damit aufhielten die Vorkommnisse im letzten Sprints genaustens in die zeitliche Abfolge zu bringen.

Ziel:
Bei der FRIM-Methode soll das Team auch über alles nachdenken was passiert ist, was sie positiv und negativ beeinflusst hat.

Wichtig ist hierbei die Auswirkung/Stärke (Impact) und die Häufigkeit (Frequency). So wird klar was wirklich dringend verändert werden muss.

Oft werden die Dinge die einen gerade einen Tag vor der Retrospektive passiert sind und noch unter den Fingernägeln brennen, aber selten auftreten, überbewertet.

Vorgehen:
An das Whiteboard wird ein 6×6 Raster gezeichnet.

Die x-Achse bildet die Häufigkeit ab:
0 = sehr selten
1 = maximal einmal pro Iteration
2 = 1-2 mal pro Iteration
3 = alle 2-3 Tage
4 = täglich
5 = mehrmals täglich

Die y-Achse bildet die Grad der Auswirkung ab mit den folgenden Einteilungen:
0 = keine Auswirkung
1 = Sehr kleine Auswirkung
2 = Geringe Auswirkung
3 = Moderate Auswirkung
4 = Signifikante Auswirkung
5 = Maximale, sehr starke Auswirkung

Nun dürfen die Teilnehmer auf farbigen Karten dokumentieren:

  • was sie erfreut hat, vorangebracht hat (grün)
  • was sie geärgert, aufgehalten, gestört hat (rot)
  • welche Ereignisse ihnen im Kopf hängen geblieben sind (gelb)

und frei im Raster aufhängen.

Die Karten werden mit der Unterstützung vom Moderator von rechts oben (5er Auswirkung – 5er Häufigkeit) nach links unten (0er Auswirkung – 0er Häufigkeit) durchgesprochen.

in der Praxis:
Die Team-Teilnehmer und ich kamen mit FRIM gut klar und erzielten schnell weiterverwertbare Ergebnisse.frim-board
Nur mir den “Ereigniskarten” hatten die meisten Schwierigkeiten, da die Ereignisse immer positiv oder negativ belegt waren. Zum Beispiel unsere neue Art die Stories beim Review in großer Runde abzunehmen wurde von allen Teilnehmern nicht als gelbe wertfreie Karte aufgehängt, sondern durchweg als grünes positives Feedback an die Wand gehängt.

Besonders erfreut hat mich, dass die rechte obere Ecke des Rasters (maximale Auswirkung und maximale Häufigkeit) sich mit jedem weiteren Teilnehmer wie eine schützende Hecke um die restlichen roten Karten legte.

Hals über Kopf

kopfstandDie Kopfstandmethode oder Anti-Methode kann immer verwendet werden, wenn kreative Ideen gesucht werden oder um eine Denk-Blockade zu zerstören. Die Ideen werden durch einen gedanklichen Kopfstand ermittelt. Es wird nicht versucht das Problem zu lösen, sondern genau das Gegenteil.

Was ist das schlimmste Szenario?

Das ist eine schöne Abwechslung und gerade für Menschen, die sich nicht für kreativ halten oder wenig motiviert sind, bei andere “Spielen” mitzumachen.

Es fällt eben leichter schlecht zu denken und zu meckern.

Und das allerschlechteste was wir zu einem Thema oder Problemstellung finden, wird genommen um mit dem Gegenteil das Ziel zu formulieren.

 

Beispiel “Software-Dokumentation”

Dies Beispiel stammt aus dem Entstehungsprozesses unserer Werte-Liste.

Ein Punkt der auf dieser Werte-Liste für ein gutes Produkt sein sollte war: “Software-Dokumentation”.

Kopfstand-Frage: Was sieht die schlimmste Dokumentation aus?

Die erste Idee war: “Keine Dokumentation”

Aber in der weiteren Diskussion kam heraus, dass vielleicht falsche/veraltete Dokumentation noch schlimmer ist.

Denn bei fehlender Dokumentation würden wir Entwickler und gleich den Code anschauen um zu verstehen, wie es benutzt wird.

Bei falscher Dokumentation würden wir viel Zeit auf mit der falschen Benutzung und Debugging verwenden, oder mit falschen Resultaten weiterarbeiten.

Aus dem Kopfstand-Ergebnis: “falsche Dokumentation” ist nun das Ziel “korrekte und aktuelle Dokumentation” entstanden.

Tut das Not, dass ihr hier so lange rumoxidiert?

oder anders gefragt: Kann man eine Retrospektive abkürzen? Denn alle 2-3 Wochen das komplette Team sich für eine Retrospektive zusammen setzen zu lassen kostet.

Wir können uns ja mal vorstellen was passiert wenn einer der Teile ausgelassen wird.

1. Set The Stage:

-> Jeder hat jeden Tag dringende Emails, Bugs, Feature Requests, Telefonate, etc und jeder benötigt Zeit um diese Gedanken beiseite zu schieben und sich auf das bevorstehende Meeting zu fokusieren. Ohne diese Einstimmung, würden die meisten Teilnehmer erst nach der Hälfte des nächsten Teils auf Drehzahl kommen.

-> Eine Erinnerung an die Meetingregeln ist die beste Prävention gegen Geklingeln und den darauf resultierenden Ärger der anderen Teilnehmer (z.B.: “Mach sofort das Händy aus, du fräche Schnoddä ! Das is verbotn !”)

-> Ohne den Review der letzten Iteration würden im Gather Data – Teil garantiert die ein oder andern Dinge vergessen werden (z.B. ob das Bug/Feature-Verhältnis im grünen Bereich ist, oder welche Konzeption besonders gut für die Entwicklung war)

-> Ohne die Verkündigung der Agenda und des Fokus der Retrospektive (z.B.: “Wie gut passt der Prozess zu uns?”, “”continuous improvement”, “Zusammenspiel Product Owner / Entwicklungsteam”), kommt es zu einem sehr großem Feld an gesammelten Daten. Diese ganzen Daten können nicht einer angemessenen Timebox analysiert werden. Zum einen versanden wichtige Punkte und es kann sich Frust bei den Teilnehmern aufbauen, deren Punkte in den folgenden Teilen der retrospektive besprochen und analysiert werden.

-> Der Icebreaker ist nicht nur für schüchterne Teilnehmer eine Hilfe um aktiv an der Retrospektiv teilzunehmen, sondern kann auch als Teambuilding  beitragen, wenn dadurch gemeinsame Hobbys, Konzertbesuche oder Lieblingsfilme erkannt werden.

2. Gather Data

-> Die Teilnehmer würden nicht die Sichtweisen und Probleme der Anderen erfahren. Die gesamte gemeinsame  Grundlage für alle weiteren Teile der Retrospektive würde fehlen.

3. Generate Insights

-> Es würde nur eine ganz gewöhnliche, meist oberflächliche Problemfindung sein. Die Aktivitäten dieses Teils der Retrospektive sorgen im Normalfall für einen tiefes Verständnis und Ursachenforschung der Probleme. Den meist liegen die Probleme tiefer als sie scheinen.

4. Decide what to do

Ok, hier fällt mir wirklich nichts ein. Wer würde ernsthaft eine Retrospektive abhalten ohne daraus Aktivitäten abzuleiten. Selbst früher als wir noch keine Retrospektiven,  sondern nur wenn ein Projekt besonders schlecht lief im nachhinein eine Manöverkritik abhielten, haben wir uns Aktivitäten überlegt.

5. Close

-> Die Retrospektive an sich würde sich nicht verbessern, da das Closing nicht nur die Verabschiedung und das Herrichten des Raumes beinhaltet, sondern die Retrospektive der Retrospektive.shortcut

Ich bin selbst überrascht wie wichtig die Randphasen einer Retrospektive sind, gerade wie viele Gegenargumente ich für das Auslasen des Meetingbeginn ich gefunden habe. Also nehmt euch Zeit dafür und kürzt es nicht ab. Jeder Teil ist absolut sinnvoll oder in Meister Röhrichs Worten: „Ihr bleibt heute solange, bis das fertich is!”

Warum? Warum? Warum? Warum? Warum?

Nein, was wird kein Blogpost über meine Kinder die mir täglich Löcher in den Bauch fragen,domino sondern über die “5 whys”.

In einer der letzten Retrospektiven haben wir diese Methode angewandt
um den Kern der Probleme aufzuspüren. Da wir diesen Weg das erste Mal gegangen sind, war er etwas holperig  aber trotzdem konnten wir gute Aktivitäten aus den Problemen ableiten.

Die Idee die hinter der 5 whys – Methode steckt, ist mit jedem why einen Schritt näher an den Ursprung des Problems zu kommen.

Also zum Beispiel:
Problem:  “Am Montag war die Site offline”

  • Warum?   “Weil der Server überlastet war”
  • Warum?   “Weil die Software nicht performant genug war”
  • Warum?   “Weil für die Optimierung keine Zeit war”
  • Warum?   “Weil bei der Projektplanung und Festsetzung der Deadline die Urlaubszeit der Entwickler nicht berücksichtigt wurde”
  • Warum?   “Weil der Urlaub sehr kurzfristig eingereicht wurde”

-> Lösung: Bessere Projektplanung durch frühe Urlaubsplanung!

Hierbei wird deutlich, dass eine schnelle Maßnahme, wie Hardware nachrüsten bei der schlechten Planung immer wieder zu Problemen und unperformantem Code geführt hätten.

Wie ist man sicher, dass die richtige Ursache gefunden wurde?
Dies kann mit einem wenn-dann-Umkehrschluß überprüft werden.
Also:

“Wenn der Urlaub frühzeitig geplant wird, dann wird die Projektplanung und Festlegung der Deadline das berücksichtigen”

Wie stellt man sicher, dass man am letzten Knoten angelangt ist?
Wenn man sich mit den Antworten irgendwo in Prozess Nähe befindet, ist die Chance groß, dann man am Ende angelangt ist.

Was ist, wenn man verschiedene Ursachen findet?
Dann verzweigt sich der Pfad, was in den meisten Fällen ein Indiz dafür ist, dass das Problem zu generell ist und kein spezifisches Problem.
In der strengen 5 why Methode wird nur ein Strang verfolgt, da nur so genau ein Ursprung gefunden werden kann.
Alternativ kann man die verschiedenen Stränge nacheinander abarbeiten und evtl. führen sie trotz Verzweigung zum gleichen Ziel.

Die wichtigste Regel ist, dass sich keiner von einer vermutlichen Problemlösung leiten lässt und die Fragetreppe in eine ganz bestimmte Richtung leitet.

Diese Methode der Ursache-Wirkung-Bestimmung ist wirksam, nur leider auch sehr anstrengend.

Viel Spaß damit!