Scrumtips - Tips om Scrum!

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.

Johan, som anlitat mig som konsult tidigare, mailade mig med några frågor. "Länge sedan sist. Jag har en fråga till dig på lite argumentation kring agil utveckling och främst scrum. Det rör egentligen hur man hanterar commitments på leverans i scrum. Typ: 'ni scrum-tomtar säger ju alltid att ni aldrig kan garantera vad ni kommer att leverera det funkar ju inte. Skulle du köpa ett arkitektbyggt hus till ett fast pris utan att veta vad du får?' (alternativt rörligt utan några som helst garantier). Ofta beställare som känner att man inte har något commitment från projektet på slutresultatet. Jag kan argumentera mot detta men det blir ofta ganska komplicerat och långt. Skulle vilja ha ett kortfattat svar." Jag svarade Johan att jag inte har något universalrecept, men väl lite tankar om hur man kan närma sig ett svar.  Korta svaret:  "vi kan inte förutsäga framtiden, men vi kan prioritera och utföra jobbet på ett sätt som maximerar sannolikheten att vi bygg

Robin, som gått kurs hos mig, hörde av sig och ville ha lite (jobbrelaterade) lästips till hängmattan. Jag utgick från att han hade en hängmatta med starka rep, och stor läslust, och svarade med denna lista. De böcker som varit till störst användning för mig har inte alls handlat om agila metoder per se, utan om alla de saker man behöver förstå och träna på för att lyckas med att jobba agilt. Becoming a Technical Leader av Jerry Weinberg, som handlar om den typ av stöttande ledarskap som behövs för att lyckas med den här typen av arbetssätt Leading Self-Directed Work Teams av Kimball Fisher. Handlar om hur man får igång team på riktigt. Project Retrospectives av Norm Kerth handlar om att leda retrospektiv, och föregår mycket av det Esther Derby skriver om i sin Agile Retrospectives-bok The Blind Men and the Elephant av David Schmaltz Zen and the Art of Motorcycle Maintenance, som jag blir sugen på att läsa igen bara jag skriver namnet på den. En kombination av road trip och f

Vad är en scrum-coach egentligen? Trots att jag sällan kallar mig scrum-coach har jag arbetat med att coacha andra i att använda Scrum sedan 2003, när jag först lärde mig om Scrum på allvar och började använda metoden i praktiken. Jag brukar inte kalla mig för scrum-coach, utan för konsult. Om någon som pratar engelska frågar vad jag gör säger jag att jag är en “software management consultant”, vilket låter rätt pretentiöst när man väver in titeln i en svensk mening. På engelska låter det - i mina öron - som en saklig beskrivning av vad jag gör: jag jobbar med chefer, ledare och team för att förbättra hur man styr och leder sin mjukvaruutveckling. Kärt barn har förstås många fler namn. Andra som gör det jag gör använder titlar som mentor, rådgivare eller agile coach. Eftersom jag arbetar som konsult i ordets ursprungliga bemärkelse (jag erbjuder en konsultativ tjänst) anpassar jag mitt engagemang hos kunden efter vad situationen kräver. Ibland gör vi en serie workshops, ibland finn

Vad betyder det egentligen att vara klar med något? Det är svårt att komma överens om det, eftersom vi har olika mål, perspektiv och behov. En begriplig och gemensam definition av vad det innebär att vara klar med en ny funktion kan göra utvecklingsarbetet både effektivare och mindre frustrerande för alla inblandade. Utvecklare tycker ibland att arbetet är klart när de funktioner som efterfrågats finns implementerade i kod. Testare brukar vilja fylla i med att funktionerna måste vara testade också. Folk i supporten brukar lägga till att buggarna man hittade under test gärna får vara lösta innan man levererar ut funktionen till användarna. Nyanställda utvecklare brukar gräma sig över att den kod som skrevs innan man själv började är så grötigt skriven att det nästan är omöjligt att sätta sig i den. Därför vill de lägga till att koden ska vara snyggt skriven och väl designad. Scrums definition på att vara klar med något är ganska krävande. De flesta organisationer får jobba länge på

Scrum är ett idealsubstitut. Det är en trevlig modell att sikta mot, men knappast en slutdestination. Grupper som ser på Scrum som slutdestinationen löper större risk, enligt min erfarenhet, att låta förändringen stanna av när man fått till grunderna i Scrum. Man kör sprintar, planerar och följer upp dem tillsammans, och bygger saker och ting som går att demonstrera. Då tar energin för förbättringsarbetet slut, trots att det finns massor av saker kvar att förbättra. Stanna inte efter den första etappen. Ni kanske behöver ta en paus och sänka förändringstempot lite, om ni är utmattade, men stanna inte helt. Då kommer ni kanske inte igång igen.