Posts Tagged ‘agile_planning’

h1

Det är dyrt att vara riktigt agil. Eller?

onsdag, 2 november, 2011

Att vara agil när man jobbar i Scrum betyder (bland annat) att man efter varje iteration har lyckats bygga en ny fungerande och värdefull version av produkten (eller systemet) som går att leverera till kund eller butik om man så önskar. Men att vara riktigt agil kostar. Eller?

För att varje sprint ska resultera i en nytt levererbart inkrement ställs det stora krav. Först måste vi ha lyckats bryta ner våra features så att de är tillräckligt små så att flera får plats i sprinten. Och med ”få plats” menar jag att man hinner med allt för att gå från idé till leverans, dvs. varje enskild feature ska designas, kodas, testas, dokumenteras och sammanfogas med helheten (allt enligt vår Definition of DONE for User Stories). Vi behöver dessutom känna oss trygga i att resten av systemet fortfarande fungerar och att vi inte har introducerat nya buggar.

Om vi förutsätter att vi har kontroll över våra IT-system och inte har några externa beroenden vad gäller testmiljöer och servar (vi är inte beroende av externa köer för att få något jobb gjort) så är det ändå inte helt trivialt att få till en leverans varje sprint.

Låt oss titta på ett exempel på hur en treveckorssprint skulle kunna se ut.

.

Först och främst har vi våra Scrum möten. Syftet med dessa är att planera (läs analysera) vad vi ska göra härnäst (Sprint Planning), hur vi på bästa sätt koordinerar oss inom teamet (Daily Scrum), fånga upp feedback så att vi kan förbättra processen (Sprint Retrospective) samt lära oss vad som kan göra produkten ännu bättre (Sprint Demo). Sista fredagen är dessutom en sprint-fri dag där teamet kan hämta andan och samla ny energi till nästa sprint.

.

För att vi med trygghet ska vilja lämna ifrån oss den nya versionen (som innehåller våra nya features) vill vi dessutom känna oss trygga i kvalitén. Detta gör vi med att arbeta med att fixa buggar och verifiera buggfixar (Hardening). Vi vill också testa igenom systemet i sin helhet för att försäkra oss om att vår nya kod inte saboterat någon annan funktionalitet eller försämrat någon egenskap (såsom t.ex. prestanda). Denna testning inleds typiskt med en uppgradering av acceptancetestmiljön. Hela teamet hjälps åt att testa. Vad man fokuserar på klurar man ut som team genom att göra en riskanalys. Det kan t.ex. innebära en balans mellan körning av delar av regressionstestsviten plus identifierade Exploratory Testing sessioner. Var man lägger sin testfokus beror på var man ser att riskerna finns, vilka moduler som utsatts för förändring etc. När så slutgiltig paketering är gjord och en sista hand har lagts på dokumentationen är teamet redo att leverera den nya versionen till kund eller förvaltning. Tada!

.

Det som återstår är vårt utrymme för utveckling. Det är alltså denna tid som finns tillgänglig för design, kodning, testning och dokumentation av nya features. Det vi påbörjar ska hinna slutföras innan ”Code-freeez-mode” slår till.

.

Sådärja. Då har vi lyckats visualisera de olika typerna av arbete som pågår under en sprint. Låt oss visualisera hur de olika formerna av arbeta står i proportion till varandra…

.

Nu ska man ställa sig två frågor:

Vilket arbete tillför värde?
Vilket arbete är waste?

.

Eftersom exemplet inte förtäljer hela historien så kan vi bara spekulera. ”Development” och ”Scrum Meetings” tillför såklart värde, det är här vi skapar, analyserar, planerar, designar och koordinerar oss. Sedan bör vi ställa oss frågan – kan Scrum mötena (såsom sprint planeringen) göras effektivare och kortare?

”Hardening” borde inte behövas om vi byggde kvalitet från början. Detta är tydlig waste. Packaging, miljöuppgraderingar etc. döljer också troligtvis en hel del waste – detta borde gå att automatisera.

Den gemensamma testinsatsen som sker i slutet av sprinten… är den waste? Jag skulle argumentera för att den inte är det – här bygger vi kunskap om hur systemet som helhet mår efter att vi infört våra förändringar och bygger beslutsunderlag till frågan – ska denna release gå till kund?

.

.

Det som blir uppenbart av att titta på bilden är dock att själva utvecklingen av nya features som mest utgör hälften av arbetet. Mycket tid går åt till ”annat”. Man skulle kunna påstå att Velocityn blir ”lidande” (antal features eller Story Points per sprint) eftersom vi anstränger oss för att vara helt agila. Från ett leveransperspektiv är det så att varje sprint levererar ett färdigt och komplett increment, dvs. Definition of DONE för User Stories är komplett och lämnar inget till senare. Vi VET att vi hela tiden är redo för leverans till kund. I exemplet ovan ”vet” vi att vi har levererat 24 features när deadline närmar sig.

.

Att vara helt agil i Scrum kostar så det är enkelt att lockas till att flytta ut vissa kriterier från Definition of DONE for User Stories till Definition of DONE for Release. Dvs. vi skjuter viss testning, viss dokumentation, etc. till en ”release sprint”. Detta ökar vår Velocity (antalet features per sprint), men vi är å andra sidan inte leveransredo varje sprint eftersom vi har skjutit arbete och risk framför oss. Faktum är att release sprinten troligtvis inte alls blir en strikt timeboxad sprint eftersom vi inte vet hur mycket arbete och risk vi skjutit framför oss förrän vi sitter ner och planerar (och exekverar) den sprinten. Med detta upplägg kanske vi levererat 30 features när deadline kommer, men det troliga är att vi kämpar med testning, buggfixningar och refactoring av tekniska svagheter långt förbi deadline. Vad ännu värre är att vi har skapat en rejäl fördröjning i feedbacken mellan test och kodning då vissa tester inte körs förrän så mycket som fem sprintar senare.

.

Att inte vara DONE utan att först uppnå DONE i release sprinten öppnar upp för följande:

Vi riskerar missa deadline
Vi introducerar waste genom långa feedbackcyckler (både vad gäller test och kvalitet men även kundens feedback om funktions värde)
Vi skjuter på tekniska risk och missar chansen att hantera problem tidigt
Vi tappar den sanna insynen i hur vi faktiskt ligger till (vi vet inte vad som är klart och vad som är ”work in progress” eftersom vi inte testat klart)
Vi förlorar styrförmåga. Innan vi helt kan styra om fokus måste vi genomföra release ”sprinten”.

.

Så är det dyrt att vara agil, eller är det kostsamt att inte vara det?

.

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

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

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

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

Agila verktyg i min Android

onsdag, 14 april, 2010

Har upptäckt att det finns en hel del små fiffiga appar på min Android som kan vara bra att ha till hands för utvecklarna i det agila teamet och den gadget-glade Scrum Mastern. (Jag är säker på att samma appar eller motsvarande går att hitta till iPhone också.)

När jag började skriva detta inlägg tänkte jag ta upp alla appar jag hittat hittills men då hade inlägget återigen blivit på tok för långt så därför fokuserar jag denna gång på några time-managment appar.

.

Pomodoro timers

Har precis börjat studera Pomodoro och praktiserar det faktiskt just nu! Därför blev jag glad när jag upptäckte en radda appar för ändamålet. Pomodoro går kort och gott ut på att man gör en To Do lista för dagen, angriper den punkt man tycker är viktigast, vrider upp timern på 25 minuter, jobbar oavbrutet och fokuserat på vald uppgift tills klockan ringer, tar en kort paus och väljer sedan den punkt i To Do listan som känns viktigast nu (eller så väljer man att fortsätta på uppgiften man höll på med om man inte blev klar). Jag föredrar dock alltid en riktig timer framför dessa appar men det är inte alltid man har en till hands och det är inte alltid folk runtomkring en uppskattar tickandet och ringandet.

Pomodroid
(Utvecklad av: Neto Marin)

En simpel timer man kan start och stoppa. Startar alltid om på 25 minuter (ej konfigurerbart). När man klickar på skärmen startar timern och tomaten blir röd. När 25 minuter har gått ringer och vibrerar telefonen. Kort och gott. Gillar appen för dess renhet och enkelhet.

.

Pomodoro Tasks
(Utvecklad av: Kavan Puranik)

Denna Pomodoro app är lite mer avancerad. Du sätter upp din To Do lista innan du startar timern för en vald uppgift. Listan kan sorteras om, tasks stryks enkelt med en fingerdragning och lite andra funktioner finns.

Även om det är en fin idé så faller appen också lite på just dess utbud av funktioner, det finns helt enkelt inte stöd för allt man vill göra (som t.ex. anteckna hur många pomodoros en uppgift tog m.m.). Känner själv att verktyget begränsar mer än hjälper.

.

Meeting Time Tracker
(Utvecklad av: Espinassous Etienne)

Ett enkelt verktyg i första hand designat för Scrum Mastern eller mötesordföranden för att se till att möten inte överskrider Time-boxningen.

Du stället helt enkelt in hur långt mötet är och startar timern. Utöver att skriva ut tiden visar den även hur status på hur långt det är kvar; hälften, 15 minuter, 10 minuter och 5 minuter. (Planerar att använda själv den på fredag när det är dags för nästa seminarie för att enkelt hålla koll på om jag hinner med dom slides jag tänkt mig innan nästa paus.)

h1

Scrum myt #4: Zoomar man in är Scrum bara små, små vattenfall

onsdag, 31 mars, 2010

”Om man zoomar in tillräckligt mycket i Scrum, in i en sprint så är det ju bara små, små vattenfall. Inget nytt under solen.” FEL!

.
.
.

Scrum är inte små, små vattenfall.

Det grundläggande arbetssättet:
1) planera,
2) utföra,
3) kontrollera och
4) agera

dvs. att man tänker och planerar innan man handlar är inte synonymt med vattenfall.  Så gör man i alla situationer, oavsett uppgift.

.

Så, till skillnad från vattenfall så…

  • Levererar Scrum affärsvärde och ROI väldigt tidigt.
  • Scrums korta feedback cykler förändrar dagligen planen och planering.
  • Planering i Scrum fokuserar på att leverera affärsvärde (inte sprida ut arbetsuppgifter och deadlines i en kalender).
  • Scrum processen är själv-justerande och själv-förbättrande genom kontinuerlig utvärdering och granskning (i motsats till att ha en projektutvärdering i slutet).
  • Scrum välkomnar förändringar, till och med sent i processen, och detta är en naturlig del av processen.
  • Springer man in i bekymmer och tidsnöd så anpassar man i Scrum omfattningen (i motsats till att låta arbetsuppgifterna i planen skjutas framåt som ett tåg av dominobrickor).
  • I Scrum räknas inte framgång i antalet implementerade krav per deadline utan i levererat affärsvärde och kundnytta per sprint.
  • Levereras projektet enligt Scrum kan beställaren efter valfri* Sprint säga ”Nu är jag nöjd” (till skillnad från vattenfallsapproachen då allt eller inget levereras).
  • Scrum levererar potentiellt installerbar system/levererbar produkt varje sprint. Dvs. dokumentation, test, förvaltningsöverlämning etc. ska ske kontinuerligt (i stället för att komma som faser i slutet).

* Brasklapp. Det kan såklart dröja några sprintar innan man nått en minimal nivå av funktioner för att produkten ska gå att använda över huvud taget. Och ibland kanske det också krävs en stabiliserings- och Deploy sprint efter att beställaren ”är nöjd”.

.

Jag kan fortsätta rada upp skillnader. Jag hoppas dock i och med detta utbrott att det en gång för alla är vederlagt och fastslaget att det är stor skillnad mellan sekvensiell up-front planering/big-bang leverans (a la vattenfall) och agil planering/iterativ inkrementell leverans (Scrum). Fast att tro något sådant kanske vore nog naivt…