Therese Reuterswärd

din konsult inom ehandel och digital marknadsföring

12 fallgropar i Scrum

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

4 kommentarer på ”12 fallgropar i Scrum

  1. Huvudet på spiken: Projektägare borde finnas hos både kund och leverantör; som beställare på ena sidan och som “proxy för den verkliga kunden” hos leverantören. Scrum Mastern bör ansvara för teknisk höjd, vägval, problemlösning och coachning av utvecklarna. Fördelen med både en Scrum Master och en PL är att projektledaren då hinner leda fler projekt parallellt. Sen har jag som “proxy” inget emot att styra upp scrum board, planning meetings, demos, köpa extra minne till teamets datorer eller testa färdig funktionalitet :)

  2. I en perfekt värld skulle jag säga att det är produktägarens roll att övervaka budgeten medan konceptförståelsen kommer naturligt för hela teamet genom att det inte finns någon person som är ansvarig för kundkontakten, dvs hela teamet har kontakt med kunden och sätter sig in i hur kundens verksamhet fungerar.
    Sen kan ju verkligheten naturligtvis sätta sina begränsningar. Av de scrumprojekt jag deltagit i hittills tycker jag mig dock kunna uttyda att det fungerar mycket bättre när det inte finns någon person som har en enbart administrativ och relationsbyggande roll (läs: projektledare) i teamet utan då alla teamets medlemmar adderar kundnytta, om än i olika utsträckning.
    Emil skrev ett intressant inlägg om detta för ett tag sedan, http://unwillingcoder.com/Entry.aspx/get-rid-of-the-project-manager-get-more-value

    Sägas bör dock att jag inte tror att den traditionella projektledaren inte längre behövs, men jag tror att den personen är betydligt bättre lämpad som produktägare hos kunden eller (i värsta fall) som proxy för den verkliga kunden hos leverantören.

    Gällande att hålla kodbasen lättrörlig så förstår jag att inlägget inte på något sätt uteslöt det. Jag tycker dock att det är en fråga som diskuteras på tok för lite, framför allt i proportion till hur mycket projektmetodik diskuteras. Detsamma gäller ofta för hur man ser på frågorna i många organisationer. Jag tycker ofta att man ser att företag skickar sina projektledare på utbildning för att bli scrum masters och sina utvecklare på utbildning för att lära sig en specifik teknik, typ EPiServer CMS, och sedan ska man tuta och köra med agil mjukvaruutveckling. I själva verket tycker jag att man borde skicka sina projektledare på utbildning i produktägarskap, uppmuntra sina utvecklare att läsa på om några av de ämnen jag nämde i min tidigare kommentar och ständigt söka nya vägar att bygga mera flexibel mjukvara. Och skicka alla på den där scrum kursen :)

    Ursäkta långrandigheten, som du märker är detta ett ämne som intresserar mig :-)

  3. Att kodbasen är lättrörlig är ju en oerhört viktig förutsättning! Du har helt rätt, och som projektledare utgår man ifrån att teamet tar eget ansvar för att rätt metodik för systemdesign och utveckling tillämpas. Jag tycker också själv att Scrum Master ska vara en utvecklare (även om det inte rekommenderas att det är tech-gurun). Men Scrum Mastern måste isåfall också ha kundkontakt, konceptförståelse och övervaka timmar och budget. Scrum hanterar ju som bekant inte kostnad och projektekonomi heller..

  4. Mycket intressant och välskrivet Therese!

    Jag saknar dock den, enligt min erfarenhet, vanligaste och djupaste fallgropen: att inte inse att projektmetodiken bara är en av flera delar i att jobba lättrörligt med mjukvaruutveckling.
    Minst lika viktigt är i min mening att systemdesign och utveckling sker på ett agilt sätt, vilket inte scrum på något sätt garanterar.
    Framför allt då scrummastern är en icke-tekniker (i min mening fel) tas ofta egentligen självklara begrepp som SOLID-principerna, TDD och continous integration (för att nämna några) inte upp alls. Finns inte de bitarna på plats är projektet dömt att misslyckas efter några månader, oavsett hur väl man har infört scrum, eftersom kodbasen inte är lättföränderlig. Man har slagit i scrum-väggen, http://allankelly.blogspot.com/2009/07/scrum-wall-another-agile-failure-mode.html.

    Som vanligt har Ayende formulerat det jag försöker säga mycket bättre än vad jag kan på sin blogg: http://ayende.com/Blog/archive/2010/02/20/nice-process-but-what-about-the-engineering-bits.aspx

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *

Tillbaka till toppen