Göra rätt saker, sakerna rätt och sakerna på rätt sätt - tre dimensioner av krav som vi fuskar med
Foto av Staff Sgt. Michael Battles
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.)
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 och detta verifieras senare vid effekthemtagningen då kunden sagt sitt efter att använt funktionen i skarp miljö. Dock kan ofta detta inte ske förrän långt efter releasen då man börjat använda funktionen effektivt. Man kanske måste ändra sitt 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. Om vi applicerar det till min metafor här, piloten, 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.
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äscheten 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 och det finns det ju oftast inte. Tillbaka till min pilotmetafor och se det som den checklista med processer (ex försäljning av taxfree) du kryssar i tillsammans med din crew innan ni lämnar planet för avslutat arbetspass. Förväntningarna från kunderna (features) och säkerhetskraven (regulatoriska krav) är då uppfyllda.
Så långt allt väl men att sedan knö in att 3. 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. Som pilot spelar det ingen roll hur många flygtimmar du har 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.
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
/Ove Holmberg, Knowit Require
