Dagens inlägg handlar om releaseplanering av programvara. Om den något märkliga sanning som många företag upptäcker när de använder sig av agila metoder.
I en värld där förändring ska bejakas så ska sprintlängd och tiderna mellan företagets olika releaser vara fix. En agil releaseplanering borde rimligen vara lika anpassningsbar som allt annat.
Låt oss ta ett exempel genom att studera Automattic, företaget som utvecklar och har huvudansvaret för bloggplattformen WordPress.
WordPress är den mjukvara som gör att du fått hem den här sidan i din webbläsare.
Det är det verktyg jag använt för att skriva det här textmaterialet och det är där jag lägger upp bilderna som ska visas till.
Det är WordPress som ger bloggen sitt utseende och som hanterar kommentarerna, serverar annonsbilderna och som skickar ut mail och rss-feeds till de som följer det som görs här.
Och det gör man för en mycket mycket stor andel av världens alla bloggar.
Worldpress är en open source-lösning i en Internetvärld i snabb förändring och även om man är absolut världsledande så saknar man inte utmaningar eller utmanare.
Det kanske största problemet är att det är en gigantisk mjukvarulösning som är tillskrivs som varande: ”Jack of all trades, master of none”.
Här har vi alltså en mjukvarulösning som måste ”hänga med” i den allmänna teknikutvecklingen, vilken går med rasande fart, samtidigt som man behöver ”spetsa till” sin funktionalitet på en rad områden för att inte bli omkullsprungen av mer nischade konkurrenter.
Samtidigt måste man stödja den stora mängden driftsatta siter med säkerhetsuppdateringar och buggfixar.
Det här har WordPress försökt möta genom att införa två huvudreleaser om året vilket får anses vara ett ganska vedertaget sätt att arbeta.
Däremellan släpps bara mindre uppdateringar.
Fungerar det bra då?
Svaret är nog ja, nej och absolut inte! Det är ett av skälen till att man, åtminstone tillfälligt, släppt den modellen och senast använt en releasemodell som mer handlar om att viktig funktion ska med, till rätt kvalité, och att tiden är underordnad det.
I praktiken innebär det att man haft drygt ett år mellan de två senaste releaserna. 4.9 släpptes i november 2017 medan 5.0 officiellt fanns tillgänglig 6 december 2018.
Man har använt sig av en agil releaseplanering och frågan är om inte detta kommer fortsätta.
Exemplet ovan visar på ett vanligt problem som fler företag har noterat när det blir för styrda av ett schema. Sprintar som är två-tre veckor.
Releaser som sträcker sig över ett halvår, vilket ofta ger betydligt kortare implementationsfönster för funktioner, ger sammantaget en ”snuttifierad” värld där större funktionslyft är svåra att göra.
Man måste ha en mer agil releaseplanering.
För Worldpress fungerade ansatsen bra några år. Då kunde man prioritera och fylla sina releaser med jobb som passade in. Men sedan blev det svårare.
Det man gjort nu är att man förändrat hela gränssnittet och användarupplevelsen för mig som gör inläggen.
Det jobbet bygger på tidigare arbete och gränssnitt man implementerat sedan länge, men den faktiska slutanvändarupplevelsen man ville realisera hade inte en chans att rymmas inom en sexmånadersrelease trots det.
Det här är en intressant och ganska allmän insikt i sammanhang där man utvecklar, förbättrar eller förändrar något. Om det så är en mjukvara, sitt liv eller en organisation.
Efter en förändring kommer en period där stegvisa förbättringar och förändringar passar bra.
Men relativt snart når man ett lokalt optimum i någon mening.
Då krävs större steg för att komma vidare. Därför har agil releaseplanering en plats.
