Lessons Learned

Bakgrund

Under det sista åren har jag hållit i ett antal sittningar för Lessons Learned (den svenska termen är eventuellt erfarenhetsreflektioner). Redan i lumpen träffade jag på något som liknade Lessons Learned - då gick det under namnet heta stolen. Målet var att hitta något som var bra, något dåligt och något man skulle prova på. (Det jag minns av min utvärdering var att jag skulle tona ner den ganska grova humor jag hade då, och det har jag - men jag tror det dröjde innan jag fick barn till jag blev riktigt rumsren.)

Nu så här innan sommaren 2015 så handleder jag en sommarjobbare. Halvvägs in i hennes sommarjobb så tyckte jag det kändes bra att göra en avstämning, så vi gjorde ett riktigt seriöst retrospektiv. Då insåg jag att jag hittat ett mönster för Lessons Learned som jag ofta upprepar. Jag tycker det är bra så jag vill skriva ner det.

Recept

Roller

Jag brukar vara den som är sammankallande, moderator och sekreterare på mötena. Är man ett stort gäng är det kanske vettigt att sära på rollerna - när det är viktigt att jag är opartisk försöker jag i alla fall delegera rollen som moderator.

Förbered

Mina möten brukar vara ganska informella och inte följa agendan speciellt hårt. Däremot tycker jag om att gå tillbaka till agendan då och då för att se att man inte glömt något. Så för mig är det viktigt att jag förberett inför mötet - till exempel genom att ha gjort en agenda, plockat ut dokumentnummer om det behövs, skapat ett dokumentskelett med tomma rubriker, och ha en timme avsatt i kalendern.

Agenda

För att hitta en typisk agenda brukar jag fundera på vilka olika aktiviteter som projektet innehåller eller innehållit. Det kanske kan handla om Definition of Ready, de nya autotesterna som skrevs, hur designen och bygget av det nya testsystemet genomfördes, vilka möten man haft, hur kommunikationen fungerat, och så vidare. Det viktiga är att man har en massa punkter att prata kring. Agendan funkar för mig som en checklista - se Boken The Checklist Manifesto.

För varje ämne följer man sen mallen jag fick i lumpen, med några smärre justeringar, man pratar kring:

• Vad var bra? (eller: Vad borde vi fortsätta med?)
• Vad borde förbättras?
• Vad skulle vi kunna prova istället?
• Vilka överraskningar fick vi?
• Vilka hinder stötte vi på?

Inte alla punkter i projektet får kommentarer på alla ämnen.

Exempel

Utifrån samtalet jag hade med sommarjobbaren, och även utifrån erfarenheter från tidigare sittningar, så ska jag försöka ge exempel på saker som kommit upp.

• Vad var bra?
  • Arbetet har gått framåt.
  • Designdokumentet för X var bra - det formatet borde vi kunna använda när vi gör en sån nästa gång.
• Vad borde förbättras?
  • En grej som kom upp i samtalet med sommarjobbaren som jag lärde mig är att: allt är inte alltid lätt. Jag fick en aha-upplevelse av när en kollega kommenterade att jag sade till henne sagt att YAML var lätt. Det är lätt för mig. Nu. När jag jobbat med det formatet i ett par år. Det är inte lätt när man inte kan det. Så det var en attitydfråga som var en bra erfarenhetsreflektion för mig.
• Vad skulle vi kunna prova istället?
  • Här måste man ta tillvara på folks frustration. Om de säger att något är dåligt brukar de, om man bara får dem att vinkla om tankesättet, kunna kanalisera frustrationen till något konstruktivt.
  • Jag minns en diskussion om toalock som slamrade på kontoret. En kollega sade att folk var ouppfostrade och att man skulle satsa på att lära folk att stänga locken bättre. Jag föreslog att vi skulle köpa in långsammare lock som inte låter något.
  • En gång pratade vi om att vi ändrat oss många gånger om en viss lösning. Efter lite reflektioner kom vi fram till att vi inte förstod eller inte hade modellerat problemet tillräckligt. Lösningen blev en semistrukturerad session framför en whiteboard och lite dokumentation.
• Vilka överraskningar fick vi?
  • En klassiker är att "Oj, tar det fyra veckor att få hem prylen av typ X?" Av någon anledning lär man sig vissa saker väldigt långsamt.
  • En annan goding är att man missförstått vad kunden ville ha.
• Vilka hinder stötte vi på?
  • Till exempel att sätta sig in i nya filformat (typ YAML) eller tekniker (typ javascriptbaserade webbramverk).
  • Men också ibland saker som att prioriteter inte kommunicerats på tillräckligt bra sätt.

Se upp för

En sak som IEEE 1028 (se Metod För Formell Granskning) tar upp som även nämns i kursplanen för Istqb Foundation Certified Agile Tester är att man ska hålla mötet positivt och konstruktivt. Det gäller antagligen alla möten. Det är bra att undvika personangrepp.

Sammanfatta

När mötet börjar närma sig sitt slut brukar jag scanna över agendan och se om någon punkt har oväntat lite reflektioner, om vi skrivit saker på rätt plats och kanske dubbelkolla att deltagarlistan är komplett.

Sen brukar jag, och detta är en ganska ny lärdom för mig, försöka sammanfatta vad som var viktigast. Denna information måste till första sidan under någon form av rubrik som gör den lätt att hitta. Anledningen är att mellanchefer och chefer inte investerar sin tid på bästa sätt med att läsa alla detaljer i ett protokoll från Lessons Learned.

Att lyfta fram ett par punkter till närmsta chef blir då lätt - man copy/pastear från första sidan till ett mail.

Genom att tillsammans med mötets deltagare sammanfatta mötet så märker man lätt om mötet har konsensus eller inte.

Andra Test Closure Activities

När jag började skriva denna text funderade jag på vad ISTQB och min husgud Rex Black har för tankar om erfarenhetsreflektioner. Jag slog upp kapitel 2.7 i Boken Advanced Software Testing och hittade ett par tankar till.

Deras första budskap är att man borde göra fyra typer av aktiviteter när man avslutar ett test-projekt:

• Säkerställ att testningen är klar: En bra checklista är Definition of Ready/Definition of Done (se Boken Testing In Scrum)
• Undersök om testprodukter kan återvinnas: Ofta kan testscript leva ett liv efter projektet. Kanske behöver hårdvara man använt fixas till (dokumenteras) om de ska lämnas över från projektet?
• Delta i projektretrospektiv: Det är i princip det ovanstående text handlar om.
• Arkivera testartefakter: Stoppa in testscript, designdokument och så vidare i versionshantering till exempel.

Övriga tankar

Den stora anledningen till att jag började hålla sittningar med Lessons Learned var att jag stötte på det i den mall för testrapport som ingår i Software Testing Standard Iso Iec Ieee 29119. Det jag vill nämna här är inte att man alltid ska lyssna på vad ISTQB eller ISO säger, utan att man ska låta sig inspireras av hur andra tänker. Ibland håller man med, ibland håller man inte med, och ibland får man modet att prova något nytt om man hör att andra haft framgång med det.

Denna text ingår i Kategori Test
Denna text ingår i Kategori Mallar

Se också Metod För Formell Granskning