Slik skalerer du smidig utvikling (med Giovanni Asproni fra Zuhlke Engineering Limited)

Les transkripsjonen:

Vi prøver ut transkripsjon av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Ben Aston:

Velkommen til DPM-podkasten, der vi går lenger enn teori for å gi råd som fungerer når man skal lede bedre digitale prosjekter. Takk for at du lytter. Jeg heter Ben Aston og er grunnleggeren av Digital Project Manager. Alle er begeistret for smidig utvikling, men hvordan får man det til å fungere på tvers av flere team eller prosjekter? Hvordan kan man øke hastigheten, hvor kan det gå galt, og hvordan hindrer man at det går galt i utgangspunktet? Fortsett å lytte til dagens podkast for å forstå hvordan vi kan skalere smidig leveranse, og hvordan vi kan få smidig utvikling til å fungere i stor skala. Denne podkasten presenteres av Clarizen, lederen innen programvare for virksomhetsomfattende prosjekt- og porteføljestyring. Besøk clarizen.com for å finne ut mer.

I dag har jeg med meg Giovanni Asproni. Han er hovedkonsulent hos Zuhlke Engineering Limited. Jeg uttaler sikkert navnet feil, men han holder til i London. Han er programvarearkitekt, programmerer, coach og konsulent, med lang erfaring fra mange ulike bransjer, blant annet telekommunikasjon, bank, olje og gass. Han har deltatt på mange konferanser og bidratt til flere bøker. Giovanni, takk for at du blir med oss.

Giovanni:

Hei. Takk for invitasjonen.

Ben Aston:

Og hvordan uttaler vi navnet på firmaet ditt?

Giovanni:

Det er egentlig et sveitsisk navn, så det skal uttales Zuhlke.

Ben Aston:

Der har vi det. Jeg hadde ikke klart å uttale det riktig.

Giovanni:

Jeg uttaler det feil hele tiden selv, så ikke bekymre deg.

Ben Aston:

Greit. Fortell oss litt om hva du jobber med nå. Vi snakket så vidt om det tidligere, men hvordan ser en vanlig dag ut for deg?

Giovanni:

En vanlig dag for meg er i hvert fall for tiden ganske travel. I begynnelsen av juni startet jeg på et nytt prosjekt der jeg faktisk følger mine egne råd, noe som er svært klokt. Etter et oppdrag hos en stor Zuhlke-kunde gjennomførte jeg og noen kolleger en vurdering av et svært stort program. Vi snakker om rundt 500 personer og 57–60 team. Nå gjennomfører vi deler av anbefalingene, i hovedsak ved å gi dem et system for å samle inn prosjekt- og programmatriser slik at hele arbeidet kan styres bedre. Det er ganske travelt. Jeg arbeider med teknisk ledelse og krav, rapporterer til alle ledelsesnivåer hos kunden og skriver også litt kode når det passer.

Ben Aston:

Fortell oss litt om vurderingsprosessen. Jeg synes det er interessant at man ikke bare går inn i et selskap og sier «Hei, dere må begynne med Scrum» og forsøker å rulle det ut, men at det inngår en vurdering først.

Giovanni:

Ja.

Ben Aston:

Hvordan ser den ut?

Giovanni:

Når vi gjennomfører en vurdering, prøver vi først og fremst å forstå hva som skjer. Vi snakker med personer som representerer teamene og med ledere på alle nivåer, og prøver å finne ut hva som faktisk skjer i praksis. Vi gjennomfører også kodegjennomganger, ser på prosessene teamene følger, hvordan de legger inn kode i systemet, og hva de gjør for å sikre kvalitet. Vi snakker med ledelsen for å forstå deres syn på hvordan ting fungerer. På den måten lager vi et bilde av situasjonen. Store prosjekter har ofte mange likheter, men detaljene er vanligvis svært forskjellige.

Ben Aston:

Når det gjelder anbefalingene dine etter slike vurderinger av store selskaper: Hvor forskjellige er anbefalingene fra gang til gang når de skal gjennomføres? Ender det alltid opp med omtrent det samme?

Giovanni:

Nei, det avhenger av hva vi finner. Noen ting går igjen, fordi vi ofte gjør de samme feilene på de samme måtene. Når selskaper skalerer opp til svært store programmer – kanskje 100 eller 200 personer, i dette tilfellet 500 – gjør de det gjerne for å øke hastigheten. Men som regel har de ikke verktøyene på plass for å forstå om det de gjør faktisk gir noen fordel.

Ben Aston:

Du nevner verktøy. Hvilke verktøy bruker du for å vurdere om oppskaleringen, der de har lagt til flere ressurser, faktisk fungerer?

Giovanni:

Vi ser på flere ting. Vi undersøker om alle forstår hva de skal gjøre, og om de trekker i samme retning. Det er overraskende hvor ofte ulike personer har ulike oppfatninger av prosjektets mål. Vi ser også på bruken av måltall. Når man har team og personer, hvordan vet man at de faktisk arbeider raskere? Ikke basert på følelser, men på reelle data. Vi vurderer systemdesignet og om arkitekturen passer med teamstrukturen. I store prosjekter blir kommunikasjonskanalene ofte stivnet til svært formelle strukturer, og da blir det vanskelig å løse problemer raskt.

Ben Aston:

Før vi går videre til artikkelen din, vil jeg gjerne spørre om din egen erfaring. Hva er den største feilen du kan fortelle om fra arbeidet med å skalere smidig utvikling eller fra smidige team? Hva lærte du, og hvordan kan vi unngå å gjøre det samme?

Giovanni:

En feil skjedde ganske nylig. Det var ikke en gigantisk tabbe, men det gikk galt på flere måter. Jeg ble sendt inn for å løse en situasjon der vi hadde problemer med noen av våre team og noen av kundens team. Hos Zuhlke arbeider vi ofte inne i kundens organisasjon. Mange ting gikk bra, men en politisk situasjon i selskapet førte til at prosjektet ble avsluttet av feil grunner. Lærdommen er at selv om vi tror vi forstår hva som skjer, ser vi ikke alltid alt som kommer. Det oppsto interne maktkamper hos kunden, og vi havnet i kryssilden.

Ben Aston:

Politikk er alltid viktig, selv om vi helst skulle ønske at det ikke var slik.

Giovanni:

Politikk er viktig. Politikk i seg selv er verken bra eller dårlig. Når mennesker arbeider sammen, oppstår det alltid politikk. Utfordringen er hvordan man bruker den.

Ben Aston:

Hva er ditt viktigste råd til noen som vurderer å begynne å arbeide smidig, men som kanskje ikke vet helt hva det innebærer?

Giovanni:

Det viktigste er å forstå og avklare forventningene. Når folk sier at de vil at prosjektet skal være smidig, må man spørre: Hva mener dere? Hva er behovet? Hvilket problem forsøker dere å løse? Smidighet er ikke målet; det er et middel for å nå ett eller flere mål. Mange bestemmer seg for å bli smidige fordi de har hørt at andre selskaper gjør det og leverer fantastiske resultater raskt. Da bommer de ofte på poenget. Det handler om forventningsstyring og avklaring.

Ben Aston:

Målet er ikke prosessen, men å levere verdi mer effektivt og skape resultater, i stedet for å fokusere på hvordan man kommer dit.

Giovanni:

Ja.

Ben Aston:

Hvilke verktøy bruker du når du vurderer og gjennomfører endringer og hjelper team med å bli mer smidige?

Giovanni:

Et veldig analogt verktøy jeg bruker, er notatboken min. Når jeg snakker med folk for å vurdere et prosjekt, sitter jeg vanligvis ikke med teknologi foran meg. Hvis du åpner en bærbar datamaskin, skaper den en barriere mellom deg og den andre personen. Det er mindre truende å skrive i en notatbok. Det viktigste utstyret jeg har med meg, er derfor en penn og en notatbok.

Jeg bruker også programvare. Jeg kopierer notatene mine inn i Scapple. Det lar meg skrive ned ting og koble dem sammen uten å begrense meg til et enkelt tre. Det er mer som en busk eller en skog. Jeg skriver ned alle slags tanker. Når man vurderer noe sammen med mennesker, er det ikke nok å lytte til ordene deres. Man må også lese rommet: Er de avslappet eller anspente? Sier de kanskje noe de ikke selv tror på? Det er viktig å observere menneskene.

Det er også viktig å gjennomføre slike samtaler i et trygt miljø. Hvis jeg snakker med utviklere om hvordan de opplever prosjektet, gjør jeg det tydelig at jeg ikke vil ha ledere i rommet. Jeg gjør det samme med lederne. Selv i selskaper som sier at alle står fritt til å uttrykke meningene sine, er virkeligheten mer komplisert. Trygghet er svært viktig.

Ben Aston:

Hva med programvareverktøy for å gjennomføre smidige prosjekter? Har du et prosjektstyringsverktøy du foretrekker?

Giovanni:

Det avhenger helt av konteksten. Hvis alle alltid er på kontoret, fungerer en tavle svært godt. Man kan ta bilder av tavlen hvis man trenger å dele noe på nettet. Hvis teamet ikke er distribuert, men folk arbeider hjemmefra innimellom, er elektroniske verktøy bedre. Et vanlig verktøy er Jira. Jeg er ikke spesielt glad i det fordi det er tregt og har sine egne problemer, men det er bedre enn en tavle når folk befinner seg på ulike steder. For meg avhenger valget helt av konteksten.

Ben Aston:

Finnes det andre verktøy du nylig har oppdaget?

Giovanni:

Egentlig ikke. Jeg leter ikke etter spesielle verktøy. Ofte er det beste man kan gjøre å holde ting enkelt. Jeg anbefaler det enkleste verktøyet som løser oppgaven.

Ben Aston:

La oss snakke om artikkelen din om hvordan man skalerer smidig utvikling. Det er velkjent at flere personer i et programvareprosjekt ikke nødvendigvis øker produktiviteten. Ofte faller produktiviteten når forvirring oppstår, folk blir usikre på hva de arbeider med og hvorfor, og integrasjon blir vanskelig. Det må finnes en bedre måte å få mer gjort på. Artikkelen din beskriver regler, skaleringsloven, forutsetninger for skalering og hensyn ved teamstruktur.

Hvorfor er dette viktig? Hvorfor bør vi bry oss om å skalere smidig utvikling?

Giovanni:

Det er viktig å forstå skalering fordi man før eller senere møter det. Prosjekter vokser ofte, særlig i store selskaper. Min generelle anbefaling er: Ikke skaler. Først må du få orden på situasjonen du har. Hvorfor vil du skalere? Hva er årsaken? Er du sikker på at du kan gjøre det? Hvis du ikke oppfyller forutsetningene, får du bare et større rot. Alle de store prosjektene jeg har sett, inkludert et med 1300 personer, hadde store problemer. De kunne ha gjort en bedre jobb med en brøkdel av bemanningen. Før man vokser, må man arbeide effektivt fra starten.

Ben Aston:

Når man snakker om å skalere smidig utvikling, virker hovedbudskapet å være at man bør holde det så lite og slankt som mulig for å maksimere effektiviteten, beholde klarheten i målet og sikre at alle leverer verdi. Men når man først skalerer, finnes det da én løsning som passer alle, eller trenger ulike team forskjellige prosesser og strukturer?

Giovanni:

Én løsning som passer alle, fungerer aldri. Når man har 500 eller 1000 personer og mange team, vil teamene uunngåelig ha ulike behov, preferanser og arbeidsmåter. Samtidig må det finnes et visst nivå av ensartethet, ellers blir det umulig å forstå hva som skjer i prosjektet som helhet. Mitt forslag er å la teamene arbeide på den måten de foretrekker, men sørge for felles grensesnitt, særlig for rapportering, fremdrift og åpenhet. Det må finnes en konsekvent måte å formidle status på tvers av teamene.

Ben Aston:

Hvordan ser rapporteringen ut i praksis?

Giovanni:

Det finnes mange måter. I stedet for å påtvinge Scrum på hvert eneste team kan enkelte team arbeide mer flytbasert, for eksempel fordi de håndterer hendelsesstyrt arbeid. Et team som både utvikler og gir brukerstøtte, kan ikke love at det ikke skal håndtere henvendelser på et par uker. Når en bruker ringer, må teamet gjøre noe. Slike team har andre behov, men på et overordnet nivå kan man fokusere på historier, funksjoner, epik­er eller andre måleenheter. Man kan også analysere hva som skjer i koden og hvordan teamene påvirker eller forstyrrer hverandre.

Ben Aston:

Hva kjennetegner god og dårlig skalering?

Giovanni:

Dårlig skalering skjer ofte når noen høyt oppe i ledelsen bestemmer at alt går for sakte og kaster flere personer på problemet. Et annet eksempel er planlegging basert på kapasitet: «Dette er et prosjekt på hundre personår, så vi ansetter hundre personer og blir ferdige på ett år.» Slik fungerer det ikke. Samtidig handler ikke god skalering om å la alt være som det er. Man må ha riktige personer med riktige ferdigheter i teamene. Den beste måten å starte på er å involvere teamene og erfarne tekniske personer: Kan dere arbeide med noen flere? Trenger dere hjelp? Har dere arbeid til flere? De som utfører arbeidet, vet best om de trenger hjelp.

Ben Aston:

Så det handler først og fremst om bevissthet.

Giovanni:

Ja. Det er også viktig at folk forstår hvilken rolle de faktisk har. I programvareprosjekter er programmerere og brukere uunnværlige. Det betyr ikke at alle andre er unyttige, men roller som prosjektledere, konsulenter og testere er avhengige av prosjektet. Oppgaven deres er å gjøre programmererne mer effektive. Som prosjektleder bør du derfor ikke bare fortelle teamet hva det skal gjøre, men spørre: Hva trenger dere fra meg? Hva kan jeg gjøre for at dere skal lykkes?

Ben Aston:

Hvordan ser den beste skaleringen du har sett, ut?

Giovanni:

Jeg har bare sett det fungere svært godt én eller to ganger, og da i mindre systemer. Det var situasjoner der folk visste hva de gjorde, forsto plassen sin i helheten og visste hvem de skulle snakke med i andre team. Det fantes noe formell kommunikasjon, men mye uformell kommunikasjon mellom personer som visste hva de holdt på med. De store prosjektene jeg har sett, hadde store problemer og kunne ha klart seg med langt færre mennesker. De var skalert av feil grunner.

Ben Aston:

Hva synes du om ferdigdefinerte rammeverk for smidig utvikling i stor skala?

Giovanni:

Noen ganger fungerer de, men bare når konteksten passer. Jeg liker ikke ferdige rammeverk fordi de forsøker å presse prosjektet inn i sin egen form. Alle rammeverk forutsetter en bestemt kontekst. Hvis konteksten din ikke passer, får du en interessant tid. Rammeverkene fokuserer ofte mye på struktur, men ikke nok på hva mennesker faktisk gjør fra dag til dag. De kan også gi ledelsen en behagelig følelse av kontroll uten å hjelpe dem som faktisk utfører arbeidet.

Ben Aston:

Jeg er enig i at det samme kan sies om Scrum. Et rammeverk forutsetter en kontekst, og konteksten må være til stede for at det skal fungere. Det er lett for ledelsen å tenke at løsningen er å innføre Scrum fordi alt står skrevet ned. Men det tar ikke nødvendigvis hensyn til teamet, prosjektet eller kunden. Vi bør heller utvikle en prosess som passer vårt team, vårt prosjekt, vår kunde og begrensningene våre. Å følge reglene betyr bare at du følger rammeverket. Det betyr ikke at du leverer verdi bedre, raskere eller mer effektivt.

Giovanni:

Jeg er enig. Da jeg først introduserte ekstrem programmering i et team, ble det presentert som en samling praksiser. Vi ble enige om målene våre, begynte i det små med én eller to praksiser som ga verdi, lærte av dem og bygde videre. Det er viktig når et rammeverk inneholder mange ting som må brukes samtidig. Man kan bli overveldet av alt man må lære. Ideelt sett bør man begynne med et lite team, lære underveis og vokse på en ryddig måte. Vi mennesker kan ikke lære for mye samtidig.

Ben Aston:

Hvis et rammeverk plutselig blir påtvunget, kan folk utføre aktivitetene uten å forstå hvorfor. Da skaper man bare merarbeid og en fasade av smidig arbeid, mens folk egentlig fortsetter som før.

Giovanni:

Ja, det ser jeg hele tiden. Folk gjennomfører statusmøter uten at noen lytter, eller retrospektiver blir klagekonkurranser uten oppfølging. De utfører aktivitetene uten å forstå hensikten eller hvordan de kan skape verdi. Mange selskaper kopierer også modeller de har sett andre bruke, selv om de opprinnelige selskapene hele tiden tilpasser prosessene sine. Den første av de seks enkle reglene er: Før du gjør endringer, må du vite hva menneskene dine faktisk gjør. Ikke anta at de arbeider på en bestemt måte. Gå og se, forstå vanskelighetene og problemene, og skap deretter noe som gir mening for organisasjonen.

Ben Aston:

Hva er det viktigste prosjektledere og andre støttefunksjoner kan gjøre for å hjelpe teamet uten å stå i veien?

Giovanni:

Det viktigste er å forstå hva teamet trenger fra deg. Spør hvordan du kan hjelpe. Prosjektledelse er viktig, særlig i mellomstore og store prosjekter. Det er ikke slik at man kan fjerne prosjektledere og tro at alt ordner seg. Jeg anbefaler også at prosjektledere antar at menneskene på prosjektet gjør sitt beste innenfor sin kontekst. Ikke gjett hva folk tenker; spør dem. Da finner du mange måter å hjelpe på. Utviklere ønsker ofte ikke å arbeide med budsjetter, tidsplaner og administrasjon. Det er viktig arbeid, men noen må ta ansvar for det.

Ben Aston:

Ingen ønsker å være alene ansvarlig for budsjettet, tidsplanen eller arbeidsbeskrivelsen. Det er nyttig å høre at dette også hører hjemme i samtaler om smidig utvikling. Kunden vil vite når prosjektet leveres, hva det koster og hva de får.

Giovanni:

Derfor er jeg skeptisk til mange samtaler om «ingen estimater». Kundene ønsker å vite dette. Når prosjektledere skal gi tidsplaner eller prognoser, bør de be dem som utfører arbeidet om estimatene. Ikke be dem gi et lavere estimat bare fordi du ikke liker tallet. Hvis det virker for langt eller for dyrt, still spørsmål: Hvorfor vil det ta så lang tid? Kan du forklare? Hvorfor er det så dyrt? Men spørsmålene må være oppriktige. Hvis estimatet faktisk er det beste estimatet, må du ha mot til å forsvare teamet overfor kunden. Teamet vil sette pris på det.

Ben Aston:

Det er viktig at prosjektledere ikke bare fordeler et budsjett ovenfra og ned. Estimater må kommuniseres som estimater: Vi tror vi kan levere dette innen denne tiden, men teknologien er kompleks. Vi bør også stille gode spørsmål når et estimat virker stort, bryte arbeidet ned i mindre deler og forstå hvorfor utvikleren har kommet frem til tallet. Prosjektlederens rolle i et smidig miljø handler i stor grad om kommunikasjon – å skape klarhet mellom team, kunder og interessenter om visjon, retning, verdi, tid, kostnad og omfang.

Takk for at du ble med oss i dag, Giovanni.

Giovanni:

Tusen takk. Det var en glede.

Ben Aston:

Hva synes du? Har du prøvd å skalere smidig utvikling? Hvordan gikk det? Hva fungerte, og hva fungerte ikke? Fortell oss i kommentarfeltet. Hvis du vil lære mer eller komme videre i arbeidet ditt, kan du bli med i fellesskapet vårt gjennom DPM-medlemskap. Gå til thedigitalprojectmanagement.com/membership for tilgang til Slack-teamet vårt, maler, workshop­er, kontortid, e-bøker og mer. Hvis du likte det du hørte i dag, kan du abonnere. Bruk et par minutter på å legge igjen en ærlig omtale av DPM-podkasten på Apple Podcasts. Takk for at du lyttet, og på gjensyn.