Archive for the ‘Agila verktyg’ Category

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.

.

Annonser
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

Fingervotering – Blixtsnabb konsensus check

fredag, 26 mars, 2010

Fingervotering, ”Fist of Five”, är en simpel men effektiv teknik för att se om ett förslag har stöd i en grupp.

När det är dags formuleras det eventuella beslutet teamet ska ta (exempelvis av Scrum Mastern). Sedan ombeds varje teammedlem visa vilket stöd de känner för förslaget genom att hålla upp ett antal fingrar som representerar hur mycket de stöttar förslaget, alternativt en sluten näven.

Mycket effektivare än att t.ex. gå varvet runt och be alla uttrycka och förklara sitt stöd (eller ogillande av förslaget) med ord – speciellt när alla är ense ;-p

Sluten näve = ”Jag vill diskutera förslaget ytterligare för jag kan inte gå med på det som presenteras just nu”. Ett sätt att blockera konsensus.

1 finger = ”Jag vill diskutera mera, belysa vissa problem och/eller föreslå några ändringar.”

2 fingrar = ”Jag är ok med förslaget men vill diskutera några detaljer lite ytterligare.”

3 fingrar = ”Jag håller inte med till 100% men kan vara ok med det. Behöver ingen ytterligare diskussioner.”

4 fingrar = ”Gillar förslaget och kommer jobba för dess sak.”

5 fingrar = ”Grymt förslag! Jag leder gärna arbetet!”

.

Konsensus?

Om alla håller upp tre eller fler fingrar antas förslaget ha stöd i gruppen och teamet nått konsensus.

Om någon håller två eller färre fingrar ska dessa ges en chans att förklara sina argument eller tvivel. Teamet diskuterar och argument bemöts. Sedan fingervoterar man igen och fortsätter tills teamet nått konsensus – eller beslutat sig för att lägga förslaget på hyllan och gå vidare.

h1

Lägg krut på rätt ställe med ”Focus Scales”

måndag, 22 mars, 2010

Hur vet man att man lägger krutet på rätt saker? Hur kan man förenkla utmaningen med att kommunicera kundens vision in i Scrum-teamet? Räcker Produktbackloggens prioritering för att nå maximal verksamhetsnytta? ”Focus Scales” kan vara ett kraftfullt verktyg för att fylla gapet mellan kundens behov och teamets ansträngningar.

.

Agiles projektledningstriangel

Scrums verktyg för att ena kunden och Scrum-teamen under samma ledstjärna är ett Vision Statement. Denna beskriver visionen för IT-lösningen, dvs. vad dess syfte är, mål och önskat resultat. Agiles projektledningstriangel säger vidare att vi aldrig får kompromissar med kvaliteten utan att vi anpassar scoopet för att nå tid och budget.

Även fast vi aldrig tummar på kvalitét gör vi fortfarande kontinuerligt andra typer av val; dels avgör vi löpande i vilken ordning vi utvecklar funktionerna (dvs. vad som ska levereras efter nästa sprint). Men vi avgör också löpande hur mycket krut vi ska lägga ner på varje funktion, dvs. hur avancerad eller minimalistisk implementering av varje User Story ska göras.

.

Focus Scales

Själva prioriteringen av Produktbackloggen gör Produktägaren givetvis löpande i dialog med kunden. Det är dock en mycket god idé att samtidigt som man tar fram ”Vision Statement” även målar upp några enkla tumregler för vad man ska lägga extra tid och energi på och vad man ska hålla enkelt.

Som ett diskussionsunderlag för Produktägaren (och teamet) i sin dialog med kunden kan man använda sig av något jag kallar Fokus Scales. Dessa kan även teamet använda internt när de designar funktionerna och funderar över hur pass avancerad eller enkel lösning de ska sikta på.

Att dessutom ta fram dessa vågskålar under en workshop där både kund och teamet är med (eller åtminstone representanter för teamet) öppnar upp för en fantastisk möjlighet att diskutera idéer, koncept och nå konsensus över vad man vill åstadkomma och vad som är viktigt.

Ett exempel på ett projekts fokus vågskålar…


Varje vågskål beskriver hur balansen ska läggas när man väljer mellan två olika kriterier. Observera att kriterierna absolut inte behöver vara motsatser eller utesluta varandra, de ska endast vara vägledande och fungera som diskussionsunderlag. Kriterier som är vettiga i ett projekt kanske helt saknar relevans och betydelse i ett annat. Det är en god idé att begränsa antalet vågskålar till ett fåtal (kanske 3-5 stycken). Med för många vågskålar riskerar summan av dem bli svårbegripliga och motsägelsefulla.

.

Tydligare ledstjärna!

Genom att börja med att ta fram Vision Statement och Focus Scales etableras och kommuniceras en tydlig målsättning och gemensam ledstjärna för både kund och team från början. En framgångsfaktor för alla agila projekt.

(Ursprungligen publicerad på sogeti.blogg.se)