Archive for the ‘Scrum metodik’ Category

h1

Vilka frågor besvarar er Working Agreement?

torsdag, 6 december, 2012

Alla team har någon form av uppfattning kring vad som betraktas som accepterat och bra beteende i teamet mellan teammedlemmar. De flesta vet att kollegor inte uppskattar när du är sen till ett möte. Kanske har ni en tyst överenskommelse kring hur ni röstar och tar beslut.

Vissa team skriver ner sitt beteende- och samarbets-”protokoll” i en Working Agreement.

Du kanske tycker att sunt förnuft täcker det mesta och att skriva ner det känns fåning. Suprise! Sunt förnuft är subjektivt och ni har antagligen olika uppfattningar kring mycket. Toppen! Låt oss diskutera och upptäcka våra gemensamma värderingar.

 

Läs hela blogginlägget här (på engelska på Crisps blogg).

 

 

h1

Övning: Agile Values

onsdag, 29 februari, 2012

Nu har jag lagt upp ytterligare material under ”Verktyg och Mallar”. Denna gång blir det en övning som jag själv kört flera gånger med fantastiskt resultat.

”Agile Values” är en diskussionsövning under vilken teamet eller projektet får en chans att fördjupa sin förståelse kring agiles och leans principer, men framförallt en möjlighet att diskutera dem!

Under övningens gång (som tar cirka 90-120 minuter att genomföra) får teamet (alternativt projektet eller avdelningen) en chans att diskutera agiles och leans principer och värderingar. Inte nog med det, grupperna får också en chans att diskutera hurvida man tror att principerna och värderingarna är sanna – dvs. är de viktiga att följa och värna om för att projektet ska nå maximal framgång?

.

.

Du hittar övningen genom att klicka här, eller på ”Verktyg och mallar” i högerspalten.

.

h1

Ikon-mani på Scrum-väggen

torsdag, 23 februari, 2012

I projektet jag är Agile projektledare och Scrum Master i just nu har vi tapetserat 8 meter vägg med allehanda Backlogs, Burndowns, grafer, prognoser och information. Det har också skett en mindre explosion i antalet ikoner vi använder oss av för att tydligare visualisera vad som pågår och vilken status arbetet är i.

Väggen som helhet ser ut såhär:


(Klicka för att se en större bild. Sprint Backloggen är ytan i mitten som är tjock med Post-Its.)

.

Sprint Backloggen

Sprint Backloggen är enkelt strukturerad:

Task-lapparna beskriver saker som ”Implementera X”, ”Koda Y”, ”Fixa Z”, ”Skriva testfall”, ”Systemtesta”, ”Skriva systemdok”, ”Fixa browserkompatibilitet”, ”Acc Test”, m.m. m.m.

Jobbar man med en task så placerar man en av sina egna avatar ikoner på eller bredvid Task-lappen. I projektet blev temat av någon anledning superhjältar i olika skepnader. Vi har ”The Governator”, ”The Iron Lady”, ”Chuck Norrs”, ”Yoda”, m.fl. som var och en representerar en person i teamet. Varje person har max tre avatarer, dvs. man tillåts inte jobba med mer än tre saker samtidigt. Oftast används dock bara en eller två samtidigt, vilket är bra.

Varje task i ”In work” kolumnen uppdateras dagligen dessutom med ett estimat på återstående effektivt arbete i timmar. (Dessa summeras dagligen i Sprint Burndown charten.) För varje dag som en task sitter i ”In Work” kolumnen får den dessutom en prick på sig så att vi kan se hur många dagar den suttit där. De flesta tasks är så små att de ska vara möjliga att slutföra under en dag så om antalet prickar växer vet vi att något skumt pågår.

Denna uppbrytning har dock inte visat sig vara en tillräcklig visualisering av nuläget. Så, för att komplettera status och vad som händer använder vi oss av en stor skara laminerade ikoner som vi fäster med häftmassa på Feature-lapparna eller Task-lapparna.

Förhoppningsvis ger det någon inspiration så håll till godo, här kommer ikonerna 🙂

.

Status ikoner

Topic för morgondagens Daily Standup
Om det är något vi känner att vi vill diskutera tillsammans i teamet på nästa morgonmöte markeras Feature- eller Task-lappen med denna ikon. Varje morgon scannar vi Backloggen det sista vi gör efter dessa Daily-ikoner, diskuterar dem, och tar sedan bort ikonen.
Top Prio!
Denna ikon signalerar att denna Feature eller Task är något som vi verkligen behöver fokusera på tillsammans!
Tar konstigt lång tid
Om en task fortsätter sitta i ”In Work” kolumnen dag ut och dag in gör vi alla uppmärksamma på detta med denna ikon. Uppenbart så pågår något underligt. Antingen så är personen störd av andra åtaganden, eller så behöver han/hon hjälp. Oavsett vad, något lurt pågår.
Pausat
Av någon anledning kan vi för tillfället inte jobba vidare med denna task. Antingen väntar vi på svar eller information från någon utanför teamet, eller så kanske personen som jobbade på uppgiften gått och blivit sjuk.
Frustration!
Med denna ikon delar vi med oss av den frustration vi upplever. Häromdagen hade en om samma task tre stycken frustrationsikoner. Så jobbigt var det att få ordning på den.
Defekter spökar
Denna ikon har vi använt lite olika men nu verkar det som om vi börjat använda den för att signalera att systemtesterna inte nått i mål på grund av funna buggar.
Färdig 🙂
För att komma ihåg vad man gjorde dagen innan så placerar man denna ikon på tasken när man flyttar in den i ”Finished” kolumnen. Då blir det mycket enklare att summera gårdagen på nästa Daily Stand-Up.
.För att tydligare visualisera vilka funktioner som är redo för systemtest och vilka som är redo för acceptanstest har vi nyligen skapat ytterligare några ikoner. Det visade sig att det inte var uppenbart enbart genom att kolla av i vilken kolumn våra Task-lappar satt för att avgöra i vilken miljö featuren fanns i.
Awaiting ST Deploy
När utvecklaren känner sig färdig och redo med funktionen och har gjort grundläggande testning i sin egen utvecklingsmiljö är koden redo att läggas upp i Systemtest (ST) miljön. Detta markerar vi genom att placera denna ikon på den stora Feature-lappen.
System test Ready
När funktionens kod har hamnat i ST-miljön (efter ett sk ”lyft”) markeras Feature-lappen med denna ikon. Det betyder att Systemtest-fall är skrivna och att vem som helst (förutom personen som utvecklade funktionen) kan påbörja systemtestning.
Awaiting AT Deploy
När systemtest är genomförd och teamet känner att funktionen är av tillräckligt hög kvalitet för att lyftas till acceptanstest (AT) miljön placeras denna ikon på Feature-lappen.
Acceptance test Ready
Denna ikon signalerar att funktionen finns i acceptanstest miljön. Dvs. när uppgradering sker av AT-miljön byts ”Awaiting AT Deploy” ut mot denna ikon. Det kan finnas kända problem, men den håller tillräckligt hög kvalitet för att teamet ska vara redo att ta emot feedback från acceptanstestning.
h1

Det är dyrt att vara riktigt agil. Eller?

onsdag, 2 november, 2011

Att vara agil när man jobbar i Scrum betyder (bland annat) att man efter varje iteration har lyckats bygga en ny fungerande och värdefull version av produkten (eller systemet) som går att leverera till kund eller butik om man så önskar. Men att vara riktigt agil kostar. Eller?

För att varje sprint ska resultera i en nytt levererbart inkrement ställs det stora krav. Först måste vi ha lyckats bryta ner våra features så att de är tillräckligt små så att flera får plats i sprinten. Och med ”få plats” menar jag att man hinner med allt för att gå från idé till leverans, dvs. varje enskild feature ska designas, kodas, testas, dokumenteras och sammanfogas med helheten (allt enligt vår Definition of DONE for User Stories). Vi behöver dessutom känna oss trygga i att resten av systemet fortfarande fungerar och att vi inte har introducerat nya buggar.

Om vi förutsätter att vi har kontroll över våra IT-system och inte har några externa beroenden vad gäller testmiljöer och servar (vi är inte beroende av externa köer för att få något jobb gjort) så är det ändå inte helt trivialt att få till en leverans varje sprint.

Låt oss titta på ett exempel på hur en treveckorssprint skulle kunna se ut.

.

Först och främst har vi våra Scrum möten. Syftet med dessa är att planera (läs analysera) vad vi ska göra härnäst (Sprint Planning), hur vi på bästa sätt koordinerar oss inom teamet (Daily Scrum), fånga upp feedback så att vi kan förbättra processen (Sprint Retrospective) samt lära oss vad som kan göra produkten ännu bättre (Sprint Demo). Sista fredagen är dessutom en sprint-fri dag där teamet kan hämta andan och samla ny energi till nästa sprint.

.

För att vi med trygghet ska vilja lämna ifrån oss den nya versionen (som innehåller våra nya features) vill vi dessutom känna oss trygga i kvalitén. Detta gör vi med att arbeta med att fixa buggar och verifiera buggfixar (Hardening). Vi vill också testa igenom systemet i sin helhet för att försäkra oss om att vår nya kod inte saboterat någon annan funktionalitet eller försämrat någon egenskap (såsom t.ex. prestanda). Denna testning inleds typiskt med en uppgradering av acceptancetestmiljön. Hela teamet hjälps åt att testa. Vad man fokuserar på klurar man ut som team genom att göra en riskanalys. Det kan t.ex. innebära en balans mellan körning av delar av regressionstestsviten plus identifierade Exploratory Testing sessioner. Var man lägger sin testfokus beror på var man ser att riskerna finns, vilka moduler som utsatts för förändring etc. När så slutgiltig paketering är gjord och en sista hand har lagts på dokumentationen är teamet redo att leverera den nya versionen till kund eller förvaltning. Tada!

.

Det som återstår är vårt utrymme för utveckling. Det är alltså denna tid som finns tillgänglig för design, kodning, testning och dokumentation av nya features. Det vi påbörjar ska hinna slutföras innan ”Code-freeez-mode” slår till.

.

Sådärja. Då har vi lyckats visualisera de olika typerna av arbete som pågår under en sprint. Låt oss visualisera hur de olika formerna av arbeta står i proportion till varandra…

.

Nu ska man ställa sig två frågor:

Vilket arbete tillför värde?
Vilket arbete är waste?

.

Eftersom exemplet inte förtäljer hela historien så kan vi bara spekulera. ”Development” och ”Scrum Meetings” tillför såklart värde, det är här vi skapar, analyserar, planerar, designar och koordinerar oss. Sedan bör vi ställa oss frågan – kan Scrum mötena (såsom sprint planeringen) göras effektivare och kortare?

”Hardening” borde inte behövas om vi byggde kvalitet från början. Detta är tydlig waste. Packaging, miljöuppgraderingar etc. döljer också troligtvis en hel del waste – detta borde gå att automatisera.

Den gemensamma testinsatsen som sker i slutet av sprinten… är den waste? Jag skulle argumentera för att den inte är det – här bygger vi kunskap om hur systemet som helhet mår efter att vi infört våra förändringar och bygger beslutsunderlag till frågan – ska denna release gå till kund?

.

.

Det som blir uppenbart av att titta på bilden är dock att själva utvecklingen av nya features som mest utgör hälften av arbetet. Mycket tid går åt till ”annat”. Man skulle kunna påstå att Velocityn blir ”lidande” (antal features eller Story Points per sprint) eftersom vi anstränger oss för att vara helt agila. Från ett leveransperspektiv är det så att varje sprint levererar ett färdigt och komplett increment, dvs. Definition of DONE för User Stories är komplett och lämnar inget till senare. Vi VET att vi hela tiden är redo för leverans till kund. I exemplet ovan ”vet” vi att vi har levererat 24 features när deadline närmar sig.

.

Att vara helt agil i Scrum kostar så det är enkelt att lockas till att flytta ut vissa kriterier från Definition of DONE for User Stories till Definition of DONE for Release. Dvs. vi skjuter viss testning, viss dokumentation, etc. till en ”release sprint”. Detta ökar vår Velocity (antalet features per sprint), men vi är å andra sidan inte leveransredo varje sprint eftersom vi har skjutit arbete och risk framför oss. Faktum är att release sprinten troligtvis inte alls blir en strikt timeboxad sprint eftersom vi inte vet hur mycket arbete och risk vi skjutit framför oss förrän vi sitter ner och planerar (och exekverar) den sprinten. Med detta upplägg kanske vi levererat 30 features när deadline kommer, men det troliga är att vi kämpar med testning, buggfixningar och refactoring av tekniska svagheter långt förbi deadline. Vad ännu värre är att vi har skapat en rejäl fördröjning i feedbacken mellan test och kodning då vissa tester inte körs förrän så mycket som fem sprintar senare.

.

Att inte vara DONE utan att först uppnå DONE i release sprinten öppnar upp för följande:

Vi riskerar missa deadline
Vi introducerar waste genom långa feedbackcyckler (både vad gäller test och kvalitet men även kundens feedback om funktions värde)
Vi skjuter på tekniska risk och missar chansen att hantera problem tidigt
Vi tappar den sanna insynen i hur vi faktiskt ligger till (vi vet inte vad som är klart och vad som är ”work in progress” eftersom vi inte testat klart)
Vi förlorar styrförmåga. Innan vi helt kan styra om fokus måste vi genomföra release ”sprinten”.

.

Så är det dyrt att vara agil, eller är det kostsamt att inte vara det?

.

h1

Video: Kanban applied to Scrum

måndag, 31 oktober, 2011

Jag tycker om att tipsa om korta filmer som på ett snyggt och enkelt sätt presenterar olika aspekter av agil utveckling.

Denna YouTube video på sju minuter från bti360 presenterar hur principerna bakom Kanban på ett enkelt sätt kan användas för att förbättra din Scrumprocess.

.

 

 

h1

Snygg (och fyndig) introduktionsvideo till Scrum

måndag, 20 juni, 2011

Ramlade idag över denna video som introducerar och förklara de flesta av de grundläggande elementen av Scrum på ett snyggt och roligt sätt.

Det finns många introduktionsvideos om Scrum på nätet men jag tycker denna från CollabNet sticker ut lite extra i sina förklaringar och i sin presentation av Scrums mekanismer och grundpelare.

.

.

Se ”Scrum Training Series | Introduction to Scrum” här:
https://training.csfe.collab.net/sf-images/training/scrum/intro/Intro_to_scrum.htm

h1

The Hyperproductive Scrum Dream Team

tisdag, 21 december, 2010

Den 2:a december höll jag ett seminarie på Lantmäteriet i Gävle med titeln ”The Hyperproductive Scrum Dream Team”. Seminariet spelades in och nu finns den tillgänglig på YouTube.

Seminariet handlar om Scrum teamet och hur man skapar förutsättningar för hyperproduktivitet. Vilka är nyckel- faktorerna? Vilka är utmaningarna? Om Death by Technical Debt. Hur möjliggör man och skapar en miljö där teamet kan växa inifrån.

.

.

Filmen är uppdelad i fyra delar. Klicka på länkarna nedan för att se dem alla:

PS. Ha gärna överinseende med mina många stammningar och ”öh…”. Jag vill minnas att jag blev ganska nervös när jag 10 minuter innan seminariet ska börja blev upplyst om att det skulle filmas. DS.