KategoriFallstudier

WordPress senaste release – Agil releaseplanering

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.

Fallstudie 3: Att smida medan järnet är varmt!

Det här är del två av en tidigare fallstudie som lite kort kan sammanfattas så här!

Vecka ut och vecka in skulle jag lösa ett problem som uppstått i ett sammanhang som jag inte var delaktig i. Som diskuterades där jag inte närvarade. Som löstes av personer långt från mig som jag inte ens visste namnet på.  Ofta var problemet redan avhandlat vid testtillfället då felet visade sig, eller timmarna efter. Vanligtvis fanns det ingen konflikt kopplat till rättningen – och fanns det det i form av exempelvis prioriteringar så fördes de diskussionerna direkt med huvudprojektledaren – och inget ”problem” fanns att lösa för mig på projektledarnivå.

Hur kunde ett fel i samband med ett systemtest leda till att så många människor, som inte hade något att bidra med, blev så djupt inblandade?

Fortsätt läsa

Fallstudie 3: Att leva här och nu i projekt

För ett par år sedan ansvarade jag för ett team – vi kan säga att jag var teamledare – om cirka 10 – 15 personer där en liten del, i princip en person, arbetade med mjukvara. Resten av gruppen arbetade med andra typer av teknikfrågor långt från mjukvaran. Jag la viss del av min tid på projektet men mycket av mitt fokus var på de underleverantörer vi hade och de arbete teamet gjorde tillsammans med dem. För mig var programmeringsarbetet inte 5% av mitt fokus, något som förstärktes av att våra funktioner sedan länge var färdiga. Vi förvaltade det vi gjort.

Projektet, där vi var en del, var mycket omfattande och mjukvarudelen var inget undantag. Det fanns i storleksordningen 10 – 15 team i projektet och mjukvaruverksamheten omfattade flera hundra personer. Vi var organiserade i en klassiskt pyramid med en huvudprojektledare i toppen, delprojektledare, teamledare och ingenjörer.

En gång i veckan – på fredagar – hade vi ett omfattande systemtest/regressionstest av mjukvaran och under en period hade vi stabilitets- och integrationsproblem i princip varje vecka.

Fortsätt läsa

Fallstudie 2: När det inte går att skilja på projekt och verksamhet – del 2

Det här är del två på den fallstudie vi tidigare påbörjat. Börja gärna med att läsa den då jag inte väljer att repetera något material idag utan går direkt på slutsatser och lärdomar.

I de flesta företag som arbetar med komplexa produkter i en konkurrensutsatt marknad  kan endast väldefinierade projekt skapas som resultat av arbete i projekt. Detsamma gäller arbetspaket och detaljerade nedbrytningar av arbetsinnehållet; det är endast när kompetensen hos utförarna i projektet är närvarande som rätt kvalité på definitionsarbete kan nås och effektiva arbetsformer skapas. Det skapar sanning nummer ett:

Ett projekt måste hela tiden arbeta med att förtydliga och definiera arbetsinnehåll och arbetsformer. Naturligtvis bör projektets syfte vara definierat vid projektstart men det är en utopi att tro att detta kan göras speciellt detaljerat. 

  1.  Projekten måste hela tiden sträva efter att förtydliga målet med olika aktiviteter och insatser så att det blir tydligt att aktiviteter faktiskt blir avslutade. Det handlar om att säkerställa verkan och värde. 
  2. Projekten måste ha en fungerande dialog med en styrgrupp så att projektets mål och omfattning kan justeras under projektets löptid.

Sanning nummer två hittar vi i rörigheten som uppstår när projektets genomförare hela tiden prioriterades på annat:

Över tid trumfar effektivitet allt!

 




 

Det spelar ingen roll hur många projekt ett företag har, hur många linjechefer med egen agenda som finns eller vad som är ledtidskritiska aktiviteter med hög risk. Röriga företag, och människorna som verkar däri, hittar alltid ett skäl till att starta ytterligare en aktivitet även om det innebär ytterligare splittring av resurser, tid och energi. Men jag har inte sett ett enda dåligt fungerande projekt eller företag som varit fokuserade på nuet, på sin förmåga att leverera och komma till avslut i pågående verksamhet. Vad jag sett däremot är välfungerande projekt som haft sådan effektivitet att man helt enkelt svalt tillkommande jobb; riskutfall och offertarbete för framtida projekt utan att några planer ändrats.

På högsta managementnivå är det lätt att få acceptans för att projekten ska ledas så att rätt mål och verkan nås i stort som smått. Det är inte heller några problem att få gehör för att verksamheten sak vara effektiv även om det kan vara läpparnas bekännelse. Problemen uppstår där verkligheten drabbar företag och organisationer. Det är i verkligheten kunder behöver hjälp; nya releaser av programvara för tidigare kunder måste utvecklas och släppas; där säljavdelningen har en kund som vill ha offert snarast och det nya häftiga teknikprojektet, som är företagets framtid, ska dras igång.

Det är i verkligheten tvisterna börjar. Om vem som ska göra vad och om vems resurser det är som ska jobba. Om prioriteringar och vem som leder. Om nya teamgrupperingar och linjeorganisatoriska hemvister. Men oftast är det bäst att helt enkelt göra jobbet som krävs i befintlig organisation. Att hålla team och grupper intakta. Det kräver att projektledaren kan ta verksamhetsansvar och att chefer kan stödja befintliga strukturer och arbetsformer.

Slutsats

Moderna organisationer har ofta små möjligheter att dela upp verksamheten så enkelt som projektmodellen förespråkar. I själva verket så finns det endast en organisation som ska lösa det som krävs oavsett projektåtaganden, linjestrukturer och strategiska planer. Organisationens kunskap sitter dessutom i huvudsak i utförarorganisationen som ofta är hårt uppstyrd i projektverksamhet. Det sätter vissa sanningar kring projekt, hur de ska formas och drivas på ända och riskerar att skapa en situation där ledare i organisationen mest träter om vem som ska göra och när.  Pusslandet med resurser blir en konstart och individerna som pusslas med tappar lätt sammanhang och motivation. Det är fel fokus! Ledare ska fokusera på att få resultat i den verksamhet som bedrivs och på organisationens effektivitet. När det lyckas blir ofta projekten – eller ibland linjeverksamhet – huvudfokus där verksamheten drivs med hög effektivitet. Tillkommande arbete sväljs av de välfungerande teamen och saker och ting har en tendens att startas vid rätt tillfälle och faktiskt avslutas. Här stödjer cheferna sina team och sina projektledare som möter verksamhetens krav, inte bara projektens.

Fallstudie 2: När det inte går att skilja på projekt och verksamhet – del 1

Fallstudie nummer två är inte så specifik som fallstudie ett var, utan får kanske mer betraktas som en mer allmän betraktelse över moderna kunskapsintensiva organisationers utmaningar vad gäller förutsättningarna att skapa väldefinierade och tidsavgränsade projekt.

Jag var verksam i en organisation som drev sin utvecklingsverksamhet genom att skapa projekt. Oftast innebar arbetet att vi gjorde kundanpassningar med en befintlig produkt som grund, och den nya anpassade produkten skulle införlivas i produktportföljen när projektet var avslutat. Det innebar att en stor del av arbetet redan från början var uppstyrt av historiska beslut kring produkten vi hade som bas och vår organisation som vidmakthöll våra produkter, samtidigt som en rad processer och verktyg för exempelvis produktdata, provning, certifiering och konfigurationsstyrning också var av gud givna. Det här gjorde att projekten hade en stor andel arbete som, även om det ekonomiskt var arbete i projekten för den specifika kunden, genomfördes som en form av kontinuerligt linjearbete. Det i sin tur innebar att projekten i sig inte var så synliga och inte heller alltid involverade i daglig arbetsledning av verksamheten.

Fortsätt läsa

Fallstudie 1: En röra där veckorna passerade – del 2

Det här är del två i fallstudien – du läser del 1 här där jag pratar mer om projektet – där vi tittar på en verksamhet som hade goda förutsättningar att lyckas, men som samtidigt snarast kämpade för att överleva.

Här följer en kort resumé av del 1.

Projektets starka sidor

Fortsätt läsa

Fallstudie 1: En röra där veckorna passerade – del 1

Jag var nyrekryterad till ett företag för att ansvara för delar av utvecklingsverksamheten. Det var ingen stor verksamhet, den var inte heller speciellt tekniskt avancerad. Den var tvärfunktionell, vi utvecklade främst mekanik och elektronik mot kunders krav, och antalet projekt var stort, medan omfattningen per projekt var bedömd som relativt liten.

Kompetensen som helhet i projektet var god, även om erfarenhet och kompetens varierade från person till person.

Fortsätt läsa