Fortsätt till huvudinnehåll

Läsning till hängmattan

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 filosofisk avhandling. Handlar om vad vi egentligen menar med kvalitet.
  • Idealized Design av Russell Ackoff. Kompletterar agila metoder med metodik för att etablera en vision att iterera mot. Det är inte tillräckligt att bara vara flexibel och lättrörlig, vi måste veta vad vi rör oss mot också.
  • Scaling Lean and Agile av Bas Vodde och Craig Larman. Handlar om teori och praktik kring användning av agila metoder i större organisationer.
  • The Five Dysfunctions of a Team av Patrick Lencioni. Ett ramverk för att förstå och utveckla team.
  • The Power of Learning av Klas Mellander. Handlar om hur vi lär oss, och varför så mycket av traditionell undervisning misslyckas med att sprida förståelse. Relevant när man börjar prata om att köra utbildningar på stor skala för många medarbetare.
  • Slack, av Tom deMarco. Brilliant skrivet om vikten av att ha spelrum på jobbet, problemen med övertid, svårigheterna att planera och mycket mer.
  • Are Your Lights On av Jerry Weinberg. Om hur vi ser på problem och hur vi löser dem.
  • The Psychology of Computer Programming. Jerry var tidigt ute med att kombinera teknik och psykologi för att få en bättre helhetsbild av vad som får utvecklingsarbete att lyckas eller misslyckas.
  • The Fifth Discipline av Peter Senge. Storsäljare från 90-talet om systemtänkande och systemdynamik, om hur vi själva orsakar många av de problem vi drabbas av, och vad vi kan göra åt det.

Kommentarer

Skicka en kommentar

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...
6 kommentarer
Läs mer

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...
Skicka en kommentar
Läs mer

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...
7 kommentarer
Läs mer