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.