Scrum i Praktiken

Igår kom mitt första inlägg på Projektbloggen upp. Det är en omskrivning av en artikel jag skrev 2007.

---------------------------------------------------
Scrum sägs vara en enkel metod för att hantera komplexa projekt. Det stämmer väldigt bra. Grunderna i Scrum är enkla att beskriva och enkla att förstå. Svårigheten är kanske att veta hur man ska använda den i ett verkligt projekt. Hur använder man Scrum i en organisation som annars kanske jobbar enligt vattenfallsmetoden? Hur anpassar man sig till en organisation som har en fungerande releasehantering enligt t.ex. ITIL?

En del i enkelheten i Scrum är att det bara finns tre olika roller: Scrum master, produktägare och utvecklare.

• Scrum mastern ansvarar för att processen följs och agerar mentor eller coach till teamet och produktägaren.
• Produktägaren är den person som prioriterar kraven efter affärsvärde och styr vad som ska utvecklas i produkten eller systemet.
• Utvecklare är medlemmarna i teamet som ansvarar för att leverera. Det spelar ingen roll om din expertis är inom programmering, arkitektur eller test, i Scrum benämns du ändå som utvecklare.

Sprintar
All utveckling inom Scrum sker inkrementellt i iterationer som kallas för sprintar. Längden på en sprint är individuell men mellan 14 och 30 dagar. I början av projektet kan man experimentera med olika sprintlängder. Det är dock viktigt att sedan bestämma sig och hålla sig till samma sprintlängd. Anledning till att jag tycker att man ska hålla en given sprintlängd är för att man vill ge teamet en känsla över hur långt man ska ha kommit efter en viss tid in i sprinten. Det underlättar också när man estimerar då man enklare kan använda sig av teamets hastighet.

Den första dagen i en sprint spenderar teamet tillsammans med produktägare och Scrum master för att komma fram till vad teamet ska leverera när sprinten är slut. Dagen är uppdelad på två möten, ett där teamet och produktägaren förhandlar om innehållet och ett där teamet tidsuppskattar och bryter ned kraven till uppgifter. Efter dag ett lämnar Scrum över kontrollen till teamet och kräver bara att en gång per dag få status om hur projektet går. Detta sker genom ett dagligt möte som varar max 15 minuter där teamet lämnar status till varandra om hur arbetet fortskrider.

Nu ska teamet börja jobba. Klockan tickar… Bara 29 dagar kvar till en potentiellt levererbar produkt ska vara klar. Vad ska vi göra nu? Hur ska vi kunna leverera den kvalitet som förväntas? Hur ska vi kunna testa den här funktionen som har beroende mot andra externa system som vi inte har tillgång till? Frågorna hopar sig och som sagt… tick tack, tick tack...

Fokus och ostördhet
I det här läget är det många som tar hjälp av eXtreme Programming för att t.ex. få till automatiserade byggen, enhetstester och kontinuerlig integrering. Scrum säger väldigt lite om vad som händer i sprinten, utan betonar att teamet ska lämnas ostört och få möjlighet att fokusera på leveransen. Scrum och XP fungerar väldigt bra tillsammans även om XP i sig är en helt komplett metod. Det som skiljer XP från många andra agila metoder är att den ger väldigt många rekomendationer till vad teamet kan göra under en iternation.

Utbildningar
På marknaden idag finns det en del utbildningar som riktar sig mot Scrum masters men få som riktar sig mot utvecklare i ett Scrum-projekt. Då menar jag inte själva utvecklingen i C#, VB.NET eller Java, utan snarare vad man kan göra för att förbättra kvaliteten och öka produktiviteten i leveranserna. För just produktivitet betonas väldigt tydligt i Scrum.
Ett exemple på en sådan utbildning är Scrum i Praktiken på Addskills. Den kursen riktar in sig mot just teammedlemmar i ett Scrum-projekt. Första dagen handlar om Scrum och om estimering och andra dagen handlar om practises från XP.

Själv gick jag min Scrum Master-utbildning på Citerus i Uppsala med Tobias Fors och Mikael Lundgren och det var en helt fantastisk kurs som jag varmt kan rekomendera.

Någon som har gått eller sett någon annan utbildning i Scrum som inte är någon av de officiella Certified Scrum *-utbildningar?

Scrum med ITMaskinen

I fredags hade jag unge herr Deurell en föreläsning för ITMaskinen om agile, Scrum och hur man kan använda Microsofts verktyg för att lyckas. Min roll var så klart att prata om agile och Scrum och Micke pratade om TFS och vikten av test med hjälp av Team System.

Läs mer i inlägget De tre vise männen coh Scrum på ITMaskinens eminenta bloggsida.

Vad betyder affärsvärde?

Jag har följt och varit inblandad i en tråd i ett forum på Pellesoft.se som handlar om vad värde betyder i ett agilt projekt. Man pratar hela tiden om att man ska leverera affärsvärde tidigt och ofta men vad betyder värde. Den enkla definitionen av affärsvärde är enligt mig ”något som beställaren kan använda i sin verksamhet för att tjäna pengar”.

En definition av värde som Tom och Kai Gilb har är:
Value is a perceived benefit: that is, the benefit we think we will get from something. It’s is relative to a stakeholder.

Alltså värde är något som är relevant för en intressent och som den intressenten uppfattar som en fördel.

Om man sedan pratar om affärsvärde så måste man också definiera vem intressenten är och i en försäljningssituation pratar man om tre olika typer av köpare:

Ekonomisk: Den ekonomiska köpare är den som skriver under kontraktet, ser till att projektet får de ekonomiska resurser det behöver och den enda person som kan säga ja till ett projekt.

Teknisk: Den tekniska köpare är den eller de som ansvarar för att projektet eller produkten som köps in möter tekniska specifikationer och organisationens normer. Tekniska köpare kan säga nej till ett projekt eller en produkt.

Användare: Slutanvändare av en produkt eller system. Kan också säga nej.

När man har slutfört en försäljning och fått ett signerat avtal är det allt för ofta som tekniska köpare och användare tar över projektet och den ekonomiska köparens behov (eller utlovat affärsvärde), samt hur de ska levereras, förbises.

Okej, så vidare till en definition av affärsvärde:
Business Value is the perceived benefit the Economic Buyer (and ideally the organization) will get from making investments to improve something of importance to them.

Äffärsvärde är alltså, precis som värde, en uppfattad fördel som den ekonomiska köparen kommer att få ut av en investering.

Hur mäter man då affärsvärde? Affärsvärde kan vara svårt att mäta direkt men det kan mätas om man använder en teknik som kallas Measurable Objectives. Därför kan vi säga att vi levererar affärsvärde om vi är på väg att uppfylla den ekonomiska köparens mätbara mål. Dessa mätbara mål bryts sedan ner till features som implementeras i systemet och varje feature uppfyller en eller flera av de övergripande målen.

Jag var på en presentation idag av Ryan Shriver, www.theagileengineer.com, och vi gjorde ett antal övningar runt Measurable Objectives vilket var väldigt intressant. Han hade även beräkningar där man kunde avgöra hur väl olika features man planerar att implementera uppfyller målen och vilken relation det finns mellan kostnad för implementationen och levererat affärsvärde. Detta kan man sedan då använda för att avgöra om man ska implementera feature A eller B.

Agile estimering och plannering

Tidigare har jag förespråkat att använda T-shirt sizing när man estimerar produktbacklog och sedan story points till sprintbacklog-tasks men efter att ha lyssnat på Mike Cohn idag så får jag nog tänka om! Visserligen ska man inte ändra det som funkar och i de projekt jag har varit med så har det fungerat riktigt bra. Men de nackdelar med t-shirt sizing som han tar upp går ju inte att bortse ifrån.

Ett problem är att använda M, L och XXL när man estimerar features på produktbackloggen är att man inte kan addera dessa tillsammans och en kund kommer alltid att vilja veta när man ska vara klar med ett projekt. Att då svara att vi är klara om 4 small, 3 medium och 2 large funkar inte. Man måste ha estimat som går att addera så att man kan ta reda på vilken hastighet man har och därmed också kunna säga när i tiden man kommer att vara klar.

Så vad Mike föreslår är man ska använda story points när man estimerar de items man har på sin produktbacklog. Den typen av estimering gör man normalt innan första sprinten när man gör sin releaseplanering. Man bör försöka komma igenom hela produktbackloggen men inte lägga för mycket tid på varje item (ca 20 i timmen bör man klara av). Nya items kommer att komma in på produktbackloggen kontinuerligt så därför måste man också kontinuerligt estimera under varje sprint. För att estimera produktbacklogen funkar det alldels utmärkt att använda sig av Planning Poker och då behöver man heller inte konverera sina estimat till timmar.

När man sedan ska planer det jobb man ska göra i första sprinten måste man veta vilken hastighet teamet har. Om man har ett team som har genomfört ett antal sprintar är det ju inget problem men om man har ett nytt team så finns det även tekniker för att ta reda på vilken hastighet teamet kommer att ha. Hastigheten baserar man då på hur mycket teamet tror att de kommer att kunna hinna med under nästa sprint och använder det som teamets hastighet.

När teamet sedan ska bryta ner features från produktbackloggen till uppgifter i sprintbackloggen måste uppgifter mätas i ideala timmar. Vi har gjort så att vi har spelat planning poker och satt story points på uppgifterna och sedan räknat om dessa till ideala timmar. Jag frågade Mike vad han tyckte om det och han sa att det är nog i det läget bättre att göra det ”the old fashion way” och bara sätta timmar på de olika uppgifterna. Jag har alltid förespråkat att man ska, även på uppgiftsnivå, dra nytta av allas input i estimaten men Mike menar att om man har en databasexpert i temat som säger att en uppgift tar fyra timmar så är det bara att sätta fyra timmar på den uppgiften. Att implemntera en feature på produktbackloggen blir mest troligt ändå flera olika uppgifter, tex att skapa en stored procedure, att modifiera objektmodellen, att anpassa gränssnittet samt att testa de olika delarna. Och då är det bäst att de olika experterna för de olika områdena får sätta timmar på uppgifterna.

Det jag tror att jag kommer att ta med mig till mitt nästa projekt är att lära mig mer om user stories för att få en bättre produktbacklog. Estimera produktbackloggen mha planning poker i story points och sedan bryta ner den till tasks i sprintbackloggen och direkt sätta optimalatimmar på dessa.

Man blir så lycklig när man känner att bitar faller på plats! Nu måste bara se till att också uppdatera min kurs :-D

Fråga via Messenger på min blog

Det är fantastiskt kul när någon kontaktar mig på Messenger genom min blog. Då känns det verkligen att det finns någon där på andra sidan som läser det man skriver då och då. Idag hände det för andra gången men den här gången var jag på lunch och kunde inte svara :-(

Frågan handlade om hur man estimerar uppgifter i en sprintplanering i Scrum och om man bör dela upp estimaten för en uppgift i implementation respektive i test.

På Sprint Definition Meeting (som man har innan Sprint Planning Meeting) kommer teamet överens med produktägaren vilka product backlog items man ska implementera under den kommande sprinten. Dessa bryter sedan teamet ner till uppgifter under sprintplanneringen och varje uppgift estimeras. Dessa uppgifter ska estimeras utifrån ett sedan tidigare definierat klart-begrepp där det i min värld absolut ingår test!

Så säg att "Klart" för ett specifikt team betyder "Kodat, Verifierat, Granskat, Incheckat", ja då ska estimatet på 5 story points innebära att det är just kodat, verifierat, granskat och incheckat. Om klart-begreppet istället är "Kodat & Incheckat" (vilket det är för många utvecklare) så har man aktivt valt att lägga test utanför sprinten.

Det kan så klart också vara helt okej att lägga test utanför sprinten. Om man tex har en testavdelning och en testprocess som är implementerad och fungerar bra så tycker jag inte att man ska riva den och flytta in testresurserna i teamen. I alla fall inte initialt, utan då tycker jag att man ska anpassa sig till det man har och se till att man ökar kvaliteten på sina leveranser till testavdelningen tex genom testdriven utveckling.

John, hoppas att det här var svar på frågan du ställde på messenger och om inte är det bara att du hör av dig igen!

Länkar till scrum & agile

I materialet till min Scrum-kurs som jag ger på Addskills eller på ett företag nära dig har jag en samling med länkar till verktyg, böcker, bloggar osv som kan vara bra att ha. Av någon anledning finns den inte med i det tryckta materialet så nu tänkte jag att jag lägger ut den här istället.

Länkar:

• http://www.mountaingoatsoftware.com/


• http://www.planningpoker.com/


• http://www.infoq.com/agile


• http://www.agilemanifesto.org/


• http://www.agilealliance.org/

Böcker:

• Ken Schwaber
• Agile Project Management with Scrum
• The Enterprise and Scrum
• Agile Software Development with Scrum


• Mike Cohn
• Agile Estimating ang Planning
• User Stories Applied: For Agile Software Development


• Jean Tabaka
• Collaboration Explained


• Kent Beck
• Extreme Programming Explained: Embrace Change (2nd Edition)


• Martin Fowler
• Refactoring: Improving the Design of Existing Code


• Andy Hunt and Dave Thomas
  
  • Pragmatic Unit Testing in C# with NUnit

Verktyg:

• nAnt: http://nant.sourceforge.net/


• CruiseControl.NET: http://ccnet.thoughtworks.com/


• CCNetConfig – Configuration Tool For CC: http://www.codeplex.com/ccnetconfig


• TFS Plug-in for CC.NET: http://www.codeplex.com/TFSCCNetPlugin


• NUnit: http://www.nunit.org/


• CIFactory – Set up CI in a minute: http://www.cifactory.org/joomla/


• nCover – Code Coverage for .NET: http://ncover.org/site/


• XTUnit – Rollback för nUnit-tester: http://tools.osherove.com/


• TestDriven.net: http://www.testdriven.net/

Connectas Planning Poker-kortlekar klara!

Nu är äntligen Connectas kortlekar för Planning Poker tryckta och klara. Det är inte utan lite stolthet som man får börja sprida ut kortlekar till agila projekt runt om i organisationen. I det projekt jag jobbar i nu kunde det inte ha kommit lämpligare utan vi fick direkt användning för dem i en väldigt lyckad pokersession i fredags.

Mest troligt har vi tyvärr tagit på oss för mycket jobb i den här sprinten. Speciellt med tanke på att jag själv är hemma med sjukt barn idag och imorgon och håller ett seminarium i Visual Studio 2008 tillsammans med Addskills på fredag. Det är rätt många timmar som försvinner i ett team på fyra personer i en sprint på två veckor :-S

Nu har jag precis skickat in mina slides inför fredagen och imorgon ska jag nöta mina demos.

EssUp kommer att bli gratis

Början av det här inlägget handlar mycket om besvikelse men det kommer att vändas lite längre ner… Jag säger inte att det vänds till odelad positivism men det vänder i alla fall…

På TechEd Developers i Barcelona i november träffade jag representanter för Ivar Jacobsons företag Ivar Jacobson Consulting för att prata lite mer om deras Essential Unified Process (EssUP). Jag blev ganska besviken ett år tidigare när jag var på TechEd Developers och lyssnade på Ivar prata om EssUP för första gången men tänkte att jag skulle ge den en ny chans.

Även denna gång blev jag besviken då jag fick informationen att EssUP bara kommer att vara tillgängligt för Ivar Jacobson Consultings kunder. Dvs att om man anlitar dom och deras konsulttjänster så får man också tillgång till processen.

Dag König skrev i ett inlägg på hans blog att han var glad att EssUP släpps för Team Foundation Server så jag ställde frågan till honom om det stämmer att EssUP inte är gratis. Han ställde frågan vidare till Ivar Jacobson Consulting och fick samma svar: EssUP och EssWork är idag gratis för alla våra kunder. Man får alltså tillgång till allt vårt IP som en del av ett engagemang (utbildning och/eller konsultuppdrag). Det här känns helt galet! Att idag lansera en agil process som är så starkt kopplad till ett företag känns helt fel.

Någon dag senare läste jag en kolumn i Computer Sweden skriven av Ivar Jacobson och då tänkte jag att jag måste gå till källan för att få rätt information. Så jag skrev ihop ett mail till Ivar och ställde samma fråga: ”Hur ska jag som fristående konsult kunna använda mig av EssUP på mina kunder om jag inte får tillgång till materialet?”

Någon dag senare fick jag också ett svar från Ivar! Svaret var väldigt positivt men det som är lite oroande är varför de ger så olika svar på samma fråga. I alla fall så var Ivars svar: ” När det handlar om ”produkterna” EssUP and EssWork så skall dessa bli fria. Innan de är fria genomgår de en förfining tillsammans med 10-20 kunder över hela världen.Vi vill inte göra något fritt som man inte kan lyckas med utan hjälp av oss.”

EssUP kommer alltså att bli gratis och helt fritt. Paketet kommer att doneras till Eclipse Process Framework där det kommer att finnas en EssWork community. Det finns också verktygsstöd för Visual Studio och Eclipse på klientsidan samt för Team Foundation Server och JIRA på serversidan.

Jag kommer att skriva fler inlägg om EssUP inom kort när jag börjar få tag i material och testat att installera EssWork på Team Foundation Server.

Som sagt är jag inte odelat positiv till EssUp men jag ska ge det en ärlig chans och min största besvikelse har vänt och förhoppningsvis kommer jag att hitta delar jag kan använda även om det skulle vara Scrum som används som process.

Sagan om Ringen - live

Igår var jag och en kompis och såg Howard Shore och Kungliga Filharmonikerna framföra musiken från Sagan om Ringen-trilogin. Det var en mäktig upplevelse att se Howard med stor inlevelse dirigerade orkestern och den makalösa kören. Till stöd för minnet så projicerades också illustrationer från filmerna på filmdukar runt orkestern. Det blev dock lite väl långt kan jag tycka och jag hade vissa stunder lite svårt att koncentrera mig och började istället tänkte på annat. Vilket inte är fel – hur ofta får man möjligheten att sitta och filosofera till en sådan bakgrund!

Mina funderingar gick oftast till hur mycket en dirigent egentligen tillför? Någon som vet? Här har vi ett minst sagt högpresterande team av otroligt skickliga individer och tillsammans presterar något som i sin helhet ger mycket mer än summan av dess ingående delar. Men frågan är; skulle de klara det lika bra utan sin ledare? I det här fallet är teamet (Filharmonikerna) vana att jobba tillsammans, de kan den domän de verkar i och känner till varandras styrkor och svagheter. Men deras Scrum master (dirigenten Howard) har inte jobbat nått med teamet så vad har han egentligen att tillföra?

Jag pratade med en stolt mamma till ett av barnen i kören som även var på genrepet och där hade Howard tydligen avbrutit många gånger och guidat orkestern när de inte spelade som han ville så visst är det så att han gör skillnad. Men eftersom att teamet redan från start är så pass högpresterande så behövs inte så mycket guidning från Scrum Mastern utan han (i det här fallet) kan bara göra små justeringar för att nå perfektion.

Min Scrum-artikel är online!

Jag har skrivit en artikel för AddSkills (fd Jönsson och Lepp) om Scrum och nu, i samband med namnbytet och lanseringen av deras nya site så finns den online.

Jag har precis avslutat det andra tillfället av min två-dagars-kurs Scrum i Praktiken och hade nio mycket nöjda deltagare. De sista sidorna i mitt kursmaterial är lite rekommenderad läsning och länkar. Detta har av någon anledning AddSkills klippt bort så jag tänkte att jag ska få till en blog-post med det innehållet.

Den här gången har det varit väldigt väldigt mycket frågor om allt från enhetstesting till hur man bemannar Scrum-team och hur 17 man ska kunna estimera i Story Points. Väldigt utmanande och utvecklande!

Nu när den här kursen är avslutat blir fokus helt på en jump start i Visual Studio som jag ska hålla nästa vecka på Microsoft för Microsofts räkning. Där är maxantalet 50 personer vilket ska bli en ny upplevelse!

Kortlek för Planning Poker

På Connecta håller jag på att jobba med att ta fram en kortlek för Planning Poker. Just nu håller vi på att ta fram en design av korten och förhoppningsvis ska de vara klara till i Januari 2008.

Min plan med kortlekarna är att använda den i min kurs på Jönsson och Lepp som heter Scrum i Praktiken där ett av momenten är att gå igenom och prova på Planning Poker samt att ge den till kunder och annat löst folk som är intresserade.

Hör gärna av dig om du är intresserad av en kortlek så ska jag se till att skicka en så snart de är klara.

Första Scrum-projekt för kund

I våras var jag på intervju för ett projekt på en av Connectas kunder. Under intervjun pratade vi en del om deras arbetssätt och det som de beskrev var väldigt likt Scrum så mitt förslag var att vi skulle inför Scrum fullt ut. De nappade på förslaget så när jag började så började teamet jobba efter Scrum.
Vi var ett relativt litet team på bara fyra personer och jobbade mot personer som var vana att på att snabbt få resultat. Så här i efterhand skulle vi nog kanske ha haft kortare iterationer men överlag så funkade det rätt bra.

Första iterationen var en katastrof. Vi tog på oss allt för mycket jobb och tog inte tillräckligt med hänsyn till att jag var helt ny i projektet och att en medlem i teamet skulle vara borta en hel del. Andra iterationen gick dock mycket bättre och vi levererade vad vi hade åtagit oss på utsatt tid.
Några saker som jag tar med mig från den tiden är:
• Sätt ett mål för sprinten. Målet för sprinten är otroligt viktigt när man ska fokusera på vad man ska göra och säkerställa att man är på väg i rätt riktning.
• Definiera vad klart betyder!
• Automatisera deployment, byggen och tester.

De här erfarenheterna är något jag tagit med mig till den kurs jag tagit fram och som jag nu ger på Jönsson och Lepp som heter Scrum i praktiken.