Mer SCRUM

Under de gångna veckorna har det förts diskussioner om att arbeta mer enligt agila metoder, specifikt SCRUM, i projektet i stort efter de lyckade resultaten med SCRUM-team på både system- och software-sidan. Man har stöd från Volvo för att jobba ännu mer agilt, inte bara internt utan gentemot Volvo, och tittar på hur man kan förändra processer mellan de två företagen för att underlätta detta arbetssätt. Det återstår ännu att se exakt hur det kommer att se ut men förhoppningen är att man ska få en snabbare och mer effektiv kommunikation mellan leverantör och kund.

På ett möte med team leads idag där jag satt med (och gav exempel på mina slutsatser) fick jag reda på att en del av de rekommendationer jag har faktiskt kan komma att beaktas. Det är hoppfullt! (Det rör sig om olika ambitioner att ändra processer som andra driver inom projektet, men som jag håller med om).

Ett förtydligande

Efter samtal med medarbetare på kontoret styrks min uppfattning att projektwikin på Mecel är ett bra verktyg för somliga ändamål (som att leta efter tips och trix kring specifika tekniska problem) men att den också, “som alla wiki:er”, lider av att den lätt blir rörig och att det är svårt att hitta till precis rätt artikel om man inte vet exakt vad man ska söka efter.

Medarbetarna framhåller dock att viktig information i huvudsak sprids via mail och inte via nyhetsflödet på wikin.

 

En jämförelse

Efter att ha varit på plats här ett litet tag och tittat på projektledning, kommunikation i projektet och spridning av information vill jag nu dela några observationer och tankar jag har kring likheter och skillnader mot dels mina tidigare VFU-erfarenheter från gymnasieskolan och dels andra företag.

Verksamhetshandboken

På Mecel finns en stor samling dokumentation som gemensamt kallas Verhsamhetshandboken (VHB). Denna utgör grunden för företagets verksamhet och beskriver systematiskt processer och samband mellan olika funktioner och roller. Den tar ett helhetsperspektiv och beskriver allt ifrån företagsidén och värderingar samt strategi för de kommande åren till personalpolicy, miljöansvar och inköpspolicy. Verksamhetshandboken innehåller gott om illustrationer och flödesdiagram för att illustrera beskrivna processer och alltsomoftast är enskilda bilder klickbara för mer detaljer, dock kan informationen vara alltför kortfattad bitvis och (vedertagna?) förkortningar florerar friskt. Jag har inte sett någon liknande dokumentation i gymnasieskolan, i alla fall där jag varit. Kanske är det så att motsvarande policyer finns dokumenterade även där men jag tror inte att man kan hitta dem samlade på samma ställe på detta sätt. Gymnasieskolan regleras ju kraftigt av skollagen och andra statliga och kommunala regelverk men frågan är hur tillgänglig informationen är i den lokala kontexten för den enskilde läraren. Jag kan inte säga något säkert för jag hade inte personlig tillgång till intranätet när jag var på VFU på skola men jag misstänker att man inte jobbat på samma sätt där.

Men jag undrar hur mycket den enskilde medarbetaren använder sig av verksamhetshandboken på Mecel, särskilt de medarbetare som inte sitter i en system- eller chefsfunktion. Det är dock positivt att informationen finns så tillgänglig för alla, om man skulle vilja förkovra sig i den. Jag upplever att handboken är något man är stolt över att ha upprättat och jag får intrycket att alla företag kanske inte har en sådan formulerad.

Wiki

Mecel har en egen intern wiki som används för att dela med sig av information. Jag får intrycket att den används för flertalet syften, bl.a.:

  • Som en anslagstavla med viktiga nyheter som angår potentiellt alla (förstasidan har en kolumn med nyheter)
  • Som ett ställe att samla projektspecifik information (ofta under en “sub-wiki” med egen huvudsida och eget nyhetsflöde)
  • Som ett ställe att samla tips&trix och guider för specifik mjuk- och hårdvara
  • Som ett register över labbutrustning och andra tillgängliga prylar

Fördelen med en wiki är naturligtvis att underlätta editering (alla kan editera men man måste vara inloggad) så att det inte är ett så stort projekt att dokumentera något matnyttigt man just kommit fram till (för att underlätta för medarbetare i liknande situation). Wikin håller även reda på redigeringshistorik på sina sidor vilket ger spårbarhet.

Återigen är jag osäker på om gymnasieskolan jag varit på har något liknande i sitt intranät eller, än viktigare, om det i så fall används av den enskilde läraren. Intrycket jag fick där jag var var att lärarna i stort arbetade mycket självständigt och använde främst e-post och personliga möten för att kommunicera med medarbetare och chefer.

Det är lätt att tänka att skolan här kanske har något att lära av näringslivet, att man borde satsa mer på denna typ av verktyg, men det är inte säkert att det är det bästa. Vi måste tänka på att Mecel är ett tekniskt företag med genomgående teknikintresse och kompetens bland medarbetarna – något som man inte kan ta för givet i skolan. Det betyder att där dessa medarbetare finner det naturligt att använda t.ex. en wiki är det inte säkert att alla lärare gör det eller kan motiveras att lära sig systemet eller (kanske än viktigare) grundidén till varför det finns tillgängligt. Det är nog inte till stor nytta att introducera nya verktyg om man inte vet till vad de ska användas (även om detta ibland fungerar, ta t.ex. surfplattor som det kontinuerligt skapas nya användningsområden för).

Förstå mig rätt, jag säger inte att wiki:er är en dålig idé i skolkontexten, jag säger bara att man noga bör tänka igenom vilken funktion man vill att en sådan ska fylla och utvärdera andra plattformar i ljuset av den tänka målgruppen innan man bestämmer sig för något. Jag tror dock att det skulle behövas effektivare sätt att nå ut med best practices och tips&trix även i skolan, sätt för lärare att enkelt dela med sig av uppgifter/lektionsupplägg osv.

Frukost

Varje dag erbjuds ett lättare frukostfika kl 9, både på huvudkontoret men även i Lundby (eftersom så många sitter mer eller mindre permanent här och inte är inne så ofta på huvudkontoret). Dessa frukostar bjuder mig, förutom en god macka och kaffe, ypperliga tillfällen att prata om arbetet här i ett lite mer informellt format. Vår svenska fikakultur är något värt att värna. Mycket bra tänkt där, Mecel.

Telefonkonferenser

En observation jag gjort är att man flitigt använder telefonkonferenser när man ska fatta beslut och förmedla information inom systemteamet eftersom delar av teamet sitter på olika ställen i världen. Man använder både vanliga telefonkonferenser (genom att ringa in till ett nummer) och skype-konferenser samt lync-konferenser (ibland i kombination) och blandar inte sällan detta med att flera sitter i ett konferensrum och delar på en telefon- eller skypelinje.

Det kan t.ex. gå till så att man sätter på högtalartelefonen på en mobil och lägger den på mitten av bordet i ett konferensrum och ringer upp konferenssystemet. Vid sidan kan någon vara inloggad på skype och ha med en tredje person på länk den vägen (så att konferensrummet förmedlar ljudet mellan datorns skype och mobiltelefonen på bordet).

Pragmatiskt.

Utbildning i git/gerrit

Förra veckan var det utbildningstillfällen inplanerade här inom HMMIOM-projektet i Lundby. Det gällde den planerade rollouten av git och gerrit som kodrevisions- och granskningssystem istället för det befintliga och begränsade systemet. Git är som bekant ett distribuerat versionshanteringssystem som enligt design erbjuder kraftfull, snabb och flexibel funktionalitet men på ganska låg nivå. Det är väldigt flexibelt och inte specifikt anpassat efter ett visst sätt att jobba men samtidigt kan man skjuta sig i foten ganska lätt. Det kräver med andra ord lite mer kunskap av slutanvändaren. Eftersom de flesta jobbar i en Windowsmiljö och man inte vill påtvinga kommandoraden på någon så har man valt att introducera git och gerrit tillsammans med ett gui som heter git extensions. I detta kan man göra de flesta uppgifter så som att göra commits, checka ut olika delar av repositoryt, skapa och navigera bland branches mm med point-and-click.

Jag var med på två utbildningstimmar förra fredagen där verktyget presenterades av en kunnig medarbetare för de andra i kontoret. Överlag tycker jag att presentationen var välgjord och ändamålsenlig. Presentatören varvade powerpoint som han berättade utifrån med live-visning av verktyget på sin dator. Folk fick avbryta och ställa frågor vilket bjöd in till diskussion och jag kunde flika in med mina erfarenheter och dela med mig. Jag har ju tidigare erfarenhet av git sedan bl.a. exjobbet.

Det märks tydligt att arbetsprocesserna varit mycket präglade av det gamla verktyget man använt. Folk frågade hur man i git och gerrit gjorde motsvarande delar av processen som man tidigare gjort i det andra verktyget. I många fall fanns en ungefär match men i andra fall inte. Man har valt att försöke ingripa på processen så lite som möjligt för att minimera riskerna i transitionen och man kommer synkronisera git-repositoryt kontinuerligt in i det gamla systemet för att ha en failsafe om något skulle gå snett och man måste gå tillbaka. I och med en stor release som skedde förra fredagen har man nu börjat på en ny stor utvecklingsbranch med nytt kodnamn. Detta markerar också början av att använda git och gerrit i skarpt läge. Det enda jag är lite orolig för är att man lärde ut systemet i en lite för ytlig väg, att man försökte ducka för en del av den konceptuella basen som gör git lite speciellt och vid första anblick lite svårt. “Det kommer vi inte använda så det behöver vi inte veta om”. Det finns en viss risk i att man kommer skjuta sig i foten och inte förstå systemet och varför det gör som det gör i vissa lägen om man inte lär sig dessa bitar. Jag tror inte att det skulle ta jättemycket mer tid i anspråk, men jag vet inte. Tiden får utvisa.

Jag är ändå glad att man tagit beslutet att satsa på git. Det är i min mening ett bra och kraftfullt verktyg, väl kapabelt att ersätta det (efter vad jag förstått) gamla, långsamma, instabila och inflexibla verktyg man tidigare använt (och som kommit “uppifrån”, från Delphi i stort). Jag önskar dem all lycka i detta!

 

En veckas uppehåll

Hej igen!

Jag har inte bloggat på ett tag eftersom jag varit borta en vecka och fokuserat 100% på exjobbet som jag skiver parallellt. Men nu är jag tillbaks igen och fortsätter som vanligt.

Under tiden jag var borta har saker rullat på ganska mycket enligt schema. Den här veckan var planerad för utbildning i git/gerrit och det har inte förändrats. Jag ska idag delta på kurstillfällen för att se hur de förmedlar de nya arbetsformerna och verktygen till anställda. Det ska bli intressant! Mer om det senare.

Man hade också planerat en mjukvarurelease till imorgon, och den kommer ske som planerat. Skönt när saker rullar på!

Hörs snart igen,
Rikard

Processverktyg

System, Software och Test

Projektet är indelat i tre huvudgrupper som har olika ansvar. Systemteamet har i grova drag hand om projektledning, kravhantering och administration. Det är dessa personer som utgör kontaktytan mot kunden, de tar emot förändringsförfrågningar och krav och det är de som meddelar kunden till vilken release kraven kommer vara uppfyllda. Systemteamet har viss tillgång till Volvos system ur vilken de hämtar ut information som matas in i interna system på Mecelsidan.

När förändrade krav godkänts och ska implementeras tar Softwareteamet över. Detta team är i sin tur indelat i olika delar som sitter på olika geografiska platser. En del i Sverige, andra utomlands. Gränssnittet mellan Systemteamet och Softwareteamet är ett konfigurationshanteringssystem där funktionsförändringar behandlas. Ett ärende i systemet skapas typiskt av Systemteamet och när de behandlat det färdigt lämnar de över till Softwareteamet för implementation (programmering). När programutvecklaren så tycker att förändringen är genomförd så lämnas ärendet över till Testteamet som finns utomlands. Dessa genomför då en mängd tester för att säkerställa kvalitet och funktionalitet och när de rapporterar att förändringen är ok så får Systemteamet tillbaks ärendet. De kan då meddela kunden att förändringen är klar och kan väntas i en viss software-release i framtiden.

Idag har jag haft tre möten med medarbetare på Mecels Systemteam här i Lundby. De har sedan början av året jobbat enligt Scrum-metodik och är indelade i tre Scrumteam med varsin Scrum master. Praktiskt innebär det att de har större inblick i vad de andra jobbar med och att man i teorin kan reagera effektivare på t.ex. om någon har för stor arbetslast eller om någon är t.ex. sjuk eller VABbar. Men för medarbetarna tycks förändringen i arbetssätt mest märkas i att de har dagliga standup-möten på morgnarna och arbetar med postit-lappar.

I systemteamet har man nyligen börjat använda git tillsammans med ett grafiskt GUI som verktyg för att hålla reda på specifikationsdokument och dess livscykler. Tidigare hanterades detta manuellt i en delad arbetsyta vilket var mindre effektivt.

Jag frågade idag hur en medarbetare i Systemteamet tror att de bör förändra hur de jobbar för att klara av att bli färre i projektet. Denne uttryckte att det i stort inte borde krävas så stora förändringar eftersom antalet begärda förändringar från kunden borde minska och därmed deras arbetsbörda i Systemteamet.

Jag är ju här för att sätta mig in i hur man arbetar i det stora projektet med fokus på hur kommunikationen sker. Därför är det extra intressant att höra om de olika IT-stöden de använder för att förmedla information och beslut. Jag är särskilt nyfiken på gränssnitten som finns mellan system och mellan individer och riskerna för missförstånd.

Min uppfattning är att det i många fall sker ett “onödigt arbete” med att manuellt skyffla information mellan inkompatibla IT-system. Detta borde man kunna effektivisera.

MEN

… men å andra sidan är problemet nog inte så enkelt. Det som förefaller vara enbart ett manuellt jobb där en person flyttar data från A till B är egentligen mycket mer komplext. I och med att en person med god domänkunskap gör detta jobb utsätts informationen för mer kontroll på sin väg mot målet. Fler personer får chans att hitta misstag eller felaktigheter. Detta kan en dator aldrig göra. Så även om själva “dataskyfflingen” skulle kunna automatiseras så betyder inte det att projektet skulle bli effektivare eller att medarbetaren som tidigare jobbade med detta skulle bli ledig för annat. Nej, så enkelt är det inte.

Jag hör den gode Wickenbergs ord liksom eka i mitt huvud när jag lunkar omkring och pratar med folk och läser dokumentation och i övrigt försöker förstå mig på projektet: “Sök särintressena. Det finns alltid särintressen. Särintressena styr och kan förklara beslut och ageranden som vid första anblick ter sig obegripliga.”.

Turligt nog har jag hamnat i ett projekt med god stämning, trevlig och kompetent personal och en vilja att hjälpa till och dela med sig av erfarenheter. Nog hoppas jag kunna hitta något användbart jag kan dela med mig till Mecel av, något de kan förbättra inför framtiden, men jag kommer nog få leta med ljus och lykta.

/Rikard

Kontoret i Lundby

Uppdragsgivaren runt hörnet

Mecel har sitt Göteborgskontor nära Korsvägen. Där jobbar många av de anställda och det var dit jag åkte första dagen, men efter att ha kvitterat ut passerkort och skrivit på diverse papper och formulär så har jag nu fått en plats i Volvos lokaler i Lundby där projektteamets svenska del sitter. Man har berättat att det är en stor fördel för projektledningen att jobba på plats i Lundby eftersom själva uppdragsgivarna sitter i samma byggnad inte långt härifrån vilket underlättar kommunikationen. Här finns också testriggar (förarmiljön med ratt, reglage, displayer osv) där man gör en del mjukvarutester. Volvo har som de flesta stora bolag rigorösa processer för hur exempelvis förändringar i specifikationer eller annan information ska förmedlas från dem till Mecel. Närheten till människorna bakom systemen gör dock att man kan påskynda maskineriet i vissa fall genom att bara gå några meter och prata direkt med de berörda för att reda ut frågetecken. Detta är förstås både en stor fördel (snabbare och smidigare) men också en tänkbar nackdel då det innebär att potentiellt viktiga diskussioner förs off-the-record och inte finns lagrade någonstans, varken som e-post eller i andra system. Om det är bra eller dåligt beror helt på sammanhanget och vem man frågar, och samma problematik finns ju med organiserade möten och telefonsamtal. I praktiken innebär det nog mer fördel än nackdel. Många har vittnat om att processer, när de blir för stela och rigida, förlorar sin stödjande funktion och istället blir ett produktivitetshinder.

Många i samma hus

I lokalerna i Lundby sitter såväl Volvo som andra av deras underleverantörer, dvs konkurrenter till Mecel. Därför poängteras att det är viktigt att medarbetare låser datorer när de är iväg och att man inte lämnar känsliga handlingar framme. Jag upplever att det verkar finnas en slags gentlemen’s agreement i att man respekterar andras privata ytor så förhoppningsvis är industrispionage inget problem i praktiken. Och är det det så lär det ske så diskret att jag inte har någon chans att upptäcka det. Själv låser jag alltid min dator men det är mest av privata skäl.

System och processer

Men på tal om detta så verkar Volvo ha en lite ambivalent relation till Mecel som leverantör i fråga om hur man ska förhålla sig. Å ena sidan sitter man i samma lokaler och ett nära samarbete eftersöks för att minimera misstag och förseningar och få så god kvalitet på slutprodukten som möjligt – det ligger ju trots allt i bådas intresse! – men å andra sidan håller man hårt på viss information från Volvos sida och Mecel tillåts bara access i vissa av deras system och på ett onödigt begränsat sätt vilket gör det nödvändiga informationsutbytet krångligare än det skulle behöva vara. De två företagen använder olika (proprietära och inkompatibla) system för att hantera projekten och change management och jag upplever att många personer behövs bara för att mer eller mindre manuellt skyffla information mellan de två systemen och de två företagen. Det ska bli spännande att se om jag ändrar denna uppfattning längre fram när jag fått se mer och har en större inblick. Jag misstänker att denna problematik dock är mer regel än undantag i branschen.

/Rikard

Vad gör Mecel?

Jag har nu varit på Mecel i två veckor och ska göra ett försök att introducera företaget och projektet jag kastats in i. Som jag nämnde tidigare är jag på plats två dagar i veckan (de andra dagarna jobbar jag med mitt exjobb på Ericsson). Framåt juni när exjobbet är slut kommer jag troligen gå över till heltid här på Mecel för resten av kursen.

Så vad gör Mecel och vad gör jag på Mecel?

Projektet jag gästar arbetar sedan 2008 med att utveckla en datorkomponent (både hårdvara och mjukvara) för Volvos och Renaults nya lastbilar. Komponenten är central för lastbilens olika datorsystem och kan kort beskrivas som spindeln i nätet för användargränssnitten i bilen. Det är den som ser till att alla delar av bilen kan prata med varandra och att rätt saker händer när man aktiverar knappar och reglage samt att rätt information presenteras på skärmen och instrumentbrädan. Det är en komplex uppgift som innefattar mycket mer än man kanske tänker på.

Det är ett stort projekt som innefattat ca 150 personer i tre länder sedan starten, i Sverige, Polen och Indien, men nu är man på väg att skala ner projektet på alla led eftersom man börjat leverera till kund och man inte längre har behov av lika stor organisation. Mecel är numera ett helägt dotterbolag till Delphi, ett stort amerikanskt företag med nära på 150000 medarbetare globalt så även om det är Mecels medarbetare som jobbar i projektet här i Göteborg är det ett Delphi-projekt.

En del kodutveckling görs här i Göteborg och en del i Indien medan testning i huvudsak sker i Polen. Detta ställer naturligtvis specifika krav på kommunikationen, både språkligt men också beträffande vilka IT-system och processer man använder. Under min tid här på Mecel ska jag försöka gräva mig ner i denna kommunikationsstruktur i ljuset av att projektet ska bli mindre (och därmed kanske behöver ändra och slimma hur man kommunicerar idag) och jag hoppas när den här tiden är slut ha lite tankar och idéer från mitt “outsider”-perspektiv som kan vara intressanta för dem.

Konkret kommer jag att spendera mina dagar med att gå på möten, gräva i processdokumentation, intervjua medarbetare lite mer formellt och känna pulsen på dem vid kaffepauserna. Dessa raster är en oumbärlig källa till nyttig information! Jag ska försöka hålla huvudet kallt och hela tiden ha antennerna ute för att lyssna in vad personer verkligen tycker och tänker och jag vill vara öppen för eventuella målkonflikter eller olika syn på saker som kan finnas. Jag ser mig själv som väldigt autonom i min studie av företaget och projektet och det är viktigt att medarbetarna känner att de kan vara ärliga med mig utan risk för att chefer får reda på det. Detta framhåller jag vid varje intervju.

I framtida inlägg ska jag berätta mer om mina första tankar och reflektioner kring hur man jobbar.

Tills dess, allt gott!
/Rikard