Posts Tagged ‘definition_of_done’

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?

.

Annonser
h1

Ena teamet med en Working Agreement

torsdag, 23 september, 2010

Definition of DONE är ett viktigt verktyg för det agila teamet för att för att teamet som veta vad som förväntas av dem innan de får lov att  säga ”Nu är vi helt klara med funktion X!”. Men Defintion of DONE beskriver inte hur vi jobbar eller vilka principer och värderingar vi värderar och eftersträvar. Det här är teamets ”Working Agreement” kommer in i bilden, ett sorts av kontrakt som beskriver samarbetet, processen och principerna.

I mitt nuvarande uppdrag har teamet under kort tid växt kraftigt och vi har diskuterat mycket hur vi ska samarbeta bättre och mer fokuserat, både internt i teamet men även gentemot våra beställare och stakeholders. Därför har behovet vuxit fram att dokumentera vårt sätt att arbeta och enas kring vad vi tycker är viktigt.

Dels har vi under årets lopp etablerat rutiner och en rytm, men vi har också haft många workshoppar på sistone där vi diskuterat hur vi vill jobba framöver och hur vi behöver ändra vårt angreppssätt för att kunna lägga i en ännu högre växel. Alla i teamet har engagerats i dessa diskussioner men även våra beställare, våra mottagare av systemen i förvaltning och berörde avdelnings- och it-chefer. Idag påbörjade jag arbetet att summera allt i en ”Working Agreement”.

.

Innehåll i en Working Agreement

En Working Agreement innhåller saker som till exempel (och vårt är inget undantag):

  • Daily Stand-Ups – När och var hålls dom? Vilka är bjudna? Hur ser rutinen ut?
  • Planering – Hur genomförs Sprint Planning, Pre-Sprint Planning, Story Time Sessions, etc. När går de av stapeln? Vad är målet för respektive möte? Vem förväntas förbereda vad? Osv.
  • Test- & Kvalitetsstrategi – Hur testar vi? Vad testar vi? Vilka testar? Hur samarbetar teamet med beställaren i acceptans-testandet?
  • Principer och värdering – Vilka principer och värderingar vill vi att alla i teamet värnar om och lever efter? Vad är viktigt för oss vad gäller dialog och samarbete?
  • Hantering av buggar och defekter (under sprinten, efter sprinten)
  • Produktägarens ansvar
  • Scrum Masterns ansvar
  • Rapporter, Burndowns och Protokoll – Vilka behövs? Vem behöver dem? När önskas dom?

.

Workshoppa fram en Working Agreement

Enklaste och bästa sättet är (såklart) att bjuda in alla berörda till en workshop där ovanstående punkter diskuteras igenom ordentligt. Var inte snål med tiden då många av punkterna kan väcka mycket diskussion och debatt och det är viktigt att alla enas och håller med om det som slutgiltigen skrivs ner i en Working Agreement.

.

Signering

När Working Agreement diskuterats klart och formaliserats i text bör var och en i teamet skriver under på att man håller med och att man lovar att anstränga sig för att leva upp till överenskomna principer och värderingar och att man ämnar jobba efter den process man tillsammans kommit överens om.

När en ny teammedlem introduceras till teamet ska såklart även denna ta del av Working Agreement samt ges möjlighet att påverka och diskutera innehållet innan man skriver på.

.

Att vara agil betyder att lära sig

En Working Agreement är på inget sätt något heligt som är skrivet i sten. Kommer teamet fram till att man vill jobba på ett annorlunda sätt eller om nya principer och värderingar växer fram gäller det att kontraktet uppdateras så att det reflekterar detta.

Ha som vana att på Sprint Retrospective ställa er frågan om det är något som behöver justeras, uppdateras, tas bort, läggas till eller öppnas upp för diskussion.

.

Erfarenheter och tankar?

Har du erfarenhet av att sätta ihop en Working Agreement (eller liknande konstruktion) i ditt team? Hur gick ni tillväga och hur har resultatet fallit ut? Har det hjälpt teamet?

.

h1

Gott och blandat från Sommaren

onsdag, 18 augusti, 2010

Har snart plöjt igenom alla mina RSS flöden och hittat några godbitar jag tänkte dela med mig av.

Jag trodde alla hade haft semester, men icke. Vissa är visst lika flitiga på att skriva och ha åsikter oavsett årstid. Här nedan kommer ett litet axplock av dom de jag uppskattat hittills. Har som sagt några ytterligare att plöja igenom… ca 67 stycken…

.

Agile Adoptation Anti-Patterns

Denna artikel från LeadingAnswers: Leadership and Agile Project Management Blog radar upp 5 ”populära” fallgropar organisationer gärna trillar ner i på sin resa till en agil organisation.

Läs artikeln här:
http://leadinganswers.typepad.com/leading_answers/2010/07/agile-adoption-antipatterns.html

.

Top 100 Agila Böcker

Jurgen Appelo har sammanställt en lista över de 100 populäraste böckerna på Agile ämnen genom att kombinera information från bland annat Amazon.com och GoodRead.com m.m. Visste knappt att det fanns hundra böcker om ämnet…

Se listan här: http://www.noop.nl/2010/08/top-100-agile-books.html

.

Övning ”Define your Definition of Done”

Tobias Fors beskriver ingående en övning för Scrum-teamet för att definiera Definition of DONE. Tobias går steg för steg igenom övningen på ett tydligt och bra sätt.

Läs artikeln här: http://www.tobiasfors.se/?p=575

.

Crowdsourced Testing, Changing the Game

InfoQ reflekterar över ”Crowdsourced Testing” och summerar åsikter och kommentarer på ämnet från olika bloggar. Själva konceptet tycker jag är mycket spännande och intressant, och jag är också övertygad om att denna approach kommer att växa snabbt inom de områden där det är möjligt.

Läs artikeln här:
http://www.infoq.com/news/2010/08/crowdsourced-testing

.

Your Scrum Checklist

Boris Gloger har släppt en ny version av ”Your Scrum Checklist” för gratis nedladdning på InfoQ (kräver inloggning).

Klicka här för att ladda hem den gratis som pdf (kräver inloggning):
http://www.infoq.com/minibooks/scrum-checklists

.

h1

Grundmall för ”Definition of DONE”

torsdag, 18 mars, 2010

Precis som utlovat kommer här min åsikt om vad ”Definition of DONE” bör innehålla. Oavsett innehåll är det viktigt att alla i projektet, dvs. Teamet, Scrum Mastern och Produktägaren, alla är överens om vad den definerar – och vad den utelämnar.

”DONE” bör enligt min uppfattning minst innehålla:

Collaborated & Designed
Coded
Versioned
Tested
Documented
Knowledge Shared
Deployable/Deliverable
Approved

Denna lista är på intet sätt komplett eller tillräckligt tydlig. Varje team måste själva tillsammans med sin Produktägare och Scrum Master ta ställning till vad DONE ska innehålla och vad varje punkt betyder. Glöm inte bort att DONE beskriver krav på vad som ska ha utförts/fullgjorts av teamet för varje User Story som demonstreras på Sprint Demo.

Sedan kan det vara så att alla kriterier inte är applicerbara eller meningsfull för allt som teamet åtar sig under en sprint. Det kan också självklart vara så att man för vissa typer av User Stories lägger till ytterligare kriterier. Men lägger man till för mycket bör det diskuteras ifall något annat kanske ska tas bort. För många och för höga kriterier kan resultera i överprestation som inte är efterfrågad, a.k.a Waste.

Har ni i ert team inte alla DONE kriterier ovan? Försök införa dem än efter än så kommer ni se att er kvalitet och kundnöjdhet kommer att öka och er tekniska skuld att minska.

Vidare vill jag trycka på att alla i teamet är ansvariga tillsammans för att DONE efterlevs och uppfylls. Detta innebär också att var och förväntas hjälpa till för att färdigställa alla påbörjade åtaganden och tasks innan Sprint Demon.

Tvivlar du på om det är värt besväret? För några dagar sedan skrev jag ett inlägg om värdet på ”Definition of DONE”.

.

Collaborated & Designed

Teamet har tillsammans med produktägaren (och eventuellt med kund) diskuterat och beskrivit funktionen. Vad gäller den tekniska implementeringen har teamet suttit och diskuterat vad man vill uppnå och kommit överens om en teknisk lösning. (Detta kan t.o.m. ha skett i föregående Sprint.)

Coded

Funktionen/featuren är färdig kodad, dvs. all kod som ska skrivas har blivit skriven. Jobbar teamet med TDD på enhetstestnivå har dessa enhetstester blivit skrivna.

Versioned

Kod och dokumentation är incheckat i versionshanteringssystemet.

Tested

Den utvecklade funktionen/featuren är testad. Här behöver det detaljeras vilka krav på tester som krävs och vilka typer av tester funktionen/featuren ska utsättas för. Exploratory Testing? Automatiserade Acceptance tester? Integrationstestat av det nattliga bygget?

Documented

Överenskommen dokumentation är skriven och/eller uppdaterad. Exakt vilken dokumentation behöver defineras. Finns det system översikter som ska uppdateras? Användarmanualer?

Knowledge Shared

Antingen utövas Par Programmering eller så har person/personerna som utvecklade funktionen berättat för övriga i teamet vad de gjort, hur de tänkte och vilka moduler, klasser, tester, dokument, etc. de har skapat/ändrat.

Deployable/Deliverable

Funktionen/featuren är redo för leverans/installation, dvs. eventuella installations script har uppdaterats, installationspaket har kompletterats, etc. Testmiljöer ska dessa ha uppdaterats. (Detta betyder dock inte att funktionen automatiskt ingår i nästa leverans. Dock ska  funktionen, med minimal ansträngning, kunna ingå i nästa version av produkten/systemet närhelst det beslutas av Produktägaren.)

Approved

Produktägare och/eller kund har gett feedback och sitt godkännande genom att prova på och testa i testmiljön.

.

Uppdatering: 2010-03-19

InfoQ presenterar ett intressant förslag på ”Definition of DONE” från Alixx Skevington på sin hemsida: http://www.infoq.com/news/2010/03/mainfesto-of-done

h1

En väldefinerad och välförankrad ”Definition of DONE” är ovärderlig!

tisdag, 16 mars, 2010

Fördelar med en bra DONE definition

En DONE definition beskriver som bekant vad som krävs för att teamet ska få lov att säga att dom är helt ”klara” med en User Story och för att de ska tillåtas demonstrera den på sprint demon. Typ en checklista för teamet när de utvecklar. Men…

.

En väldefinierad och förankrad DONE defintion som teamet följer disciplinerat är användbar och värdefull på så många fler sätt:

  • Underlättar vid User Story estimering av Product Backlog (så att man inte glömmer bort någon aspekt)
  • Hjälper teamet att bryta ner User Stories till tasks vid sprint planering
  • Gör det tydligt för Product Owner och stakeholders vad teamet menar när dom säger att dom är ”klara” men någonting
  • Beskriver önskad kvalitetsnivå (genom att teamet till exempel genom diskussion med Product Owner specificera vilka typer av tester som skall göras)
  • Hjälper teamet hålla den tekniska skulden låg
  • Ger kunden/beställaren möjlighet att vara ”nöjd” efter valfri sprint (då man vet att det som har blivit demat är helt klart och redo för paketering eller leverans)
  • Synliggör  för Product Owner och att det finns andra uppgifter utöver själva programmeringen som tar tidstakeholders.

Det går enkelt att komma på många fler fördelar! Någon som behöver ytterligare inspiration? 😉

Återkommer inom kort med vad jag tycker att en ”Definition of DONE” minst borde innehålla…

h1

Bygg inga pussel. Utveckla vertikalt!

tisdag, 9 mars, 2010

Vad innebär det att jobba inkrementellt? Hur levererar man en komplex lösning med en komplex arkitektur i små steg enligt en iterativ process såsom Scrum?

Iterativt = Upprepbar, lärande process. Små steg. Förvänta dig inte att få det rätt första gången. (Sprint = Iteration)

Inkrementellt = Bygg i vertikala tårtbitar (Stories) hellre än i lager, dvs. bygg inte en modul i taget för att i slutskedet försöka foga ihop dem. Bygg och leverera en liten del av helheten i varje iteration.

Så, vad är det man ska undvika?

  • Dela inte upp team efter applikationens lager.
  • Bygg inte en komponent i taget bara för att i projektets slutskede (under exempelvis integrationstestningen, eller än värre – efter leverans) upptäcka att bitarna inte passar ihop och måste skrivas om.
  • Bygg inte något under sprinten som inte resulterar i någonting som inte är av värde för slutanvändaren och som inte kan demonstreras på Sprint Demo.
  • Brodera inte ut komponenter med extra funktioner som kan ”vara bra att ha” eller som inte är nödvändiga just nu för den Story som ska levereras. (Med största sannolikhet är det antagligen ogjort jobb. ”Bra att ha”-funktioner visar sig ofta överflödig eller nödvändiga att skriva om när de väl ska anropas/användas.)

Hur ska vi göra istället?

  • Gruppera Stories i områden och bygg tvärfunktionella team runt varje område (som har kunskap som krävs för att utveckla och testa alla lager, exempelvis UI, server och databas).
  • Bygg en Story i taget och bygg alla funktioner som behövs (dvs. bygg det som behövs i UI, det som behövs på servern och det som behövs i databasen), och inget annat än det som behövs för Storyn.
  • Se till att Storyn som utvecklas under Sprint är tillräckligt avgränsad för att bli KLAR (dvs. kodad, testad, integrationstestad, dokumenterad, levererbar och installerbar)

Meh!?

…kanske någon tänker, ”Är det inte svårt att bygga något varje sprint som slutanvändaren kan använda och som har faktiskt värde för verksamheten?”

Svar ja.

De första Sprintarna kommer mycket energi och tid gå till att bygga skelettet och ramverket i arkitekturen. Och det måste det få göra annars riskerar man att få en slarvig struktur som inte går att bygga vidare från. Men ledordet även här måste vara – ”Bygg enbart och endast det du behöver, men gör det bra”. Försök inte förutse framtida behov utan bygg en arkitektur som är tillräckligt flexibel och stabil för att kunna anpassas, byggas ut och justeras i framtiden.

Balansgången är svår men däri ligger också nyckeln till förmågan att kunna leverera värdefull mjukvara efter varje Sprint och en av hemligheterna till hur man uppnår snabbhet och flexibilitet.

(Ursprungligen publicerad på blogg.sogeti.se)