Posts Tagged ‘scrum_master’

h1

En talande magisk Scrum Board. På riktigt!

tisdag, 7 december, 2010

Igår fick jag se någonting fantastiskt! En magisk Scrum Board som automatiskt uppdaterar JIRA när du flyttar på de fysiska lapparna. Och som kan prata!

Jeff Sutherlands tipsade om någonting fantastiskt på sin blogg i inlägget Scrum Board on Steroids: The Awesome Nature of Awesomeness. Ett Scrum team på Vodafone i Köpenhamn har byggt en magisk Scrum Board.

Den klarar bland annat av följande:

  • När du flyttar på lappar uppdateras JIRA automatiskt (genom RFID taggar på varje lapp).
  • Sprint Burndownen projiceras på whiteboarden med hjälp av en projektor.
  • Om någon uppdaterar JIRA pratar Scrum Boarden (med hjälp av Google Voice) . Den säger då åt teamet att flytta på lappen så att den sitter där det står att den sitter enligt JIRA.
  • Visualisering av hur många stories och tasks som är planned/in development/development complete/done genom belysta staplar.
  • När någon flyttar på en lapp startar en kamera som spelar in fem sekunders film. På så sätt kan man senare kan se vem som flyttade vad, och när.
  • Teamets Scrum master har kopplat konfigurerat sin bakgrundsbild att visa det senaste tagna fotot av Scrum Boarden så att han supersnabbt kan se vad status är och vad teamet jobbar på.

Detta är både ljuv musik och en smula magiskt för mig. Jag skulle vara beredd att betala ganska ordentligt med pengar om någon fick för sig att paketera detta som en produkt!

Till allt detta har de också byggt en kraftfull och intelligent Continuous Integration server som automatiskt deployar det senaste bygget till test miljön och automatiskt via mail meddelar testare och Product Owner om när nya funktioner finns tillgängliga för test.

.

Klicka här för att se en demonstration från teamet.

.

Följande video visar en hel sprint i ultra rapod.

Annons
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!

.

h1

Video: Vägen från PL till Agile Coach

torsdag, 1 juli, 2010

Blev genom en av bloggarna jag följer tipsad om en fantastisk videopresentation av Lyssa Adkins. Om du har rollen som Scrum Master eller Agile Coach kommer du nog finna den mycket inspirerande och givande.

Lyssa Adkins släppte i Maj 2010 boken ”Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches and Project Managers in Transition”. Efter att ha kikat igenom presentationen (två gånger faktiskt) är detta en boken som ligger högst just nu på min att-läsa-lista.

.

.

The Road from Project Manager to Agile Coach

Del ett (ca 10 min):

.

Del två (ca 10):

h1

Projektledningsaspekter i Scrum?

torsdag, 15 april, 2010

När jag är ute och föreläser om Scrum för en publik som är nyfiken på agila utvecklingsmetoder så är det oftast projektledare och arkitekter som skruvar på sig mest och ställer flest frågor.

Speciellt projektledare verkar ha svårt att se hur sin egen yrkesroll passar in i Scrum. Uppgifter och ansvar som typiskt åligger en ”klassisk” projektledare förekommer naturligtvis i Scrum också, fast i annan skepnad och ansvaret distribueras mellan flera olika personer. Jag ska därför försöka mig på att presentera en översikt över hur de olika ansvarsområden som en projektledare har i ett vattenfallsprojekt hanteras i ett Scrum projekt.

.

Projektledningsaspekter i Scrum

(eller ”Vem ansvarar för vad?”)

.

Varför? Hur ser visionen ut?
Varför bygger vi detta system?
Product Owner
(och kund)
Vad? Vilka features är användbara och värdefulla för kund och användare?
När? Vilka features har mest värde för kund och användare? (Dvs. i vilken ordning ska vi bygga och leverera för att maximera Return of Investment och minimera Time To Market?)
. . .
Kostnad? Hur jobbigt är det att bygga en viss funktion?
Hur lång tid tar det?

Vilka kunskaper behövs?

Scrum Team


Hur? Hur ska funktionen byggas (från ett tekniskt perspektiv)?

Vilken arkitektur och design är bäst?

. . A
Hur? Efter vilka spelregler (process) jobbar vi?

Hur förbättrar vi processen och våra metoder?

Vem ansvarar för att teamet får förutsättningar och möjlighet att utföra ett bra jobb?

Scrum Master


. . .
Problem? Lyfta frågor rörande…

  • Resurser och behov
  • Förändringar i Release planer (omfattning eller tid)
  • Tekniska beroenden mot andra team

…till Meta-Scrum (Styrgrupp) eller till Scrum-of-Scrums?

Alla

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

Project Manager – to be, or not to be?

tisdag, 30 mars, 2010

En PMI certifierad  project manager ställer sig frågan ”Can a ScrumMaster be a project manager — are the positions one in the same?” i en nyligen publicerad artikel. Vidare hävdar hon att ”The project manager is the overarching manager and person accountable at the project level, while the ScrumMaster is the one responsible for the product development.”

Redan i ingressen känner jag i magtrakten att det är något knepigt i hennes tankengångar. Det tog ett tag innan jag lyckades formulera det för mig själv.

Låt oss vända på det hela.

.

Anta att vi har ett projekt som omfattar:

  • en Scrum Master som ser till att alla följer Scrum, utbildar, inspirerar, möjliggör teamet, kontinuerligt provocerar till förbättringar och sköter den dagliga adminstrationen,
  • ett agilt team (cross-functional, self-organizing and empowered) som estimerar storys i produktbackloggen, formar sina egna sprintmål efter produktbackloggens prioritering och bygger den faktiska mjukvaran,
  • en Product Owner som ser till att produktbackloggen är uppdaterad och prioriterad, för tät dialogen med teamet samt sköter release planering, samt eventuellt (men inte nödvändigtvis)
  • en styrgrupp, aka Meta-Scrum, som stöttar teamet med t.ex. resurser, staffing, etc.

Vad återstår? Är inte alla planerings-, koordinerings- och ansvarsfrågor omhändertagna? Om man ser behovet att behålla rollen ”Project Manager” har man inte lyckats (eller inte vågat) gå hela vägen mot en agil leverans och organisation!

Lisa A. Grant skriver vidare i sin artikel; ”The project manager ensures that the business case is clearly defined, compliance documents are completed in a timely manner, product deployment activities are executed — and he or she manages all other business aspects of the new product launch.”

Det här är ju perfekta uppgifter för produktägaren att ta ansvar för och prioritera in i release planering. Produktägaren initierar projektet (genom att formulera visionen, förankra visionen och kontinuerligt bygga upp och underhålla produktbackloggen) och är självklart med hela resan tills systemet/produkten är klar och sjösatt. Däremot kanske scrum teamets konstellation och storlek varierar med tiden.

.

Jag tycker att Lisa istället borde acceptera att hennes roll i ett agilt projekt, i en lean organisation, kanske är överspelad. Hennes kunskaper och erfarenheter är det såklart dock inte! Sedan om hon passar bäst som Scrum Master, Produkt Owner eller annan organisatorisk roll har jag ingen aning om.

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