Photo by F Delventhal / CC BY 2.0

Prodfrysen – ännu inte ute i kylan?

Många kunskapsintensiva verksamheter stänger ner i långa perioder flera gånger per år.

Nej, jag tänker inte på den gamla hederliga industriferien som åtminstone tidigare präglade julimånaden.

Inte heller skolan, med sina sommar- och andra lov, är i fokus för denna blogg.

Nej – jag tänker på alla de IT-utvecklingsorganisationer som fortfarande, i nådens år 2018, frivilligt väljer att stänga ner all utrullning av ny funktionalitet i produktion i långa perioder kring jul, andra högtider och stora delar av sommaren.

Bakgrund

Den historiska bakgrunden till anakronismen, populärt kallad frysperiod eller endringsrestriktiv periode, är en ovilja att göra ändringrar som kan ha regressioner eller utlösa fel under perioder då det kan vara lite folk på jobb. Detta baserar sig på tanken att ändringar är riskabla och onaturliga, att ändringar i produktion bör hanteras av specialister, att man har god överblick över totalitetens tillstånd i produktion och om man bara “fryser ner” detta under perioden då man har brist på kritisk specialkompetens så kan problem undgås.

Detta blir rätt problematiskt tankegods när konstant ändring blivit den nya normalen och autonoma kryssfunktionella utvecklingsteam har fått kapabiliteten att självständigt produktionssätta, få feedback på och – om det skulle bli nødvendigt – rulla tillbaka nya features.

Utvecklingsarbetet har övergått från ett vattenfallsbaserad tillnärmning där orelaterade ändringar bulkades upp till stora releaser som överlämnades till specialister för produktionsättning till en kontinuerlig pipeline där den naturliga visionen är att varje feature, med så kort tidsfördröjning som möjligt, rullas hela vägen ut i produktion av teamet själv (så kallat one-piece-flow). Det är bara i produktion man kan få avkastning och feedback på features.

Problemet

Utrullningsfrys stør pipeline’n i alla faser:

  • Före frysen är frestelsen stor att stressa igenom halvbakade features för att undgå lång väntetid på att få feedback från produktion.
  • Under frysen är det stopp i slutet av pipelinen och teamet, om det nu är på jobb, lägger istället ändringar (som inte kan få feedback på) på is.
  • Så fort frysen är över produktionsätts bulken man ackumulerat, gärna som en större-än-normal utrullning, med de konsekvenser det kan ha.

Frys är inte bara ödeläggande för time-to-market utan kan faktiskt även ha en negativ kvalitativ nettoeffekt.

Menar jag att man bör eftersträva att trycka igenom stora features sista dagen innan hela teamet tar julferie? Eller göra API-ändringar i komponenter som flera andra applikationsteam är avhängiga av i påsken?

Självklart inte! Det jag menar är att om det finns team på jobb som lagar features så ska det naturligtvis också vara möjligt att produktionsätta dessa om och när teamet finner det lämpligt – även om andra delar av organisationen nu händelsevis samtidigt skulle råka vara tunnare bemannad än normalt.

Det är hög tid att ställa utrullningsfrysen där den hör hemma – ute i kylan i gott sällskap med lagspelaren vattenfallsmetoden!