Göra rätt saker, sakerna rätt och sakerna på rätt sätt – tre dimensioner av krav som vi fuskar med

Reading Time: 5 minutes

Nyligen hjälpte jag en startup med kravhantering. Det gick inget vidare då chefen ändå smög in brådskande nya features på post-it lappar och jag kunde inte förstå varför teamet jobbade sena kvällar.

Före det hjälpte jag ett 100 årigt gediget svenskt tjänsteföretag med att, bland annat, coacha produktägarna. Det gick heller inget vidare då produktägarna inte hade tid och behövde sköta sitt riktiga jobb.

Så vad förenar dessa två helt olika organisationer om vi håller oss till krav? Jo, bägge företagen fuskade grovt med flera rubricerade dimensioner av krav (och en hel del annat) och här är min spaning hur dessa kan skapa ett fundament för bra krav. (Givetvis har jag feedbackat detta till respektive företag men det tål att tas upp igen.) Varning dock för att det är svårt att skilja dessa tre dimensioner från varandra men det är syftet med detta inlägga att försöka förklara det på ett pedagogiskt sätt.

1. Att göra rätt saker är att säkerställa att vi levererar rätt värde med rätt timing. Först gör vi en bra ranking* av våra backlog (aka refinement) och detta verifieras senare vid effekthemtagningen då kunden sagt sitt efter att använt funktionen i skarp miljö. Detta kan ofta inte ske förrän långt efter releasen då man börjat använda funktionen effektivt. Man kanske måste ändra sitt sätt att arbeta för att nyttan ska uppstå och det kan ta tid. Frågar du mig så är effekthemtagningen det sista steget i Definition Of Done på funktionsnivå men tyvärr är det mer regel än undantag att man skippar effekthemtagningen och tror att allt som är releasat är bra skit. Statistiken säger att två av tre funktioner inte används. Det krävs stor disciplin för att göra rätt saker och det är produktägarens ansvar.

Om vi applicerar detta på en metafor, flygresan, så innebär det att starta och landa på annonserad tid och under tiden inte flyga genom åskväder eller att lasta planet med jordnötter. Dvs planen för utförandet av resan.

Min rekommendation här är att ha en väl definierad discovery process med tydliga steg i en egen kanbanbräda där sista steget är att uppfylla Definition Of Ready innan det rinner över på delivery processens egen bräda som ju slutar med Definition Of Done (där INVEST kan vara en ledtråd). Här är det bra om DoR är generell för alla epics i företaget så samarbete över värdeströmmarna kan underlättas men specifik för varje story så teamet som ska utföra arbetet äger sin process. En varning är dock att DoR kan bli en stoppkloss i ditt flöde i stället för en överenskommelse för kvalitet. En stor fördel med DoR är dock att det skapar en möjlighet för teamet att kunna säga nej till skräp som kommer ovanifrån.

2. Att göra sakerna rätt är att acceptanskriterierna är uppfyllda, dvs vi har producerat funktionen i linje med kraven förväntningarna. Här märker jag alldeles för ofta att acceptanskriterierna skrivs på tok för sent. Just in time är ett begrepp som tolkats till att man ska krava den dagen funktionen ska implementeras för att säkerställa fräschheten i kravet. I realiteten innebär det att man får en user story och inget mer samma dag som sprintplaneringen. Här måste utvecklarna steppa upp och känna yrkesstolthet och vägra utveckla något som inte uppfyller INVEST kriterierna. Hur ska du som utvecklare annars veta vilka förväntningar som finns? Och framför allt måste du vägra estimera skiten, förutsatt det finns säkerhet inbyggt i din kultur, men det finns det ju oftast inte.

Tillbaka till min flygmetafor och se det som den checklista med förväntningar som löser ut (ex billig taxfree, landa på tid, bra benutrymme etc) som flygplansbesättningen kryssar i innan ni lämnar planet efter avslutat arbetspass. Förväntningarna från resenärerna (features) och säkerhetskraven (regulatoriska krav) är då uppfyllda.

Min rekommendation här är att likt discovery, ha en väl definierad delivery process med tydliga steg i en egen kanbanbräda där sista steget är att uppfylla Definition Of Done innan det rinner över på BAU processens egen bräda.

Ett tips på en bra formulerad förväntning om det handlar om en user story är att använda formatet Given/When/Then:

Given i as a traveler has stepped off the plane, when i think back on the trip, then i had no incidents with air bumps, deviations or other safety aspects.

Med detta format berättar du en story och ett tidsförlopp vilket ger en bättre känsla för hur nyttan skapas. Har man ett krav/task/uppgift (ej story) så har man bara en klassisk checklista med saker som ska uppfyllts. Det är detta som skrivs först i förväntningen och sedan testas innan den är klar.

Du måste även formulera förväntningen så vi förstår varför vi ska göra detta. Här kommer user storyn in:

As a traveler i need to have a safe flight so i get a great start on my vacation.

Styrkan med user storyn är att den pratar ur en användares perspektiv varför den behöver någon men inte hur. Det ger oss spelrum för innovation.

3. Att göra sakerna på rätt sätt blir svårare, men om vi tänker på Definition Of Done som listan på processer/steg som den blivande funktionen måste ta sig igenom för att bli ”färdig”.  Allt för ofta har teamet en DoD men i nio fall av 10 så följs inte den. Man skippar gärna det där med kodgranskning och dokumentation som vi lovat varandra och ut kommer ett fuskbygge som endast möter det estimat vi i något svagt ögonblick lovat. För när vi estimerade tog vi ju inte med dokumentation? Jag kallar detta för att ha goda vanor. Tyskarna kallar det för disciplin eller ordnung, något vi agilister ser som negativt men som erfarna ser som nödvändigt.

Åter till metaforen flygresan, så spelar det ingen roll hur många flygtimmar du har som pilot om du inte följer checklistan vid start och sedan ser till att passagerarna får en behaglig resa. Innan du stiger av lämnar du över till näste pilot.

Exempel på en DoD vid systemutveckling är

  • Dokumenterad
  • Incheckad
  • Kollad och godkänd av annan teammedlem
Toppen på kravisberget, jag föreläser och utbildar gärna kring detta.

En gång försökte jag coacha en produktägare av den gamla skolan i ovanstående men hon blandade friskt i begreppen ovan vilket fick till följd att förvirringen var stor och ingen förstod vad som var vad. ”Lekskola” var hennes svar på mina försök trots att hon en gång jobbade på ett bolag som konsultade kring kravhantering. Som coach får man ge sig om de gamla rävarna inte vill lära sig så jag gav upp och backade ur teamet med ett ”lycka till”. Det skulle gå två år innan de levererade någonting.

Slutligen, om du applicerar dessa tre dimensioner som kvalitetssäkring av krav så är jag övertygad om att din organisation – ung som gammal, liten som stor, statlig eller privat, platt eller inte, kommer att skapa bättre nytta och i förlängningen gladare aktieägare/medborgare/kunder. Eller som vi sa i lumpen, på rätt tid och plats med rätt utrustning. Och för att passa i treeningheten här så skulle vi även haft med på rätt sätt.

*) Ranking = prioritet/ansträngning

Länk till mindmappen

Se även kursen för detta här

Håller du med? Eller inte? Diskutera här...