I webbradion kan man höra mig berätta om hur man jobbar agilt i webbprojekt med hjälp av Scrum-metoden. I anknytning till den intervjun och för er som funderar på att börja använda metoden tänkte jag nu presentera min syn på de vanligaste fallgroparna när man jobbar med Scrum.

5-7 personer är optimalt i ett Scrum Team
  1. Är ni redo för scrum? För att passa för scrum måste man våga prata med varandra, be om hjälp och lära sig teamwork och parprogrammering. Scrum är perfekt för att införa en ny och öppnare arbetskultur!
  2. Ovana vid att estimera. Hur långt är ett snöre? Alla som har jobbat i IT-projekt vet att tidsuppskattning är det svåraste och ofta viktigaste steget innan utvecklingen kan starta. I Scrum underlättar man tidsestimeringen genom att spela Planning Poker. Det är roligt och gör att man hjälper varandra att hitta troligast möjliga tidsåtgång.
  3. Ingen jobbar 100%Ingen utför en 8-timmars uppgift på 8 timmar. Utgå ifrån att effektiv arbetstid är ca 75% om dagen, och lägg utifrån detta till ca 25% i tidsuppskattningen.
Planning Poker deck
  1. Frånvarande produktägare. Det klassiska misstaget är att produktägaren (kunden) är frånvarande vilket är förödande för Scrumprojekt. Men så länge man internt utser en person som kan ”täcka upp” för produktägaren och fatta beslut i dennes ställe så behöver det inte bli några problem.
  2. Avsaknad av kompetensDet är svårare att lyckas med Scrum om det inte åtminstone finns ett par utvecklare med erfarenhet av Scrum med i projektet. En annan stor sårbarhet i Scrum är dessutom att byta ut personer i teamet under projektets gång.
  3. Brist på disciplin. Scrum kräver disciplin i teamet som är mycket mer självgående än i traditionella projekt.Tidsuppskattningar, metodval och problemlösning är enbart upp till personerna i teamet. Det får inteförekomma några förändringar i backloggen under en sprint och någon måste också löpande övervaka att man håller budget.

    Scrum board
  4. Ser inte, hör inte. Se till att teamet har både närhet till varandra, till Product backlog, Burndown chart, Scrum board och till produktägaren (som gärna får besöka teamet någon gång i veckan) När som helst måste teamet kunna se, flytta, röra, ändra, överblicka och helst ”känna” på projektet. Post-itlappar eller andra fysiska visuella avbilder är att föredra framför Exceldokument och Powerpoints. Men det finns digitala verktyg som imiterar en whiteboard med postit-lappar, testa Scrumy.com. Och glöm inte att prata med varandra!
  5. Ingen tid för design och testDesignarbete och test är svårt att planera in i en sprint. Design för att det är en inleverans som inte mår bra av att delas upp i små items utan levereras i ett stycke. Och test för att det behövs ett koncentrerat fokus för att gå till botten med fel. Hantera design som en separat inleverans innan projektet startar. Gör sedan HTML stories för varje sidmall och låt HTML-utvecklaren beta av sida för sida. Eftersom frontend går snabbare kommer förhoppningsvis motsvarande HTML att vara klar innan backend påbörjas. Lägg in en- eller två dagars test och buggfix i slutet av sprinten för att åtgärda allmänna fel och beroenden som inte fångats upp i det löpande testandet. Ha korta hellere än långa sprintar. Om buggar upptäcks tidigt är de billigare och enklare att åtgärda.
  6. Ineffektiva Daily ScrumsScrum Mastern måste se till att det dagliga mötet inte blir en lägesrapport utan en tidpunkt för att identifiera problem och öka produktiviteten. Det gäller även kravspecning och förtydliganden. Om de tar längre tid än 30 sekunder ska de förläggas till efter att mötet är avslutat. Mötet bör hållas vid en tidpunkt bekvämt för alla. Man får inte glömma att nämna vad man ska arbeta med under den kommande dagen, och att inte skämmas för att be om hjälp eller att berätta när man kört fast.
Scrumy.com
  • Felprioriteringar. Det är positivt att skyffla om, ta bort och tänka till. Det är dock viktigt att Scrum Master lägger tid på att hjälpa teamet att prioritera! (förutsätter att Scrum Master har en god förståelse för kundens önskemål) Checka inte ut uppgifter slumpartat så att viktiga items blir kvar till slutet av sprinten. Glöm inte heller att låta systemarkitekten och teamet få en möjlighet att se över kundens föreslagna backlog. Vissa saker är tekniskt beroende av att uppgifter längre ner i prioriteringslistan görs först.
  • Nya önskemål dyker uppIgnorera nya önskemål om funktioner och förändringar medan en sprint pågår, och vänta till nästa sprintplanering med att prioritera in dem.
  • För mycket dokumentation. För mig är Scrum en metod som är snabb, intuitiv och flexibel. Om det fanns krav på dokumentation i varje sprint skulle för mycket av det härliga tempot som skapats gå förlorat. Så hur avgör man när något är klart? Jag brukar inte inkludera acceptanstest och användardokumentation i definitionen av klar. Låt teamet avgöra när en funktion är färdig! Det ska ju trots allt gå att visa upp för kunden på ett skarpt demo i slutet av sprinten. Och bra kod behöver inte dokumenteras :)

Vill du läsa mer?
http://scrumfromthetrenches.blogspot.com/2008/05/daily-scrum-mistakes.html
http://on-agile.blogspot.com/2006/09/scrum-pitfall-i-focusing-on-people.html
http://www.gamasutra.com/view/feature/3724/top_10_pitfalls_using_scrum_.php
http://stackoverflow.com/questions/63100/scrum-process-management-tips-pitfalls-ideas