Archive for the ‘Scrum metodik’ Category

h1

Fel, fel, fel!

måndag, 28 juni, 2010

Under Agila Sverige 2010 höll Joakim Ohlrogge från Agical ett mycket uppskattat blixttal som handlar om hur vi ser på fel och hur vi hanterar dem. Titeln för blixttalen var ”Fel, fel, fel!”.

Mot slutet av sin presentation argumenterar han för att vi kanske borde betrakta och hantera fel och testning på ett radikalt annorlunda sätt…

Det hölls många intressanta, insiktsfulla och lärorika blixttal under Agila Sverige 2010. Jag var inte där själv men har fått möjlighet att kika igenom dem alla på video efteråt.

Joakims tal fokuserar kring fel, hur vi betraktar dem och hur vi hanterar dem. Dels har vi antalet fel, dels har varje fel en ”allvarlighetsgrad”. Bilden blir dock inte komplett om vi inte dessutom tar hänsyn till hur lång tid felet existerar. En litet fel som existerar under en lång tid kan göra större skada än ett kortvarigt allvarligt fel. Det riskerar sluta i irritaion, frustration, färre användare, färre sålda produkter, osv. Med andra ord…

Felyta = allvarlighet x tid.
Den totala felytan kan då minskas på tre olika sätt:

  1. ”Släppa igenom” färre fel (minskar antalet fel)
  2. ”Släppa igenom” mindre allvarliga fel (minskar allvarligheten)
  3. Reagera på och hantera fel så fort som möjligt (minskar tiden)

Han argumenterar för att om vi kan agera snabbt och reparera fel fort kanske vi inte behöver vara lika rädda för att ”släppa igenom” fel. Även om felet är allvarligt blir felytan liten om felen bara existerar en kort stund.

Felytan för ett mindre allvarligt fel kan vara större än för ett kritiskt…

.

Konsekvens = Ingen testning?

Om man godtar felyta som vårt mätetal och som en mer sann beskrivning (för systemets kvalité ur ett defekt-perspektiv) fullt ut får det stora konsekvenser för vår testprocess.

Att minska antalet fel som slinker igenom och felens allvarlighet med en allt rigorösare testprocess är både kostsamt och tidskrävande, och gör dessutom inget för att dra ner livslängden på de fel som faktiskt hittas. Det kan till och med vara kontraproduktivt, en tung testprocess kan göra så att våra fel lever längre innan de blir åtgärdade.

Om vi istället fokuserar på processen (dvs. att höja kvalitén genom test driven development, par programmering, continuous integration, m.m.) och att möjliggöra snabba fixar (genom t.ex. defensiv programmering, defect proofing, rigorös loggning, etc.) samt att stöda snabba deployer av nya versioner som metoder för att minska felytan kan detta visa sig vara både betydligt effektivare och betydligt billigare.

Kan det vara så att det absolut effektivaste är att inte ha något testning alls? Hmm…

.


Joakim Ohlrogge är konsult på Agical AB.
Hans blogg heter ”The Point is Missed”.

.

.

Videoupptagningar från Agila Sverige 2010 hittar du här:
http://www.webbtv.nu/5557.htm

För att se ”Fel, fel, fel!” klicka på ”Celsius 20100510”.
När videon väl har laddats klicka på sista passet ”Fel, fel, fel!”.

h1

”Slack” ger högre kvalitet och effektivitet!

torsdag, 24 juni, 2010

Bakom Agiles princip ”The sponsors, developers, and users should be able to maintain a constant pace indefinitely” döljer sig mycket visdom.

Det kanske mest uppenbara principen säger är ”Sprinta [som i att rusa fort framåt] inte”, se till att ha ett jämt tempo för alla inblandade.

.

Lagom tempo

  • Skapa inte falska förhoppningar om produktivitet (genom att t.ex. jobba för mycket övertid) som leder till att varje sprint blir en stressad kamp för teamet att hinna klart med alla löften.
  • Ha inte för långa Sprintar som tillåter teamet producera mera än verksamheten hinner absorbera och ge feedback på.
  • Ha en bra balans av kompetenser inom teamet så att det inte uppstår trafikstockningar i slutet (för t.ex. testning, integrering, dokumentation, etc).

Blir varje sprint stressad kommer snart vissa bränna ut sig, andra tröttnar på att anstränga sig och troligtvis kommer teamet så småningom att hitta ”hemliga” sätt att hantera detta på för att få en drägligare tillvaro. Detta i sin tur leder till att teamet kommer att prestera olika mycket varje sprint. Förutsägbarheten (och förmågan att planera framåt) och kvalitén undermineras och saboteras.

”Om du alltid spurtar så joggar du i själva verket bara!”

Pauser

Vidare ges ofta rådet att ha en paus mellan två sprintar, så kallad ”Slack Time”, dvs. ha inte Sprint demo på förmiddagen och Sprint planeringen på eftermiddagen. Ge teamet en chans att återhämta sig och vila upp sig. Både produktägare och teamet kan dessutom behöva en liten stund att fundera och smälta feedbacken och tankarna från Sprint demon och Sprint retrospective och för att samla sig för nästa iteration. Se till att åtminstone ha en natt eller en helg emellan.

.

Projekt-fria dagar!

Det kanske mest kontra-intuitiva rådet är att inte enbart ha en naturlig paus (som t.ex. en helg) mellan två sprintar, utan en eller två fria arbetsdagar under vilka teammedlemmarna får ägna sig åt precis vad de vill. Uppmuntra självstudier, laborationer, test av nya verktyg och tekniker osv. men ställ absolut inga krav på resultat! Låt kreativiteten, nyfikenheten och det personliga intresset stå i fokus.

Men, skulle det dock dyka upp buggrapporter på det teamet nyss levererat måsta de släppa det de håller på med och återgå till arbetsbänken till dess att problemen är lösta.

.

Kvalité blir heligt

Dessa projekt-fria dagar blir snart heliga för varje teammedlem. Teamet kommer att göra sitt yttersta för att inte riskera bli bestulna på sin ledighet!

Teamet kommer göra sitt allra bästa för att uppfinna metoder och tekniker för att bättre säkra kvalitén (genom t.ex. automatiserade tester, m.m.) och kommer att föra djupare och bättre dialoger med produktägaren, kund och beställare för att inte missförstå kraven. Ingen vill vara ”orsaken” till att resten av teamet fick avbryta sina projekt-fria dagar för att lösa ett problem man borde fångat upp under sprinten.

Jag låter det vara osagt om teamets arbete att höja kvaliten med detta grepp föds ur höjd teamkänsla eller grupptryck. Det lämnar jag öppet för diskussion…

.

.
Ursprungligen publicerad på sogeti.blogg.se

.

h1

Om att mäta det agila projektets framgång (2/6) – Resultat

tisdag, 15 juni, 2010

Hur vet man att investeringen i utvecklingen matchar förväntningarna? Hur håller man koll på att projektet levererar ”i tid”? Hur mäter vi att mottagarna och beställarna är nöjda? Scrum påstår sig leverera mera funktionalitet av högre kvalitet som bättre matchar förväntningar och behov. Men hur mäter man och följer upp detta? Detta är andra delen av min artikelserie om tips, trix och verktyg för att mäta det agila projekts framgång och status.

Nedan listar jag några verktyg och mätvärden användbara för projektets produktägare och styrgrupp (Meta-Scrum) för bland annat release- och resursplanering. Men som alltid ska man ställa sig frågan varför man mäter något? Vad ska statistiken användas till? För vem är mätvärdet värdefullt? Historisk statistik på ett mätvärde i sig har inget värde, det är först när vi omsätter det till kunskap, insikt och handling som det ger oss något tillbaka. Fram tills dess är insamlandet och sammanställandet waste och kanske t.o.m. kontraproduktivt. Vi riskerar att belysa fel saker och kanske luras försöka bota symptom istället för det bakomliggandet problemet.

.

Release Plan vs. Effektmål

Vilka effektmål/affärsmål har vi satt upp med nästa Release? Vilka verksamhetsproblem hoppas vi lösa? Kommer nästa Release nå dessa mål? Ser prognostiserad tidplan ut att hålla?

Med en Release Burndown kan man enkelt prognostisera när scoopet för releasen är klar. Release Burndownen är också ett enkelt verktyg för att anpassa release-scoopet för att nå önskat release datum. Finns tydliga mätbara effektmål kan Produktägaren också avgöra om tillräckligt många av dessa blir uppfyllda.

Release Burndownen ger en tidig indikation på hur projektet går. Produktägare och styrgrupp kan avgöra om release-scoopet ska justeras, deadline flyttas fram eller om teamet behöver förstärkas med ytterligare resurser.

.

ROI kontra Kostnad

Får vi valuta för pengarna? Är förväntad Return Of Investment (ROI) högre än sprintens kostnad? När ROI/Sprint sjunker under en viss gräns är det kanske dags att vara nöjd och avrunda projektet… eller se över Produktbackloggen, dvs. ta ett kreativt omtag och  klura ut nya funktioner som kan skapa högre affärsvärde än de som ligger i produktbackloggen just nu.

Att leverera enligt Scrum ger oss möjlighet att kontinuerligt försäkra oss om att teamet jobbar på just de saker som ger mest affärsvärde. Men det är inte bara en möjlighet utan även produktägarens skyldighet att se till att just så är fallet.

Utöver själva sprintens kostnad växer förvaltnings- och driftkostnader desto större och komplexare systemet blir. Denna aspekt återspeglas inte i illustrationen intill men bör finnas med som beslutsunderlag vid releaseplanering.

.

Rest/Släp

Hög rest-ratio (dvs. ration rest-tasks från föregående sprint/sprintar kontra ny funktionalitet) kan signalera många olika saker men framförallt en oförmåga att avsluta features och efter sprint demo ha en produkt som är ”klar”, dvs. redo för paketering och leverans. Ju fler features som är  ”work in progress” mellan sprintar desto mindre flexibilitet får produktägaren i sitt arbete med att prioritera produktbackloggen och desto mindre frihet över release-planeringen och större osäkerhet kring release-prognoser.

Vidare, om det alltid följer med rester från tidigare sprintar in i nästa sprint finns det en risk att man missa eventuella underliggande tekniska problem eller andra typer av hinder som gör att teamet har svårt att avsluta features. Inte nog med att produktägaren får allt mindre ”nytt” levererat per sprint, projektets sanna status blir allt svårare att utläsa.

.

Driftsättnings-/Packeteringsinsats

Hur stor är den faktiska insatsen att driftsätta (alt. paketera produkten) efter nästa Sprint Demo? Har projektet skjutit upp tasks rörande överlämning till förvaltning, dokumentation, acceptanstest, installationsscript, etc. betyder det inte att man är redo för leverans bara för att Release Burndownen närmar sig noll.

Så länge Scrum-projektet inte levererar en potentiellt installerbar/levererbar ny version av systemet/produkten varje sprint förlorar man den kontroll och flexibilitet som Scrum utlovar.

Skjuts vissa saker upp tills det ”är dags” måste detta förankras med produktägaren (och eventuellt styrgruppen) eftersom Release Burndownen inte längre berättar hela historien. (Alternativt lyfts dessa arbetsuppgifter in i produktbackloggen och görs till en del av releasen.)
.

Risk Burndown

Agila utvecklingsmetoder hanterar risk på daglig basis naturligt genom korta feedback-cykler, dagliga möten, öppen insyn i teamets progress, ärlighet, tät dialog osv. Trots detta kan det vara en god idé att synliggöra de risker som finns och hur de förändras och hanteras under projektets gång. När projektet närmar sig release ska självklart denna risk helst nått noll.

Läs mer om Risk Burndown Chart i ett tidigare inlägg.

.

Project Success Sliders

Project Success Sliders är ett enkelt men kraftfullt sätt för stakeholders och produktägaren att förmedla sina förväntningar till teamet. I projektets inledande fas defineras ett antal ”sliders” som var och en ger uttryck för hur projektets framgång kommer betygsättas och bedömas.

Hur bra (eller dåligt) stakeholders och produktägare upplever att projektet går i jämförelse med uppsatta ”kriterier” bör följas upp löpande så att projektet så ofta som möjligt får en chans till feedback och möjlighet att agera och reagera om så krävs.

.

Project Success Sliders beskrevs först av Rob Thomsett i sin bok ”Radical Project Managment”. Nyligen släppte Mountain Goat Software ett snyggt och enkelt webb-verktyg för att skapa och ställa in project sliders – ”Project Success Calculator”.

.

Detta är del 2 av 6. Läs vidare:

Om att mäta det agila projektets framgång (1/6) – Introduktion

Om att mäta det agila projektets framgång (2/6) – Resultat

Om att mäta det agila projektets framgång (3/6) – Produktivitet

Om att mäta det agila projektets framgång (4/6) – Kvalitet

Om att mäta det agila projektets framgång (5/6) – Teamets nivå

Om att mäta det agila projektets framgång (6/6) – Agera på kunskap

(Länkarna uppdateras allteftersom artiklarna publiseras.)

h1

Om att mäta det agila projektets framgång (1/6)

fredag, 11 juni, 2010

På den gamla goda tiden gick det enkelt att ta reda på om det går bra eller dåligt för ett projekt. Hur många procent av kravlistan har vi bockat av? Hur stora (eller små) är avvikelserna från budget och deadlines? Samma frågeställningar fungerar inte tillfredställande i det agila projektet.

Vilka verktyg och mätvärden finns till hands när man jobbar agilt?

.

I ett agilt projekt finns det såklart oftast budget och deadlines men ingen detaljerad plan eller detaljerad kravlista att mäta avvikelser från. En av anledningarna till att man jobbar agilt är för att man insett att dessa måttstockar inte berättar något om hur bra produkt eller system man har byggt. Samt kommit till insikt om att planer bara är prognoser och inte något facit.

Detta betyder dock inte att vi ska sluta bry oss om hur bra eller dåligt ett Scrum-projekt går. En agil process som välkomnar förändringar och bygger på att skapar kunskap verkar dock slingra sig från att mätas. Vi måste ta till andra metoder och mätvärden än de vi kanske är vana med för att få en bra insyn i hur projektets sanna status är.

Först och främst borde vi förtydliga vad det är vi egentligen undrar när vi ställer oss frågan om ett projekt går bra? Kanske kan frågan styckas upp i följande, mer konkreta, frågeställningar:

  1. Är alla stakeholders nöjda? Tycker beställaren han/hon fått valuta för sina pengar?
  2. Upplever användaren att produkten/systemet är användbart och värdefullt?
  3. Håller produkten/systemet hög teknisk kvalitet och är fritt från buggar?
  4. Är systemet enkelt att förvalta/vidareutveckla?

.

Nedan listas förslag på mätvärden som kan användas för löpande utvärdering av ett projekts framgång och status och som beslutsunderlag under den löpande planeringen. I kommande artiklar (del 2-6) kommer jag beskriva var och en djupare och förklara vad dom syftar till och vad mätvärdet kan berätta om.

.

Agila mätvärden

.

Resultat
Projektets förmåga att göra stakeholders glada och leverera värdefull mjukvara enligt plan och prognoser…

  • Release Plan vs. Effektmål / ROI
  • Rest/Släp
  • Driftsättnings-/Packeteringsinsats
  • Risk Burndown
  • Project Success Factors

.

Produktivitet
Teamets förmåga att produktivt bygga och leverera funktioner…

  • Velocity – Trend
  • Velocity – Förutsägbarhet
  • Work In Progress
  • Focus Factor/DRAG
  • Time To Market

.

Kvalitet
Teamets förmåga att bygga kvalitativ mjukvara…

  • Buggar i produktion
  • Teknisk Skuld
  • Rest/Släp

.

Teamets nivå
Mår man bra och är motiverad gör man ett bättre jobb…

  • Agile/Scrum Mognadsgrad
  • Teamets välbefinnande

.

”You want the truth? You can’t handle the truth!”

Man får dock inte luras att tro att det finns egenvärde i något av ovanstående mätvärden! Eller än värre, ge sig i kast med att försöka sub-optimera med hänsyn till ett enskilt värde.

Alla former av suboptimeringar har en tendens att slå tillbaka och försök att belöna (eller bestraffa) team eller individer baserat på valfritt mätvärde riskerar sabotera projektet och kommer med tiden undergräva teamets effektivitet, moral och förmåga att bygga kvalitativ mjukvara.

Innan ni i ert projekt börjar föra statistik och historik fråga er varför ni mäter X, vilket problem hoppas ni kunna lösa och hur resultatet ska användas.

.

Detta är del 1 av 6. Läs vidare:

Om att mäta det agila projektets framgång (1/6) – Introduktion

Om att mäta det agila projektets framgång (2/6) – Resultat

Om att mäta det agila projektets framgång (3/6) – Produktivitet

Om att mäta det agila projektets framgång (4/6) – Kvalitet

Om att mäta det agila projektets framgång (5/6) – Teamets nivå

Om att mäta det agila projektets framgång (6/6) – Agera på kunskap

(Länkarna uppdateras allteftersom artiklarna publiseras.)

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.

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