Fortsätt till huvudinnehåll

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 inte ändringar utan att först ha reflekterat över om vi verkligen förstår konsekvenserna av de ändringar vi gör.

Ett exempel förtydligar.

Mats är Scrum Master för ett Scrumteam. Teamet är ganska litet, bara fem personer. Två personer som mest programmerar, men även hjälper till med test, två personer som mest testar, dels explorativt, dels med automatiserade testverktyg, och en domänexpert.

Sedan man började med dagliga statusmöten tycker Mats att han fått en mycket bättre insyn i projektet, men hans kollegor är inte lika nöjda. Alla teammedlemmarna är överens om att det skulle räcka med morgonmöten måndagar, onsdagar och fredagar. Mats har presenterat de argument han tycker talar för ett dagligt möte (det blir kortare, information sprids snabbare med mera), men han lyckas inte övertyga teamet. Mats sätter sig med teamet en halvtimme för att bestämma hur de ska göra.

Mats börjar med att gå igenom syftet med morgonmötet igen. Det visar sig att alla är överens om att man vill ha daglig koll på läget i projektet. Alla är också överens om att man ska uppdatera planeringsväggen varje dag, så att alla har en bra bild av vad som händer.

Teamet presenterar sina argument mot ett dagligt möte. Det här är inte första gången man jobbar tillsammans. Samtliga är seniora utvecklare, och gruppen har en effektiv dynamik. Man sitter tillsammans i ett stort rum, med egna avgränsade platser så att man får avskiljdhet, men så nära att man lätt kan byta information med varandra och fånga upp vad som händer. Teamet menar att man sedan länge har lärt sig att kommunicera frekvent om mål, uppgifter och hinder, och deras track record visar att det inte bara är prat.

Tillsammans bestämmer Mats och teamet sig för att vara progmatiska. Man har förstått värdet i ständig insyn i projektets status och kontinuerligt utbyte av information i teamet. Man tycker att ett dagligt möte utöver den fungerande och mogna kommunikation man redan har känns märkligt, som något man skulle göra "bara för att metoden säger det", och den känslan är man överens om är demotiverande. Man köper helt enkelt inte att en paketerad arbetsmetod skulle veta bättre än deras samlade erfarna omdöme.

Teamet och Mats beslutar att pröva att ha scrum-möten tre gånger per vecka under några sprintar framöver. Mats gör en notis i sin Scrum Master-dagbok. Först skriver han ned datumet, sen skriver han ned vilket beslut de tagit, varför, och vilket resultat de förväntar sig av det. Sist skriver han ned när han ska följa upp om det blev som de tänkte sig. Sen känner han sig helt nöjd med utkomsten. En av tankarna med Scrum var ju trots allt självorganiserande team, tänker han, medan han tillsammans med sina kollegor städar undan kaffekopparna från det gemensamma arbetsbordet i teamrummet.

Kommentarer

Jag håller med. Det finns ingen anledning att använda vanor som inte gör någon nytta. Jag brukar dock påpeka att det kan vara bra att vänta med att såga i "kärndelarna" av scrum eller XP innan man provat dem en tid. Det är lätt att annars missa viktiga effekter som kan vara svåra att förutse. Ett intressant biämne är att du nu ser retrospektivet som en självklar del av scrum. Har för mig att första boken om scrum inte direkt lägger tonvikten vid retrospektivet, men många (däribland jag själv) anser nu att det kanske är den enda delen av scrum som man absolut inte får tumma på. Vad är scrum idag? Hmm, kanske det blir en ny blogpost en vacker dag? Tack för en välskriven blog iaf!
Tobias Fors sa…
Måns: intressant kommentar om retrospektivets roll i Scrum. Har inte tänkt på att det kanske inte trycks så mycket på detta moment i Kens första Scrumbok, men så kanske det är. En risk med för mycket betoning på retrospektivet kanske kan vara att det sänder ut signalen att förbättringar _bara_ sker under retrospektiven, och det är ju inte så bra.

Apropå vad Scrum är idag: bra fråga. Jag tror att Scrum är ganska många olika saker idag. För mig har det landat som en grundstomme för att tänka kring iterativ utveckling, ett ramverk som kan fyllas i, och även justeras, efter behov och kontext. Jag brukar kalla Scrum för en provokationsmetod: ramverket är så enkelt att det provocerar fram en massa frågor om hur saker ska göras, så att man får ett tryck att besvara de frågorna - och själv börjar jag hellre där än med en metodlunta som folk antingen somnar av eller blir rädda för att ändra i.

Tack för kommentaren!
En anledning till motstånd till morgonmöten, enligt min erfarenhet, kan vara att arbetet i projektet bedrivs väldigt specialiserat. Jag gör bara sånt som har med utskrifter att göra; du sysslar bara med webbformulär; och ingen av oss rör någonsin nånting som har med databasen att göra, för det är Staffans baby. Vi har liksom väldigt få naturliga beröringspunkter.

Stor fråga kanske, men hur tar man sig ur/bryter en sån situation?
Tobias Fors sa…
Magnus, tack för att du tittar in! Se svar i separat post.
Jag tänker på "Shu-Ha-Ri"-nivåerna som det talats om i samband med systemutveckling. Teamet i ditt exempel verkar ha nått "Ha" eller kanske tom "Ri" och kan därför utan risk bryta reglerna.
Tobias Fors sa…
Hej Anders! Shu-ha-ri är definitivt en intressant metafor här. Jag har tränat aikido i ett antal år (har tyvärr slutat sen länge), och har hört att det inte varit ovanligt inom den japanska budon att nya elever fått träna många år med bara de absolut mest rudimentära teknikerna, innan man ansetts mogen att gå vidare med mer djupare applicering. Min träning i Uppsala var dock mer "progmatisk", man behövde inte nöta enbart grundstegen i tre år innan man fick pröva mer avancerade tekniker.

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…