Archive for mars, 2010

h1

Hög-tempo vecka med seminarie, kurs och självinsikter

fredag, 19 mars, 2010

Veckosummering… De första blev tre intensiva dagar i projektet. Frukostseminariet gick fantastisk bra och för några timmar sedan kom jag hem från en innehållsrik, spännande och utmanande kurs. Phew.

Projektet

I början på veckan lyckades vi få upp utkastet till vårens releaseplanen på väggen baserad på tidigare dialog med beställaren. Många detaljer saknas än men det känns bra att fått den visuell. (Varje kolumn är en sprint. Raderna fylls med projekt. Vi anstränger oss för att, om möjligt, fokusera på ett projekt i taget.)

Nu återstår att förankra den hos de olika projektens ägare och övertyga dem om att det här är rätt ordning för hur vi använda teamets energi och fokus på. På onsdagen hade vi Story Time Session inför nästa Sprint som börjar nästa vecka.

Bland annat.

Det var mycket som hans med under veckan.

.

Frukostseminariet

På torsdagsmorgonen var det dags för frukostseminarie: Scrum för ledning, ledare och kravställare. Det blev ett bra pass. Publiken kom från många olika företag och hade spridda roller och positioner. Gemensamt var att alla sitter i (eller inom kort kommer att sitta i) beställarens position gentemot scrum projektet.

Det kom många riktigt bra frågor och flera spännande diskussioner uppstod. Ämnena berörde allt från beställarens och organisationens roll, vad som behöver (och vad som inte behöver) förberedas och ske innan teamet kan börja sprinta, olika mekanismer för agila kontrakt, produktägarens ansvar, roll och befattning. Och mycket mera 🙂

.

Kurs och självinsikter

Direkt efter seminariet skyndade jag iväg mig till en två dagars kurs som kort kanske kan beskrivas en introduktion för sälj- och ledar-trainees. Såklart en del formella kunskapspass men fokus låg på dig själv, du, dina förmågor och kvaliteer, självinsikt, din roll i en grupp, du som ledare, osv. Oerhört spännande! Inga revolutionerande nyheter kanske men mycket givande att få nya verktyg för att förstå sig själv och andra med. Många nya tankar väcktes och jag tog med mig många funderingar hem. Extra roligt såklart var att det leddes av självaste branschchefen som har enorm erfarenhet och många visa insikter.

Nu återstår bara att se vart detta leder – eller rättare sagt, vart jag kommer låta det leda mig.

.

Nu är det helg!

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

LOL! Toyota kör vattenfall

onsdag, 17 mars, 2010

Läste precis ett fantastiskt spännande reportage av Henrik Kniberg från Toyotas mjukvaruutvecklingsavdelning. Det visar sig att källan till Lean inte lever som de lär – de kör fortfarande vattenfall!

Henrik Kniberg berättar på sin blogg om hur han (tillsammans med några andra, bl.a. Tom and Mary Poppendieck, m.fl.) åkte på ”Lean study tour” till Japan i april 2009 för att lära sig hur Toyota jobbar Lean i sin verksamhet. De träffar bland annat Satoshi Ishii, chefen för embedded software, som tar dem på en rundtur och berättar om deras historia, deras problem och om deras framtidsplaner – och hur de jobbar enligt vattenfallsmodellen!

”We are trying to learn how to apply TPS [Toyota Production System = Lean] to software development” var en av hans reflektioner. Kanske en mycket bra idé med tanke på vad som hänt på sistone… Jag menar, man tappar ganska ordentligt med tyngd och poäng när man under föreläsningar eller kurser refererat till Toyotas filosofi – ”bygg in kvalitet”.

Läs hela hela artikeln på Henriks blogg här.

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

Ny bok om Scrum & Kanban från ”the trenches”

måndag, 15 mars, 2010

Henrik Kniberg skrev 2007 den populära boken ”Scrum and XP from the Trenches”. Nu har han tillsammans med Mattias Skarin skrivit en ny bok om hur man kan kombinera det bästa från Scrum med det bästa från Kanban – ”Kanban and Scrum – making the most of both”.

”Scrum and XP from the Trenches” slukade jag snabbt när jag kom över den första gången och är oftast den första bok jag rekommenderar till personer som vill ha lästtips om Scrum. ”Kanban and Scrum – making the most of both” var precis lika välskriven och lättläst. Jag mer eller mindre sträckläste den under söndagseftermiddagen.

Boken går igenom vad likheterna och skillnaderna är mellan Scrum och Kanban, tar upp många exempel från verkligheten, innehåller många bra och förklarande diagram och illustrationer samt en bra case-study av hur två team implementerade Kanban.

Jag känner inget direkt behov att byta ut Scrum mot Kanban i mitt nuvarande projekt, men som Henrik skriver i boken – Scrum och Kanban är bara verktyg. Jag känner mig dock inspirerad och kommer antagligen att försöka bygga på vår Scrum process med några av godbitarna från Kanbans verktygslåda (speciellt försöka hitta ett sätt för oss att arbeta med Work-in-Progress begränsningar).

Däremot skulle jag rekommendera support och maintanance team därute att ta sig en rejäl funderare på om inte Kanban skulle göra livet bättre.

”Kanban and Scrum – making the most of both” finns för gratis nedladdning här på InfoQ:s hemsida. Du måste dock du registrera dig och bli medlem för att kunna ladda hem pdf:en.

h1

Scrum Gathering 2010 i Orlando? Vad hände?

söndag, 14 mars, 2010

Är lite småbitter över att jag inte fick möjlighet att göra en liten tur till Orlando i USA och delta på Scrum Gathering 2010. Men å andra sidan, vad är väl en konferans på Gaylord Palms Resort & Convention Center?

Jag var hur som helst såklart nyfiken på vad som hände och diskuterades och hittade en fina sammanfattning på Scrum Alliance hemsida.  (Klicka här för att läsa summeringen över de tre dagarna.)

Konferansen pågick den 8:e till 10:e mars. Det fanns många spännande seminarier och workshops på agendan men eftersom det övergripande temat på träffen var ”collaboration” bestod (såklart) hela dag tre av Open Space.

Precis som brukligt på Open Space samlades alla deltagare i en cirkel på morgonen för att föreslå, planera och organisera dagens Open Space pass. Dagen leddes av ingen mindre än Open Space grundare Harrison Owen.

Jag gissar att bilden ovan är tagen strax innan alla deltagarna stormade in i rummet. Fatta vilken kreativitet och energi som måste ha sprudlat där den dagen… Men nej, nej. Jag är inte avundsjuk.

Fast jag kan ju alltid göra ett försök att ta mig till Scrum Gathering i Shanghai i April, eller till Sydafrika i September.

Troligt.

PS. Fler bilder finns här. DS.

.

Uppdatering: 2010-03-19

Nu finns anteckningarna från ett trettiotal av Open Space passen publicerade på ”Community of Scrum Gathering, Orlando 2010” hemsida.

http://sg2010usdialogroom.posterous.com/reference-list-of-open-space-sessions-open-sp

h1

Gratis frukostseminarie; Scrum för ledning, ledare och kravställare – Om att arbeta mot en agil leverans

lördag, 13 mars, 2010

Jag höll detta seminarie i Sundsvall och Oxelösund under januari och ser nu fram emot nästa vecka då det är dags för Stockholm.

Båda tidigare tillfällen blev både välbesökta och uppskattade och jag hoppas det blir precis lika roligt på torsdag med mycket frågor och intressanta diskussioner. Har du inte tid eller möjlighet att komma själv, tipsa gärna kollegan eller varför inte den motsträviga chefen som inte verkar gilla ordet ”agile”?

Välkommen!

.

Scrum för ledning, ledare och kravställare – Om att arbeta mot en agil leverans

Precis som i traditionella projekt är utmaningarna många, men vad som dessutom sker i agila projekt är att behovet av samarbete och kommunikation mellan IT, kravställare och ledning ökar.

Högre krav ställs på att det sker kvalitativ och löpande dialog mellan alla parter. Ledning och kravställare erbjuds helt nya verktyg för planering, uppföljning och prognostisering. För första gången ges möjligheten att kontinuerligt se ett projekts sanna status. Problem, konflikter och risker synliggörs tidigt och kan därmed också adresseras för att maximera projektets framgång.

Tid: Torsdagen den 18 mars, klockan 08.00-10.00. Frukost serveras från klockan 07.30.

Plats: Sogetis kontor i Solna Business Park, Svetsarv 4, våning 5.

Seminariet (inkl. frukost) är kostnadfritt.
Mer information och anmälan här
.

h1

Skälet till varför Agil utveckling lönar sig

fredag, 12 mars, 2010

Denna fem minuter långa video beskriver enkelt och övertygande varför det lönar sig att jobba agilt, dvs. varför levererat värde och ROI (Return Of Investment) blir högre när man…

  • arbetar i korta iterationer
  • ofta leverera små inkrement av systemet/produkten
  • leverar första versionen av systemet/produkten så tidigt som möjligt
  • har tät feedback från kund och verksamhet

Med andra ord, varför det lönar sig att jobba Scrum.

h1

Scrum på 10 minuter

torsdag, 11 mars, 2010

Hittade denna video på YouTube för en liten tid sedan. En riktigt ok sammanfattning av Scrum på endast tio minuter.

Håller kanske inte med om hans påstående att man är redo att tuta och köra efteråt men videon ger ändå en bra introduktion och förklar bra de grundläggande momenten och scrums roller.

h1

Belönar Scrum dåliga beteenden?

onsdag, 10 mars, 2010

En fråga jag ibland klurar på är om Scrum belönar vissa former av ”dåliga” beteenden? Dvs. finns det mekanismer i Scrum som uppmuntrar till fusk eller genvägar i någon form inom något område?

Jobbar jag exempelvis som utvecklare i ett vattenfallsprojekt vågar jag efter ett tag inte ge uppriktiga estimat då jag blir bestraffad om min arbetsprognos inte matchar den faktiska tid det tog för mig att göra jobbet. Konsekvensen blir att jag ger pessimistiska estimat med mycket luft. Detta blir jag såklart belönad för då jag nu lyckas hålla mina deadlines. Att jag får massa tid över för att klicka refresh på aftonbladet är ju iofs trevligt för mig – men ett ordentligt slöseri med tid och pengar. Detta är ett  exempel på när en process riskerar belönar ett dåligt beteende.

Frågan blir således: Om projektet drivs enligt Scrums alla regler skulle teammedlemmar kunna praktisera ”dåliga” beteenden som de senare belönas för?

Om svaret är ”nej” betyder det att Scrum är den magiska projektmodell som alla borde köra.

Är det så?