Dags att utrota Sprint Demo?

En feedback loop

Va? Är inte Sprint Demo en fantastisk idé?

Visst, grundtanken när man kör en Sprint Demo är ofta god. Man vill ha feedback. Så långt är allt bra, men att köra Sprint Demo för med sig ett antal problem också.

Att köra en demo efter varje sprint leder oftast till missade releasedatum, teknisk skuld och till felaktiga prioriteringar!

Så många och stora problem orsakas av Sprint Demos att jag skulle vilja be er alla att genast plocka bort dem från era kalendrar.

Men Sprint Demo är väl en del av Scrum?

Nej, faktiskt inte. Det finns en liknande sak i Scrum som heter sprintgranskning (eng. Sprint Review), men det är en väldigt annorlunda aktivitet jämfört med det som oftast kallas “demo”.

Inte för att det spelar någon roll om ni följer Scrum eller inte, men i just det här fallet tror jag att de flesta skulle kunna få ut mer värde genom att byta från “demo” till “granskning”.

Vad är skillnaden på en demo och en granskning?

Syftet

  • Tänk dig att en försäljare demonstrerar en produkt för dig. Syftet är att få den att se bra ut. Kanske att ge en applåd från publiken när de ser hur snyggt och bra allt ser ut!

  • En granskning har däremot syftet att skapa en verklig förståelse av hur det ligger till med något. Utan försköning. Bra eller dåligt. Om man vet hur man ligger till kan man göra planer, prioriteringar och fatta beslut som bygger på fakta. Får man en felaktig uppfattning om hur man ligger till blir planerna opålitliga och besluten fel.

Samspelet

  • En demo är oftast en enkelriktad aktivitet. Någon visar upp/demonstrerar något.

  • Deltagarna i en granskning däremot är aktiva och letar efter fel som kan åtgärdas och förbättringar som kan göras.

Kvalité

  • Jag har varit med och byggt demos för många olika kunder. Det kan vara för en kundpresentation eller för en mässa t ex. Stressen är ofta stor för att få med så mycket som möjligt och för att få produkten att se bra ut.

    Tillfälliga lösningar och genvägar tas till för att hinna. Kvalitén är långt ifrån det man vill ha i produktion och alltihopa borde helst kastas bort och göras om för att kunna vara en del av en kvalitetsprodukt. Kunderna får dock intrycket av att det är klart vilket ökar pressen ännu mer. Dålig kvalité börjar smyga sig in i produkten.

  • På en sprintgranskning går man bara igenom de saker som lagts till i produkten och som uppfyller Definition of Done. Dvs de har full tekniskt kvalitet och är klara för produktion.

    En bra Definition of Done innebär att man kan lägga en story/feature åt sidan när den passerat. Man behöver inte gå tillbaks till den för att göra klart någon del eller rätta tekniska defekter i framtiden.

    Eftersom man inte behöver gå tillbaka till en feature/story kommer den inte att påverka de framtida planerna.

    Det kan ta ett par år att komma hit som organisation. Automatisering av test/regressionstest brukar t ex vara en utmaning. Likaså brukar det ta ett tag att införa vanan att refaktorera fungerande kod tills den är lätt att läsa och ändra innan man räknar den som “Done”. Men när man lyckats blir allt mycket lättare. Tid som man förr lade på att rätta gamla saker frigörs. Man kan fokusera på nya saker, får snabbare progress och en roligare arbetsmiljö.

Ett exempel

 

15 teams som integrerar

I en organisation som jag jobbade med hade vi ca 15 teams och körde demos efter varje sprint. Alla teams hade jobbat hårt och gjort en massa saker. På demon berättade de om allt de gjort och visade små filmer. Alla var glada och det verkade rulla på bra med utvecklingen. Det verkade dock som att det alltid var något lite kvar att göra för varje sak innan den var riktigt klar. Det mesta var 90% klart…

Efter demon skulle produktägarna uppdatera sina prognoser/tidplaner. Det här var en del av en stor organisation med många beroenden utåt, så det var viktigt att kunna visa hyfsade prognoser mot externa teams så att de kunde anpassa sin planering.

Vad var problemet?

Hur mycket utvecklingstid återstår då på en feature som är 90% klar? Vad skulle produktägarna räkna med i sina planer? Problemet är att ingen vet det. Innan vi är helt klara kan det alltid dyka upp nya oväntade problem. Små som stora. När det är 90% klart, kanske 90% återstår...

Effekten av att jobba så här är att när man närmar sig någon viktig leverans så är allt 90% klart och ingen har en aning om hur man ligger till. Alla får jobba övertid och endera missar man leveransen eller så släpper man ut en tekniskt undermålig produkt. Felen strömmar in och man får betala dyrt i form av bortslösad tid. Rättningar tar normalt sett minst 5-10 gånger längre tid än vad det tagit att göra rätt från början. Stressen ökar och kvalitén sjunker ännu mer.

Omgivningen blir missnöjd över kvalitén och den dåliga precisionen i planeringen. För att få koll börjar ledningen kräva mätvärden och detaljstyra teamen. Statusrapportering av felrapporter kommer i fokus istället för nyutveckling och innovation. Mätvärden i form av “velocity” gör att kvalitén försämras ytterligare när teamen tar genvägar för att visa upp bra resultat.

Vad vi gjorde

Det här var fortfarande i ett ganska tidigt skede i ett nytt utvecklingsinitiativ. För att förekomma alla de här dåliga konsekvenserna bytte vi namn på Sprint Demo till sprintgranskning och införde nya regler. Bara det som uppfyller Definition of Done får visas på sprintgranskning. Definition of Done i det här fallet innebar bl a att automatiska testfall ska finnas i CI-kedjan och att all integration mellan de 15 lokala teamen ska vara gjord.

Förändrings-smärtan

 

Irriterade teams

Förändringen gav upphov till en hel del missnöje. T ex

  • “Varför får inte vi visa vad vi gjort? Vi är ju klara. Vi väntar ju bara på att kunna integrera med det andra teamet!”

  • Våra saker är så stora att då kommer vi ju aldrig att få visa något!

  • Vi är ju klara nu! Det är ju bara problem med CI-miljön som gör att vi inte kan skriva klart testerna!

  • Energin är väldigt låg nu med det nya sprintgransknings formatet, vi måste ändra agendan för att uppmuntra våra team!

  • “Den dumma som har hittat på det här med integrerade end-to-end-feature-slices (jag ? 😉 ) kan göra nedbrytningen själv!”

När vi började hålla på de nya reglerna för sprintgranskning visade det sig också att det inte var lätt att få något helt klart. De första 3 sprintarna lyckades inget team få klart någon av totalt ca 30 saker de räknat med att göra under perioden! Efter ett kvartal började det släppa och slutligen lyckades teamen få klart ca 10 av de 60 funktioner som de själva lagt som prognos för kvartalet.

Förbättringen

Innan tyckte man alltså att det gick i stort sett bra och enligt plan. Nu visste vi mer om hur lång tid det tar att verkligen tar att göra klart något och kunde vara mer trovärdiga i våra planer/prognoser mot vår omgivning.

När slutligen progressen började komma, kom glädjen och energin tillbaka i sprintgranskingen.

Saker som är “Done” har nu automatiserade regressionstester och kommer att ställa till med mindre problem och störningar i framtiden.

Fokus på att få klart saker drev också många bra diskussioner/beteenden:

  • Fokus på samarbete/samplanering mellan team så att integration kan göras under sprinten. Mindset-förändring: I en miljö med många team och beroenden kan inte ett team vara klara utan att de andra är klara. Innan allt går att köra i den gemensamma integrerade målmiljön är det inte “Done”. Innan dess återstår ju nämligen integration, vilket är ett av de största problemen/riskerna i stora organisationer, så det vill vi inte skjuta upp, utan helst göra kontinuerligt (CI). Som senast ska det vara gjort inom sprinten.

  • Fokus på nedbrytning i mindre end-to-end slices av funktioner som kan avslutas inom sprintarna. Det ger tidigare integration, bättre förutsägbarhet och gör det lättare att alltid har en releasebar produkt. Dvs ingen övertidshets eller dålig kvalité när det närmar sig leverans.

    Mindre arbetspaket förbättrar också flödet och ökar farten. Det vet den som har koll på idéerna i Lean. 
  • Fokus på teststrategier och samarbete mellan teamen på att lösa svåra testfall drev fram bättre tekniker för test. 

Invändningar

Om vi väntar tills något är “Done” innan vi visar det på vår sprintgranskning, går vi inte miste om feedback då?

Nej, se till att ha ett nära samarbete under sprintarna med era intressenter och fånga feedbacken där. Att hitta problem på sprintgranskning är i senaste laget. Mycket arbete kan ju vara nedlagt förgäves om man väntar till sprintgranskningen med att få feedback. Låt den vara en sammanfattning istället där vi gör en sista koll av att alla är överens om att en feature/story är “Done”. Försök även så långt som möjligt granska om den löser det verkliga behovet/levererar tänkt värde.

Spelar det någon roll vad det heter? Vi kan väl kalla det Sprint Demo och ha fokus på “Done”?

Nyord

Tyvärr funkar det inte i praktiken. Många försök att ändra betydelsen av olika ord har gjorts i agile-värden. T ex att kalla något för en demo men att köra en granskning. Men vilka ord man använder påverkar mer än vad man kan tro.

Kallar man det demo så blir fokus på att visa saker och få det att se bra ut. Prio läggs på det som är lätt att presentera istället för det som har högst prio. Saker som inte går att demonstrera tas inte ens upp till granskning. Kvalitén sänks för att få saker att se bra ut.

Dvs; det går inte! Ord har en betydelse och det går inte att ändra med en annan agenda. Ni måste byta namn på er Sprint Demo om ni vill få fördelarna av en sprintgranskning.

Sammanfattning

Genom att gå över från Sprint Demo till sprintgranskning så lärde sig organisationen i exemplet ovan relativt snabbt en hel del om vad som krävs för att många teams ska kunna bygga en produkt tillsammans.

Att byta sin Sprint Demo mot en sprintgranskning är inte en helt enkel ändring att göra. Helt plötsligt blir den verkliga progressen synlig. Likaså blir alla problem som hindrar organisationen från att ta sig framåt smärtsamt tydliga.

Men fördelen med det är ju att när man vet vad man har för problem kan man åtgärda dem. Utvecklingen kommer då bara att flyta på bättre och bättre ju fler saker man lyckas åtgärda. Trivseln kommer att öka och man kan såsmåningom löpande leverera kvalitetsprodukter som alla kan vara stolta över, utan panikartade övertidsrace.

Har ni “demos” hos er, på sprintnivå eller på andra skalningsnivåer? Fundera på om det inte är dags att gå vidare och börja köra en granskning istället!

Gilla och dela gärna det här inlägget:

maj 21, 2018


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


LinkedIn
Facebook
Facebook
Instagram
Follow by Email