Posts Tagged ‘impediments’

h1

Daily Scrum Checklistor

fredag, 10 september, 2010

Daily Scrum är säkert vardag för många, liksom mig själv, men efter ett tag riskerar rutinen att ta över. Därför blev jag glad när jag snubblade över några nyttiga checklistor för scrum mastern att ha i bakhuvudet inför, och efter Daily Scrum (aka Daily Stand-Up).

Mike Griffiths publicerade nyligen två artiklar på bloggen LeadingAnswers: Leadership and Agile Project Management Blog:

.

Detta är Mikes Top 5 viktigaste saker att tänka på innan och efter Daily Scrum, och jag håller varmt med om att det är bra punkter. Har dock inte funderat djupare och kritiskt granskat hans prioritering eller klurat över hur min egen lista sett ut om jag hade gjort den från scratch.

Det absolut viktigaste syftet med Daily Scrum är dock att ge teamet en chans att tillsammans reflektera över hur det går och hur teamet tillsammans på bästa sätt framgångsfullt och effektivs ska arbeta för att lösa dagens bekymmer och utmaningar och för att nå uppsatta sprint mål.

.

5 saker att tänka på innan Daily Stand-Up

  1. Vad arbetas det på just nu? – Vilka funktioner och User Stories arbetar teamet på just nu? Vad höll man på med igår? Är man klar med dessa eller kommer arbetet fortsätta under dagen?
  2. Gårdagens problem – Vad rapporterade folk för problem och bekymmer igår? Har dom blivit åtgärdade? Några uppföljningar som borde ske?
  3. Uppmärksamma teamet! – Är det någon som snart fyller år? Precis har gift sig? Visa uppmärksamhet och bry dig även om vad som pågår i teammedlemmarnas privata liv.
  4. Dolda surdegar? – Är det någon som kämpar på med en task utan att komma någon stans? Någon som försöker komma igång med något nytt utan att få fotfäste? Någon som switchar mellan tasks för att man kontinuerligt kör fast? Detta kräver speciell uppmärksamhet.
  5. Vad tänker du säga? – Precis som teammedlemmarna berättar om vad dom gjorde igår, vad dom tänker göra idag och  om dom har några bekymmer så bör även Scrum Mastern dela med sig av sina göråmål.

.

5 saker att tänka på efter Daily Stand-Up

  1. Problem – Problem och bekymmer som togs upp ska upp på Impediment listan (dvs. Scrum Masterns Att-Göra) och sedan adresseras i prio ordning. Följ upp dagen efter vad som gjorts (eller inte gjorts).
  2. Avvikelser i Velocity – fdskf jsdjkgfdklfjsfdjghjsfdkjg
  3. Känslor – Hur verkar teamet må? Var någon upprörd? Finns det frustration och irritation eller spänningar inom teamet? Ett litet samtal kring känslor kan iband göra underverk.
  4. Frågor – Uppstod frågor under mötet som behöver svar? Behöver du som Scrum Master sätta dig in i något tekniskt för att bättre förstå hur du ska hjälpa teamet?
  5. Beröm och feedback – Alla behöver återkoppling och uppskattar beröm och är i behov av  positiv kritik för att göra ett bra jobb. Uppmärksamma alltid om någon gör ett bra jobb, eller bidrar på ett värdefullt sätt till teamet, och tveka inte att rapportera tillbaka till teamet om någon annan ger beröm eller positiv feedback!

.

Annonser
h1

Brist på erfarenhet och ledningens motstånd är de största hindren för framgångsfulla agila projekt

tisdag, 24 augusti, 2010

Excel är det populäraste verktyget för sprint planering, brist på erfarenhet sänker flest agila projekt och ledningens motstånd mot agila metoder är det största hindret för det agila projektets framgång.

Detta, och många fler intressant saker, går att utläsa i VersionOnes rapport ”State of Agile Survey 2009”, en redovisning av resultatet från en löpande undersökning hur agila metoder tillämpas runt om i världen.

.

Vad stjälper det agila projektet?

Rapporten listar bland annat de vanligaste skälen som stjälper ett agilt projekt och i topp tre hamnar:

  1. Avsaknad av erfarenhet kring agila metoder,
    .
  2. Företagskulturen och företagsklimatet kolliderar med de agila värderingarna, och
    .
  3. Vet ej

På fjärde plats hamnar dock: Externa påtryckningar att följa vattenfallsprocessen.

Ärligt talat trodde jag ”Företagskulturen” och ”Externa påtryckningar” skulle hamna över ”Avsaknad av erfarenhet”. Att avsaknad av erfarenhet, och troligtvis avsaknad av extern professionell coashning och stöd, ofta är ett stort problem tror jag beror på att Scrum i sig har under åren blivit väldigt populärt och att det är många som ger sig an att byta process utan investera tillräckligt mycket i utbildning och coachning.

.

Störst utmaningar med att skifta till Agile?

Rapporten pekar också ut de tre största upplevda problemen med vidare utrullning av en agil utvecklingsmodell. I topp tre hittar vi:

  1. Ledning är emot förändringen
    .
  2. Avsaknad av up-front planning (dvs. långsiktiga detaljerade planer från start)
    .
  3. Förlorad kontroll

På plats fyra och fem hittar vi ”Sämre förutsägbarhet” och ”Avsaknad av dokumentation”.

Att man kan vara emot förändringar kan jag förstå, de kan vara smärtsamma och jobbiga. Att inte göra detaljerade långsiktiga planer tycker jag är en bra sak. En plan är som mest värdefull när den görs. Dagen efter drabbas den av verkligheten. Förlorad kontroll upplevs enbart om man inte är kontinuerligt delaktig i det agila planerandet.

Att det agila projektet är oförutsägbart (inom rimliga gränser) visar bara på att man gör rätt, dvs. att man löpande anpassar sig efter rådande omständigheter och nya prioriteringar.

Saknas dokumentation gör man fel. Att jobba agilt ska inte betyda att man slutar dokumentera.

Skulle jag i mitt eget huvud försöka analysera ovanstående kan jag inte komma fram till annat än att personerna i projekten och organisationen runtomkring som upplever ovanstående problem inte uppskattar och förstår vad det betyder att jobba agilt och varför en agil process ser ut som den gör. Gör man ”rätt” bör dessa saker inte upplevas som bekymmer.

.

Andra intressanta siffror…

  • De vanligaste skälen till att växla till en agil process är att minska Time To Market samt viljan att öka förmågan att hantera förändringar och nya prioriteringar.
    .
  • 64% upplever att projekten genomförs snabbare (med agila metoder)
    .
  • 50% kör Scrum (eller Scrum-liknande process). Endast 3% använder någon form av Lean Development. (Då Kanban starkt vunnit i popularitet det gångna året blir jag en aning förvånad över dessa siffror. Tror de skulle se annorlunda ut om man analyserade de svenska svaren.)
    .
  • Excel är det överlägset vanligaste verktyget. På andra plats kommer Microsoft Project och på tredje plats kommer Jira.

.

Om ”State of Agile Survey 2009”

Undersökningen genomfördes under july till november 2009 och 2570 personer från 88 olika länder deltog och svarade på enkäten. VersionOne sponsrar undersökningen och detta är den fjärde årliga rapporten i ordningen.

.

.

Rapporten i sin helhet kan beställas här:
http://pm.versionone.com/StateOfAgileSurvey.html

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”