krav och test
Testaren som agil coach – från kval till kvalitet
Det agila projekttåget är i rullning. Men det går för långsamt. Något i projektet har sannolikt gått snett, men ingen verkar veta vad som behöver göras. Det är nu vi agila testare måste ta plats som coacher – i förarsätet. Här kommer argumenten till varför.
Du sitter som ensam testare i ett anonymt mötesrum med ledningen. Du kan svagt höra ljudet från det agila projekttåget strax utanför rummet. Det rullar redan. Ledningen förklarar för dig att projektet överväger att ta in en testare. På frågan om vilken utvecklingsprocess som används händer plötsligt något märkligt. Ledningens annars så självsäkra attityd förbytts till flackande ögon, obekvämt skruvande på stolen, och svaret blir: ”Vi arbetar, hm, agilt, ungefär”, eller kanske ”Vi jobbar scrum-ish”. Känner du igen dig? Du är inte ensam.
Om projektet hade gått enligt plan hade antagligen självsäkerheten varit i topp, men nu är det inte så. Något skaver på självförtroendet. Något i projektet har högst sannolikt gått snett. Tåget rullar långsamt. Det är här du som erfaren agil testare måste marknadsföra dig inte bara som testare, utan även som agil coach!
Varför är då en erfaren agil testare bra på coachning i ett stormigt projekt frågar man sig, kanske rentav lika bra som en renodlad projektcoach? Svaret är enkelt. Testdesign och exekvering kommer ofta in som aktiviteter i slutet av en lång process. Alla problem på vägen, från otydliga önskemål hörda på en kundträff till trasslig kod, ansamlas och synliggörs likt en perfekt storm hos testaren. Stormen avtar inte, utan blir allt värre i takt med att den tekniska skulden och berget av buggar ökar. De flesta agila testare är frispråkiga, envisa och ryggar inte för en kamp i motvind. En testare i denna situation ger inte upp sin kamp för förbättringar i första taget. Är problem självupplevda och dagliga kommer i alla fall inte testaren att låta dem sopas under mattan i första taget!
Den som varit mitt i stormen ett flertal gånger är en person värd att lyssna på. Sannolikt har testaren erfarenhet sedan tidigare, och kan träffsäkert identifiera både orsaker och beprövade förslag att coacha projektet med för att rida ut stormen även denna gång!
Låt oss ta några exempel på vanliga orsaker till stormiga projekt :
Detta var bara några exempel på hur den agila testaren ofta per automatik och utan att reflektera djupare hjälper till att coacha och få det agila projekttåget på banan igen. Varför pratas det då inte mer om detta? Jag tror att vi testare helt enkelt är för dåliga på att marknadsföra oss själva. Handen på hjärtat, vet de som håller i pengarna om att vi gör så mycket mer än att bara skriva felrapporter? Gör de inte det har vi faktiskt hittat ett nytt fel – hos oss själva.
Varför inte sätta upp en mognadsstege liknade CMMI på den agila projekttavlan eller bifoga den till ledningen i din månatliga testrapport och visa på de stegvisa förbättringar test tillför projektet? Gör du det rätt, så sitter ni nog mångdubbelt fler testare i det där anonyma mötesrummet nästa gång. Ledningen kommer att få en insikt och ett helt annat förtroende för utvecklingsprocessen då test öppnat och visat på innehållet i den agila verktygslådan genom sina förbättringsinitiativ.
Kan då något gå fel då med agil coachning som bedrivs av testare?
Ja, så klart. I retrospektivmöten kan problem som identifierats av testare konsekvent röstas ned i demokratisk anda (ofta är utvecklarna i majoritet och röstar kanske enbart på ”sina” isolerade problem). Risken är att viktiga processförbättringar därmed fördröjs ”tills dess att snöbollen blivit en lavin”.
