Fortsätt till huvudinnehåll

Ifrågasätt Scrum

Ingen lösning är så bra att den inte orsakar problem för någon. Här kommer dagens hjärngymnastik.

  1. Välj ut en regel från Scrum som du gillar. Kanske väljer du vanan att ha dagliga morgonmöten, kanske något helt annat. Välj den regel du tycker känns mest självklar och mer eller mindre okränkbar.
  2. Skriv ned minst tre, och helst fler, exempel på problem den regel du valt kan orsaka för någon i din organisation.
  3. Om du inte kan hitta minst tre exempel har du inte tänkt tillräckligt länge än, så gå tillbaks till steg två. Annars, reflektera över om regeln fortfarande känns självklar.
  4. Posta gärna dina reflektioner som en kommentar här nedan!

Kommentarer

Kul utmaning. För att göra det svårt för mig själv valde jag givetvis min favoritvana, återblicksmötet (retrospektivet).

* Konsulter ska inte behöva förbättra sig, de kostar redan 1000:- per timme.

* Det medför bara merarbete som är svårt att prioritera in i nästa iteration.

* De som leder retrospektiv är typiskt tekniker som inte har någon utbildning för den här typen av möten.

* Jag som arbetsgivare vill bestämma vad de resurser jag betalar ska bli bättre på, annars blir det bara fokus på det som är roligt.

* Vi är redan tillräckligt duktiga nu gäller det bara att kavla upp ärmarna.

Övertygad än? ;)
Anonym sa…
Att teamet själva sätter tider på det som ska göras. En del av scrum som jag anser väldigt viktig, men som man inte alltid är så bra på...


* Det kanske visar att det tar teamet för lång tid att göra ett bra jobb.

PO:

* Så lång tid kan det väl inte ta?!

* Vi måste ju leverera det redan den här sprinten, och det gäller ju alla de andra lapparna också. Då måste ni jobba fortare!

* Kan ni inte göra en fullösning istället? det går ju på fem minuter.

* Va? Ingick inte automatiserad testning?

* Jag sätter ner tiden på den här så att jag får in den i sprinten också, så får ni göra så mycket ni hinner. Men det måste bli färdigt...

* Det finns ju övertid också!

* Jag kan inte begripa varför det är så många buggar?!
Ok, jag väljer korta iterationer med delleveranser och kan komma upp med följande problem som folk i organistationen skulle kunna eller har hittat:

* Som beställare vill jag ha allt jag betalat för, att få en liten del är inte intressant

* Det är omöjligt att hinna både speca, designa, implementera och testa på bara 4 veckor

* För att kunna bygga något körbart måste vi ha alla delar på plats, och det hinner vi inte på en iteration.

* Att bygga en del av systemet innan vi har arkitekturen klar blir inte bra eftersom delarna kanske inte passar ihop eller vi missar något viktigt

* Vi måste kunna ge ett fastpris på hela systemet/alla funktionerna innan vi börjar bygga det/dem, och en detaljerad projektplan där innehållet i alla iterationer finns med, och det kan vi inte om vi inte hittar alla aktiviteter från början.

Populära inlägg i den här bloggen

Pragmatisk eller dogmatisk? Progmatisk!

Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart. Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför. Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor? Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning . Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör vi

Introduktion till story points

Estimering med storlekspoäng är en sån där sak som somliga älskar och andra tycker är totalt förvirrande. Jag gillar det lugna sköna tempot i den här korta snutten om story points från Rally Software.

Hur lång ska en sprint vara?

Jag fick en fråga på mailen som löd: "Fick frågan av min chef varför vi har 3 veckors sprintlängd. Vet inte riktigt vad jag ska svara, det bara blev så. Vad säger du?" En sprint i scrum är en synonym för iteration. Det som utmärker scrums sprintar är att vi vill att de ska vara väldigt fokuserade och att de ska sluta i klar, potentiellt levererbar, produkt. Potentiellt levererbar betyder att om vi ville  så kunde vi skeppa ut produkten med ganska lite efterarbete. Tydlig och regelbunden feedback krävs för att styra utvecklingsarbete. Längre sprintar betyder att det blir längre tid mellan större avstämningar av nuläget, vilket ökar risken att vi drar iväg i fel riktning, eller att omvärlden ändrar sig så mycket under sprinten att det vi bygger hinner bli irrelevant. Ibland kan det kännas som om man lägger för mycket tid på planerings- och uppföljningsworkshops, vilket leder till idén att göra sprintarna längre. Jag vill hellre börja med att undersöka om arbetsmötena k