Månadjanuari 2019

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.

Hur sprider vi projektledarkunskap i en organisation?

Hur blir ett företag, avdelning, projekt eller individ bättre på att leda projekt? Det finns massor av idéer kring det. I det här inlägget tänkt jag nämna några och kommentra de kort utifrån min erfarenhet, sedan tänkte jag föreslå ett sätt som inte används så ofta, inte som jag sett åtminstone, som handlar om projektgenomgång och projektgranskning.

Kurser och utbildningar: En bra metod att flytta positionerna kunskapsmässigt något. Ger energi och nya insikter men vänder sig främst till individer och sprider egentligen inte organisationens kunskaper, om inte kursen är utformad och genomförs av företaget själv.

Certifiering: Min personliga erfarenhet av PMP-certfieringen är att den är personlig medan IPMA genomgången mer öppnar för ett ökad spridning av kunskap i organisationen. Lärdomar formuleras – vilket är ett första steg för att de sedan ska kunna spridas – och det går att ha bisittare med vid genomgången som får höra och lära mer.

Lessons learned: I någon form så sammanfattar man lärdomar gjorda ur ett projektledarperspektiv och kommunicera dessa i organisationen. För den som medverkat i ett projekt, fas eller verksamhet och som kanske dessutom deltagit i arbetet med att sammanställa de lärdomar man gjort kan förstärka sin reflektion och inlärning avsevärt med den här metoden. Hur kunskapen når andra är mer oklart och väldigt personberoende. Det finns studier som visar på att dokument som lagras med lärdomar ”ruttnar fort”.

Arbeta tillsammans – mindre erfaren med erfaren: Mycket bra metod då det finns möjlighet att lära av varandra naturligt i arbetet. Denna metod kan dock lätt komma att handla om att man hjälps åt med ”volymarbetet” i projektet. Det är inte säkert att sammarbetet sker kring samtliga delar i hantverket ”projektledning” och spridningen av kunskap blir begränsad.

Intervjuer: Det här är en metod jag sett i praktiken inom bilindustrin. Inför en viss händelse eller fas i projektet så får ledaren på sig att intervjua utpekade nyckelpersoner i företaget. Det kan vara specialister, kvalitetspersonal eller projektledare med tidigare erfarenheter inom området. Det här är ett alternativ till Lessons learned på papper där dialogen och kontakterna gynnas till förmån för det skrivna ordet.

Audits, genomlysning eller projektgenomgångar: Jag har haft förmånen att bli tufft granskad av en mycket elak kvalitetsingenjör från en fransk biltillverkare. Förmånen säger jag med viss blandning av ironi och sanning. Att bli granskad är inte roligt, men det kan vara mycket lärorikt. Det kan dessutom göras betydligt mycket trevligare än vad man kanske först anar och fortfarande vara lika lärorikt. På ett ställe då jag var chef så samlade jag ledningsgruppen och så satte vi oss med respektive projekt och gick igenom en rad av projektets artefakter. Vi tittade på tidplan, risker, aktionslista, milstolpar och styrdokument. Vi pratade om dokumenten med projektledaren och hans teamledare. Projektkontorschefen lärde sig mer om sina projektledare och cheferna lärde sig mer om vad deras personal var tvungna att bli bättre på och stötta projektledaren inom.

Då vi gjorde det här med en rad projekt i rask takt såg vi också var de olika projekten hade best practices värda att sprida, var ökad överhörning mellan projekten skulle gynna oss som företag och samtliga inblandade fick möjlighet att diskutera frågeställningar i vardagen. Hur skriver man bra aktionslistor och vem följer upp aktionerna? Hur detaljerad ska planering vara och hur används den planering som görs? Hur styr projektledaren sin tid? Vem äger olika projektledningsdokument och projektets rutiner?

Det här synsättet kan naturligtvis tas längre men då börjar det allt mer påminna om projektkvalitetsarbete och då sticker omfattningen lätt iväg.

Har jag glömt någon bra metod för att sprida projektledarkunskap inom en organisation?

Jag levererar! Eller vad är det jag gör?

För rätt många år sedan nu var jag på en tredagarskurs som Semcon arrangerande. En ”lär känna dig själv och öka din självinsikt”-kurs för ledare. Det var en kurs som många lämnade med en fadd smak i munnen tror jag. Det var ingen måbra-kurs kan vi säga, men den var givande trots det.

Åldersmässigt var det ett relativt stort spann på oss som deltog i kursen. Jag var nog bland de äldre och tidsmässigt så befann jag mig i en tid där jag främst ledde genom att leda ledare. Alla andra ledde team eller grupper mer direkt. De satt närmare de som faktiskt utförde något i de företag de arbetade. På så vis var det en skillnad mellan oss. Men det fanns också många likheter. Alla jobbade i storbolag exempelvis.

Nästan alla lyfte fram sig själva och sitt bidrag i arbetslivet genom att säga ”jag levererar”. Inte så att det nödvändigtvis var det första de sa, men den absoluta majoriteten såg sig själva som ”doers” och de visste att det var så de levererade värde även som ledare.

Jag vet att den som ska leverera något i ett rörigt storbolag, i synnerhet om man inte sitter i den prioriterade delen av verksamheten, bör sätta ett värde i att få ut något genom dörren och jag vet att jag, på samma sätt som de som var på kursen, är duktig på det.

Trots det hade jag svårt att använda begreppet ”jag levererar” när jag skulle beskriva mig själv. För vad levererar någon som leder ledare i ett utvecklingsprojekt som rullar halvårsvis utan att göra en leverans av något slag? Visst, vi kan hitta på milstolpar och skapa interna mål men alla dem kan inte vara kritiska och koppla direkt till mig som ledare. Det blir aldrig samma sak som att skicka iväg den första prototypen på prov eller rätta ett fel och leverera uppdaterad mjukvara till kund när man själv är en handfast del i processen.

Vad levererar jag som ledare? Är det saken som går ut genom företagets port, laddas ned via ftp eller driftsätts i en IT-tjänst? Är det jag som tvingar fram de leveranserna eller är de ”bara ett resultat” av mitt ledarskap? En sorts spinn-off av det vi ändå gör? Eller har allt sin tid och plats? Att få något över tröskeln är det bara en del i ledarskapet? Är det kanske en väldigt liten del? Är det den del som är lättast att delegera?

I ett fotbollslag är det forwards, lagets stjärnor, som ska leverera. Det är inte lagledaren. Det är när jag verkligen lyckats i mitt lagledarskap jag genererat allra mest värde för den organisation jag jobbat i och för människorna jag arbetat med. Här någonstans är förklaringen till varför jag inte känner mig bekväm med begreppet ”jag levererar”.

Jag lämnar er hängande i luften där med mina tankar och sticker ut med en provokativ slutkläm: Jag tror att ett allt för stort fokus på de hårda leveranserna i ett projekt lätt gör att man som ledare utövar ett transaktionellt ledarskap.

Storskalig granskning the scrum way

Granskning!

Ett ord jag har en viss hatkärlek till.

Nu under hösten läste jag en kurs i kravhantering på universitetet. I universitetsvärlden gillade man granskning. Som projektledare gillar jag också granskningar. Vi sätter ner foten och säger att nu är det här jobbet klart. Vi kvalitetssäkrar det vi gjort och går vidare. Kod, dokument, krav eller länkning spelar ingen roll. Teoretiskt så är allt så bra!

Men jag vet också att granskning är svårt. Jag har arbetat som ledare i en organisation som släppte ut en mjukvara med ett mycket allvarligt fel på marknaden. Efteranalys visade att alla granskningar var gjorda och att vi processmässigt gjort ett gediget jobb. Problemet var att ingen som granskade dokumentationen eller koden hade tillräckligt god kunskap för att kunna hitta felet, eller ens se att de saknade förmågan till det. Det handlade inte om att granskarna var okunniga, tvärtom hade man valt mycket relevanta granskare utifrån den grupp som kunde vara aktuella. Istället handlade det vårt tillkortakommande till stor del om synen på den kunskapsuppbyggnad som följer med implementationen av mycket komplex funktionalitet i mjukvara. Vi litade för mycket på en person under lång tid och trodde andra skulle kunna kvalitetssäkra det arbetet personen gjort under åratal i efterhand.

Granskning kan också bli väldigt tråkigt vilket gör att kvalitén i aktiviteten sjunker. Artefakter där granskning är en viktig del i kvalitetssäkringen bör utformas så att granskning underlättas.

Granskning och scrum

Kan flera människor i ett tvärfunktionellt team granska en stor mängd artefakter, kanske i delar som bara är några timmar långa åt gången, och finns det några fördelar i att bedriva granskning så?

Jag skulle säga ja på båda på båda frågorna.

Men några saker måste vara på plats och är de det så bidrar det dessutom till att höja kvalitén i den granskning som ska göras.

  • Det måste vara tydligt vad som ska granskas för respektive artefakt och hur kommentarerna ska hanteras.
  • Artefakterna måste vara granskningsbara och strukturerade så att granskning av delar, eller vissa aspekter, är möjligt.
  • Det måste finnas en granskningsledare och någon form av verktygsstöd som säkrar helheten.

Att sprida granskningen vid en scrum-tavla kan dessutom tvinga fram vissa effekter som i sig höjer kunskapsnivån på teamet och bidrar till att höja kvalitén i det som görs indirekt. En tydlighet i vilken granskning som ska göras och vad den ska mynna ut i kombination med en gemensam insats att planera upp granskningen, exempelvis vid en scrum-tavla bidrar till det.

I praktiken kunde det se ut ungefär så här i Excelarken vi använde.

I praktiken hade vi 1000-tals ting att granska och vi granskade varje artefakt utifrån ett ganska stort antal aspekter. Det här var i sig inget nytt, åtminstone var inte kravet att granska det. Det som var nytt var att vi gjorde det med hela projektets bemanning – ungefär 50 personer – och att alla kunde, alternativt var tvungna, att hjälpa till. Att det gick berodde bland annat på att vi delat upp och förtydligat vad som skulle granskas med avseende på vad väldigt detaljerat. Och vi gjorde det på ett enkelt tydligt vis genom att använda ett schema enligt bilden ovan.

De artefakter som var svårgranskade, främst en grupp dokument, arbetades till viss del om för att passa vårt schema istället för tvärtom.

Förmodligen fanns det inledningsvis en person som granskat koden bäst. Eller som kunde kravverktyget bäst och därför borde granska länkningen som gjorts. För att inte tala om hur det såg ut avseende varningarna i byggresultaten. Det ville ingen kunna något om. Men att visualisera och dela upp tog oss framåt. Det var inte så svårt för systemkillen att granska alla filer med varningar när allt kom omkring. Det blev en eller två punkter som behövdes tas upp i större grupp. UI-gruppen gjorde ett mycket bra jobb i granskningen av testfall och länkningen av dem.

Ibland kunde vi gjort saker i en ordning som varit klokare, men eftersom vi alla hjälptes åt och blev allt klokare så gick eventuella omtag snabbt.

Vi höll på i månader. Först gnölade något över att vissa dokument inte granskades i sin helhet. Att allt snuttifierades. Någon ansåg att ingen hade överblick på om systemet faktiskt fungerade som tänkt och enligt ställda krav – något vi genom allt arbete som gjorts tidigare samt systemtester, robusthetstester och vad alla tester nu kunde tänkas heta var rätt säkra på när vi startade slutgranskningarna- och någon ansåg att deras kompetens kunde användas bättre.

Men det tog inte många veckor innan alla var positiva. Ingen satt med svartepetter. Kunskapsspridningen i granskningen gjorde att kvalitén snarare höjdes än sänktes. Kanske viktigaste för arbetsmoralen var att det vi hittade, som behövdes undersökas, snabbt gick att hantera. Ingen nyckelperson satt fast i granskning två veckor. Sällan hade någon en arbetsuppgift längre än ett par timmar.