När processen bryts ner och går sönder

När processen bryts ner och går sönder

Jag var med i ett litet scrumteam som tog fram en ganska stor webb under ett års tid. Vi lät Scrum Master-ansvaret gå runt mellan oss för att jämnt fördela den byråkratiska bördan, men också för att sprida erfarenheten. Processen följdes bokstavstroende, men förfinades för varje sprint för att passa vår situation, precis som sig bör.

Kanban och Scrum enligt Wikipedia

Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development.

Projektet tog slut och gick in i en förvaltningsfas. Verksamheter är ständigt i rörelse och webben måste följa med. Ändrade krav leder till nyutveckling, rättning av buggar och optimering av beställningsflöden. Plötsligt kom det nya direktiv från verksamheten.

Scrum är alldeles för långsamt för vår verksamhet. När vi har en bugg i systemet kan vi inte vänta tre veckor på att få den fixad. När våra leverantörer ändrar sina API:er kan vi inte stå still i tre veckor tills vi har en implementation.

Oron för boxen som begränsar i Scrum var stor. Boxen som bestämmer hur mycket tid vi har och begränsar funktionaliteten som vi levererar inom en sprint. Oron var att behöva vänta på funktionalitet och på ändringar i flera veckor.

För att komma runt detta problem valde man att ersätta Scrum med Kanban.

Unboxing Scrum

Vi byggde ut den befintliga scrumboarden som vi hade till en kanban board som skulle representera samtliga tillstånd för en beställning. Resultatet blev ungefär såhär.

Vår tidigare scrum board representerade arbete som teamet skulle utföra under pågående sprint. När verksamheten fick chansen att bygga sin egen Kanban-board representerade den alla tillstånd som en beställning kunde befinna sig i, från idéstadie till att ha varit produktionssatt månader tillbaka.

Det viktigaste för verksamheten var att ha en gräddfil längst ner där akuta ärenden skulle gå förbi all annan utveckling för att snabbt komma ut i produktion. Vi kallade dessa för hotfixar, och byggde på Stop the Line från Lean.

Free for All

Scrum erbjuder en tydlig inramning av en tidsbox med sprintplanering, sprintreview och demo. Man följer dagligen upp status genom en burndown chart och ser ifall teamet ligger bra till eller om något behöver göras för att leverera sprinten i tid.

Produktägarens bild av Kanban var att varje enskild task skulle åtas när den var godkänd och levererad till produktionsmiljön när den var klar.

Scrum Master-rollen avvecklades och kvar hade vi ett självorganiserande team med utvecklare som fick beställningar godkända av verksamheten genom ett produktägarforum bestående av en grupp intressenter.

Beställningarna estimerades med story points men skulle aldrig brytas ner i timmar, eftersom en beställning utvecklas tills den är färdig, och teamet inte ville binda sig till att vara klar efter ett estimerat antal timmar.

Vi använde denna modell i 1,5 år då vi rev upp allting och återimplementerade Scrum efter manualen. Anledningen var att verksamheten stoppade in beställningar, men ingenting kom ut i produktion, eller kom ut ett år för sent. Vi har sedan dess gått från att leverera till produktion var sjätte månad, till var tredje vecka.

Definition of done

Hur kan friare tyglar missgynna effektiviteten hos utvecklarna? Sitter vi med lata, dåliga eller omotiverade utvecklare som inte bryr sig om produkten? Nej, tvärt om. Teamet drabbades av prestationsångest.

När verksamheten bad om ett HTML-mail byggde teamet en e-postmotor. När det visade sig att verksamheten vill personalisera varje e-post, då refaktorerade teamet om hela motorn för att skapa dynamiska mallar. När verksamheten ville följa upp e-postutskick i statistiken då byggdes hela motorn om så att alla e-post kunde lagras i databasen. En liten beställning kunde växa till flera månaders arbete; ju mer beställaren såg ju mer ville beställaren ha.

Ju mer beställaren såg desto mer ville beställaren ha.

Teamet kunde aldrig avgöra när en beställning var färdig för att specifikationen inte var komplett när utvecklingen skulle påbörjas. Eftersom teamet var så angeläget om att allting skulle bli perfekt byggdes funktionaliteten med alla tänkbara kvalitetsverktyg från parprogrammering, enhetstestning till kodgranskningar – vilket visar sig bli väldigt dyrt när kraven ändras under pågående utveckling.

Vi hade ingen deadline när beställningen skulle levereras, så teamet såg ingen anledning att säga nej till ändrade krav. I slutet av Kanban-perioden införde verksamheten ett önskat leveransdatum till processen, vilket aldrig blev mer än ett fiktivt datum som ingen i teamet committade sig till.

När det tog längre och längre tid för teamet att leverera stoppade verksamheten mer beställningar i gräddfilen och teamet fick stoppa all utveckling för att hantera de prioriterade beställningarna. Om man har arbetat med releasehantering vet man hur svårt det är att dra utvecklingspuckar förbi pågående utveckling. Det ökar komplexiteten och orsakar att den ordinära utvecklingen tar ännu längre tid.

Think inside the box

Kanban ersätter inte Scrum som process.

Att Scrum skulle vara för långsamt för verksamheten är en illusion. Visst finns det stunder då produktionsmiljön står still och varje minut är dyrbar, men dessa stunder är så sällsynta att de inte behöver vara en del av arbetsflödet utan kan hanteras när situationen uppstår.

Kanban är ett utmärkt verktyg för att visualisera arbetsflöde men det ersätter inte Scrum som process. Tar man bort iterationer utan att på något sätt mäta ledtiderna för varje beställning, då förlorar man incitamentet att snabbt få upp en lösning i produktion, där beställningen först börjar generera värde.

Självorganiserande team tar bort mycket av den överväldigande byråkrati och möteshysteri som kan uppstå med en despotisk projektledare, men det är också viktigt att inte förlora det kollektiva ansvaret att leverera när ansvaret slussas ut på teamet och inte den enskilde personen.

Ha en plan, sätt upp krav och kom ihåg att kod under utveckling levererar inget värde.

Bild av Michael O'Connor under CC BY-SA 2.0

comments powered by Disqus