Rätt arbetsmängd är avgörande

Några saker sticker ut från när jag lärde mig Scrum från Ken Schwaber i slutet av 2003. En av dem är insikten om hur avgörande rätt arbetsmängd är. Ken beskrev Scrum som fokuserat på "workload management", till skillnad från ett mer tradtionellt fokus på "work management". Scrum Masterns jobb är att hjälpa teamet att ta sig an rätt mängd arbete i sprinten, inte att styra det arbete teamet tar på sig.

Några av fördelarna med att ett team tar på sig rätt mängd arbete:

• De kan göra ett starkt åtagande. Ett starkt åtagande betyder att teamet tror på och äger sin egen plan. Man har tagit på sig en utmanande mängd arbete, men inte för mycket. Man kan med gott självförtroende säga att man kommer att leverera det man tagit på sig.
• Man kan leverera med kvalitet. Ett team som har för mycket att göra måste hitta någon sorts ventil att ventilera genom. Den allra vanligaste ventilen är produktens kvalitet. Man sänker helt enkelt kvalitetsambitionerna. Det funkar på kort sikt, men är fullständigt förödande på lång sikt. Ett team som har tagit på sig rätt mängd arbete för en tid, i Scrum en sprint, har tagit på sig den mängd arbete man kan göra med upprätthållande av hög kvalitet. Det betyder att man inte behöver ta genvägar för att nå målet. Vi vet ju alla att ordspråket är sant: genvägar äro senvägar. Mjukvaruutveckling är inget undantag.
• Moralen förblir hög. I vilket team tror du arbetsmoralen är högst? I teamet som har pressats att ta på sig för mycket arbete, kanske med motivationen att "stretch goals" är bra för dem, eller i teamet som under tankfull dialog inbördes och med produktägaren vridit och vänt på arbetet som behöver göras för att hitta rätt mängd för den kommande sprinten? Min satsning blir på teamet som lagt sin egen ribba.
• Misslyckande betyder något. Tänk dig ett team som av någon anledning övertygas om att ta på sig mer arbete än de själva tror att de kommer att klara av. Tänk dig sedan att de träffas i en sprintåterblick för att prata om varför de inte lyckats leverera enligt plan. Vad tror du att de kommer att säga? Självklart kommer man att peka ut den press man utsatts för som orsaken till att man inte levererat enligt plan. Tänk dig nu ett team som själva väljer ut hur mycket arbete man kommer att klara av den närmaste månaden. Tänk dig nu att även detta team misslyckas, och därför i sin sprintåterblick diskuterar detta. Det kommer att vara lättare för detta team att vända tillbaks samtalet till den egna rollen i misslyckandet. Därför kommer de att kunna lära sig från sitt misslyckande.
• Den goda hälsan består. Jag arbetade med ett team på Arbetsmiljöverket vid ett tillfälle. En morgon när jag väntade i receptionen på att insläppt bläddrade jag i en publikation från myndigheten. En siffra stack ut i statistiken som presenterades: att det var så många som led av problem orsakade av att man inte hade kontroll över sin egen arbetssituation. Det är ju inte så konstigt egentligen - självklart är det stressande att förväntas kunna åstadkomma mer än vad som är realistiskt. Det gäller oavsett om man utvecklar mjukvara eller inte. Varför tror vi att det är en bra affär för våra företag att försöka pressa ut mer än vad som är möjligt ur varandra?

Så för att summera: Scrum handlar om att lära sig vad man kan åstadkomma genom att själv få möjligheten att pröva sina vingar. Det lärandet kan inte komma till stånd om situationen komprometteras av ett aldrig så välment tryck att göra mer än vad görararen tycker är möjligt. Du kan välja själv: antingen får du lite, lite, mer just nu, till priset av osäkra åtaganden, dålig kvalitet, låg moral, försvarsmekanismer som förhindrar lärande och dålig hälsa - eller så får du mycket mer på långt sikt, plus leveranssäkerhet, hög kvalitet, hög moral, ständigt lärande och hälsa.