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? ;)
Mr Brown 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

Vad sprintplanering och glassinköp har gemensamt

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare.

Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan.

En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade a…

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fu…

Både Scrum Master och teammedlem?

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet?

Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli?

För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen.
En anledning till uppdelningen är att redan i förväg bygga en beredskap för framtida…