Handskakningen

"Hörruduru Jens, peta inte i syltburken. Säg bara vad som är problemet så löser vi det. Du behöver inte vara här och komma med detaljerade förslag på lösningen". När jag började som ny produktägare fick jag denna kommentar vid ett tillfälle. Jag fattade direkt vad de menade, och insåg att jag petade i mitt teams arbete lite för mycket.

Lite senare på samma företag hörde jag från några andra team att de fick "one-liners" av sina projektledare och beställare, och de inte fattade vad som behövde göras, "kraven är för luddiga, vi vet inte vad vi ska göra". I detta fall så fick de en mening skriven i en Excel, och teamet hade svårt att förstå vad som behövde göras, och varför de skulle göra just denna sak.

Har du varit med om följande?

• Du arbetar som produktägare, intressent eller beställare och när beskriver vad du vill få gjort så får du höra av teamet att kravet är antingen för luddigt eller för detaljerat?
• Du arbetar i ett team, och en produktchef, beställare eller intressent kommer med en lösning som de vill få gjort?
• Du arbetar i ett team och det är svårt att förstå vad som behöver göras, och alla har sin egen bild av vad som är problemet och lösningen
• Du arbetar som chef, ledare eller intressent, och när du behöver få en samsyn kring något som behöver göras, märker du att alla du pratar med har olika syn kring problem och lösning.

Fortsätt att läsa genom att logga in eller bli medlem (det är gratis)

Ibland när jag är ute och arbetar hos kunder, märker jag att det saknas något strukturerat sätt att arbeta med överlämning eller handskakning 🤝  I denna text beskriver jag hur du på ett enkelt sätt kan arbeta med detta, oberoende vart du sitter i ditt företag och hur du arbetar.

Dokumentation är ju inte roligt, det tycker nog de flesta. Jag brukar säga att dokumentation är ett resultat av avsaknad av samarbete. Främst när det kommer till att vi behöver förklara något som behöver blir gjort. Min tes är att ju mindre tillit och ju längre jag sitter från någon som ska utföra något, ju mer dokumentation skapar jag. Om jag sitter i ett team och vi jobbar nära varandra, så behövs det mindre dokumentation, och mycket kan lösas genom att prata och visa hur jag tänker. Ibland behöver vi ingen dokumentation alls för alla ska veta vad som behöver göras.

Om du har vana att arbeta i agila produkt-team så har du säkert en erfarenhet att arbeta med User Stories. Detta är en kort beskrivning kring vad som behöver göras och innehåller

• Användare — den som berörs av förändringen
• Önskan — vad vi vill att användaren skall kunna göra eller få stöd med
• Mål — det förväntade utfallet när vi levererat vårt arbete

Det  jag har erfarenhet av är att på en taktisk eller strategisk nivå så saknas det ofta en struktur, metodik eller en process för att beskriva vad som är problem och en möjlig lösning. Ofta behöver vi samarbeta runt ett gemensamt dokument för att beskriva något som vi vill få gjort.

Precis som på operativ teamnivå där du skriver User Stories kan du göra samma sak fast på taktisk nivå. Enda skillnaden är att du inte är lika detaljerad och granulär, utan målar med det stora penslarna.

Så hur kan detta då se ut? Jag har nedan listat ett antal frågeställningar som behöver besvaras för att alla ska ha en bättre förståelse kring problem och lösning. För att få svar på dessa frågor behöver du ofta prata, diskutera och samarbeta med flera andra i din organisation. Samarbete och kommunikation är viktigt och jag vill trycka på vikten att involvera, och transparens enligt de agila principerna. Vi vill ju inte ha en massa dokument som mejlas runt, eller hur?

Nedan har jag beskrivet ett antal frågor som är en bra start. Det som är viktigt är att ni är överens i er organisation kring vilka frågor som behöver besvaras för att göra en handskakning så bra som möjlig. Jag vill även trycka på att detta dokument är levande, och att det behöver uppdateras över tid då vi lär oss mer kring problemet och lösningen ju längre vi arbetar.

Frågor att besvara

• Vad är en kort sammanfattning som förklarar vilket problem vi försöker lösa och för vem?
• Vad är bakgrund och kontext?
• Hur kopplar detta till vår vision, mission, affärsplan eller övergripande planering?
• Vilket problem eller möjlighet ser vi?
• För vem ska vi lösa problemet?
• Vad kan vara en möjlig lösning?
• Vilka mål och effekter är vi ute efter att realisera?
• Hur mycket tid borde vi lägga på detta? Hur länge eller stort är detta arbete?
• När vet vi att vi är klar och lyckats?
• Vart hittar jag mer information kring detta?
• Vem har varit med och arbetar fram detta?

Visualisering och mall

Nedan är ett exempel på en visualisering hur det skulle kunna se ut. Du kan använda Powerpoint, Word, Teams, Jira, Confluence eller nått annat verktyg som hjälp för att få en handskakning. Det bästa är ju när detta dokument eller information finns online, så det blir enklare att samarbeta i samma dokument.

Nu ligger allt på en sida vilken kanske inte möjligt. Men som jag skrev innan, ju närmare du jobbar teamet ju mer kommer du behöver beskriva vad som behöver göras.

Tips

• Samarbete — Jobba inte ensam utan involvera dina intressenter och de som utföra arbetet
• Gemensam standard — Se till att ni är överens om vilka frågor som behöver vara besvarade. Då slipper ni ha en diskussion över vad som är för detaljerat och eller luddigt
• Levande — Arbeta kontinuerligt med att uppdatera dokumentet och se det som levande
• Tid — Avsätt tid för att prata och arbeta med dokumentet. Agila team har något som de kallar för refinement möte där de arbetar med att just förfina sin arbetslista (backlog) och User stories. Om du arbetar på taktisk och strategisk nivå behöver du göra samma sak
• Möjliga lösningar — Jag tycker det är bra att ha med möjliga lösningar i detta dokument. Jag skriver möjliga lösningar för att ha något att prata kring. Ofta vet teamet bäst men se det som ett underlag till diskussion. Det kan vara en kort text t.ex. "En mobil app som visar status". Det kan också vara en grov pappersskiss för visualisera dina tankar. Kom överens med de du arbetar med vad som är en rimlig nivå.
• Storlek — Kom överens vad storlek betyder. Ofta är detta en grov uppskattning, helst i början innan vi vet vad vi behöver göra. Jag brukar använda Small, Medium, Large och X-large. Prata ihop er vad dessa betyder i storlek, t.ex. att Large betyder en månads arbete för teamet.

Sammanfattning

Handskakningar behövs  på alla nivåer, inte bara på operativ teamnivå. Se till att hitta en process, metodik och mallar som hjälper dig och er. Försök att få flera att samlas kring vad som är viktigt, vad som är ett måste och vad som bör vara med. Genom att prata och få samsyn kring handskakningen kan du komma ifrån utmaningen att inte behöva peta i syltburken eller att du är för vag kring ett behov eller krav.

Är det några andra frågor som du tycker borde vara med som bör besvaras för att få till en handskakning?