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

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…