Archive for the ‘Scrum metodik’ Category

h1

Vår dagliga Sprint Burndown

tisdag, 1 juni, 2010

Dagens sprintplanering är precis avklarad. Lite bökigare än vanligt eftersom våra sprintmål denna sprint var väldigt spretiga men vi nådde i land till slut. Spretiga sprintmål riskerar sluta i att det blir svårt att fokusera och samlat och disciplinerat jobba mot en sprint demo. Dock borde vi kunna hålla bra koll på våra framsteg med hjälp av JIRA och vår dagliga Sprint Burndown, verktyg som vi blir allt bättre på att använda och utnyttja.

Då teamet sitter distribuerat har vi inga daglig Stand-Up Meeting utan kör istället med ”Daily Call-Up”. Strax innan telefonkonferensen mötet skickar jag också ut en fräsch och uppdaterad Burndown-chart för att vi ska kunna lyfta blicken och inte bara fokusera på ”här och nu”. Bäst hade såklart varit att träffas fysisk IRL runt en vägg med sprint planeringen och flytta runt på lappar istället för att uppdatera tasks i JIRA, men men, vi arbetar kontinuerligt med att göra det bästa av situationen.

Vår Sprint Burndown är absolut ingen rocket-sciense men tänkte att det alltid är någon som uppskattar att se exempel från verkligheten. Denna screenshot är några veckor gammal men passar ändå bra som exempel.

(Klicka på bilden för att se en större version)

.

Utöver att spåra återstående tid har vi längs med resan lagt till ytterligare dimensioner på vår burndown (information som extraheras från JIRA). Alla värden och estimat i tabellen ovan är i timmar.

Total – Summan av orginal-estimeringar för alla tasks. Vissa sprintar ”uppstår” arbete när vi lär oss mer om de tekniska utmaningarna. Ibland stryks detaljer funktioner (pga av det antingen blir inaktuellt att implementera dem eller för att de scoopas ut från sprinten). Vi har lärt oss att vår velocity ligger på ungefär 3,5 – 4,5 per dag och teammedlem och det är vi planerar efter.

Remaining – Återstående arbete, dvs. summan av uppskattad återstående tid (Remaining Estimate) för alla tasks som inte är ”Resolved”.

DONE – Avklarat arbete. När en tasks går från ”In Progress” till ”Resolved” ökar DONE med taskens ursprungliga estimat.

In Work – Original estimate summeras för de tasks som är ”In Progress” just nu. Denna försöker jag hålla så låg som möjligt så att det inte jobbas på för mycket parallellt.

.

Det jag saknar och eventuellt överväger att lägga till är:

Added/Removed Work – Möjlighet att se hur mycket arbete som läggs till eller tas bort under sprintens gång. Just nu ser vi bara hur totalen växer och minskar. Om en task tas bort och en annan läggs till syns ingen skillnad i grafen.

Annonser
h1

Den dysfunktionella produktägaren

måndag, 3 maj, 2010

Det vanligaste källan till dysfunktionella Scrum projekt är problem kring och rörande Produktägaren.

Det som kan ställa till det är hur rollen defineras i organisationen och projektet samt produktägarens engagemang och kommunikation med teamet, kund och beställare.

.

Product Owner Anti-Patterns

På 2010 Shanghai Scrum Gathering höll Monica Yap från SolutionsIQ ett seminarie som vackert listade upp sex stycken Produktägar anti-patterns. Gillar själva uttrycket ant-pattern, på sätt och vis en vacker omskrivning för ”gör inte så här”.

  • Frånvarande produktägaren – Produktägaren är otillgänglig och teamet ges ingen styrning eller snabb feadback.
  • Kopiering – ”Jag vet inte och bryr mig inte. Vi ska ju bara bygga om den gamla versionen av X så kolla hur den beter sig.”
  • Skenande Backloggen – Sprintmålen ändras frekvent under sprinten.
  • Vag DONE definitionen – Oklart vad teamet förväntas göra och uppnå för att få demonstrera och leverera en funktion/feature.
  • Ingen enskild produktägare – Produktägaren har inte mandat att ta beslut själv utan alltid måste vända sig till andra i organisationen för godkännande.
  • Saknade stakeholders – Nyckelpersoner som Produktägaren behöver konsultera och/eller samarbeta för att föra vision till leverans och avslut saknas

Hon radar både symptom, potentiella negativa konsekvenser men också botmedel.

.

Common Product Owner Mistakes

Likaså tar Roman Pichler upp sex stycken vanliga bekymmer rörande produktägaren i sin nya bok ”Agile Product Management With Scrum – Creating Products That Customers Love”. Vissa snarlika, andra nya:

  • Den kraftlöse produktägaren – Produktägaren saknar tillräcklig mandat.
  • Den överbelastade produktägaren – Produktägaren hinner inte engagera sig tillräckligt för att proaktivt kunna stötta teamet.
  • Den splittrade produktägaren – Flera personer delar på produktägarenrollen, dvs. ingen av produktägarna har helhetsansvaret.
  • Den avlägsne produktägaren – Produktägaren är otillgänglig eller nfsd fdsg fgsfd gsdg kjsdfkgjsdfklgjsfdlkg
  • Produktägar-ersättaren – För att hantera en kraftlös, överbelastad eller avlägsen produktägare brukar ofta någon i teamet (som inte har verksamhetskompetens eller bra kundförståelse) ta på sig rollen som produktägar-vikarie.
  • Produktägar-kommiten – En kommite fyller rollen som produktägare och delar på produktägarens ansvar och makt (vilket gärna riskerar sluta i ”Death by Committe”).

Även Roman tar upp konsekvenser men även råd och botmedel om man ser och märker av symptomen.

.

Ladda hem Monicy Yaps presentation ”Product Owner Anti Patterns” Scrum Alliance hemsida här.

Beställ Roman Pichlers bok exempelvis här (Amazon).

h1

Prototype Driven Development – En utopi?

torsdag, 29 april, 2010

Denna vecka har jag fått seriösa griller i huvudet. Företaget jag höll kurs för i tisdags arbetade hårt med prototyping för att undersöka vilka koncept som fungerade och inte fungerade. Tänk om hela produktbackloggen kunde ersättas med en levande prototyp?

Fram tills i tisdags betraktade jag prototyping endast som ett verktyg för teamet och produktägaren för att flytta en funktioner och features från ”Anarchy” or ”Complex” space ner mot ”Complicated” eller ”Simple” space.

Prototypen blir närmast ett verktyg för groomingen av produkt-backloggen. När produktägare och kund sett och klickat runt i prototypen kan EPIC User Stories brytas ner, detaljeras och prioriteras (eller förkastas). När detta arbete är gjort har prototypen spelat ut sin roll. Den fungerar alltså bara som ett ”hur”, ett verktyg att förstå vad man vill ha och vad som fungerar bäst, ett steg i utvecklingsprocessen på resan mot att leverera värdefull och användbar mjukvara.

Med lite tur kan man ibland återanvända lite kod från prototypen till den ”riktiga” produkten men oftast har den spelat ut sin roll och förkastas till skräpkorgen (eller arkivet).

.

Men nu snurrar (för mig) många nya tankar, åtminstone kring prototyping av gränssnitt och dialoger. POC:ar för att undanröja tekniska frågetecken eller risker lämnar jag därhän för tillfället.

.

För, tänk om…

  • Vi inte alls förkastar våra olika prototyper utan prototypen föds i tidig analysfas och fortsätter sedan leva, förändras och växa genom hela projektet.
    .
  • Prototypen är så enkel att bygga ut och laborera med att Produktägaren själv kan experimentera med att lägga till dialoger, skapa dummy-funktioner och koppla ihop systemet på olika sätt. (Kanske har produktägaren ett prototyp-team till sin hjälp eller så spenderar ordinarie team en viss tid av sin sprint för att skulptera prototypen som ett steg i det kontinuerliga analys- och designarbetet.)
    .
  • Prototypen kan ”spelas upp” i olika skepnader. Man bygger inte en helt ny prototyp för att gestalta en annan variant av dialogen utan prototypen kan ställa in i vilket version vi vill experimentera med denna testkörning. Skepnader och flödesvarianter kan enkelt konfigureras on the fly.
    .
  • Vissa delar av prototyp-produkten består av luddiga dialoger och grova funktioner medans andra är tydligare, mer detaljerade och närmare en implementerbar nivå.
    .
  • Prototypen låter sig delas upp i funktioner och komponenter som teamet kan estimera.
    .
  • Estimaten behöver inte lagras i en separat lista någon stans utan är en del av modellen och kopplas till ”prototyp-komponenter”.
    .
  • Komponenterna kan innehålla dolda attachments som inte syns vid körning. Exempelvis word dokument, sökvägar in i wikin, osv.
    .
  • Komponenterna kan innehålla annan meta-information som t.ex:
    • Prioritet
    • Att-Göra-lista med öppna frågor för produktägaren
    • Vilket team som eventuellt ska bygga funktionen
    • Vilken release/sprint funktionen eventuellt är planerad till
      .
  • Slutligen så går prototypens komponenter att skriva ut som en prioriterad lista. Denna lista kommer snarare likna ett träd med grenar som spretar iväg. Ibland lever flera varianter av samma funktion (User Story) fram tills dess att en av dem implementeras och andra förkastats.

Kommentar: När jag skriver ”komponent” ovan menar jag inte modul eller klass, jag syftar till en dialog eller en specifik funktion i användargränssnittet.

.
.

Om denna fantasi besannas har vi då helt och fullt lyckats ersätta produktbackloggen med en prototyp?

Men varför stanna där? Anta att plattformen och språket vi bygger prototypen med är samma som vi använder när vi bygger den ”riktiga” produkten och att implementera en komponent/funktion i prototypen enbart handlar om reda ut återstående detaljer, skriva koden bakom, testa av samt rensa bort döda versioner och aspekter?

Når vi hela vägen hit är vår release-branch helt enkelt en specifik konfigurering av prototypen. Känns definitivt som en utopi men kanske ett vision att arbeta mot?

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

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

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…