Jaime Gomez reflekterar om vad man ska tänka på när man vill införa SCRUM
Häromdagen gick jag till ett seminarium i Lund organiserad av SAST-Öresund. En av föreläsarna pratade om tendenser inom testing. En av de tendenserna är agila metoder i allmänhet och SCRUM i synnerhet. Det verkar oundvikligt att inte prata om SCRUM i dagens läge.
Jag ska inte prata i detalj om hur SCRUM är uppbyggd. Det är inte själva idén med den här artikeln. Men jag vill gärna prata om hur lätt eller svårt det är att göra övergången från en mer traditionell model typ vattenfall till just SCRUM. Löser SCRUM verkligen alla problem som finns med en vattenfallsmodell? Svaren för dessa frågeställningar är både ja och nej. Det finns inte möjlighet att ge ett rakt svar på den frågan, tycker jag. ”Det beror på” skulle jag säga.
Skillnaderna mellan SCRUM och traditionella modeller är stora. Skillnaderna börjar med själva filosofin som finns bakom. SCRUM är väldigt affärsinriktat. Det förväntar sig ett gott resultat och det ska visas snabbt. Därför ska det finnas en körbar version efter varje sprint. Detta är ett uppenbart problem med traditionella metoder. De tar för lång tid att producera software med god kvalitet. Men frågan kvarstår: kan verkligen SCRUM producera mjukvara snabbare med samma kvalitet? Mitt svar på det är att SCRUM har möjligheter att producera mjukvara snabbare än traditionella metoder, men bara
- efter en lång mognadsprocess av hela organisationen
- efter en anpassning av SCRUM till organisationens behov
Det går inte att improvisera. Att ändra från traditionella till agila modeller, t.ex. SCRUM, kräver en anpassningsprocess. Det är nödvändig att planera en införande av SCRUM med en övergångsfas där:
- en dubbelinriktade anpassasningsprocess sker där delar av organisationen anpassas till SCRUM och där SCRUM anapassas till organisationen
- en förankringsprocess planeras och exekveras bland intressenter på olika nivåer
SCRUM kräver en annan dynamik och ett annat tankesätt med alla intressenter, inte minst med testare som inte är lätt att förankra. Det kräver tid och en process med tydliga och mätbara kortsiktiga och långsiktiga mål för det. Varför ett annat tankesätt? Jo, SCRUM har andra roller som traditionella metoder inte har. Scrum Master är ett bra exempel. Det motsvarar en projektledare, men inte riktigt. Produktägaren har helt plötsligt andra befogenheter och kan i stor utsträckning påverka arbetet. Och sedan har vi resten av Scrum Team. De har större chanser att säga sitt och påverka, men de måste också arbeta snabbare och visa resultat.
Och var står Testare i detta sammanhang? Ett problem som jag ser med SCRUM är att det är väldigt programmeringsinriktat. Testaspekten har en tendens att försvinna eller åtminstone försvagas. Testledarens eller Testarens roll hör inte hemma i en standard SCRUM. Alla i Scrum team måste utveckla och testa. Frågan är om testdokumentation som vi vanligtvis är vana vid att producera, inte heller får plats. Jag tycker att det behövs en mer utvecklad SCRUM modell där testfrågor hör hemma som en naturlig del av utveklingsprocessen. Och här kommer ett påstående som kan vara kontroversiellt: standard SCRUM försvagar testarens roll och försummar testprocessen. Det verkar som om testkompetensen som en testare besitter inte spelar så stor roll i standard SCRUM. Alla kan testa hur som helst! Men min erfarenhet säger att testkompetensen inte växer på träd helt spontant. Det kräver tid och vilja att utveckla sig som testare. Vi behöver en annan sorts SCRUM där testing är lika viktig som utvecklingen, där testing interagerar med programmering med lika villkor och där hanteringen av testprocessen sker på ett effektivt sätt.
Kravlistan är ett annat nyckelbegrepp i en utvecklingsprocess. Utan tydliga krav är det större risk att leverera fel produkt. Traditionella metoder har stora problem med krav som ändras under utvecklingstiden. SCRUM kan hantera detta på ett bättre sätt, men problem med otydliga eller inkompletta krav kan inte lösas med att bara ändra utveklingsmetod. Det har att göra med hur noggrant kravspecifikatiosnlistan skapas. En Produkägare kan också göra ett slarvigt arbete med sin Product Backlog i SCRUM och problemet kvarstår eftersom utvecklarna inte riktigt vet vad de ska utveckla. Jag tänker ta en lite mer ingående reflexion om detta intressanta ämne vid ett kommande tillfälle.
Det är dags att arbeta proaktivt och ta initiativ för att lyfta upp testaspekten i SCRUM. Man kan se olika initiativ i denna inriktining. Några projekt skapar till exempel en Test Sprint efter en Utvekling Sprint. Detta går emot SCRUM principerna eftersom man inte kan ha en körbar applikation precis efter varje sprint, men man återfå fokusen på testet och på längre sikt finns det bättre förutsättningar för att mjukvarukvaliten är acceptabel. Det finns exempel på organisationer där man börjar införa olika sorts ”definition of done” i ett SCRUM projekt: definition of done för en sprint, definition of done för en aktivitet, definition of done för en user story, definition of done för ett testaktivitet, definition of done för en bugfix, osv.
Det går inte att förneka att SCRUM har flera fördelar, bland annat att produktägaren eller beställaren är mycket mer involverad från första början i hela produktionsprocessen. Vi kan utöka fördelarna med SCRUM genom att börja testa så tidigt som möjligt. Vi kan börja med testet tidigare än i en vattenfallsmodell i alla fall, och det gör att fel och avvikelser kan upptäckas tidigt. Test Plan har en annan karaktär i agila metoder. De är väldigt dynamiska där det inte finns plats för detaljer eller rigurositet. Exploratory Testing är nästan ett naturligt verktyg i agila metoder. På detta sätt, med kreativitet, kan vi anpassa SCRUM till vad en organisation behöver. Var inte rädd för att förändra standard SCRUM. Anpassa verktyget efter organisationes behov och inte tvärtom. Detta är ett mycket vanligt fel när man börjar arbeta med SCRUM. Man vill introducera SCRUM i punkt och pricka utan att analysera konsekvenserna för hela organisationen.
Jag tror inte på den perfekta testmodellen. Däremot tror jag på den perfekta kombinationen av olika metoder och verktyg för att åstadkomma ett bra och professionellt resultat. Och det är där, i det sättet av hur man kombinerar saker och ting, där testledarens skicklighet sätts på prov.
För att sammanfatta:
- Satsa inte allt på bara SCRUM. Analysera vilken typ av agila eller icke agila metoder som passar in i din organisation och använd den bara när det behövs.
- Försök inte att använda SCRUM till alla typ av projekt. Det är som om en snickare alltid skulle använda en hammare som enda verktyg för att tillverka ett fönster. Det skulle vara otänkbart! Varför vill man på IT-branschen endast använda SCRUM? Det går helt enkelt inte!
- Analysera konsekvenserna för din organisation om ni inför SCRUM. Vad händer om experimentet misslyckas? Förbered en plan för att minimera riskerna.
- Sätt mätbara och realistiska mål när du vill införa SCRUM.
- Var öppen för att ändra standard SCRUM till en modell som passar din organisation. Tillåt inte en ”polis SCRUM”-attityd bland dina medarbetare. Det som är viktigt är inte själva SCRUM utan att en iterativprocess berikar arbetsättet i din organisation
- Förankra det nya processen på olika nivåer i din organisation.
- Använd ett litet eller medelstort projekt för att ”provsmaka” i verkligheten din agilmodell. Utvärdera resultatet, identifiera och åtgärda de svaga punkterna. Om SCRUM inte passar, lägg det vid sidan om och leta efter en annan modell.
- Slarva inte med kravlistan eller Product Backlog. Det har negativa konsekvenser.
- Använd kompetensen som ditt testteam besitter. Det gynnar alla.
- Du får vara beredd att använda Exploratory Testing. Det är den mest effektiva sättet att testa och dokumentera agile.
Bra och utförlig beskrivning av Jaime om införande av SCRUM. En helt riktig slutsats är denna om att rollen Test/testledare/QA har försvunnit eller definerats om. Liksom många andra förutom Jaime, så ska man ju se SCRUM som en metod och arbetssätt som fungerar bra, mindre eller inte alls beroende på situation och projekt. Alla vill ju lära sig och förstå nya verktyg som alla talar om. Liksom Jaime delar jag upfattningen att ta de delar som är användbara i kombination med andra. Morgonmöten och PostIT lappar arbetade jag med på 80- 90-talet. Det är inget nytt. Men tack säger jag till SCRUM som har blåst liv i detta arbetssätt igen
Intressant artikel. Du ta upp en del faror med att gå över från en vattenfalls modell. Du väljer att skylla på Scrum för dessa. Lite orättvist att säga att det är Scrums fel tycker jag. Det är viktigt att ha i åtanke att Scrum är en projektstyrningsmodell inte en utvecklingsmodell. Det finns lika lite beskrivet hur utvecklingen ska ske i sprinten som det finns hur testningen ska utföras. Det är inte att man glömt bort det eller inte har kunskap om det utan det ligger inte inom scopet för scrum att beskriva hur det faktiska utvecklings/test arbetet ska utföras. Det räcker inte att bara införa Scrum utan man måste fylla på med utvecklings och test modeller så som tex XP, Lean, FDD, TDD, Agile test principer , Exploratory Test eller vad man nu tycker skulle passa bäst. Utan att ha gjort det uppkommer många av dom problem du tar upp i artiklen.
Det är viktigta att inte likställa Scrum med Agile. Du kan vara agil utan att använda Scrum och du kan vara ”oagil” trots att du använder Scrums principer.
Att säga att man inte värderar testningen i Scrum tycker jag är direkt felaktigt då önskad Kvalite har högsta prioritet och aldrig är något man tummar på.Detta står tydligt i Scrums principer.
Man säger att ett Scrum team ska vara självförsörjande alså klara utföra teamets uppgifter utan extern hjälp. Det innebär inte att alla ska kunna allt. Utan att teamet som helhet ska ha den kompetens som man behöver för att klara sig själv. Testkompetens får mycket väl plats inom ett scrum team och har en naturlig roll tycker jag. Det är rätt att det inte finns någon definierad testar roll men det finns ju inte heller någon definierad utvecklar roll. Utan man är ett team med de roller som krävs för att utföra uppgiften, vilka de rollerna är och balansen där emellan beror ju på vad det är man ska göra i sprinten.
Jag håller med dig i att oavsätt vilken metod eller modell man väljer att använda sig av så måste men ta hänsyn till rådande förhållanden i just den organisation man verkar i. Dock så skulle jag gärna se att fler faktiskt provade att implementera Scrum och tex XP ”fullt ut” innan man börjar göra avsteg från principerna. Mycket av problemen som många upplever uppkommer just av anledningen att man bara tar och väljer dom bekväma delarna och ligger sen kvar med sitt gamla med annat. Det brukar sällan vara en lyckad kombination. Det är då bättre att implementera lite för mycket och sen upptäcka vad som inte fungerar och justera det då än att gissa sig till i förväg vad som är bra och vad som är dåligt. Här fyller retrospektiven en väldigt viktig funktion.
”Det är dags att arbeta proaktivt och ta initiativ för att lyfta upp testaspekten i SCRUM. Man kan se olika initiativ i denna inriktining. Några projekt skapar till exempel en Test Sprint efter en Utvekling Sprint. ”
Detta är inte proaktivt utan reaktivt. Man tar på sig för mycket utvecklingsarbete under sprinten så man hinner inte testa så mycket som man önskar och därför är man tvungen att lägga in Test sprintar. Ha alltid som mål att hinna med alla aktiviteter inom sprinten, då får ni ett bra flyt över tiden och tillfredställelsen av att känna att ni blir klara med saker och ting.
Så jag tror inte att det är så att Scrum behöver uppdateras för att innehålla mer. Vill man ha mer så finns det ju andra modeller man kan använda sig av tex RUP.
Det viktiga är att man inte bara implementerar Scrum och tror att man av den anledningen är agil. Scrum är en management modell och innehåller inte några utvecklings eller test principer, dom måste man kompletera med själv. Och bara för att man fyller på med andra modeller och metoder så innebär inte det hella av automatik att man är agil. Agile är i mitt tycke ett förhållningsätt till hur man agerar. Där man baserar sitt agerande på människor och komunikation.
Bra Jaime, skönt att någon vågar ta upp den andra sidan av scrum. Scrum har varit så hett det senaste året så det har känts som att ingen har vågat kritisera metoden över huvud taget. Jag känner igen mig i precis allt som du skriver. Min uppfattning är också att det är mycket fokus på utvecklingen inom scrum. Under RUP-eran var utvecklingen inte alls i centrum på samma sätt och jag tror det är därför som scrum fått sådant genomslag. Det har blivit lite av utvecklarnas revansch. Mycket är bra (om än kanske inte särskilt nytt) i scrum men vissa saker känns lite naiva. Jag håller definitivt med om scrum skulle må bra av att tänka mer på testaspekten.
I de scrumliknande projekt jag varit testledare i så har det alltid slutat med att man får testa i efterkommande sprint. Visst, utvecklarna genomför sina tester inom sprinten och har man automatiserade regressionstester så hinner man kanske köra dessa men mer än så hävdar jag är helt omöjligt att hinna med på en treveckors sprint. Några provskott på det nyutvecklade inom sprinten, mer djupgående tester fortsätter man med i efterkommande sprint.
Sedan läste jag Henriks kommentar och måste erkänna att han nog också har en del poänger. Det är säkert så att många, kanske omedvetet, bara använder sig av de bekväma delarna i scrum och på så sätt inte får ut max. Så har det säkert varit för mig också i mina scrumprojekt. Men känslan finns ändå kvar där, känslan av att man inte är i mål ännu. Det behövs mer finslipande på modellen och hur man arbetar med scrum innan jag är övertygad om att det är så man ska arbeta med systemutveckling.
Scrum är fortfarande ett väldigt hett ämne och rör upp väldigt många känslor. Jag förstår Jamies skeptisism men mina egna erfarenheter och reflektioner säger något annat.
Första utmaningen vi står inför anser jag vara alla förutfattade meningar och felaktiga antaganden angående scrum. Att man t.ex. inte behöver dokumentera eller skriva ordentliga krav. Detta får vi slåss hårt för i organisationen och det kan göra att det känns motigt. Vi skyller på Scrum för att det saknas dokumentation men det är inte metoden/ramverkets fel utan missuppfattningar om vad Scrum är. Vi ska absolut inte sluta dokuemtera eller skriva ordentliga krav bara för att vi kör Scrum!
En annan utmaning är att man inte kör 100% Scrum. Enligt mig är det inget alternativ att köra 70% Scrum. Du tappar hela idén med Scrum om man inte tar allt. Utveckla i så fall en egen metod istället för att säga att man kör Scrum. Jag har sett organisationer som inte tycker att dom behöver någon product owner (deras scrumprojekt fungerade inte så bra och föll så klart på back log-arbetet), jag har sett organisationer som vägrade göra en burn down chart på hela scopet för projektet (all deras långsikta planering föll och man hann inte med allt man ville. Felaktiga prioriteringar gjordes av product owner), jag har sett organisationer som vägrar ha test i teamen utan driver all test i en separat organisation (kvalitén ut ur sprinten blev så klart låg samt att Scrum teamets arbete och testorganisationens inte höll samma takt och felrättningar störde teamet). Nej, ska man köra Scrum så kör det till 100% och ta reda på vad som verkligen är Scrum! Jag har hört många som sågar Scrum vid fotknölarna i samma mening som dom säger att dom kört en variant av Scrum. Hur kan man såga en metod om man inte använt den helt ut?
Den sista utmaningen jag vill ta upp här är synen på test.
Som Henrik skriver “Det är rätt att det inte finns någon definierad testar roll men det finns ju inte heller någon definierad utvecklar roll.” Tänk på detta! Av någon anledning har utvecklarna tagit till sig denna metoden medan testare avskyr den och skyller på att det är en metod endast för utvecklare. Detta tycker jag är oansvarligt. Är det inte dags att vi testare formar vårt sätt att arbeta så att det fungerar i ett Scrum team?!? Att vi, på samma sätt som utvecklarna, tar metoden till oss och ser hur vi kan arbeta. Det gäller att tänka nytt och inte hålla kvar det mer traditionella sättet att testa. Tyvärr är det ofta så att missuppfattningen om att Scrum är en ren utvecklarmetod finns högt upp i organisationen och det kan försvåra det för test att bli inblandade och bli en lika självklar del i teamen som utvecklare. Men ge inte upp och börja skyll på metoden, det är bara att kämpa på och de projekt jag varit på har man varit oerhört tacksamma för att man haft test med!
Sammanfattningsvis, jobba intensivt med att förklara vad Scrum är och inte för alla i organisationen för att motverka alla missförstånd, kör 100% och ta ansvar för att Scrum ska vara lika mycket för test som för utveckling!
Intressant artikel och bra kommentarer!
Att gå mot att jobba inkrementellt kräver stora förändringar i vårt tankesätt som testare. Att samtidigt ingå i ett team á la Scrum där alla är ansvariga för kvalitet är också nytt. Att få jobba tightare med utvecklarna där man faktiskt samarbetar är för många också nytt. Att jobba tillsammans med produktägare i framtagning av kraven är också nytt för många. Att få testa tidigt och mycket är också främmande. Allt detta tycker jag är underbart!
Jag anser att QA, som i Quality Assurance, inte en helt naturlig roll i det här. Däremot är QA, som Quality Assistance (Läs Ongoing Revolution of Software testing av Cem Kaner), är en väldigt intressant för teamet.
Om man känner sig osäker på vilken roll man faktiskt ska ha så kan jag rekommendera att börja med att skapa en SLA (eller motsvarighet) där man går igenom vilka tjänster som man kan bidra med till gruppen. Det kan samtidigt vara intressant att visa tydligt att man inte behöver gå hela vägen varje gång i testprocessen. Ibland kanske det kan räcka med att man levererar tester och testresultat på en post-it lapp eller ett email, medan i andra fall vill via ett buggsystem.
Om vi ska överleva i en agil miljö så anser jag att man måste släppa kvalitetspolis-attityden och istället angera som en kvalitetsexpert och en teamplayer med hög flexibilitet. Om vi inte lyckas sälja våra tjänster i vår egen grupp kan vi ju fråga oss om vi behöver vara med eller istället sätta oss att fundera över varför vi har ett jobb just där?
Oavsett om man jobbar inkrementellt eller i vattenfall så går det att planera sitt arbeta inkrementellt och samtidigt agera som en service för projektet. Jag anser att det handlar mer om attityd till testning.