Slipsteknik

Vad är grejen med att slipsarna på Hennes och Mauritz alla kostar 198 kronor per styck? De flesta av dem är sjukt fula, så de borde kosta maximalt 59 kronor (60 hade varit för mycket). Jag hade tänkt köpa en ironisk födelsedagspresent till min slipsiga chef (som jag inte har sett bära slipa på ett och ett halvt år) idag, men det var dagen innan löning (vem vill egentligen fylla år den 24-e, alla presenter lär vara cheap-ass, and that's your fucking destiny, yo).

Så varför inte tala om en annan typ av slipsighet istället: projektramverket (det där tar knappt ens jag på allvar) Scrum. Scrum-evangelister gillar att berätta historier om vattenfallsstyrda projekt som inte får det allra minsta gjort, eftersom allt de gör är att rita Gantt-charts och fylla i Excel-ark, tas över av en Scrum-expert, och gör mirakulösa framsteg inom två veckor. Det stämmer säkert. Vår situation är inte riktigt sådan.

Vår situation är att vi utvecklar en produkt, som ovanifrån är styrd av en klassiskt byråkratisk projektplan, där vi samtidigt måste underhålla tidigare releaser. Vi jobbar inte bara fram mot 3.4, utan släpper även saker som heter 3.3.3 och 3.2.18. Dessa releaser är inte synkade till våra sprints, utan kanske släpps på första eller andra onsdagen under ett av våra tvåveckorssprints. Vi är ibland radiostyrda av våra kunder, som kräver en ny 3.2.x-release, med tre specifika buggar fixade, innan ett visst datum. Vi har svårt att få ihop det, och har svårt att se hur Scrum kan hjälpa oss med detta.

Men det är egentligen inte svårt. Problemet är inte att Scrum är helt inriktat på nyutveckling, utan att vi är för inkörda på att använda vårt issuehanteringssystem (svengelskan håller på att ta över min blogg totalt, men det här handlar om IT, så det är lugnt), där vi för varje uppgift sätter en planerad release. Vi kan alltså inte lägga in en buggfix för 3.2-spåret i ett sprint, för då kommer det se ut som att fixen även kommer in på sprint-releasen. Vi är inte bara radiostyrda av våra kunder, utan även av de verktyg vi har valt att använda.

Det här kommer förändras så småningom. Vi kommer gå ifrån issuehanteringssystemet som planeringsverktyg, vi kommer bygga en bättre process. Och hittills har det funkat, om än inte så smidigt, för det har känts som om något har fattats. Men man måste höja sitt huvud över marknadens sorl för att se vad problemet är. När verktygen man använder begränsar en, så måste man blanda metaforer och släppa sargen (där sargen är en typ av verktyg för hockeyspelare, för att knyta ihop metaforerna). Nu tar jag ett kraftfullt tag om stavarna (från vintersport till vintersport: hockey till längdskidåkning) och skidar vidare mot en bättre Scrum-process. Wish me luck, yo!