Scrum

AGILA BEGREPP Den mest kända och mest använda agila metoden är Scrum. Det är en metod för att utveckla och underhålla komplexa produkter. Scrum är främst fokuserad på mjukvaruutveckling och har i princip sett lika ut sedan den formaliserades i ett regelverk 1995.

Det centrala i Scrum är ett interaktivt arbetssätt som innebär att man delar upp uppdraget i lika långa etapper, vanligtvis två eller fyra veckor, vilka kallas sprintar. Varje sprint innehåller; Sprint Planning, Daily Scrum, Review & Retrospectiv. Det innebär planering av sprinten, dagliga avstämningsmöten, granskning och release i slutet av sprinten, samt en utvärdering av processen och teamets samarbete.Dessa cykliska processer upprepas i varje sprint tills uppdraget är slutfört.

Inom Scrum finns det tre roller som alla ingår i ett så kallat Scrumteam; produktägare, scrum master och utvecklare. Produktägaren har ansvar för att maximera värdet av produkten och teamets arbete. Han eller hon är ansvarig för kraven, vilka sammanställs i en produktbacklogg.

Scrummasterns roll är att vara ledare och facilitator för teamet, det vill säga se till arbetet flyter och att Scrums regelverk följs. För att ett scrumteam ska kunna vara självorganiserande och ta ansvar för såväl resultat som samarbete inom sprintarna behöver teamets sammansättning vara konstant. Man lånar alltså inte in resurser tillfälligt i teamet. Det förutsätter att utvecklarna tillsammans måste inneha den kompetens som är nödvändig för att genomföra uppdraget.

I Scrum ska varje sprint leverera värde. Därför behöver produktägaren prioritera vilka krav som sprinten ska hantera och utvecklarna planera arbetet med hänsyn till teamets kapacitet. Detta görs i början av sprinten. Metoder som user stories används för att beskriva krav utifrån behov hos olika målgrupper och arbetets omfattning bedöms gemensamt i gruppen med någon poängbaserad värderingsmetod, exempelvis poängpoker. Hinner man inte med allt i en sprint skjuts återstående uppgifter över till nästa sprint där de prioriteras och planeras tillsammans med övriga krav produktbackloggen. Scrum är liksom många andra agila metoder främst avsedd för utveckling och förvaltning. Det är inte en komplett projektmetod, även om den går att tillämpa i projekt.

Man kan certifiera sig som produktägare eller Scrummaster. Exempel på certifierande organisationer är Scrum.org och Scrum Alliance.


Det agila manifestet

Agila metoder är en uppsättning värderingar, attityder och principer som beskriver hur arbete bör organiseras för komplexa uppgifter i en föränderlig omvärld. Agila metoder har hämtat mycket från Lean.

I Agila manifestet formulerade, år 2001, en grupp mjukvaruutvecklare fyra teser som en reaktion mot trögrörliga och komplexa planeringsmetoder. Att ägna mycket möda åt planering upplevdes som bortkastat arbete när målet och vägen dit är okänd och under ständig förändring.

Planeringsmetoderna tog inte heller hänsyn till att kunskap om hur mjukvaran faktiskt ska utvecklas uppstår under processens gång. Syftet med manifestet var att skapa ett ramverk för att öka förmågan att utveckla det som faktiskt är efterfrågat samtidigt som onödigt arbete minimeras.

Agila metoder bygger på arbete i korta cykler med täta leveranser och kontinuerliga feedbackloopar. Det ger möjlighet att snabbt kunna reagera på förändringar och fånga upp det man lär sig under projektets gång. Beslut bör tas så sent som möjligt, eftersom kunskapen då är större.

Beslut bör tas av de som är närmast informationen. Därför är beslutsfattandet decentraliserat till självorganiserande grupper. Team och medarbetare arbetar bäst när de har stor möjlighet att påverka och känner ägande över sina uppgifter inom givna ramar. Allt ansvar delas av alla medlemmar i gruppen.

Agila metoder handlar om att utveckla en strukturerad förmåga att skapa och svara på förändringar i en
föränderlig omvärld och att ständigt balansera mellan flexibilitet och stabilitet. Struktur krävs i många sammanhang för att flexibilitet ska vara möjlig.

En anledning till att agila metoder blivit populära är att omvärlden förändras i allt snabbare takt och att lättrörlighet då blivit en viktig konkurrensfördel för många organisationer.

Fyra punkter ur det agila manifestet

  • Värderar individer och interaktion framför processer och verktyg
  • Värderar samarbete med kunden framför att förhandla om kontrakt
  • Värderar att reagera på förändringar framför att följa en uppgjord plan
  • Värderar fungerande mjukvara framför omfattande dokumentation

Resan mot det agila företaget

Målet med att göra ett företag agilt är att i varje ögonblick säkerställa att man arbetar med att skapa kundvärde som kan levereras kontinuerligt. För att lyckas med det behöver man ha en flexibel organisation som snabbt kan anpassa sig till kundernas förändrade önskemål och behov. I det agila företaget är begreppet kundvärde ett av de mest centrala.

Grundbulten inom agil mjukvaruutveckling är de team som skapar kundvärde. Men för att hela företaget ska bli agilt krävs att mer än bara teamen arbetar enligt agila metoder och principer. Det krävs en genomgående kulturförändring i hela företaget.

Viktiga komponenter på resan mot det agila företaget är tydlighet, lyhördhet och uthållighet. Det är en krävande resa – men också en resa fylld av möjligheter.

Tydlighet - riktning
För att en kulturförändring ska ge full effekt är det viktigt med en tydlig riktning. Det betyder att man på alla nivåer i företaget har samma bild av vad man vill uppnå och vad som behöver förändras, och självklart varför. Detta blir förstås komplexare ju större företaget är.

Syftet med att bli agil är att genom snabbrörlighet fokusera på kundvärde. Vad
som då ofta behöver förändras i stora företag är att flytta beslutsfattande till lägsta möjliga nivå, att våga släppa kontrollen och att våga prioritera. Man behöver också skapa nya vägar för medarbetare att växa och det måste finnas en vilja att hela tiden reflektera och förbättra.

Som kring alla metoder och principer finns inom den agila världen många bokstavstroende som vill visa vägen. Vad man exakt behöver förändra och hur man genomför förändringen skiljer sig dock beroende på vilket företag man arbetar i samt vilket utgångsläge och slutmål man har. Faktorer som påverkar vägval kan vara vilka kunder man har, hur stor organisationen är och vilka produkter/tjänster man utvecklar.

Min erfarenhet är att man bör lyssna, lära och låta sig inspireras. I slutändan måste man bilda sig en egen uppfattning anpassad till ens egen verklighet. Det kan till exempel handla om att man på grund av komplexitet, beroenden och storlek beslutar att behålla men förändra projektledarrollen. Att lägga tid på att skapa en tydlig riktning initialt ger mycket tillbaka under resan.

Lyhördhet - förankra och involvera
I en stor organisation kommer beslutet om en agil transformation ofta från den högre ledningen. Lyckas man förankra beslutet, det vill säga få alla att förstå varför förändringen är nödvändig, blir genomförandet av förändringen smidigare. Alla chefer och ledare i organisationen har en central roll i att förmedla riktningen.

Ytterligare en viktig byggsten i omställningen är att involvera medarbetarna. Men är det då möjligt att involvera när det redan är bestämt att förändringen ska ske och riktningen är utstakad? Absolut. Att riktningen är tydlig betyder inte att svaren på hur omställningen ska genomföras är serverade. Här finns alla möjligheter att involvera medarbetarna i hur man ska göra. I en stor organisation som hanterar många beroenden, kommer dock vissa ramar behövas. Inom ramarna bör man lämna utrymme för frihet och lita på att teamen kan och vill göra sitt bästa.

Under denna långa förändringsprocess krävs det att man är lyhörd för organisationens svar på omställningen. Det innebär ofta att man behöver upprepa riktningen. Men det betyder också att man måste vara beredd att omvärdera och justera beslut när så behövs, som när medarbetare ser nya saker som behöver förändras.

Uthållighet – våga vänta på effekterna
Att förändring tar tid vet vi alla, i synnerhet när det handlar om att förändra företagskulturen. När det brinner kan det ibland vara frestande att falla tillbaka i gamla spår. Då är det viktigt att vara uthållig och våga vänta på effekterna.

Och man kan faktiskt göra något för att minska tiden tills effekterna börjar visa sig. Just genom att se till att riktningen är tydlig och ensad, att omställningstakten är jämn i företaget samt att man förankrar och involverar, kortas tiden. För att skapa moment är det också bra att tydliggöra och fira när de första effekterna syns.

Sammanfattningsvis kan man säga att resan börjar med att skapa en tydlig riktning. Därefter följer ett kontinuerligt arbete med att förmedla denna riktning, lyssna, anpassa och att sist men inte minst orka och våga vänta på effekterna. Denna resa har en början men lyckligtvis inget slut. Under resans gång kommer man kontinuerligt upptäcka nya möjligheter till utveckling och dessutom förändras hela tiden världen runt om vilket gör att man måste fortsätta anpassa.

Text: Maya Jernström, projektledare på Moment


Governance för agila projekt

När vi talar om projekt är det vanligaste att vi utgår från projektledarens perspektiv. Vi gör djupdykningar i förstudier, planering, genomförande och avslut. En lika viktig faktor för projektens resultat är vem som har ansvar och ägarskap.

En bra projektägare tar de viktiga besluten och ser till att leda, styra och förvalta organisationens tillgångar, rutiner och processer. Något vi kallar Governance.

Brian Wernham, som arbetat som konsult för Storbritanniens regering, Förenta Nationerna och Världsbanken har skrivit flera böcker om agilitet och agila metoder för offentlig förvaltning. Han har gradvis glidit in på hur man använder ett agilt tankesätt även inom Governance.
– Det har gjorts mycket arbete på agila metoder och agil utveckling, men det har varit väldigt lite debatt kring Governance av agila projekt, säger Brian Wernham.

Det behöver finnas en bra projektstyrning från projektägaren såväl i vanliga projektsammanhang som i agila projekt och program. Först och främst är det beteendet som bör sättas i blickfånget.
– Ett agilt beteende börjar bli väldigt viktig på ledningsnivå, menar Brian Wernham. Anpassning och snabba beslut är nödvändiga med tanke på den snabbt föränderliga omvärlden och tekniken.

Agila team tar ett stort eget ansvar. Därför måste den agila projektägaren ha ett stort förtroende för teamet, samt vara lyhörd och flexibel för att lyckas. En kritisk faktor är att projektägaren förstår grundläggande agila principer och hur de sätter spår i organisationen.
– Fokus bör ligga på att arbeta stegvis och delegera alla beslut till lägsta möjliga nivå, förklarar Brian Wernham.

Om grundläggande planering utförs, samtidigt som flera vägar utforskas och hålls öppna till det sista kritiska momentet, kan ledningen skapa en bra agil strategi och kultur. Agila projekt är också i behov av kontroll. Traditionella mätmetoder och modeller som projektplaner, mervärdesanalyser, enkla aktivitetsrapporter och andra klassiska metoder är fortfarande grundläggande faktorer till att agila projekt lyckas.
– Men vi måste koncentrera oss på beteendet, mer än processerna, slår Brian Wernham fast. Om beteendet fortplantas i alla led, kommer det öka graden av effektiva tillämpningar och innovationer, samt minska risken med överplanerade projekt. Projekt som misslyckas gör det ofta på grund av missriktade ”big-bang” försök inom organisationen.

Agilt Governance är ännu i sin linda, men om vi ska sköta agila projekt och program på ett effektivt sätt måste vi hitta strukturer och grundläggande parametrar för ägande, kontroll, ansvar och styrning.

Text: Claes Nordling


VIDEO: Projektledarens nya agila roll

PROJEKTVERKTYGSDAGEN 2014
Behövs projektledare i den agila världen? David Barnholdt berättar om vilka utmaningar en projektledare har i agila processer och projekt, och diskuterar fram en ny arbetsroll i agila miljöer.


Agila metoder i byggbranschen

Projektledning är idag ett högaktuellt ämne som diskuteras intensivt. Men det sätt som projekt inom byggbranschen styrs och leds har inte förändrats nämnvärt under de senaste decennierna. Däremot har byggmarknaden, antalet aktörer och hur projekten upphandlas idag, förändrats.

Detta har lett till en spricka i ledarskapssynen hur byggprojekt idag bör utföras och hur de faktiskt genomförs, vilket i sig är skäl nog att ifrågasätta denna konservativa bransch och titta närmre på vilka möjligheter till förbättringar som kan finnas.

Agil projektledning

I mitt examensarbete, som jag fått genomföra i samarbete med teknikkonsultföretaget Grontmij, utförde jag en kvalitativ studie baserad på intervjuer över hur projekt i byggbranschen utförs och framförallt projektleds. Resultatet från denna studie jämfördes sedan med teorin bakom agil projektledning för att se om dagens byggprojektledning kan dra nytta av denna filosofi. Den agila projektledningsmetodiken har stora likheter med Lean, men har utvecklats inom mjukvarubranschen, där den har vuxit och förbättrats genom empiriska framsteg. Den är lämpad för stora komplexa projekt, där det är svårt att ange och definiera produkten i förväg. Agila metoder används idag i olika branscher, men främst i mjukvaruindustrin, där kunden upptäcker sina behov med hjälp av upprepade tester, avstämningar och förbättringar av en prototyp.

Endast i projekteringsfasen

I byggprojekten var det endast projekteringsfasen som studerades närmare. Detta eftersom det är under denna fas som det är enklast och billigast att göra ändringar och forma den slutgiltiga produkten. I samma takt som projektet framskrider, minskar möjligheterna att påverka produktens utförande samtidigt som kostnaden för ändringar ökar. När projekteringen sedan övergår till produktion, sker en drastisk förändring både vad gäller möjligheten till ändringar, men även kostnaderna för dessa. Därför bör en effektivisering av projekteringsfasen kunna leda till ett mer framgångsrikt projekt såväl kvalitativt som ekonomiskt.

Ökat engagemang

En av de största fördelarna med att nyttja agila metoder är en ökning av kundens engagemang och involvering i projekten. De agila metoderna mer eller mindre tvingar kunden att öka sitt deltagande i projektet jämfört med hur situationen ser ut idag i en del byggprojekt.

[faktaruta]

Mattias Yllén Johansson tog i våras sin civilingenjörsexamen vid Kungliga Tekniska Högskolan, där han läst Samhällsbyggnad med masterinriktning Byggprojektledning. Hans examensarbete ”Agile project management in construction industry – an inquiry of the opportunities in construction projects” handlar om agila metoder i byggbranschen. Mattias deltar idag i Rambölls 1-åriga traineeprogram. mattias.yllenjohansson@gmail.com
[/faktaruta]

Dagligt stå-uppmöte

Figur 1 illustrerar tankesättet bakom den agila arbetsprocessen. Den visar ett dagligt stå-uppmöte vars syfte är att snabbt och enkelt stämma av hur det går för projektgruppens medlemmar, om de behöver extra hjälp eller om det till exempel är något som blockerar deras arbete. Den större loopen visar en s k cykel, vanligtvis 3-4 veckor lång, där det i början och slutet av varje cykel hålls ett start- respektive utvärderingsmöte. Under dessa två möten utvärderas den förra cykeln och projektgruppen kan lära sig från eventuella misstag och förbättra arbetsprocessen inför nästa cykel. Dessa olika former av avstämningar leder förhoppningsvis till att projektgruppen kan arbeta smidigare eftersom framtida begränsningar kan förutses på ett annat sätt och undvikas. Det innebär också att kunden behöver engagera sig oftare och med en jämnare fördelning för att projektet ska kunna drivas i rätt takt.

”Time management”

De agila metoderna kan också leda till minskad osäkerhet och förbättrad riskhantering. Genom användning av ”time management” och särskilda välplanerade möten kommer metoderna också att vara till nytta för att hålla reda på projektets framåtskridande och status. Inom dessa metoder sätts tiden som den ”fasta faktorn” som inte går att ändra. Detta genererar möjligheten att i slutet av varje tidsetapp, oavsett längd, få en tydlig bild av hur projektet utvecklar sig både ekonomiskt och kvalitetsmässigt. Om allt arbete, som man skulle ha hunnit med, inte utförts under tidsetappen eller om kostnaderna för etappen blir större än förväntat, framkommer detta tydligt då tiden är oförändrad.

Beslutsfattandet i agila projekt

Figur 2 illustrerar skillnaden i beslutsfattande mellan ett agilt och ett ”traditionellt” projekt. Där ser man tydligt att både projektgruppen och produktägaren (ofta beställaren) har större mandat att fatta beslut i ett agilt projekt än i ett traditionellt. Det framgår även att Scrum master (en form av projektledare) har mindre mandat till beslutsfattande och istället har en coachande roll som ser till att rensa bort alla hinder i projektgruppens väg. Den agila uppdelningen av beslutsfattandet ger deltagarna större möjlighet att ta beslut kring de uppgifter de har blivit tilldelade, vilket i sin tur motiverar projektgruppen och får dem mer engagerade i projektet.

För den intresserade av agil metodik i byggbranschen.

Läs Mattias examensarbete som du hittar på länken: http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-101094

 


People over processes - spelutveckling på DICE

Yashar, du har arbetat med utvecklingen av ett av de bäst säljande spelen i världen under 2010. Är vi i Sverige speciellt bra på att utveckla datorspel?

Ja, faktiskt. Vi är inte så många som jobbar med spelutveckling, men vi är superduktiga och de spel som vi tar fram rankas mycket högt. Det här spelet anses vara ett av Sveriges mest framgångsrika spelprojekt någonsin. Det var 2010 bland bäst säljande spelen i världen och har sålt mer än 10 miljoner kopior. Spelet har fått toppbetyget 88 utav 100 av metacritic.com, vilket är mycket högt. Spelet har också fått många internationella priser för bästa spel inom olika kategorier.

Ni genomförde projektet på kortare tid än normalt för utvecklingen av ett datorspel. Hur gick det till?

Ja, teamet lyckades utveckla spelet på väldigt kort tid. Anledningen var att vi byggde på befintlig teknik som gjorde att vi tidigt fick fram en infrastruktur. Dessutom fanns de tekniker vi behövde på plats. Vi kunde också utnyttja en spelmotor som projektet före byggt upp. Initialt var planen att projektet skulle bli en mindre uppföljare med begränsad budget, utvecklingstid och ansats. Man ville snabbt kapitalisera på föregångaren och dess spelmotor Frostbite. Men teamet ville mycket mer än så. Genom att utnyttja våra resurser som spelmotorn, ett smart upplägg av utvecklingen av spelet samt att motivera teamet på rätt sätt, lyckades vi med detta.

[faktaruta]

Yashar Moradbakhti

  • Född: 1979
  • Familj: Singel
  • Bor: Vasastan i Stockholm
  • Utbildning: KTh, civilingenjör datateknik
  • Aktuell: Product Owner på Spotify. Talare på Projektforum 2012.
  • Fritidsintressen: Träna, läsa, dansa salsa och jobbet
  • Kontakt: yashar@spotify.com eller ymoradbakhti@gmail.com

[/faktaruta]

Det var ju ett stort projekt som kostade hundratals miljoner att utveckla. Fick ni avdelade resurser eller delade ni resurserna med andra projekt? Berätta hur organisationen såg ut?

De spelprojekt som DICE jobbar med anses vara blockbusters, dvs storsäljare. Den här typen av spelproduktioner kräver enormt mycket resurser i form av folk, teknik och marknadsfö-ring. Projektet leddes av en ledningsgrupp med leads från olika discipliner såsom grafi k, design, produkt, etc. Ytterst ansvarig är alltid en executive producer. På projektledarsidan fi nns en sk senior development director (SDD) som vi development directors/ projektledare rapporterar till. På Battlefi eld Bad Company 2 var vi tre projektledare som samarbetade med SDD och övriga ledningen för teamet. Jag ansvarade för alla banor, dvs Levels, Character Experience samt Infrastructure. Med så stora team behöver man dela upp projektledningen mellan ett fl ertal personer så man även kan fokusera på detaljerna i produktionen. Vi utvecklade Battlefi eld Bad Company 2 på halva den tid som är normalt för den här typen av projekt med ungefär 150 personer i en renodlad projektorganisation. Inom projektet samarbetade experter från många olika discipliner som designers, programmerare, grafi ker av olika slag (2D, 3D, Levels, Effekter), ljuddesigners, animatörer, leads, video, marketing, test osv för att ta fram en upplevelse som tilltalar en massmarknad. Att vi kunde öronmärka resurserna för just det här projektet var en förutsättning för att kunna hålla tidplan och budget. Ytterligare hundratalet personer var sedan involverade inom marknadsföring och testning. Den producerande organisationen bestod av ett antal självständiga team. Vi försökte se till att ledningsgruppen inte skulle fatta alla beslut, utan vi ville ge mycket av ansvaret till teamen och se till att de hade rätten att ta beslut om hur produkten skulle se ut. Jag koncentrerade mig på att sätta ihop mina team så bra som möjligt. Det är viktigt att ta hänsyn till vilka personer som arbetar bra ihop, vilka kompetenser som måste vara med i gruppen, vilka kan bli naturliga ledare inom gruppen osv. För att lyckas måste man känna till medarbetarnas kunskaper och färdigheter, förstå vad som motiverar och vad som får den enskilda personen att göra det lilla extra. Lyckas jag med det så får jag ett extremt stolt och motiverat team.

Projektorganisationen
Projektorganisationen

Ur ett projektledningsperspektiv var det unika och nyckeln till framgång för projektet att fokusera på vad som var viktigast och sätta rätt personer på att lösa det omgående. Eftersom vi arbetade med Scrum innebar det att vi tillät möjligheten att ha helt nya Scrum-team vid varje iteration om så krävdes. Tidvis hade vi upp till 10 team på gång samtidigt. Vi anpassade scrumprocessen till de olika faserna i projektet. Tanken var att vi alltid skulle jobba efter högst prioriterade uppgifter och forma Scrumteamen därefter. Det är en enkel tanke, men kräver en mycket god förståelse för alla enskilda personer i teamet, deras kompetens, vilka de samarbetar extra bra med och deras aktuella motivation.

Scrum-processen
Scrum-processen

Bara det bästa är bra nog

Varje projekt har sin egen ”själ”. Det är alltid något som är unikt för just det projektet och som måste klaras av för att projektet ska bli en framgång. Hade ert projekt någon själ?

Det skulle i så fall vara det att företaget DICE är extremt stolt över vad man producerar. Man nöjer sig inte med mindre än att vara världsbäst i branschen. Den ambitionen påverkade naturligtvis också oss. Detta att bara det bästa är bra nog är en utmaning i alla projekt där man har en fastlagd leveranstidpunkt. Det är svårt att avsluta aktiviteterna då det alltid går att göra lite mer och lite bättre. Detta var verkligen en utmaning i projektet, att få medarbetarna att förstå att deras arbete var tillräckligt bra och inte lägga ännu mer tid på detaljer, även om det gav fantastiska resultat. Det blir världsbäst ändå!

Vad är det konkret för skillnad mellan att genomföra ett spelprojekt och andra projekt som du jobbat med tidigare?

Den absolut största skillnaden är att det är mycket svårare att i ett tidigt skede avgöra om det man bestämt sig för att utveckla, kommer att vara underhållande för slutkonsumenten. Därför behöver man snabbt få upp körbar kod som man kan spela och utvärdera. Man behöver kontinuerligt ändra och förbättra resultatet så att det slutgiltigt når hög kvalitet och är underhållande. Mängden iterationer för att nå kvalitet är också mycket högre än vid vanlig utveckling av applikationer, där de inte behöver vara underhållande utan endast fungerande och användbara.

Jag gillar att styra mot milstolpar. Det ger den tydlighet och drivkraft som är nödvändig i ett projekt. Hur såg er utvecklingsprocess ut? Använde ni milstolpar som styrmedel?

Visst. Milstolparna var viktiga för oss. Inte bara som ett styrmedel utan också som en anledning att fi ra. DICE har en projektmodell som man kallar ”Game Development Framework”. Den bygger på sex faser med ”gates” och fl era milstolpar. Faserna skapar fokus för organisationen och har de tydliga leverabler som behövs för styrningen. Inom faserna jobbade vi med iterationer på två veckor.

Projektmodellen på DICE
Projektmodellen med iterationer

De externa milstolparna, i form av mässor och pressreleaser, var de viktigaste. De krävde att vi hade gjort färdigt det som skulle presenteras för journalisterna, ofta delar av systemet. Dessa presentationer gav oss kickar och en känsla av stolthet. Till en början använde vi Excel som planeringsinstrument. Sedan gick vi över till JIRA, som är ett planerings- och kommunikationsverktyg, men vi landade i att använda gula lapparnotisar. I sin enkelhet är det ett mycket visuellt system, där vi lätt kunde göra våra dagliga uppföljningar. Vi jobbade också agilt och försökte resursplanera efter projektfl ödet. Något som är extremt svårt att få till inom spelutveckling är konceptet ”kul”, dvs att göra det till en ”kul” upplevelse för kunden att använda spelet. Det är något som är ytterst svårt att planera för och det gör spelutveckling till en extremt iterativ process. Man får en kreativ process som kan uppfattas som kaotisk. Det gällde för oss som projektledare att ta fram en form av ordnat kaos. Eftersom kreativitet är ett måste inom spelutveckling, behöver man därför som projektledare tillåta iterationer och ändringar för att nå kul/kvalitet samtidigt som man måste driva på för att nå avslut så man kan vara klar i tid till releasedatum.

Ett välmående team är ett produktivt team

Du nämnde tidigare nödvändigheten av att ha motiverade team och medarbetare. Hur bar ni er åt för att hålla motivationen uppe hos så många under så lång tid?

Det här är en av mina käpphästar som förhoppningsvis hade betydelse för vårt positiva resultat. Jag vill ha en nära relation med de jag jobbar med. Jag vill känna dem väl för att kunna se vilka arbetsuppgifter som de passar för. Därför försöker jag att vara en god lyssnare, empatisk och verkligen bry mig om mina medarbetare. Jag frågar hur familjen mår, hur de trivs med jobbet just nu, hur vi kan förbättra arbetssituationen och sedan verkligen göra det. Genom att själv vara öppen tillåter man medarbetarna att ”sänka garden” och komma direkt med sina problem så att man snabbt kan lösa dem. Man ska förstå vad som motiverar och vad som får den enskilde personen att göra det lilla extra. Det är därför väldigt viktigt att visa uppskattning för bra jobb. Ofta är det frågan om enkla vardagliga saker som att tacka och ge en klapp på axeln. På veckobasis hade vi små team-event med fi ka och spel. Ibland gick vi ut gruppvis och tog en öl. När det var frågan om större fi rande vid milstolpar så kunde det t ex bli whiskyprovning. Formerna är inte så viktiga, det viktiga är att man gör något och visar uppskattning.

Jag valde som rubrik din filosofi ”People over processes”. När du nominerades till Årets Projektledare var det just ditt personliga ledarskap som framhölls som ett framgångskriterium. Vad lägger du in i begreppet ”People over processes”?

Grundtanken är att jobba så enkelt som möjligt och se till att processerna är till för ditt team och inte tvärtom. Fokus är alltså på att se till individerna i projektet, hur man kan optimera deras output genom att ge dem verktygen och möjligheten att göra sitt yttersta samt att hålla motivationen hög även under svåra omständigheter. Det här försöker jag skapa genom att sätta ihop team med erfarna seniora medarbetare som har genomfört liknande projekt tidigare. De som vet hur man ska genomföra projektet utan att fastna i detaljerna. Jag vill också ha medarbetare som kan utveckla kulturen och kan definiera vår vision och kommunicera ut den till andra. I teamet måste det också finnas personer som kan driva gänget så att vi uppnår milstolparna. Alla är viktiga för att nå målet i slutändan, det är ju en team-effort!

Det här var ett riktigt lyckat projekt, men i alla projekt, även de mest lyckade, har man problem. Vilka hade ni?

Visst hade vi problem. När det gäller teknik i framkant handlar det ju om att lösa svåra och helt nya problem hela tiden. Ibland till synes olösliga problem, som dock visade sig gå att lösa. Sedan är det extra komplicerat när många vid lanseringen ska spela samtidigt på en och samma gång. Men det fanns ett väldigt kompetent team som var väl förberett för att hantera miljontalet användare.

Innan vi avslutar, vill jag be dig ge fem råd till andra projektledare.

Absolut. Då får det bli följande:

  • Lär känna dina team-medlemmar grundligt. Lär känna deras styrkor och svagheter. Tänk på hur du kan kombinera olika styrkor för att maximera hela teamets leveransförmåga.
  • People over processes! Processer är till för att stödja medlemmarna i teamet och inte tvärtom. Det är viktigare att man lägger tid på att utveckla teamet så de vill ta mer ansvar, tar egna initiativ, blir kulturbärare, förstår sig bättre på hela ekosystemet samt förstår vikten av att leverera i tid och till hög kvalitet. Du har ansvar som team-ledare att överföra (via dig själv eller andra) denna kunskap till teamet så att de själva kan ta de flesta av besluten.
  • Bygg upp en kultur där folk är stolta över sitt arbete, produkten/ tjänsten och företaget. Man ska vilja vara bäst i världen på det man gör och det nu och inte om något år.
  • Håll energin på hög nivå och ha momentum i projektet. Jobba mot deadlines och milstolpar som är högst 1-2 månader bort. Se gärna till att dessa milstolpar är kopplade till externa event som går ut till media eller stort antal slutkunder. På så vis blir leveransen mer påtaglig och teamet kommer att vilja leverera till kvalitet (då du sedan tidigare skapat en kultur där folk är stolta över produkten).
  • Se till att ha riktigt kul på jobbet, folk ska verkligen trivas. Tacka alla för deras arbete: genom att säga tack, ha veckovisa middagar, ölkvällar, fika eller liknande. Bjud på större event efter att ha klarat av milstolpar. T ex en heldag med aktiviteter. Låt det kosta, de ska känna sig speciella.

Hur avslutar man ett så bra projekt med så många inblandade?

Vi fick hela tiden pengar av ledningen för att kunna fira. Direkt efter Nobelmiddagen hyrde vi stadshuset och hade vår egen Nobelmiddag med respektive partner. Alla regioner lanserade spelet samtidigt, men med egna kampanjer. Gemensamt för projektslutet var dock att de stora glasskåpen med champagne öppnades och vi fick tillfälle att skåla och känna oss nöjda och duktiga.

Tack för ett jättetrevligt samtal. Nu har jag fått en liten inblick i ledningen av ett spelprojekt. Det är bara att konstatera att också här är det personliga ledarskapet som skapar framgång.