Scrum för förvaltning är en dålig idé

De agila arbetssätten sprids och vinner kontinuerligt mark ute i IT-organisationer. Scrum är en av de metoder som det pratats mest om och som det kommer fortsätta pratas om. Detta är glädjande då mina erfarenheter av Scrum är väldigt positiva. En av de viktigaste delarna i Scrum är att idéen om att varje arbetssituation är unik och att Scrum måste anpassas för att fungera på ett bra sätt. Vissa principer inom Scrum har dock blivit upphöjda till att användas kompromisslöst, detta för att hantera de situationer Scrum-metodiken anser vara ett problem vid mjukvaruutveckling. Ett exempel på det är att teamet alltid ska estimera vad de hinner med utan att påverkas utifrån av eventuella intressenter och aktivt verka för att bli bättre på att estimera hur mycket arbete teamet klarar av att genomföra under en sprint.

Detta är ett sätt som jag tycker är bra att arbeta på om det finns förutsättningar att kunna ge ett realistiskt estimat. En situation i vilken detta estimat inte är möjligt att ge är när teamet har ansvar för att förvalta ett system som är satt i produktion. En förvaltnings syfte är primärt att hantera de problem som kan uppstå i produktion. Problem som uppstår i produktion är av en natur som inte har många likheter med ett vanligt ärende eller uppgift i en sprint. Problemen måste ofta lösas direkt, oftast oberoende av vilken tid det tar eller vilka andra planerade uppgifter som åsidosätts. Detta går tvärtemot Scrum-tänket där teamet ska få arbeta ostört under en sprint enligt sin egen planering.

Att använda sig av Scrum i en sådan situation gör att teamet i princip aldrig kommer att lyckas med den planering som de gör. Det i sin tur gör det mindre roligt att arbeta och teamet kommer inte kunna leverera vad de lovat. Det finns även andra argument emot. Om teamet inte känner att de någonsin klarar av vad de planerar så kan det också komma tillfällen då det blir lätt att ta genvägar för att uppnå målet.

En lösning på detta är att fokusera mer på flödet av ärenden som i Kanban. Mer om detta i ett senare inlägg.

Om författaren
Martin Johansson är testledare och certifierad ScrumMaster och fokuserar på test och testautomatisering i agila utvecklingsteam.