Posts Tagged ‘team’

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)

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

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…