Scrum i teorin

Jag har nyligen, tillsammans med en kollega, varit på en certifieringskurs för att bli Scrummaster.

Kursen hölls av James O. Coplien eller bara Cope. Han är en riktig teknolog med skepparkrans och ett mysigt ljudande "mkey" och ett stenhårt "why?". Ett energiknippe som med en religiös underton sprider Scrum och andra Agila tekniker. Han lär ut renodlad Scrum så som han vill ha den, han har inte läst Scrum definitionen på många år. Stark motståndare till all form av unit-testning då det i hans mening inte ger någon return on investment. Inspirerar genom många exempel och lekar.

Mest kontroversiellt var uttalandet om att XP aldrig har fungerat och aldrig kommer att fungera. Han anser att unit-test inte fungerar då vi inte tjänar på det, egentligen allt före integrationstest är att stjäla från produktägaren. Han ställer krav på automatiserade tester. Tester ska utföras på användargränssnittet, ty det är applikationen, allt annat är bara nödvändigt kladd som tillsammans skapar användargränssnittet. Det tål att diskuteras kan jag tycka...

Kursen var mycket givande på många sätt. Alla lekar och exempel tydliggör varför Scrum fungerar som det gör. Det ger en också lite mer på fötterna när man själv ska argumentera. Jag har jobbat i "scrumish" projekt en längre tid nu och känner att man har rättat in sig i arbetssättet, fastän det inte är Scrum fullt ut. Det blir lätt att glömma och det var verkligen bra att bli påmind om det "rena" Scrum så som det är tänkt att vara men så sällan blir.

* Scrum Mastern ska inte vara del av teamet

* Product bag items och felrapporter bör eller ska existera i samma list. Ett fel är en funktion som inte fungerar och ska prioriteras precis som vilken annan funktion som helst.

-- Fredrik Bäckström