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?

Tillbaka!

Första dagen tillbaka efter en ganska lång ledighet över julen vilket har varit otroligt skönt. Omställd till att äta frukost kl 11 var det lite tungt att kliva upp tidigt imorse och försöka få upp barnen i tid till dagis och annat. Men det funkade till slut!

Har medvetet varit så frånkopplad som möjligt under ledigheten och fick börja dagen med att skriva upp en lista med allt som måste göras. Enklaste sättet att ta reda på det är att gå igenom senaste månadens mail och lägga. Tyvärr funkar jag så att det som inte finns i ett mail, det finns inte. Så drygt 800 mail senare känner jag mig lite mera uppdaterad. (nej, jag har inte läst alla idag…)

På listan hamnade saker som att planera lite utbildningar, teamkonferens, skriva till blogginlägg, avsluta personer som tyvärr valt att sluta på Connecta och planera för såna som börjar nästa vecka.

Det verkar dock som att andra har jobbat medan jag varit ledig för det har hänt saker sista veckorna!

Windows Azure
I ett av mina många mail fanns inbjudningskoderna till Windows Azure Services så nu ska det bli kul att testa det på riktigt också. Passande nog har min artikel om Windows Azure, som jag skrivit för Addskills, också publicerats. Den finns med i årets kurskatalog. Där finns också min kollega Hans Sterby med som har skrivit en artikel om F#.

Månadens profil på MSDN
I höstas blev jag intervjuad av Johan Lindfors på Microsoft vilket resulterade i att jag blev månadens profil i december. Grymt kul!

TechDays
Den 17 och 18 mars kommer Microsofts konferens TechDays att hållas i Västerås och under julledigheten har siten fått ett uppdaterat innehåll. Nu finns en hel del av sessionerna och talarna med. Från Connecta får ni hålla utkik efter fyra talare på tre sessioner:
• Varför F# och vad är funktionell programmering? – Hans Sterby
• SharePoint Workflows, experiences from the field – Daniel Karlsson (med Mattias Lindberg från Microsoft)
• Runda gränssnitt i en fyrkantig värld - Hur man kan kombinera styrkan i WPF för rika gränssnitt med Office 2007 – Pelle Johansson & Björn Eriksen
Missa inte chansen att delta i vad jag tror kommer att bli en riktigt bra konferens på (nästan) hemmaplan.

Projectplace
Från januari kommer jag att börja skriva inlägg på Projcetplace blogg. Projectplace har funnits sedan 1998 och erbjuder ett webbaserat projektverktyg. Det är den webbplats jag brukar referera till när man säger att Software As A Service är något nytt. Där kommer jag att skriva om allt möjligt som har med agile och Scrum att göra.

Microsoft Surface!
Nu är det äntligen klart. Vi kommer att beställa ett Surface-bord till Connecta! Mycket mer om detta senare!

Agila människor är speciella... Del 2

Igår kväll på avslutningsmiddagen för konferensen fick jag svar på vad de asiatiska dansarna gjorde. De var alla japaner som förberedde ett uppträdande på middagen. En av dem fick en utmärkelse från Agile Alliance och han tog med sig sina landsmän upp på scen och sjöng sången Dear XP.

Agila människor är speciella...

Imorse när jag hade hämtat frukost och var på väg till en TDD-clinic i C# så gick jag förbi ca 20 asiatiska killar och tjejer som stod och dansade en dans, spelade i maraccas samtidigt som de kollade på en skärm. Exakt vad de gjorde där kl åtta på morgonen är för mig fortfarande en gåta men de var i alla fall glada!

Det som man ser på den här konferensen är att folk som jobbar med agile utvecklig är helt klart passionerade för det de gör!

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

Agile 2008

På plats i Toronto och imorgon börjar konferensen Agile 2008. Bor på 24de våningen och idag väcktes jag av ett falskt brandalarm från 15 våningen. Lite lätt jet-laggad kunde jag inte somna om så nu tänkte jag bege mig till Torontos stora turistattraktion – CN Tower med världens högsta, av människan skapade, observatorium.

Har för övrigt lite problem med att få ström till min dator. Igår köpte jag en konverterare på Best Buy och den funkade ju bra, till allt utom min dator. Datorn har en bredare kontakt… Någon som har nått tips på var man kan köpa en som funkar även till datorsladdar?

Annars så ser jag väldigt mycket fram emot att konferensen ska dra igång imorgon! Ska bli skönt att få lite mera kolla på läget för än så länge har jag ingen aning om var de olika föreläsningssalarna ligger. Nåja, det löser sig nog och då kan jag se fram emot föredrag under veckan av så väl Mary Poppendieck och Mike Cohn!

(I mitt förra inlägg sa jag att mitt nästa inlägg skulle handla om min första erfarenhet från verkligheten med LINQToXML men det får vänta tills jag kommer hem.)

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/

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.