Archive for april, 2010

h1

OpenAgile – Scrum för icke-IT

måndag, 12 april, 2010

Sprang nyligen på OpenAgile när jag klickade mig fram igenom bloggartiklar om Scrum och Agila utvecklingsmetoder. Att det fångade mitt intresse tror jag beror på att OpenAgile är en agil utvecklingsprocess anpassad och designad för att vara tillämpar på ett bredare spektra än enbart mjukvaruutveckling.

Jag har tidigare jobbat som projektledare i stora ideella projekt där man inte har lyxen att kunna säga ”Gör ditt jobb annars får du ingen lön!” utan allt handlade om frivilligt engagemang, motivation, ansvarskänslaoch att det skulle vara roligt att jobba. OpenAgile hade nog fungerat riktigt bra där.

Vidare så är det svårt att tillämpa Scrum utanför mjukvaruutvecklingsprojekt. Man kanske inte har resurser på heltid i ett team, det är kanske omöjligt att hålla korta sprintar i verksamhetsprojekt, involverade personer variera kraftigt eller förändras mycket med tiden, för att nämna några exempel. OpenAgile försöker lösa även dessa bekymmer.

Jag tror nog att OpenAgile kan fungera bra för vissa organisatoner som har en lös struktur eller för projekt som inte har strikta deadlines i tiden. Den har några intressanta vinklingar (beskriver t.ex. fler roller än Scrum även om bara en av dem är obligatorisk), den är betydligt lättviktigare än Scrum, fokuserar hårt på teamet och teamanda, tillåter avbrott i arbetet.

Det som jag finner mest spännande och roligast är dock kanske att detta är just en variant av Scrum som (förhoppningsvis) fungerar fint i alla sammanhang och miljöer. 🙂

.

OpenAgile in a nutshell

OpenAgile är en Agil utvecklingsprocess som fokuserar på att leverera värde. Till skillnad från Scrum som ägs av Scrum Alliance så är OpenAgile open source och under utveckling (av naturliga skäl eftersom det är open source men jag tror det också beror på att det väldigt nytt också).

I korthet så fungerar det så här: Teamet (det finns bara en obligatorisk roll, nämligen team-medlemmen) jobbar i cykler (iteration). Under en cykel träffas man minst fyra gånger för ett Progress Meeting för att diskutera hur det går, vad man lärt sig och vilka tasks man ska göra härnäst, dvs. under nästa Work Period (som kan vara allt ifrån några timmar till flera veckor). Alla väljer på frivillig basis vilka och hur många tasks.

En cykel inleds med tre möten:

  • Reflection (Vad hände förra cykeln? Vilka blev resultaten?),
  • Learning (Vad lärde vi oss? Vilka nya principer har vi identifierat? Vilka nya färdigheter har vi utvecklat?) oc
  • Planning (Vad ska vi göra denna cykel? Vilka tasks krävs för att leverera uppsatta mål?).

OpenAgile säger inget om hur korta (eller långa) cykler ska vara, bara att man ska ha några stycken innan slutmålet är nått.

OpenAgile lutar sig på tre grundvärderingar:

  • Ärlighet (dvs. ljug inte, fuska inte, lär från dina misstag),
  • Rådgivande beslutsprocess (dvs. alla ska delta och bidra i beslutfattandet och vara eniga om beslutet) och
  • Läro-cykeln (smått förenklat: 1) Reflect, 2) Learning, 3) Planning och 4) ActionI denna process ska vi vara objektiva, kunskapssökande, tycka om det vi gör och vara modiga).

Det verkar som om OpenAgile visat sig vara extra populär just i idéella projekt som inte har med IT att göra. För lite bättre, korrektare och längre förklaringar av OpenAgile kika gärna på länkarna under illustrationerna.

.


.

Jämförelse av OpenAgile och Scrum:
http://www.agileadvice.com/2010/02/01/uncategorized/comparison-of-openagile-with-scrum/

En wiki för OpenAgile (under utveckling)
http://wiki.openagile.org

Enkel summerande presentation på 22 slides
http://www.slideshare.net/mberteig/introduction-to-the-openagile-learning-system

En sida med presentationer, use-case studies, m.m.
http://www.openagile.com/

OpenAgile Primer (PDF, 1.22MB)
http://www.openagile.com/sites/default/files/OpenAgile Primer.pdf

h1

Hantera och bevaka risk med en Risk-Burndown

fredag, 9 april, 2010

Jag har redan hittat flera sätt att förbättra teamets Impediment-wall, bland annat med en Impediments Tracker, och en Risk Burndown. Har med andra ord gjort lite re-factoring och optimization på vår arbetsmetodik.

Läste under lunchen en nytt mycket intressant blogg-inlägg av Mike Cohn, Managing Risk on Agile Projects with the Risk Burndown Chart. Agila utvecklingsmetoder såsom Scrum hanterar risk på daglig basis naturligt med sina korta feedback-cykler, dagliga möten, öppen insyn i teamets progress, ärlighet med status gentemot stakeholders samt tät dialog i teamet och kontinuerlig hantering av impediments. Men Mike argumenterar för att det trots det kan vara en god idé att synliggöra de risker som finns och hur de förändras och hanteras under projektets gång.

Jag nappade genast på Mikes förslag och insåg att jag med minimal ansträngning kunde implementera hans förslag hos oss.

För varje risk-lapp bedöms risken för att ”det” inträffar samt ”kostnaden” i antal dagar försening om risken inträffar. Dessa två värden multipliceras med varandra och lappens risk-värde. Måndag varje vecka summeras risk-poängen för alla risk-lapar och Risk-Burndownen uppdateras.

När projektet närmar sig release ska självklart denna risk helst nått noll. Risk-Burndownen kommer från och med nästa vecka dessutom bli ett eget stycke i veckans statusrapport för att ytterligare synliggöra gentemot stakeholders.

Så, nu ser väggen ut som på bilden till höger. (Ett skarpt öga ser också att det tillkommit ytterligare en burndown. Vet inte riktigt hur jag ska använda denna ännu utöver att synliggöra den övergripande progressen på Impediment-wallen. Jag räknar helt enkelt antalet öppna Impediments, Risks, Questions och Tasks på daglig basis. Kanske skriver om denna senare beroende på hur experimentet faller ut.)

.

Och här följer mer begripliga illustrationer över Risk-Burndownen samt ett exempel på en Risk post-it.

.

h1

Min nya Impediments-wall

torsdag, 8 april, 2010

Igår fick jag krypa till korset. På retrospectiven i tisdags var det någon som sa; ”Ska inte en Scrum Master ha en synlig Impediment lista?”. Jovisst är det så…

Det blev en action. Bara att inse att det är en sak att föreläsa och dela ut uppmaningar och utmaningar och en helt annan att leva upp till vad man pratar om i vardagen. **

Nu var detta kanske inte en så allvarlig Scrum-synd, kanske mest jag som tyckte det var lite pinsamt. Med ändå.  Självklart är transparans och synbarhet en grundläggande agil princip. Det ska vara enkelt för vilken stakeholder som helst att med minimal ansträngning få en direkt och ”sann” insyn i hur det går för projektet. (En Impediments lista består av hinder och frågetecken som Scrum Masters ska undanröja för teamet så att de kan jobba effektivt och oavbrutet.)

Så igår skapade jag mig utrymme på en av mina väggar och kontstruerade mig en ”Impediments wall”. Flyttade över delar av punkterna i min rullande dags-check-lista till väggen. (Gillade den skarpt eftersom den var enkel och portabel. Väggen står ju där den står.)

Inget rocket sciense direkt. Några lappar, lite svart isoleringstejp, massa post-its i olika färger och en tuschpenna samt någon minuts funderande.

Jag gissar dessutom att väggen kommer förändras med tiden och att färgerna kommer att skifta i antal och betydelse. Så här ser den ut just nu iallafall. Lapparna skiftar såklart i antal och i position tätt under dagen.

.

Och här är en schematisk bild av min Impediments-wall. (Bilden tog förövrigt längre tid att rita än det tog att sätta upp den faktiska väggen.) Jag hoppas bilden är självförklarande, annars får du mer än gärna skriva en kommentar och fråga.

..

[Dåliga] Ursäkter för att jag inte haft en Impediment-wall tidigare:

  • Jag tyckte om min portabla att-göra-lista (fast det var iofs bara jag som kunde se den)
  • Teamet sitter inte på samma kontor och besöker sällan kontorsrummet (dvs. de skulle sällan sett den ändå)
  • Stakeholders har inte frågat efter den (med de har å andra sidan inte vetat om vad de saknat)

Så! Nu känns det bättre 🙂

.

** Jag är förövrigt aldrig så nervös som när jag föreläser och representanter från kunden jag just nu jobbar för sitter i publiken. Jag är livrädd för att dom efteråt ska komma till mig och anklagande fråga; ”När du förelästa berättade du för oss att man borde göra <si> annars <så>. Jag håller med och det låter vettigt. Men varför gör du inte så?”

.

UPDATE: Historien fortsätter på ”Hantera och spåra riks med en Risk-Burndown”

h1

Genvägarna till det hyperproduktiva teamet

onsdag, 7 april, 2010

Det hyperproduktiva teamet är ett uttryck som ofta florerar i Scrum litteratur och i diverse bloggar och som syftar på teamet som har nått en nivå av ansvarstagande, hängivelse, produktivitet och samarbete som låter dem vara långt mer effektiva i sin leverans av kvalitativa och värdehöjande funktioner och features än ”normalt” – hyperproduktivitet. Här och nu avslöjar jag genvägarna dit!

.

*trumvirvel och en konstpaus*

.

Dom genvägarna finns såklart inte. Tyvärr. Förlåt om jag i ingressen ingöt falska förhoppningar. Det innebär såklart hårt arbete, mycket träning och ibland en stor dos tålamod. Men – jag tror å andra sidan följande punkter är förutsättningar för att över huvud taget nå en högre nivå av produktivitet inom ett team:

  • Följ och efterlev agiles värderingar och de agila principerna. Kör projektet Scrum – kör Scrum fullt ut! Varje moment och regel finns där av ett skäl. Bemästra processen och verktygen.
  • Stakeholders och produktägaren måste visa (och bevisa) för teamet att teamet har  mandat att organisera och styra sig själva och att de (stekeholders och produktägaren) har förtroende och tillit till teamet.
  • Praktisera ”Inspect Adapt Improve”. Ta Sprint Retrospectives på allvar. Säkra stöd hos styrgrupp och organisation att genomdriva nödvändiga förändringar.

Jag är övertygad om att ifall teamet upplever stöd och tillit från ledare och ledning och ges tid att organisera sig själva så kommer dom nå ett tillstånd av hyperproduktivitet.

.

Om du fick samla nio valfria polare, skulle ni också kunna bygga ett hus på en helg?

.

Om du ändå gärna vill tro på att det verkligen existerar enkla genvägar till hyperproduktivitet föreslår jag följande länkar:

Self-Organization in Scrum
Powerpoint från Jeff Sutherland,
http://jeffsutherland.com/SelfOrganizationGoogle5Sep2008.pdf

The Secret Sauce for Improving your Scrum team
Google techtalk från februari 2009. Talare Jeff Sutherland.
http://www.youtube.com/watch?v=M1q6b9JI2Wc

Shock Therapy:  A Bootstrap for Hyper-Productive Scrum
Artikel på rapidscrum.com,
http://www.rapidscrum.com/Shock_Therapy.html

h1

”Hur rolig var sprinten?”

tisdag, 6 april, 2010

Idag brände vi av en radda produktiva och roliga team-workshoppar. Först ut på morgonen var en nästan 3,5 timme lång retrospective. Kändes förlösande att konstruktivt och kritiskt granska oss själva, vårt samarbete, vår dialog med (och beroende gentemot) organisationen och styrgruppen.

.

1. Etablerade agenda

Först etablerades dagens syfte och agendan med tidshållpunkter presenterades. Detta dels för att time-boxa passen men också för att skapa en helhetsbild att hänga upp arbetet på.

Tog 2 minuter.

.

2. Tog teamets temp

Det första jag gjorde var att be teamet snabbt och individuellt svara på en rad frågor.

1) Hur rolig var sprinten?

2) Hur nöjd är du med
din egen insats/prestation?

3) Hur nöjd är du med teamets
insats/prestation?

4) Hur bra var teamets förutsättningar
efter avklarad Sprint Planering?

5) Hur hög arbetsro rådde under sprinten?

Skalan gick från 9 (superbra) till 1 (värdelöst). Dessa temp-frågor kommer upprepas varje retrospective. Svaren kommer sparas och trackas (genomsnittliga värdet) över tiden och kan sedan analyseras och diskuteras (t.ex. jämföras mot velocity, drag, etc.)

(Nästa gång kommer vi skriva ner våra poäng först i hemlighet var för sig innan vi sätter upp prickarna. Detta för att minimera risken att påverkas av redan uppsatta prickar. )

När alla hade besvarat frågorna med sina prickar gjorde vi en super kort reflektion men stannade inte upp för djupare analys utan gick raskt vidare till nästa punkt. Syftet med övningen är endast att snabbt få igång tankeverksamheten, minnas tillbaka till den gångna sprinten och få upp energin i rummet.

Totalt tog detta cirka 10 minuter.

.

3. Brainstorming

Efter att vi tagit temperaturen på teamet gick vi snabbt vidare till ”Brainstormning”. Alla tilldelades små post-its på vilka man skulle skriva ner sina reflektioner, åsikter, tankar m.m. och sätta upp dem på väggen. Detta gjordes utan struktur och med högt till tak. Inga åsikter eller känslor är för dumma för att inte tas upp och synliggöras. Närhelst man skrivit en lapp sattes den upp och teamet diskuterade punkten tills alla förstått vad författaren ville säga eller ge uttryck för.

Detta är teamets tillfälle för självreflektion, självgranskning, förlösning, diskussion, tänka högt, dela med sig av gjädje och frustration, fånga upp idéer och förslag på förbättringar.

Om dynamiken i gruppen är sådan att vissa talar högt, mycket och gärna medans andra är tysta och blyga behöver denna del av retrospectiven en struktur och utformning för att alla ska få komma till tals och känna sig delaktiga.

Andreas klurar på sin egen nyss uppsatta lapp

Lapparna sorterades in i följande kategorier:

Roligt! Bra!
Saker som blev lyckade och som teamet ska fortsätta med. Något som var speciellt roligt eller gick speciellt smidigt? Roliga händelser. Bra – men vi kan ännu bättre!
.

Dåligt! Frustrerande! Tråkigt.
Saker som inte gick som planerat. Olyckliga omständigheter. Frustration! Rutiner eller processer som inte funkar som de ska. Saboterande omständigheter.
.

En blomma till…
Speciella tack till speciella insatser. Tack för hjälpen! Beröm. Klapp på axeln.
.
.

Funderingar. Frågetecken.
”Varför …?”, ”Jag önskar jag visste hur … ?”, ”Hur kan vi … ?”, ”Hur lyckas vi … ?”, ”Hur kommer det sig att … ?”
.
.

Ideér. Förslag.
Förslag på förbättringar, saker som kan göras annorlunda. Idéer på hur teamet kan samarbeta bättre, kommunicera bättre, minimera waste, förebygga teknisk skuld, första kund och krav bättre.
.

Denna övning tog nästan ca 90 minuter innan vi kände att vi tömt ut allt vi ville få sagt och tyckt till om det vi ville tycka till om.

OBS! Under denna övning har Scrum Mastern ett stort ansvar. Ingen kritik. Allt ska upp. Scrum Mastern får inte  bete sig defensivt eller sabotera viljan att tala och tänka fritt och högt. Scrum Mastern får inte ta bort eller formulera om lappar. Det skulle hämma möjligheten att nå insikter och få fram allas tankar och synpunkter.

.

4. Summera actions

Efter en fem minuters paus samlade vi våra tankar och gick tillbaka in i vårt war room. Nu var det dags att summera, finna bakomliggande orsaker till frustationer, konkretisera förändringsförslag och idéer.

Alla lapparna gicks igenom, var för sig. Kunde vi komma på en action till lappen satte vi upp den i ”!” rutan. Ibland fick vi klura en stund, kanske backa för att se den större bilden och diskutera en stund innan vi kunde enas om vad lämpligast och effektivast action var. Men vi tog oss igenom alla lapparna och var efteråt oerhört tillfreds med oss själva, vår analys och vår lista över actions.

När vi var färdiga med actions grupperade vi dem. Grupperna denna gång råkade bli ”Sprint Planering”, ”Dagligen”, ”Arbetsro och Övrig-prio”, ”Attidyd/Mentalitet” och ”Externt”. Kanske inte säger dig något men för oss är betydelsen solklar 😉

Detta tog cirka 60 minuter.

Denna övning kan med fördel timeboxas. Gäller såklart övriga övningar beskrivna här också. Det är enkelt att skena iväg och förlora sig i detaljer.

Listan över actions som kräver en arbetsinsats bör inte vara för lång så att den blir en belastning i sig under sprinten. Likaså kan man inte hoppas på att förändra allt man vill på en gång. Ett steg i taget leder troligtvis till beständigare förändringar. Behövs det hjälper Scrum Mastern teamet prioritera det som känns viktigast och ger störst impact.

.

5. Summering för styrgrupp

Denna gång kände vi att det var viktigt att få framföra våra idéer och förslag till styrgruppen samt dela med oss av det vi upplevde var frustrerande för att få ökad förståelse för våra förändringsförslag. Vi presenterade alla actions, svarade på frågor, diskuterade. Mycket givande! Ytterligare några actions kom upp på väggen.

Vi hade mycket att prata om och fick många frågor om våra lappar så innan denna sista övning var över hade ytterligare cirka 60 minuter förflutit.

.

6. Reflektera

Sist reflekterade vi som hastigast över förmiddagens arbete, vad som var bra/dåligt med upplägget och vad vi tyckte om vår prestation och vår gemensamma prestation. Tror det syns på bilden nedan att vi var ganska belåtna 🙂

Nu återstår bara att se hur väl vi lyckas med att genomföra våra actions och följa våra egna förmaningar till oss själva.

Teamet (från vänster): Jag, Andreas, Henrik och Peter

h1

Google Translatar min blogg

måndag, 5 april, 2010

Jag har dragits med ett litet dilemma den senaste veckan. Jag vill skriva om Scrum på svenska för att jag tror det fyller ett tomrum och ett behov, men jag vill också samtidigt kunna kommunicera med resten av den agila världen. ”Google Translate” får bli den tillfälliga lösningen på mitt problem.

Google Translate gör inte de vackraste översättningarna men resultatet blir ändå begripligt. Med lite ansträngning (och en dos humor) kan man ändå förstå artikelns kärna och budskap. Genom ett enkelt klick på den engelska flaggan till höger översätts sidan automatiskt till engelska. Fantastiskt! 🙂

Jag tror också att man kanske kan skriva texten på ett sätt som gör att Google Translate får enklare att översätta. Hmm… Övning får ge färdighet även denna gång.

.

.

Ovanstående text genom Google Translate blir:

I have been having a little dilemma in the past week. I want to write about Scrum in Swedish because I think it fills a void and a need, but I also want to simultaneously communicate with the rest of the world also agile. ”Google Translate” may be the temporary solution to my problem.

Google Translate does not make the most beautiful translations, but the results are still intelligible. With a little effort (and a dose of humor) you can still understand the core of the article and message. By a simple click on the British flag on the right side automatically translated into English. Fantastic! 🙂

I also think that perhaps we can write the text in a way that Google Translate may be easier to translate. Hmm … Practice may make perfect again.