Att skala upp agilt arbete (med Giovanni Asproni från Zuhlke Engineering Limited)

Läs transkriberingen:

Vi testar att transkribera våra poddavsnitt med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte har rätt 100 procent av gångerna.

Ben Aston:

Välkommen till DPM-podden, där vi går bortom teorin för att ge råd som fungerar när man ska leda bättre digitala projekt. Tack för att du lyssnar. Jag heter Ben Aston och är grundare av Digital Project Manager. Alla är entusiastiska över agilt arbete, men hur får man det att fungera för flera team eller projekt? Hur snabbar man upp det, och var kan det gå fel? Och hur hindrar man det från att gå fel från första början? Fortsätt lyssna på dagens poddavsnitt för att förstå hur vi kan skala upp agil leverans och få agilt arbete att fungera i stor skala. Den här podden presenteras av Clarizen, ledaren inom programvara för projekt- och portföljhantering för företag. Besök clarizen.com för att läsa mer.

I dag har jag sällskap av Giovanni Asproni. Han är huvudkonsult på Zuhlke Engineering Limited. Jag uttalade förmodligen namnet helt fel, men han är baserad i London. Han är mjukvaruarkitekt, programmerare, coach och konsult med stor erfarenhet från många olika branscher, bland annat telekommunikation, bank, olja och gas. Han har deltagit på många konferenser och medverkat i flera böcker. Giovanni, tack för att du är med oss.

Giovanni:

Hej. Tack för att du bjöd in mig.

Ben Aston:

Och hur ska vi uttala namnet på ditt företag?

Giovanni:

Det är egentligen ett schweiziskt namn, så det ska uttalas Zuhlke.

Ben Aston:

Där ser man. Jag skulle aldrig ha fått det rätt.

Giovanni:

Jag uttalar det fel hela tiden också, så oroa dig inte.

Ben Aston:

Bra. Berätta lite om vad du arbetar med just nu. Vi pratade om det innan, men hur ser en vanlig dag ut för dig?

Giovanni:

En vanlig dag för mig är åtminstone nu ganska intensiv. I början av juni började jag i ett nytt projekt där jag faktiskt följer mina egna råd, vilket är mycket klokt. Efter ett uppdrag hos en stor kund till Zuhlke genomförde jag och några kollegor en utvärdering av ett mycket stort program. Vi talar om ungefär 500 personer och 57–60 team. Nu genomför vi en del av rekommendationerna, vilket i princip innebär att vi ger dem ett system för att samla in projekt- och programmått och hantera hela arbetet mycket bättre. Det är alltså ganska intensivt. Jag arbetar med tekniskt ledarskap och krav, rapporterar till alla ledningsnivåer hos kunden och skriver även en del kod när det behövs.

Ben Aston:

Berätta lite om utvärderingsprocessen. Jag tycker att det är intressant att man inte bara går in i ett företag och säger: ”Ni måste börja arbeta enligt Scrum”, och sedan försöker rulla ut det, utan att det först görs en utvärdering. Stämmer det?

Giovanni:

Ja.

Ben Aston:

Hur ser den ut?

Giovanni:

Vid en utvärdering försöker vi förstå vad som pågår. Vi pratar med människor, representanter för teamen och personer på alla ledningsnivåer och försöker förstå vad som faktiskt händer i verksamheten. Vi granskar också processerna, ser hur teamen arbetar, hur de skickar in kod och vilka kvalitetsåtgärder de använder. Vi pratar med ledningen för att förstå deras bild av hur det går. På så sätt skapar vi en bild av situationen. Stora projekt har många likheter, men detaljerna skiljer sig vanligtvis ganska mycket åt.

Ben Aston:

Och när det gäller era rekommendationer efter utvärderingen – hur olika är de från gång till gång när det blir dags att genomföra dem? Återkommer ni alltid till ungefär samma saker?

Giovanni:

Nej, det beror på vad vi hittar. Vissa saker tenderar att vara desamma, eftersom vi ofta gör samma misstag. När företag växer till mycket stora program – kanske 100 eller 200 personer, i det här fallet 500 – gör de det ofta för att försöka arbeta snabbare. Men vanligtvis har de inte de instrument som krävs för att förstå om det faktiskt ger någon fördel.

Ben Aston:

Vilka verktyg använder ni för att bedöma om den uppskalning som gjorts genom att lägga till resurser faktiskt fungerar?

Giovanni:

Vi tittar på flera saker. Vi försöker förstå om alla vet vad de ska göra och om alla drar åt samma håll. Man skulle bli förvånad över hur olika människor ofta uppfattar projektets mål. Vi tittar på användningen av mätetal: hur vet man att teamen faktiskt arbetar snabbare, med hjälp av verkliga data och inte bara magkänsla? Vi granskar även systemdesignen och arkitekturen och ser om de passar teamstrukturen. Kommunikation är också viktig. I stora projekt blir kommunikationskanaler ofta väldigt formella, vilket gör att människor får svårt att lösa problem snabbt.

Ben Aston:

Vilket är ditt viktigaste råd till någon som funderar på att börja arbeta agilt?

Giovanni:

Det viktigaste är att förstå och tydliggöra förväntningarna. När någon säger att de vill att ett projekt ska vara agilt bör man fråga: Vad menar ni? Vilket behov har ni? Vilket problem försöker ni lösa? Agilitet är inte målet. Det är ett medel för att nå ett eller flera mål. Många väljer agilt arbete för att de har hört att andra företag gör samma sak och levererar snabbt, men då missar man ofta poängen. Det handlar om att hantera och tydliggöra förväntningar.

Ben Aston:

Vad finns i din verktygslåda när du utvärderar och genomför agilt arbete?

Giovanni:

Ett mycket analogt verktyg jag använder är min anteckningsbok. När jag pratar med människor för att utvärdera ett projekt brukar jag inte ha en dator framför mig. Om man öppnar en bärbar dator skapar den en barriär. Att skriva i ett anteckningsblock känns mindre hotfullt. Det viktigaste fysiska verktyget jag har med mig är alltså en penna och en anteckningsbok.

När det gäller andra verktyg använder jag programvara för att föra över mina anteckningar. Jag använder Scapple. Det låter mig skriva ner saker och koppla ihop dem, utan att begränsa mig till en enkel trädstruktur. Jag skriver ner alla möjliga tankar. När man bedömer något är det också viktigt att inte bara lyssna på vad människor säger, utan att läsa av rummet. Man måste förstå om de är avslappnade eller spända och om de säger något som de själva inte är övertygade om.

Det är också viktigt att genomföra sådana samtal i en trygg miljö. När jag pratar med utvecklare om deras syn på projektet ser jag till att cheferna inte är med i rummet. Jag gör samma sak med cheferna. Även i företag som säger att alla kan uttrycka sina åsikter fritt är verkligheten ofta mer komplicerad. Trygghet är därför oerhört viktigt.

Ben Aston:

Har du något särskilt verktyg för att driva agila projekt?

Giovanni:

Det beror verkligen på sammanhanget. Om alla alltid arbetar på kontoret fungerar en whiteboard mycket bra. Om teamet är utspritt eller om människor arbetar både hemifrån och från kontoret är elektroniska verktyg bättre. Ett vanligt verktyg är Jira. Jag tycker inte särskilt mycket om det eftersom det är långsamt och har egna problem, men det fungerar bättre än en whiteboard när människor befinner sig på olika platser. För mig beror valet helt på sammanhanget.

Ben Aston:

Låt oss prata om ditt inlägg om hur man skalar upp agilt arbete. Det är välkänt att fler personer i ett programvaruprojekt inte nödvändigtvis ökar produktiviteten. Ofta sjunker produktiviteten när förvirring uppstår, människor blir osäkra på vad de arbetar med och varför, och integrationen blir svårare. Det måste finnas ett bättre sätt att få mer gjort.

Giovanni:

Det är viktigt att förstå skalning eftersom man förr eller senare stöter på det. Projekt tenderar att växa, särskilt i större företag. Mitt generella råd är dock: gör det inte. Försök först lösa den situation ni har. Varför vill ni skala upp? Är ni säkra på att ni kan göra det? Om ni inte har de grundläggande förutsättningarna på plats blir resultatet bara en större röra.

Det finns ett talesätt om att antalet personer i ett projekt bör vara det minsta av antalet personer man har och tiden man har. I allmänhet måste man först arbeta effektivt innan man växer.

Ben Aston:

När man talar om att skala upp agilt arbete verkar huvudbudskapet vara att hålla det så litet och resurssnålt som möjligt för att maximera effektiviteten och behålla tydligheten kring målet. Men måste alla team arbeta på samma sätt?

Giovanni:

En lösning som passar alla fungerar aldrig. I stora projekt har team olika behov, preferenser och arbetssätt. Samtidigt behövs en viss enhetlighet för att man ska kunna förstå vad som händer i hela projektet. Mitt förslag är att låta teamen arbeta på det sätt de föredrar, men att skapa gemensamma gränssnitt – särskilt för rapportering, framsteg och transparens. Annars kan det bli omöjligt för ledningen att förstå vad som pågår.

Ben Aston:

Hur ser bra respektive dålig skalning ut?

Giovanni:

Dålig skalning uppstår ofta när någon högt upp i ledningen bestämmer att allt går för långsamt och därför lägger fler personer på problemet. Ett annat exempel är kapacitetsbaserad planering: om arbetet motsvarar hundra personår anställer man hundra personer och förväntar sig att bli klar på ett år. Det fungerar inte riktigt så.

Man behöver rätt personer med rätt kompetens i teamen. Det bästa sättet att skala upp är att involvera teamen och de seniora tekniska personerna. Fråga dem: Kan ni arbeta med några fler personer? Behöver ni hjälp? Finns det arbete för fler personer? De som utför arbetet vet bäst om de behöver hjälp.

Ben Aston:

Vilket är det viktigaste för projektledare och andra personer som ska stödja teamet?

Giovanni:

Förstå vad teamet behöver från dig och fråga hur du kan hjälpa till. Utgå också från att människorna i projektet gör sitt bästa utifrån sitt sammanhang. Gissa inte vad de behöver – fråga dem. Projektledare behövs, särskilt i medelstora och stora projekt, men deras roll bör vara att göra programmerarna och resten av teamet mer effektiva, inte att tala om för dem vad de ska göra.

När teamet lämnar uppskattningar bör man inte be dem att ge en lägre uppskattning bara för att man inte gillar resultatet. Då ber man inte längre om en uppskattning, utan om ett åtagande. Ställ i stället genuina frågor: Varför tar det så lång tid? Kan du förklara? Varför kostar det så mycket? Om uppskattningen verkligen är den bästa möjliga måste projektledaren våga försvara teamet inför kunden.

Ben Aston:

Giovanni, tack så mycket för att du var med oss i dag.

Giovanni:

Tack så mycket. Det var ett nöje.

Ben Aston:

Vad tycker du? Har du försökt skala upp agilt arbete? Hur gick det? Vad fungerade och vad fungerade inte? Berätta i kommentarerna nedan. Om du vill lära dig mer eller komma vidare i ditt arbete kan du gå med i vår gemenskap genom ett DPM-medlemskap. Besök thedigitalprojectmanagement.com/membership för att få tillgång till vårt Slack-team, mallar, workshops, kontorstider, e-böcker och mer. Om du gillade dagens avsnitt får du gärna prenumerera och ta några minuter till att lämna en ärlig recension av DPM-podden på Apple Podcasts. Tack för att du lyssnade.