Det optimala IT-utvecklingsteamet 3 - arbeta agilt

Nästa steg är att få igång arbetet på rätt sätt och tidigt få in de agila principerna och Scrum. Just detta ska vi diskutera i den här artikeln.

För att säkerställa att teamet kan införa det agila tankesättet och Scrum måste du börja med att se till så att alla förstår vad det är och hur det fungerar i praktiken. I vissa fall kanske det bara krävs en liten uppfräschning av kunskaperna, medan det i andra team kanske behövs mer krävande åtgärder som t.ex. formella utbildningar, workshops, genomgång av litteratur och liknande.

Agila team och Scrum i all ära, men varför ska vi egentligen använda oss av det? För att få med alla på tåget är det bra att skapa en förståelse för varför vi gör det. Det finns inget värre än att göra saker bara för att vi måste. Du kommer kanske ihåg vissa opedagogiska lärare från din skoltid som du frågade: -Varför ska vi lära oss det här egentligen? Vad har vi för nytta av det? Och läraren helt enkelt svarade: -Därför! Eller helt enkelt: -Ni ska lära er det för att ni måste!

Inte speciellt motiverande. Samma sak gäller för oss på arbetsplatsen. Det är inte så himla roligt att arbeta på ett visst sätt eller nyttja vissa metoder och verktyg om vi inte vet varför vi ska göra det. Att motivera användandet av agila metoder och Scrum är inte speciellt svårt. Du kan trycka på saker som att vi uppnår mer flexibilitet och att vi lättare kan anpassa oss efter förändrade förutsättningar. Vi får också en tätare dialog med kunden vilket gör att vi enkelt och med väldigt små medel kan rätta till kursen så att det vi levererar hela tiden anpassas efter kundens önskemål. På det viset minimerar vi också risken för att slösa med resurser i onödan och innan det drar iväg för mycket. 

Timeboxing är också något som är värt att trycka på. Ni som har erfarenhet av mer traditionella projekt där man jobbade med olika projektplaneringsvertyg och där varje aktivitet ritades in omsorgsfullt i allehanda grafiska presentationer vet också hur kämpigt det var när förutsättningarna ändrades eller när en aktivitet drog ut på tiden och ruckade på hela projektets tidplan. Berätta också om de ceremonier som finns specificerade, som t.ex. daily standups, sprintplanering, retrospektiv med flera.

Så på det stora hela handlar det om att vi både vill vara mer anpassningsbara gentemot våra beställare och att vi vill öka teamets välmående och produktivitet.

För att arbetet i teamet ska gå så smidigt som möjligt är bra att ha en genomgång av de olika ceremonierna och vad de används till. Det är också viktigt att förklara de olika artefakterna som används i Scrum. En viktig ceremoni är daily standups som av många kan upplevas som onödigt spenderad tid i teamet, därför är det viktigt att poängtera att detta är tänkt som korta möten på max 10-15 minuter och att detta är ett av flera sätt att snabbt anpassa sig och omprioritera teamets planer. En annan värdefull ceremoni är sprintplaneringen där alla i teamet har möjlighet att komma överens om mål på kortare sikt som alla jobbar emot och ser till att teamet uppnår dessa och kan leverera önskvärda produkter.

Just sprintplaneringen är en av de ceremonier där det kan vara lite svårt att engagera teamets alla medlemmar. Många flyter liksom bara med utan att vara delaktiga ordentligt. Ett sätt att råda bot på det är att initialt förklara att det vi kommer överens om vid sprintplaneringen också är det vi lovar utåt att vi ska leverera och det vi committar oss till. På det viset ökar möjligheterna med att få alla att också känna ett individuellt ansvar för vad som ska göras i nästa sprint. Det finns ju många andra viktiga ceremonier och det är bra att gå igenom alla och komma överens i teamet om hur de ska gå till. På samma sätt behöver du gå igenom de olika artefakter vi ska använda oss av, varför de finns och hur vi ska använda oss av dem. Jag tänker på t.ex. backloggen, storys, features, enablers, epics och olika typer av diagram vi kan använda oss av för att visualisera komplexa data och få det mer lättförståeligt.

Det finns ju ett antal fördefinierade roller i Scrum och det är viktigt att alla medlemmar i teamet förstår vad dessa roller innebär konkret och vad de kan förvänta sig av dem. Scrum Master (ScM) är nog kanske den rollen som teamet har mest kontakt med och i stället för att bara ge alla en lång uppräkning om vad en ScM gör är det bra att ”ta ner beskrivningarna på jorden”. Annars kan de ju lika gärna läsa listan på scrum.org. Huvuduppgiften för en ScM är att se till att alla verkligen förstår vad Scrum innebär, både teoretiskt och i praktiken. Sen kan ju ScM hjälpa till med många andra saker som att prioritera backloggen tillsammans med Product Owner, hjälpa teamet med att undanröja hinder, mitigera risker mm 

På liknande sätt är det bra om alla känner till vad det innebär att vara Product Owner (PO) i ett team. En PO är ytterst ansvarig för det teamet levererar och måste därför se till att detta görs så effektivt som möjligt och hela tiden anpassas efter uppsatta mål, krav och behov. Det är också PO som prioriterar backloggen och ser till att det teamet ska göra härnäst alltid återfinns högt upp i backloggen. En viktig aspekt som kanske inte alla tänker på är att det är PO som ansvarar helt och hållet för backloggen. Enda sättet för någon annan att ändra prioriteringen i backloggen är att bearbeta PO i teamet.

Sist men inte minst har vi själva teamet där produktionen sker. Teamet kan bestå av utvecklare, testare med flera och det är dessa individer som ser till att vi faktiskt kan leverera någonting och att vi får fram produkter som är anpassade efter de mål som är uppsatta.

Att arbeta med ständiga förbättringar är inget nytt koncept. Det har funnits i många år. Ett mer strukturerat sätt att arbeta med detta introducerades i Japan efter andra världskriget och fick namnet Kaizen. Det nya med Kaizen var att man insåg att små inkrementella förbättringar kan leda till stora framsteg på längre sikt. Kaizen ledde senare till metodiken Lean Manufacturing som används i stor skala än idag, framför allt inom industrin. Kaizen är också en vital del av den agila filosofin och används i hög grad inom Scrum.

Men vad menar vi konkret med att arbeta med ständiga förbättringar? Många kanske tycker det verkar lite flummigt och diffust, men med ganska små medel kan du bringa lite mer klarhet i detta viktiga arbete. Ett sätt att få en bättre förståelse för det här arbetet kan vara att introducera tydliga mätbara mål med förbättringsarbetet. Exempel på ett sådant mål kan vara att vi vill uppnå en bättre arbetstillfredsställelse hos teamets medlemmar vilket vi kan mäta regelbundet med interna undersökningar som vi sedan sammanställer och utvärderar.

En vanlig fallgrop i arbetet med förbättringar är att man tar för stort grepp på en gång och att det blir en hög tröskel att ta sig över och risken för att misslyckas blir ganska stor. Bättre är att i stället jobba med små förändringar och löpande utvärderingar av dessa. Då blir det enklare att jobba med mer experimentella saker som kanske inte fungerar som de var tänkta, men som också är enkla att sluta med. 

Med detta sagt så borde du nu ha goda förutsättningar att lyckas med ditt team eller projekt. I nästa artikel kommer jag in på det här med kommunikation och samarbete.