”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…
En PMI certifierad project manager ställer sig frågan ”Can a ScrumMaster be a project manager — are the positions one in the same?” i en nyligen publicerad artikel. Vidare hävdar hon att ”The project manager is the overarching manager and person accountable at the project level, while the ScrumMaster is the one responsible for the product development.”
Intressant föreläsning från 
De berättade bland annat om hur de gick från (en för dem framgångsfull) vattenfalls baserad utvecklingsmodell till att jobba enligt Scrum inför 
Nu kan det ju dock såklart vara så att du har en person i Scrum teamet som gått på myten och tagit med sig missuppfattningen in i teamet och som hävdar att alla förslag på att införa stuktur, design patterns, templates, etc. går emot Agile värderingar och principer. Det finns inget enklare sätt att uttrycka det på – den personen är låååångt ute på åkern och cyklar.
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.
Collaborated & Designed
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.
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)
Henrik Kniberg skrev 2007 den populära boken 
Jimmy Janlén "Den Scrummande Konsulten" 