Archive for the ‘Scrum metodik’ Category

h1

Det beroendeframkallande spelet ”Scrum”

fredag, 12 november, 2010

Det finns belöningsmekanismer inom Scrum, stora som små, kortsiktiga och långsiktiga, som går att mappa mot ett online-spels dynamiska beroendeframkallande natur. Varför inte utförska dessa och förstärka dessa element inom Scrum?

Jag fick en ”Aha!” upplevelse tidigare idag när jag läste ett blogginlägg (Scrum & Gaming Addiction) av Peter Behrens som jämförde Scrum med online-spelens beroendeframkallande belöningssystem (som i t.ex. World of Warcraft och Farmville).

Peter refererar till ett TED Talk av Tom Chatfield – 7 ways games reward the brain. Inspirerad av Toms presentation reflekterar Peter över hur online-spelens belöningsmekanismerna återkommer i Scrum:

  1. Staplar som synliggör och mäter framsteg
  2. Multipla långsiktiga och kortsiktiga mål
  3. Belöna ansträningen
  4. Snabb, tät och tydlig feedback
  5. Ett element av osäkerhet/äventyr
  6. Möjligheter för vidare åtaganden
  7. Feedback och samarbete med andra människor

Om flera av ovanstående mekanismer saknas i ett online-spel tvivlar jag starkt på att det någonsin kan bli populärt eller kommer sälja speciellt bra. Man kommer helt enkelt tappa intresset.

Jag håller fullständigt med Peter om att man borde försöka förstärka de belönande mekanismerna även i Scrum. Vem skulle inte vilja ha ett jobb som man längtade tillbaka till, som erbjöd små och stora belöningen med jämna mellanrum, och blev belönad för att man anstränger sig och gör sitt bästa.

.

Förslag på belöningsmekanismer i ett Scrum-projekt:

Förslag: Visualisera så mycket som möjligt. Det finns en konstig tillfredställelse i att flytta post-its och kryssa av check-boxar.

Förslag: Lägg ner omsorg på fina och färgglada Burndown-charts. Gör varje dags framsteg synliga.

Förslag: Fira varje Sprint Demo med en tårta. Oavsett om teamet nådde i mål med sina Sprint mål så har teamet troligtvis ansträngt sig och gjort sitt bästa för att lyckas.

Förslag: Ring i klockan eller blås i vuvuzelan när en story uppfyller DONE.

Förslag (Peters): Istället för Story Points använd ”Cost Reduction Points” (om projektet går ut på att effektivisera IT driften), eller ”Social Status Points” om man bygger en Social Community. Eller varför inte ”DragonSlayer Erf” av den enkla anledningen att det är roligare.

Förslag: Låt teamet ha en ”Tech Day” under Sprinten, dvs. en dag då man tillåts göra vad man vill, t.ex. lära sig ett nytt verktyg, experimentera med en alternativ lösning, studera, etc.

.

Annonser
h1

Ena teamet med en Working Agreement

torsdag, 23 september, 2010

Definition of DONE är ett viktigt verktyg för det agila teamet för att för att teamet som veta vad som förväntas av dem innan de får lov att  säga ”Nu är vi helt klara med funktion X!”. Men Defintion of DONE beskriver inte hur vi jobbar eller vilka principer och värderingar vi värderar och eftersträvar. Det här är teamets ”Working Agreement” kommer in i bilden, ett sorts av kontrakt som beskriver samarbetet, processen och principerna.

I mitt nuvarande uppdrag har teamet under kort tid växt kraftigt och vi har diskuterat mycket hur vi ska samarbeta bättre och mer fokuserat, både internt i teamet men även gentemot våra beställare och stakeholders. Därför har behovet vuxit fram att dokumentera vårt sätt att arbeta och enas kring vad vi tycker är viktigt.

Dels har vi under årets lopp etablerat rutiner och en rytm, men vi har också haft många workshoppar på sistone där vi diskuterat hur vi vill jobba framöver och hur vi behöver ändra vårt angreppssätt för att kunna lägga i en ännu högre växel. Alla i teamet har engagerats i dessa diskussioner men även våra beställare, våra mottagare av systemen i förvaltning och berörde avdelnings- och it-chefer. Idag påbörjade jag arbetet att summera allt i en ”Working Agreement”.

.

Innehåll i en Working Agreement

En Working Agreement innhåller saker som till exempel (och vårt är inget undantag):

  • Daily Stand-Ups – När och var hålls dom? Vilka är bjudna? Hur ser rutinen ut?
  • Planering – Hur genomförs Sprint Planning, Pre-Sprint Planning, Story Time Sessions, etc. När går de av stapeln? Vad är målet för respektive möte? Vem förväntas förbereda vad? Osv.
  • Test- & Kvalitetsstrategi – Hur testar vi? Vad testar vi? Vilka testar? Hur samarbetar teamet med beställaren i acceptans-testandet?
  • Principer och värdering – Vilka principer och värderingar vill vi att alla i teamet värnar om och lever efter? Vad är viktigt för oss vad gäller dialog och samarbete?
  • Hantering av buggar och defekter (under sprinten, efter sprinten)
  • Produktägarens ansvar
  • Scrum Masterns ansvar
  • Rapporter, Burndowns och Protokoll – Vilka behövs? Vem behöver dem? När önskas dom?

.

Workshoppa fram en Working Agreement

Enklaste och bästa sättet är (såklart) att bjuda in alla berörda till en workshop där ovanstående punkter diskuteras igenom ordentligt. Var inte snål med tiden då många av punkterna kan väcka mycket diskussion och debatt och det är viktigt att alla enas och håller med om det som slutgiltigen skrivs ner i en Working Agreement.

.

Signering

När Working Agreement diskuterats klart och formaliserats i text bör var och en i teamet skriver under på att man håller med och att man lovar att anstränga sig för att leva upp till överenskomna principer och värderingar och att man ämnar jobba efter den process man tillsammans kommit överens om.

När en ny teammedlem introduceras till teamet ska såklart även denna ta del av Working Agreement samt ges möjlighet att påverka och diskutera innehållet innan man skriver på.

.

Att vara agil betyder att lära sig

En Working Agreement är på inget sätt något heligt som är skrivet i sten. Kommer teamet fram till att man vill jobba på ett annorlunda sätt eller om nya principer och värderingar växer fram gäller det att kontraktet uppdateras så att det reflekterar detta.

Ha som vana att på Sprint Retrospective ställa er frågan om det är något som behöver justeras, uppdateras, tas bort, läggas till eller öppnas upp för diskussion.

.

Erfarenheter och tankar?

Har du erfarenhet av att sätta ihop en Working Agreement (eller liknande konstruktion) i ditt team? Hur gick ni tillväga och hur har resultatet fallit ut? Har det hjälpt teamet?

.

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

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.)