Slik får du smidig utvikling til å fungere med Metagility (med David Bishop fra Agile Worx)

Les transkripsjonen:

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

Ben Aston: Så la meg gjette: Du gjorde ting etter fossefallsmodellen, og det fungerte ikke. Deretter prøvde du smidig utvikling, og det fungerer heller ikke helt.

Så nå blander du og kombinerer. Du har en skje med smidig utvikling og en skje med fossefallsmodellen, og prøver å finne strøssel å legge på toppen. Fortsett å lytte til dagens podkast om metagility. Kanskje lærer du en ting eller to om hvordan en smidig spillebok kan brukes til å kombinere det beste fra begge verdener.

Takk for at du lytter. Jeg heter Ben Aston og er grunnlegger av The Digital Project Manager. Velkommen til DPM-podkasten. Vi har som mål å hjelpe prosjektledere med å lykkes og hjelpe mennesker som styrer prosjekter, med å levere bedre. Vi er her for å hjelpe deg med å ta prosjektarbeidet ditt til neste nivå. Besøk thedigitalprojectmanager.com for å lære mer om opplæringen og ressursene vi tilbyr gjennom medlemskap. Denne podkasten presenteres av Clarizen, lederen innen programvare for styring av virksomhetsprosjekter og -porteføljer. Besøk Clarizen.com for å lære mer.

I dag har jeg med meg David Bishop. Dr. David Bishop er teknolog, konsulent, forskningsentreprenør og instruktør med mer enn 25 års erfaring fra telekommunikasjon, transport, offentlig sektor og forsyningsvirksomhet. Han er administrerende direktør og grunnlegger av Agile Worx, LLC. Du kan besøke Agile-worx.com. Det er et selskap som tilbyr programvareverktøy for program- og prosjektstyring, opplæring og konsulenttjenester. Han er også forfatter av Metagility: Managing Agile Development for Competitive Advantage. Tusen takk for at du blir med oss i dag, David.

David Bishop: Takk for invitasjonen.

Ben Aston: Jeg vil gjerne gå inn på hele ideen om å bygge et rammeverk fra ingenting. Kan du fortelle litt om bakgrunnen din og hvordan du kom frem til at verden trenger et nytt rammeverk? Hvilken erfaring var det som førte deg dit?

David Bishop: Jeg har arbeidet med teknologiutvikling i rundt 25 år, hovedsakelig som systemarkitekt og systemingeniør, der jeg har utviklet løsninger med ny teknologi. Jeg har arbeidet innen IT, IATA, mobiltelefoni og telekommunikasjon. Som du nevnte tidligere, begynte jeg for rundt ti år siden å arbeide med et selskap som satset sterkt på industrielt tingenes internett. En av tingene de desperat forsøkte å gjøre, var å ta i bruk smidige metoder.

Ben Aston: Ja.

David Bishop: Grunnen var at kundene etterspurte det. De befant seg i en relativt ny teknologibransje. De forsøkte å integrere seg i denne bransjen, samtidig som mange konkurrenter utviklet ny teknologi for smarte strømnett med ulike former for radiofrekvenskommunikasjon.

De prøvde flere ganger å ta i bruk smidig utvikling fordi det var avgjørende å få produktene ut på markedet så raskt som mulig. De forsøkte hardt flere ganger, hentet inn mange høyt betalte konsulenter og mislyktes fullstendig, gang på gang. Jeg var en del av dette. Jeg hjalp organisasjonen med å utvikle produktene og med å ta i bruk smidig utvikling. Jeg tenkte at det måtte finnes en annen måte å gjøre dette på.

Hvorfor hadde så mange svært dyktige konsulenter vi hentet inn så store problemer? Det jeg innså, var at selv om smidig utvikling hadde hatt stor suksess og absolutt var en god idé, hadde den også svakheter. Blant annet hadde den utfordringer med distribuerte team, store team, svært komplekse utviklingsmiljøer og komplekse eller kompliserte produkter. Dette kan være store utfordringer for dem som prøver å ta i bruk smidige metoder i sin reneste form.

Ben Aston: Absolutt. Fortell litt om erfaringen din fra disse prosjektene. Jeg er nysgjerrig på hvordan dette fungerte i praksis. Jeg forstår det store bildet av utfordringene ved en smidig implementering, men hvordan så det ut i hverdagen? Hvordan skapte dette problemer i det daglige prosjektarbeidet? Hva var varselsignalene som fortalte deg at noe ikke var helt riktig?

David Bishop: Det var stor motstand i enkelte team. Jeg snakker ikke bare om litt motstand, men om svært sterk motstand og klager på at prosessen ikke fungerte og ikke kunne fungere. Grunnen var at dette var et miljø for innebygde systemer. Produktene de utviklet, var ikke bare programvare, men enheter. Enheter består vanligvis av innebygde systemer der maskinvare, fastvare og programvare utvikles i ulike spor, av ulike team, avdelinger eller selskaper.

På et tidspunkt må alle disse komponentene testes og lanseres som ett sammenhengende produkt. Det var dette selskapet gjorde. Dette gjør konteksten særlig interessant, fordi det er her mye av innovasjonen skjer i dag. For mange år siden, da manifestet først kom, handlet det meste om programvare. I dag handler det ikke bare om programvare.

Det handler om enheter, smarte enheter, smarte målere, smarte biler og mobiltelefonen din. Nesten alt er en innebygd systemenhet i dag. Derfor har selskaper som utvikler slike produkter, størst problemer med smidighet på grunn av kompleksiteten. I det daglige arbeidet prøvde konsulentene og vi å si: «Programvareteamene deres arbeider i toukersperioder og har daglige standup-møter, men vi får ikke maskinvareteamene til å gjøre det samme. De mener det ikke er nødvendig.»

Ben Aston: Ja.

David Bishop: Fastvareteamene hadde det samme problemet. De sa at dette ikke fungerte særlig godt for dem og ikke ga mening. Det stemte, fordi programvareteamene arbeidet mye raskere. De kunne utvikle i iterasjoner. Dette fungerte ikke på samme måte for maskinvareteamene. Produktene deres hadde en lanseringssyklus på 12 til 18 måneder.

Det tok lang tid å integrere et brikkesett i maskinvaren og teste det grundig. De fleste organisasjoner som utvikler innebygde systemer, befinner seg dessuten i bransjer med langt mer regulering, krav til etterlevelse, offentlig tilsyn og lignende.

Hvis du tenker på smarte målere og kraftforsyning, smarte biler eller et flyelektronisk system i et fly, kan du forestille deg at innsatsen er mye høyere på grunn av mulige tap av liv eller katastrofale feil. Slike systemer må vanligvis oppfylle langt strengere krav til kvalitet, ytelse og pålitelighet enn en vanlig programvareapplikasjon eller et netthandelsnettsted.

Ben Aston: Det stemmer.

David Bishop: De fleste bransjene som først og raskest tok i bruk smidige metoder, var bransjer der programvare sto sentralt.

Ben Aston: Hvis du vil lese mer om hvordan Metagility oppsto, kan du se innlegget på thedigitalprojectmanager.com. Der beskriver han hvordan dette utviklet seg gjennom historien om hvordan boken ble til. I stedet for å gå dypere inn i den historien vil jeg se nærmere på selve rammeverket og finne noen ideer vi kan bruke i prosjektene våre.

Mange av oss har prøvd elementer fra fossefallsmodellen. Vi arbeider sekvensielt fordi det virker mest fornuftig ut fra interessentene våre og måten oppdragene er strukturert på. Samtidig prøver vi smidige arbeidsformer: Vi arbeider samarbeidsorientert og iterativt. Vi plukker ulike deler og tar til oss filosofien om å iterere og levere verdi ofte.

La oss bygge, teste og lære. Men i praksis må vi likevel arbeide sekvensielt. Derfor vil jeg snakke om metagility og hvordan vi kan bruke det i prosjektene våre. Smidige metoder er populære og bredt anerkjent som den beste måten å håndtere programvareutvikling på, men hva smidig utvikling faktisk betyr, er åpent for tolkning.

Som vi har snakket om, representerer dette en reell utfordring for mange selskaper. Selv om en hybridtilnærming ikke alltid omtales som den beste løsningen, er den i praksis resultatet mange ender opp med når de forsøker å sette sammen ulike rammeverk og arbeidsformer innenfor organisasjonens begrensninger.

Maskinvare har lengre byggeprosesser enn programvare, mens mellomvare befinner seg et sted imellom. Utfordringen er å bygge og lansere ting i samme takt. Vi ser noe lignende i webutvikling: UX og design kan behandle ting raskt, mens utviklingen tar mye lengre tid.

Jeg vil derfor snakke om problemet du beskriver, og gå inn i ytelsen og begrensningene ved smidige metoder slik du omtaler dem i boken. Vi har snakket om takt og lanseringssykluser, men kan du utdype begrensningene ved dagens smidige metoder? La oss sammenligne på høyt nivå med SAFe og på et mer taktisk nivå med Scrum. Hva mener du er begrensningene ved disse metodene?

David Bishop: Når du snakker om rammeverk som Scrum og Kanban, finnes det også mange andre. Det finnes DSDM, LeSS og DA, altså Disciplined Agile, som nylig ble kjøpt av PMI. Det blir interessant å se hvordan det utvikler seg.

De forsøker å løse problemet fra ulike vinkler. Når det gjelder begrunnelsen for å ta i bruk smidige metoder, tror jeg mange misforstår litt. I dag er det mye fokus på å ta i bruk smidig utvikling fordi det får teamene til å samarbeide bedre, gjør deg til en bedre leder eller øker effektiviteten på en eller annen måte. Alt dette er bra.

Men det egentlige formålet med smidig utvikling handler om konkurranse og om å bli nummer én i markedet. Det smidige manifestet var inspirert av slank produksjon. Det var en programvaretilpasning av teknikker for slank produksjon fra Toyotas produksjonssystem, basert på en artikkel skrevet av to japanske forskere i 1979. Hva gjorde dette for Toyota? Det tok Toyota fra å være et selskap som produserte blikkbiler, til å bli en av verdens ledende bilprodusenter.

Hele ideen bak smidighet er å gjenskape denne typen suksess og bli nummer én i markedet. Mange av disse rammeverkene har etter min mening glemt dette. SAFe fokuserer på virksomhetsnivået, på et overordnet nivå, fordi det handler om å gjøre alle deler av selskapet smidige – enten det er HR-avdelingen eller juridisk avdeling.

Tanken er å gjøre alle deler av virksomheten og driften smidig i håp om at dette skal gi gradvise forbedringer over tid. Samtidig fokuserer det for mye på prosess. Det minner meg om de lange standardprosedyrene vi brukte for hovedrammesystemer og eldre systemer før brukerhistorier og levende dokumentasjon fra samarbeidsverktøy eksisterte. På mange måter minner SAFe om dette, fordi det produserer lange og kostbare prosedyrer for å håndtere ulike deler av virksomheten på en smidig måte. Det er ikke nødvendigvis noe galt med det, men på mange måter er det motsatsen til det smidig utvikling egentlig handler om.

Ben Aston: Ja.

David Bishop: Scrum fokuserer på teamnivået. Det er et sett med seremonier som hjelper deg med å styre teamene, og det er faktisk bra. Disse rammeverkene kan brukes sammen og trenger ikke å være i konflikt med hverandre. Du kan bruke Scrum, Kanban, metagility og SAFe i samme organisasjon.

Metagility fokuserer derimot på motoren for produktutvikling: produktet, produktstyringen, prosjektstyringen samt utviklings- og testteamene. Det handler om hvordan kravene utvikles og tolkes av teamene, hvordan produktet testes, hvordan du får det ut på markedet og hvordan du samarbeider med kunden slik at produktet oppfyller forventningene deres og holder høyest mulig kvalitet.

Hvis du vil vinne et dragrace og bygger en bil for å vinne, fokuserer du på motoren, girkassen og drivverket. Du bekymrer deg ikke for elektriske vinduer eller klimaanlegg. På samme måte mener jeg at enkelte andre rammeverk fokuserer for mye på periferien i stedet for på det som faktisk trengs for å bli nummer én i markedet.

Det er dette metagility gjør. Basert på forskningen fant vi et bestemt antall casestudier som hadde oppnådd det jeg kaller en super-smidig tilpasning. De hadde brukt smidighet til å bli nummer én i markedet. Metagility samler alt disse selskapene gjorde riktig og forsøker å gjøre det om til et produkt slik at andre organisasjoner kan oppnå de samme resultatene.

Ben Aston: Du beskriver det som en helhetlig tilnærming til å håndtere en ny og svært effektiv type identitet. Hva er egentlig metagility? Er leveranserammeverket en metode? Jeg har også sett det beskrevet som en spillebok. Hvordan vil du beskrive det?

David Bishop: Jeg vil beskrive det som et rammeverk. Det tar deg gjennom prosessen. Det første steget i metagility er for eksempel å avgjøre hvilken type smidig tilpasning du ønsker. Men la meg ta et steg tilbake. Boken begynner med å lære deg å tenke annerledes ved å bruke forskningsbaserte og vitenskapelige metoder til å ta forretningsbeslutninger.

Det finnes en hel del om dette i boken. Det finnes også en del om hvordan det smidige manifestet har endret seg basert på forskningsresultater. Når du kommer til delen om smidig transformasjon, er et av de første spørsmålene hvilken type tilpasning og implementering du bør bruke. Skal det være en ren smidig implementering? Skal det være en hybridtilnærming? Eller bør du holde deg til fossefallsmodellen? I enkelte tilfeller bør du kanskje gjøre det.

Det interessante er at det finnes mye fagfellevurdert forretningsforskning utført av eksperter på toppledernivå som kan hjelpe deg med å svare på dette. Mange konsulenter vet ikke engang at denne forskningen finnes, langt mindre bruker de den.

En forsker ved navn Barlow publiserte en artikkel om hvordan man kan ta denne beslutningen. Jeg har inkludert den i boken som et diagram. Den viser at valget av smidig implementering bør baseres på kompleksiteten i avhengighetene og gjensidige avhengighetene i produktet og organisasjonen, samt størrelsen på teamene.

Dette er svært viktig. I mange casestudier, for eksempel innen innebygde systemer med komplekse produkter og store, distribuerte team, finnes det svært mange avhengigheter og mye samspill mellom de ulike komponentene. Denne kompleksiteten betyr at du må gjøre noe litt annerledes. En ren smidig tilnærming på tvers av organisasjonen vil vanligvis ikke fungere. Du må gjøre noe annet. En hybridtilnærming kan gi fantastiske resultater dersom den brukes bevisst.

Hybridtilnærminger har ofte et negativt omdømme i bransjen. Når vi hører «hybrid», tenker vi gjerne på litt smidig utvikling, litt Scrum og litt fossefallsmodell, og i vårt eget hode ser vi for oss en mislykket implementering. Men det skjer ved et uhell. Det er det som skjer når en smidig transformasjon går galt.

Hvis du derimot har en bevisst tilnærming til en hybrid smidig implementering, bygger den på vitenskapelig begrunnelse og forskning, og du bruker en vitenskapelig forskningsmetode, vet du at organisasjonen beveger seg i riktig retning.

Ben Aston: Kan du beskrive hvordan rammeverket faktisk fungerer, og hvilke komponenter det består av, for dem som ikke har lest boken?

David Bishop: I boken har jeg et stort diagram som viser alle delene. Det er ganske interessant. I hovedsak begynner metagility med beslutningen om hvilken transformasjonstilnærming du bør velge.

Ben Aston: Og hvordan får man tilgang til betalingen?

David Bishop: Det gjør du ved å bruke Barlows diagram, som jeg nevnte tidligere og har tatt med i boken. Det er en forskningsartikkel som beskriver hvordan du kan ta denne beslutningen.

Tilnærmingen er i hovedsak en funksjon av teamenes størrelse, produktenes kompleksitet og graden av samspill eller gjensidige avhengigheter mellom teamene. Du må finne ut hvor mange avhengigheter og gjensidige avhengigheter du har mellom ulike team eller utviklingsspor for å lage produktene dine. Dette kompleksitetsnivået hjelper deg med å avgjøre om du bør velge en mer hybrid tilnærming i stedet for en ren smidig tilnærming.

Hva er så hybridtilnærmingen? Metagility inneholder trinn for hvordan du kan ta i bruk smidig utvikling på en standardisert måte. Den beskriver hva hybridtilnærmingen innebærer. Programvareteamene kan for eksempel ha toukers sprinter og daglige standup-møter, mens fastvareteamene kan ha 30-dagers sprinter og standup-møter én gang i uken.

Maskinvareteamene arbeider vanligvis med lengre sykluser på 12 til 18 måneder. De har kanskje ikke Scrum eller sprinter i det hele tatt. De kan arbeide mer etter fossefallsmodellen, men bruke teknikker som rask prototyping for å holde tritt med de andre teamene. Slik kan de gi dem plattformene eller testmaterialet de trenger for å fortsette uten blokkeringer.

Målet er å opprettholde flyten gjennom hele prosessen. Metagility beskriver hvordan dette ser ut, og hvordan ulike team tar i bruk smidige konsepter eller fossefallskonsepter. Fossefallsmodellens porter, altså trinnvis portstyring, tilpasses den hybride metoden og brukes som en form for kontroll og avstemming.

På denne måten kan portstyring fungere som kontroll for spor som beveger seg i ulik hastighet, og bidra til at de er synkroniserte. Metoden beskriver også hvilke måltall du bør bruke, og hvilke typer samhandling som bør brukes i smidig utvikling.

Vi hører mye om mennesker og samhandling fremfor verktøy og prosesser. Men ingen forteller deg alltid hva samhandling faktisk skal innebære. I metagility deler vi dette inn i seks tydelig definerte kategorier, basert på våre mest vellykkede casestudier. Vi beskriver hva samhandlingene er, hvordan de implementeres og hvordan de håndteres.

Dette gjør metagility til en detaljert spillebok for hvordan du håndterer en hybrid smidig implementering.

Ben Aston: Hvordan finner du riktig blanding av disse ulike smidige egenskapene? Folk reagerer vanligvis negativt på endring. Når vi prøver å øke smidigheten eller metagility i en organisasjon, hvordan avgjør vi hvilken blanding som er riktig? Hvordan vet vi når dagens situasjon er akseptabel, og når prosessen trenger evolusjon eller revolusjon?

David Bishop: Jeg tror det går tilbake til å bruke vitenskapelig metode og engasjert forskning. Det er slik du får det beste svaret. Altfor ofte bruker folk intuisjon, beste praksis eller intervjuer og konsensus når de prøver å løse denne typen problemer.

Det er ikke nødvendigvis noe helt galt med det, og vi tar slike beslutninger i næringslivet hele tiden. Men en smidig transformasjon, en DevOps-transformasjon eller en digital transformasjon er så krevende at det trengs sterkere medisin. Da er det på tide å tilkalle legen. Du kan behandle deg selv hjemme en stund, men til slutt blir du så syk at det ikke hjelper lenger.

Det var derfor jeg tidlig så et mønster av mislykkede forsøk. Mange av konsulentene eller ekspertene vi arbeidet med, behandlet dette som ethvert annet forretningsproblem: «Dette fungerte i det forrige selskapet mitt, så det må fungere her også.» Men det gjorde det ikke.

Forretningsforskning, særlig forskning innen datainformasjonssystemer, viser at slike miljøer er svært kontekstavhengige. De varierer mye fra selskap til selskap. Det som fungerer ett sted, fungerer ikke nødvendigvis overalt.

Hvis du bruker vitenskapelige metoder, for eksempel en fortolkende casestudie, kan du generalisere innenfor bestemte rammer. Du kan finne ut hva som kan overføres fra én organisasjon til en annen. Noe kan ikke overføres, men ved å gjennomføre nok casestudier og bruke fortolkende casestudier, etnografier og lignende metoder kan du finne ut hva som kan generaliseres fra selskap til selskap.

Ben Aston: Dette er altså ikke et rammeverk som passer for alle. Det er et tilpasningsbart rammeverk. Utfordringen med tilpasning er hvordan man vet om en implementering faktisk er metagility. Hvordan vurderer man om den er vellykket?

David Bishop: Det er et godt spørsmål. En del av metagility omfatter også teorien om smidig vortisitet. I tillegg til den hybride smidige tilnærmingen og funnene om samhandling, inneholder metagility teorien om smidig vortisitet, som kom ut av forskningen.

Dette bygger på en kvalitativ, grunnlagt teori-analyse. Konseptet smidig vortisitet svarer på hvor smidig du eller organisasjonen din er. Det er det store spørsmålet i denne bransjen. Vi gjør alt dette arbeidet for å gjennomføre en smidig transformasjon, men hvordan vet vi om det har gjort oss bedre?

Det har lenge manglet en måte å måle smidighet på. Det er dette smidig vortisitet gjør. Det er et ganske komplekst konsept som jeg går gjennom i detalj i boken. Det bygger på forskningsartikler, men svarer på spørsmålet og åpner dette området på en helt ny måte. Metagility gir dermed en måte å måle suksessen på.

Ben Aston: Hvilken effekt har du sett i organisasjonene som har implementert rammeverket ditt? Vi begynte med at målet er å bli den ledende aktøren i bransjen og mer konkurransedyktig. Hvilken effekt har du sett?

David Bishop: Mange av casestudiene våre var fra markedet for innebygde systemer. Etter min mening er dette det mest spennende og krevende markedet. Selskapene som tok i bruk metagility-konsepter, ble i de fleste tilfeller markedsledere, enten nummer én eller svært nær toppen.

Det betyr vanligvis større markedsandel og flere enheter ute hos kundene enn konkurrentene. Dette er særlig viktig i nye markeder, enten du er et stort selskap, en nyetablert virksomhet eller et stort selskap med en ny produktlinje og ny teknologi.

Nøkkelen til langsiktig overlevelse er å oppnå en kritisk markedsandel tidlig, før konkurrentene gjør det. Det betyr å ta i bruk innovativ teknologi og få den ut på markedet før alle andre.

Smidig utvikling er den beste måten å gjøre dette på, og jeg mener metagility er spesielt effektivt. De mest vellykkede casestudiene har redusert syklustiden så mye som mulig, samtidig som de har opprettholdt ønsket kvalitet og kundetilfredshet og fått innovative produkter ut på markedet før konkurrentene.

Ben Aston: Hvor har du sett at metagility ikke fungerer? Hvorfor har implementeringen støtt på problemer? Du snakker om betydningen av ledelsen i denne prosessen. Hvilke utfordringer har du sett?

David Bishop: Jeg tror det er to bestemte områder. Det første gjelder ledelsesforankring. Hvis du ikke har støtte fra ledelsen, kommer du ikke langt. Det er avgjørende ved enhver transformasjon, enten det er en digital transformasjon eller en smidig transformasjon.

Det starter på toppen, og ledelsen må forstå hva det handler om og hvilket mål dere forsøker å oppnå. Som analytiker må du legge frem en overbevisende forretningssak slik at ledelsen forstår hvordan dette påvirker bunnlinjen. Det handler ikke bare om å gjøre folk fornøyde, men om konkurransekraft, bedre resultater og høyere fortjeneste.

Den andre årsaken er dårlig kravstyring. Når vi gjennomfører en smidig transformasjon, fokuserer vi ofte på utviklings- og testteamene. Vi sørger for at Scrum-teamene er etablert og organisert, at de har toukers sprinter og standup-møter. Men vi fokuserer for lite på kravene og på forretningsanalytikerne, eller produkteierne.

Når en forretningsanalytiker blir produkteier, må vedkommende endre måten krav utvikles på i en smidig verden sammenlignet med fossefallsmodellen. Mange gjør ikke dette.

I fossefallsmodellen snakker man ofte om å samle inn krav. I en smidig verden samler du ikke inn krav – du utvikler krav. Det er en stor forskjell. Forretningsanalytikere prøver ofte å finne ut alt på forhånd fordi de er redde for å glemme noe. Men i en smidig verden finnes det alltid en ny arbeidsiterasjon.

Ben Aston: Riktig.

David Bishop: I fossefallsmodellen har du et tydelig definert omfang og en jerntriangel med omfang og kostnad. Du bekymrer deg for omfangsutglidning og prøver å samle inn alle kravene du tror du trenger, slik at du slipper å endre dem senere.

Forretningsanalytikere prøver derfor ofte å idémyldre frem krav i stedet for å samarbeide tett med kunden om å definere og utvikle dem. Resultatet er flere og flere krav. Det blir umulig å prioritere dem, lanseringene fylles opp, funksjoner som brukes lite blir bygget, og den tekniske gjelden løper løpsk.

Det er slik smidige transformasjoner mislykkes. Ethvert rammeverk, inkludert metagility, kan mislykkes hvis du ikke endrer måten du utvikler krav på.

Du må tenke annerledes om hvordan du bygger krav, samarbeide med kunden og bruke en ovenfra-og-ned-tilnærming til å bryte ned krav basert på kundens behov. Du må unngå idémyldring.

Ben Aston: Definitivt. Jeg har vært der mange ganger. Hvis du behandler kravprosessen som innsamling av krav, kan den vare i dager eller uker mens du går gjennom alle kravene. Det finnes alltid flere ting du kan legge til.

Hvis jeg er ny innen metagility, høres dette ut som en fornuftig måte å kombinere realitetene ved ulike utviklingstakter på, slik at teamene kan arbeide sammen. Hva er det første en organisasjon bør gjøre for å ta i bruk metagility og oppnå størst mulig effekt?

David Bishop: Jeg tror det første du må gjøre, er å etablere nye kunderelasjoner. Et av prinsippene i det smidige manifestet handler om kundesamarbeid fremfor kontraktsforhandling. Forskningen viser imidlertid at kontraktsforhandling og kundesamarbeid egentlig er to sider av samme prosess.

Forhandlingen skjer på alle nivåer i organisasjonen. Det er ikke bare jurister og ledere som sitter i et rom med kunden og signerer et dokument. Forhandlingen er en pågående prosess mellom interessenter gjennom hele selskapet: produktledere, produkteiere, prosjektledere, utviklingsteam, Scrum-team og mange interessenter hos kunden.

Du må etablere en samarbeidsorientert relasjon med kunden. Kunden må hjelpe deg med å teste, særlig hvis du vil få et innovativt produkt raskt ut på markedet. Kunden må være en del av prosessen.

Når vi arbeider med metagility og snakker med ledere, sier vi at det ikke handler om en plan, men om en visjon. De mest vellykkede casestudiene hadde en visjon for hvor de ville i markedet. De tok strategiske beslutninger om hvilke kunder de skulle arbeide med, og hvilke kunder de ikke skulle arbeide med.

De tok ikke imot enhver kunde som kom deres vei bare for å tjene mest mulig penger. Noen kunder måtte avvises fordi de ikke var villige til å delta i prosessen og være en samarbeidsorientert kunde.

Det første steget er derfor sannsynligvis å finne de riktige kundene, etablere et sterkt samarbeid og finne ut hvilken visjon du har for hvor du vil.

Ben Aston: Det er kloke råd. Vi kan så ofte tenke at vi bare skal ta imot det som kommer inn døren. Men hvis vi virkelig vil levere verdi til sluttbrukere og kunder, trenger vi en samarbeidsmodell som oppmuntrer til samarbeid.

Vi må etablere tillit, slik at vi kan si: «Vi vet ikke nøyaktig hva vi skal gjøre, men vi skal samarbeide om dette for å oppnå best mulig resultat.» Det vil til syvende og sist gi kunden bedre verdi enn å diskutere kontraktens svart-hvite formuleringer.

Tusen takk, David, for at du ble med oss og snakket om metagility. Dette har vært svært nyttig.

David Bishop: Tusen takk.

Ben Aston: Jeg vil gjerne vite hva du synes. Har du lest boken metagility ? Fortell oss gjerne hva du synes i kommentarfeltet. Hvis du ikke har lest den ennå, legger vi en lenke i transkripsjonen.

David, hvis folk vil lære mer om metagility og boken din, hvor kan de finne mer informasjon?

David Bishop: Du kan søke på ordet metagility, så får du mange ressurser. Du kan også besøke Agileworx.com (Agile-worx.com) for å se på selskapet vårt og det vi forsøker å oppnå.

Vi tilbyr også kurs. Kursene holdes vanligvis fysisk, men de er utsatt til høsten. Fra august til november håper vi fortsatt å kunne holde dem på stedet, men vi kan gå over til enkelte virtuelle kurs.

Du finner den nyeste timeplanen på metagility.technology. Der kan du se det oppdaterte programmet og melde deg på kurs. Du kan også kontakte meg på David@agileworx.com (Agile-worx.com). Jeg hører alltid gjerne fra folk og sjekker e-post hele tiden.

Ben Aston: Flott. Tusen takk, David. Hvis du vil lære mer og komme videre i arbeidet ditt, kan du bli med oss. Bli med i fellesskapet vårt gjennom DPM-medlemskapet på thedigitalprojectmanager.com/membership. Da får du tilgang til Slack-teamet vårt, der vi diskuterer temaer som dette, samt maler, verksteder, spørretimer, kontortid, e-bøker og mer.

Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com. Til neste gang: Tusen takk for at du lyttet.