Posts Tagged ‘scrum’

h1

Utmana teamet med ”Jimmy Cards”

tisdag, 26 mars, 2013

Söker du efter ett verktyg som har förmågan att utmana teamet och sätta igång spännande diskussioner? Diskussioner som kanske till och med inspirerar till förändring? Då tycker jag du ska prova ”Jimmy Cards”!

I söndags kväll publicerade jag en blogg på blog.crisp.se och berättade om ”Jimmy Cards”, en kortlek jag precis fått till en MVP av. Redan efter fem minuter hade första beställningen kommit in och fler beställningar har stadigt trillat in sedan dess.

Kortleken är en uppsättning frågor och används fördelaktigt som ice-breaker på scrum teamets retrospective eller för att välja ett utmanande ämne för teamets onsdagsfika.

Nyfiken på att veta mera? Klicka då här för att komma till blogg-inlägget 🙂

Annonser
h1

Sogeti Inspiration Day inspirerade

torsdag, 10 maj, 2012

Igår gick Sogeti Inspiration Day av stapeln i Stockholm. En härligt stor skara kunder och kollegor i branchen sökte sig till Vagnhallarna för att inspireras av ett dussintal talare höll seminarier inom lika många olika heta ämnen.

Själv berättade jag om ”Den Agila Revolution” som har pågått och fortfarande pågår mitt framför våra ögon.

Dagen inleddes med registrering och frukost 08:30. Sedan var det fullt ös från klockan nio fram till lunch med seminarier. Fyra parallella spår kunde man som besökare välja bland. Kategorierna var: ”Digital Närvaro”, ”Utveckling”, ”Test” och ”I hetluften”. Efter en timmes lunch upprepades agendan så att man fick en chans att lyssna till det man var intresserad av trots att man kanske valt ett annat pass under förmiddagen. Mitt seminarie ”The Agile Revolution” placerades i kategorin ”I hetluften”. Dagen avslutades med öl och mingel och mycket spännande eftersnack.

.

Mitt seminarie; ”The Agile Revolution”

I agendan för dagen kunde man läsa följande:

”Det har snart gått 20 år sedan de första agila metoderna experimenterades fram och började sprida sig. Idag pågår en revolution mitt framför våra ögon. Jimmy Janlén, Scrum Master och Agile Coach på Sogeti, delar med sig av sin betraktelser och tankar av vad som driver förändringen, vilka dom största utmaningarna är runtom i företag och organisationer samt ställer frågan – finns det rosa agila elefanter, och vilka är dom i så fall?”

Och det var i princip vad jag berättade om. Eftersom agendan upprepade sig på eftermiddagen fick jag två chanser på mig. Inför första morgonpasset var jag riktigt nervös då det fem minuter innan seminariet skulle börja endast var en person i rummet. När klockan väl slog nio så var det kanske femton sjutton personer som hade tyckt upp och som var intresse av ämnet. Pust.

När det var dags för andra passet direkt efter lunch var dock salen fylld till bredden och vi blev till och med tvugna att plocka in fler stolar. Min energi var högre, jag hade fått lyxen att repetera en gång tidigare samma dag och jag upplevda att alla i publiken var taggade och nyfikna på ämnet. Kort och gott så var det ett mycket roligt pass att hålla och jag tror jag tryckte på flera knappar som många kunde känna igen sig i.

Själv hade jag riktigt skoj och blev själv inspirerad av de frågor och reflektioner som dök upp under och efter seminariet. Tack alla som kom och lyssnade!

.

Här kommer några utdrag från presentationen.
Klicka på bilderna nedan för att se dem i större versioner.

  

  

  

h1

Summering Agila Sverige 2012 + Mitt blixttal ”Krav är en flyktig version av målet”

onsdag, 2 maj, 2012

Förra veckan gick Agila Sverige 2012 av stapeln. Det var två fantastiska dagar, sprängfyllda med blixttal, OpenX-diskussioner och nätverkande.  Jag höll ett blixttal själv på temat ”Krav är en flyktig version av målet”. Gillade du Star Wars-teckningarna så hittar du nu min presentation här.

.

Ola Ellnestam

Dag 1 – Intro och Fish Bowl

Efter registrering och frukost öppnade Ola Ellnestam som hade flygit hem (från USA?) med en intro och ett välkomnande till Agila Sverige 2012. Detta följdes av en mycket spännande Fish Bowl på scen.

Ämnet som diskuterades var hurvida mjukvarubranchen drev förändringarna i arbetsmiljön. Eller det var åtminstone där den typ började. De diskuterande personerna i panelen böts löpande ut vilket gjorde att diskussionerna aldrig fastnade utan hela tiden evolverade till något annat.

.

Blixttal – Omgång 1

Fish Bowlen följdes av fika och sedan blixttal fram till lunch. Några exempel på ämnen var: ”Aristoteles förenkling – om hierarkier, kvalitet och design” (Joakim Holm, Adaptiv), ”Perceptual Blindness” (Jagannath Tammeleht, Ontrax) och ”Allt kan inte torktumlas. Men allt kan mätas.” (Torbjörn Gyllebring, Cint).

Energin infann sig snabbt och sedan rullade det på.

.

Mitt Blixttal – ”Krav är en flyktig version av målet”

Jag, kamouflerat nervös

Själv hade jag svårt att riktigt fokusera eftersom jag själv skulle upp på scen sist detta pass. Sjukt nervös kliver jag upp för att berätta om att ”Krav är en flyktig version av målet”.

I en sal full med erfarna och duktiga Scrum Masters, Agile Coaches och kollegor i branchen är man alltid orolig för hur ens presentation och budskap kommer tas emot. Helt klart gick iallafall mina handtecknade illustrationer hem. Fick många fina kommentarer på Twitter direkt efteråt. Tack!

Klicka på bilden nedan för att se presentationen. Den ligger upplagd på SlideShare. Dock saknas kommentarer eller förklarande texter till bilderna. Detta kommer kanske senare.

.

Presentationen på SlideShare:
http://www.slideshare.net/JimmyJanlen/blixttal-agila-sverige-2012-krav-r-bara-en-flyktig-version-av-mlet

.

(Klicka för att se presentationen ”Krav är en flyktig version av målet”)

.

Mera blixttal – Drama Driven Demo

Adam Killander

Efter lunch var det dags för ännu fler blixttal. Starkast intryck under detta pass gjorde utan tvekan Adam Killander från Adaptiv som berättade om hur man kan gör Sprint Demon roligare för alla.

”Krydda din demo med rollspel”
– Adam Killander

På ett fantastiskt sätt och med stor inlevelser berättade Adam hur de i hans team hade börjat dramatisera sina Sprint Demos med rollspel för att åstadkomma mera show och locka större publik. Uttrycket ”Drama Driven Demo” var myntat och blixttalet blev en stor snackis under eftermiddagen och kvällen.

.

I samma pass berättade Joakim Ohlrogge (Agical) om ”Konsten att inte hinna göra dåliga saker” och Sebastian De Bachtin (Dynabyte) berättade om ”Praktiska erfarenheter om automatisk bildjämförelse av en webbplats”. Många fler höll spännande och bra blixttal också, men ska jag berätta om alla detaljerat här kommer jag slå rekord i blogginläggs-längd (vilket jag riskerar göra ändå).

.

Open X

Återstoden av eftermiddagen utgjordes av OpenX. En tjog ämnen röstades fram och sedan pågick det spännade och riktigt givande diskussioner i nästan tre timmar. Vad jag kan minnas så deltog jag i diskussioner kring Självorganisation, Distrubuerade Team och ”Rymms Innovation?”.

I rasterna hölls det Ignite-tal. 30 slides, 15 sekunder per slide. ”Wow” får summera de talarnas prestationer!

Alla söker febrilt efter vilket OpenX pass man ska ansluta sig till härnäst

.

Dag 2 – Ännu mera OpenX och blixttal

Dag två började som dag ett, med en härlig frukost. Hela förmiddagen utgjordes av blixttal. Något jag inte nämnt hittills var att det pågick blixttal parallellt i två olika rum så var tionde minut var det dags att välja om man ville sitta kvar eller flytta på sig. Här lyssnade jag till ett inspirerande pass om ”Innovation Games and Agile Teams” (Ulf Hannelius, Aneega AB) och ”Vad är Lean? Egentligen?” (Rickard Lindberg). Dock stack följande två blixttal ut:

Agile @ Home
– Henrik Kniberg (Crisp)

Henrik Kniberg – Om diskning

Henrik berättade hur han och hans familj applicerat Lean och Agile hemma, både i hemmets sysslor men även i planerandet och genomförandet av en riktigt lång familjesemester. Henriks redogörelse lockade till många skratt när han bland annat berättade om WIP-limitar i diskstället, barnens byrålådor m.m.

Blev så pass  inspirerad att vi hemma nu infört en WIP-limit på vår egen disk hemma. Vi har sedan en vecka nästan helt optimerat bort diskning genom att endast ha en tallrik, en kniv, en gaffel, osv. vardera. Funkar fint än så länge!

.

Making Change Stick in 30 Days
– Tom Kealey (Zerodegrees)

Tom berättade om hur man faktiskt får förändringsförslag från t.ex. Sprint Retrospectives att fastna. Mest inspirerande dock var att höra om hans egna ”30 day challenge” åtaganden. Var trettionde dag satte han upp en ny utmaning för sig själv för att växa och våga prova nya saker. Hans utmaning just nu består i att fota ett slumpmässigt valt motiv om dagen. Tror han kommer få problem att fånga ”Självmord”… Hur som helst, detta ska provas! Har redan satt igång min första challenge – förvandla en powerpoint-slide om dagen till en handtecknad illustration.

.

Återstoden av dagen ägnades först åt mera OpenX, och sedan ännu mera blixttal. När dagen var slut var det svårt att slita sig och gå hem. Jag ville höra mera, lära mig mera, diskutera mera och nätverka mera.

.

Summering

På det hela taget en fantastisk tillställning. Längtar redan till nästa år. Då ska jag också se till att börja förbereda mitt blixttal tidigare än samma dag som den ska lämnas in…

Ett stort supertack till alla i arrangörsgänget!

Arrangörsgänget

.

Länkar, bloggar och presentationer
(slumpartad ordning):

Twitter flödet:
http://twitter.com/#!/agilasverige 

Videoinspelingar (upplagda på YouTube av Adaptive):

.

Henrik Knibergs presentation ”Agile @ Home”
http://blog.crisp.se/2012/05/02/henrikkniberg/agilehome

.

Anteckningar från OpenX passet ”Det är tufft att skriva test!”
http://codification.wordpress.com/2012/04/25/det-ar-tufft-att-skriva-test/

.

Håkan Forss – Agile LEGO – Toyota Kata an alternative to Retrospectives
http://hakanforss.wordpress.com/2012/04/25/agile-lego-toyota-kata-an-alternative-to-retrospectives/

.

Rickard Lindbergs presentation – ”Använd rena funktioner för att undvika oavsiktlig komplexitet”
http://dl.dropbox.com/u/54763058/rena_funktioner_oavsiktlig_komplexitet_rickard_lindberg_agila_sverige_2012.pdf

.

Jonas Hermanssons presentation ”Se världen genom slutanvändarnas ögon”
http://www.slideshare.net/JonasHerman/agiasverige2012-jonas-hermansson

.

Läs Kjell Lauren summering av Agila Sverige 2012 (inkl. listor över allt som diskuterades):
http://agileinc.wordpress.com/on-the-road-3/agilasverige-2012/

.

Ulrika Park summerar Agila Sverige 2012 på sin blogg:
http://ulrikapark.wordpress.com/2012/04/24/2-dagars-agil-coachning-av-150-proffs-for-2000-spann/

.

Peter Antman summera i en lång bullet-lista:
http://www.antman.se/archives/388

.

Se Agicals bilder från konferensen på Flickr:
Dag 1
http://www.flickr.com/photos/agical/sets/72157629887498279/

Dag 2
http://www.flickr.com/photos/agical/sets/72157629527311614/

.

Tommy Tynjäs presentation ”Automatisera dina integrationstester!”
https://docs.google.com/file/d/0B2-t5yfEvm90TW80SzVnUGxxcGc/edit

.

Ivar Grimstads presentation ”Arkitektrollen är nödvändig i (agila) prosjekter!”
http://www.agilejava.eu/2012/04/24/agila-sverige-2012-wrap-up/

.

.

h1

Övning: Agile Values

onsdag, 29 februari, 2012

Nu har jag lagt upp ytterligare material under ”Verktyg och Mallar”. Denna gång blir det en övning som jag själv kört flera gånger med fantastiskt resultat.

”Agile Values” är en diskussionsövning under vilken teamet eller projektet får en chans att fördjupa sin förståelse kring agiles och leans principer, men framförallt en möjlighet att diskutera dem!

Under övningens gång (som tar cirka 90-120 minuter att genomföra) får teamet (alternativt projektet eller avdelningen) en chans att diskutera agiles och leans principer och värderingar. Inte nog med det, grupperna får också en chans att diskutera hurvida man tror att principerna och värderingarna är sanna – dvs. är de viktiga att följa och värna om för att projektet ska nå maximal framgång?

.

.

Du hittar övningen genom att klicka här, eller på ”Verktyg och mallar” i högerspalten.

.

h1

Q: Hur estimera buggrättningar i Scrum?

torsdag, 2 februari, 2012

Titt som tätt får jag frågor från kollegor på Sogeti, kollegor ute hos kund eller från personer ute i vårt avlånga land som på ett eller annat sätt handlar om Scrum och Agile. Jag tänkte jag skulle börja dela med mig av dessa konversationer.

Jag vill också uppmuntra dig att maila mig om du just nu tampas med något problem eller frågeställning i just ditt projekt och önskar input och reflektioner från mitt håll. Jag ska göra mitt bästa för att svara på alla mail som kommer in och kommer att publicera valda frågor och dialoger här på bloggen (eventuellt i förkortad och redigerad form). För att maila mig, leta rätt på mail-ikonen i högerspalten.

Jag börjar på en gång och delar med mig av en fråga från en kollega jag fick i början av veckan 🙂

.


Q: Hur estimera buggrättningar i Scrum?

Hej!

Just nu försöker jag köra mitt första scrum-projekt. Det har då uppstått en del diskussioner i projektet ang estimering och rapportering av tid för bug-rättningar. (—)

Bör man lägga in en task för bug-rättning per User Story, eller bör man ta med tid för bug-rättning i estimatet för utveckling? Om man väljer det senare alternativet så blir ju utvecklingstask inte klara förrän test och rättning är klara.

Finns det någon tum-regel för hur mycket tid man bör estimera för bug-rättning?

Tacksam för goda råd!

Mvh
/###### 


Svar: 

Hej ######,

Angående estimeringar…

Det finns några olika approacher till detta…

  1. Anpassa Velocity – Anpassa velocity för varje sprint (dvs. antalet Story Points teamet committar till under sprint planeringen) så att det finns utrymme (luft) i sprinten att hantera buggrättningar parallellt med att man levererar funktioner och Story Points. Detta betyder att teamet under Sprint Planeringen bara committar till så många Story Points som man historiskt sett faktiskt klarar av att leverera under Sprinten.
  2. Skruva ner ”effektiv” arbetstid – Dra ner ”effektiv” arbetstid vid sprintplanering. Dvs. om man räknar med 6 effektiva timmar om dagen, räkna med fem istället. (Egentligen en version av 1:an.)
  3. Bugg-fix tasks till varje Story – Lägg till en task ”Buggfixning” med ett estimat (i timmar) för varje User Story. Ibland tar det längre tid, ibland blir det färre buggar rapporterade. Förhoppningsvis lär sig dock teamet justera storleken på dessa bugg-tasks allt bättre för varje sprint som går.
  4. Bugg-fix bucket Story – Lägg till en Story (Generell Buggfixning) till vilken man sätter en buffert med timmar att räkna av ifrån när man fixar buggar. När denna hink med timmar är slut lägger man bugg till produktbackloggen eller tar en diskussion med produktägaren om hurvida någon annan User Story ska senareläggas till förmån för buggfixning.

Vilken approach man väljer är egentligen upp till teamet. Välj den taktik som får arbetet och planering att flyta smidigast och som möjliggör snabbast hantering av buggfixning och som hjälper teamet leverera färdig, värdefull och testad mjukvara varje sprint.

Jag tycker inte att man ska betrakta en User Story som färdig förrän den är färdigkodad och färdigtestad i sprinten. Dvs svar ja: en User Story uppfyller inte DONE förrän den är kodad och testad.

Väntar man med testning och buggrättning till sprinten efter så har man naggat rejält i kanten på sin agilitet, introducerat risker och förlängt feedback-looparna samt försämrat insikten i vilken progress projektet faktiskt gör.

Angående rapportering…

Finns det externa krav på teamet (för att t.ex. kunna sortera isär arbetade timmar till olika budgetar) behöver man kanske rapportera och följa upp hur mycket tid som lagts på buggfixning och kanske till och med hur mycket buggfixning det blev för respektive User Story. Generellt finner jag dock inget värde i att logga arbetad tid på sådan detaljnivå då det oftast är svårt att omsätta denna typ av historik till användbar kunskap inför nästa planering. Men självklart, om det faktiskt hjälper teamet att göra bättre och träffsäkrare planering med sådan typ av historisk data – då ska man självklart göra det.

Att redovisa buggfixningstiden (för de User Stories man jobbar i pågående sprint) separat tycker jag är en väldigt dålig idé. Att utveckla betyder att man kodar, testar, fixar, tänker om, planerar nästa steg, kodar, testar, fixar, osv. tills det är klart. Det är så utveckling fungerar. Att fixa buggar på det man håller på med för stunden är en naturlig del av utveckling. Redovisas det separat riskerar man trilla i fällen att uppfinna sub-optimala lösningar för att parera detta. Alla sub-optimala lösningar saboterar alltid helheten.

Bugg-fixningstid som spenderas på features och funktioner som redan levererats tycker jag dock bör loggas separat. Denna tid är att betrakta som Waste då det faktiskt är olyckligt merarbete som beror på att man inte haft en tillräckligt bra teststrategi tidigare sprintar. Teamet ska dessutom hållas ansvariga för att ständigt förbättra sin testprocess och teststrategi så att kvalitén varje sprint blir högre och allt mindre tid behövs spenderas på att städa upp gamla misstag.

Mvh
/Jimmy

h1

SKIP Scrum Seminar (22:a Feb i Göteborg)

tisdag, 31 januari, 2012

Den 22:a februari bär det iväg ner till sveriges framsida. Anna-Lisa Gustavsson, en vän från Göteborg, har bjudit in mig att föreläsa om Scrum och om vad det betyder att jobba agilt under ett seminarie på IT-Universitetet i Göteborg. Det är studentorganisationen SKIP (Systemvetarklubben för informatik och programmering) som står för arrangemanget.

.


(Klicka för större bild)

.

Ska bli jätteroligt att ta en tur ner till Götet för att föreläsa för studenterna på Chalmers. Förhoppningsvis hinner jag också träffa några gamla vänner och kollegor därnere samtidigt.

Om du inte är student på Chalmers men är intresserad av att komma ändå vet jag inte riktigt hur du går tillväga. Kanske kan du hitta mera information på facebook-sidan för eventet eller på SKIPs hemsida.

.

Vi kanske se! 🙂

.

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?

.