Så får du agilitet att fungera med metagilitet (med David Bishop från Agile Worx)

Läs transkriberingen:

Vi testar att transkribera våra poddavsnitt med hjälp av ett program. Ursäkta eventuella stavfel eftersom boten inte har rätt 100 % av tiden.

Ben Aston: Så låt mig gissa: du arbetade enligt vattenfallsmodellen, det fungerade inte, och sedan provade du agilt – och det fungerar inte riktigt heller.

Så nu blandar du och matchar. Du har en skopa agilitet och en skopa vattenfall och försöker hitta lite strössel att lägga ovanpå. Fortsätt lyssna på dagens poddavsnitt om metagilitet. Du kanske lär dig ett och annat om hur en agil handbok kan användas för att kombinera det bästa från två världar.

Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager. Välkommen till DPM-podden. Vi har som mål att hjälpa projektledare att lyckas och att hjälpa personer som leder projekt att leverera bättre. Vi vill hjälpa dig att ta ditt projektarbete till nästa nivå. Besök thedigitalprojectmanager.com för att läsa mer om den utbildning och de resurser vi erbjuder genom medlemskap. Den här podden presenteras av Clarizen, ledande programvara för projekt- och portföljhantering i företag. Besök Clarizen.com för att läsa mer.

I dag har jag sällskap av David Bishop. Dr David Bishop är teknolog, konsult, forskningsentreprenör och utbildare med mer än 25 års erfarenhet inom telekom, transport, offentlig sektor och samhällstjänster. Han är vd och grundare av Agile Worx, LLC. Du kan läsa mer på Agile-worx.com. Det är ett företag som tillhandahåller programvaruverktyg, utbildning och konsulttjänster för program- och projektledning. Han är också författare till Metagility: Managing Agile Development for Competitive Advantage. Tack så mycket för att du är med oss i dag, David.

David Bishop: Tack för att jag fick komma.

Ben Aston: Jag vill gå in på hela idén om att bygga ett ramverk från grunden. Kan du berätta lite om din bakgrund och hur du kom fram till att världen behövde ett nytt ramverk? Vilka erfarenheter ledde dig dit?

David Bishop: Jag har arbetat med teknikutveckling i ungefär 25 år, främst som systemarkitekt och systemingenjör, där jag utvecklat lösningar med ny teknik. Jag har arbetat inom IT, IATA, mobiltelefoni och telekom. Som du nämnde började jag för ungefär tio år sedan arbeta med ett företag som satsade stort på industriellt sakernas internet. En av de saker de desperat försökte göra var att införa agila metoder.

Ben Aston: Just det.

David Bishop: Anledningen var att kunderna efterfrågade det. Företaget befann sig i en relativt ny teknikbransch och försökte integrera sig i den. Det fanns många konkurrenter som utvecklade ny teknik för smarta elnät med olika typer av radiofrekvenskommunikation.

De försökte flera gånger införa agilt arbetssätt eftersom det var avgörande för att få ut produkterna på marknaden så snabbt som möjligt. De försökte hårt, tog in många dyra konsulter och misslyckades gång på gång. Jag var en del av detta och hjälpte organisationen att utveckla produkterna och att införa agilitet. Jag tänkte att det måste finnas ett annat sätt.

Varför hade så många mycket smarta konsulter som vi tog in så stora problem? Jag insåg att även om agilitet hade haft stora framgångar och verkligen var en bra idé, hade den också vissa begränsningar. Den hade bland annat problem med distribuerade team, stora team, mycket komplexa utvecklingsmiljöer och komplexa produkter. Det kan vara stora utmaningar för personer som försöker införa agila metoder i sin renaste form.

Ben Aston: Absolut. Berätta lite om din erfarenhet från de projekten. Jag förstår den övergripande bilden av utmaningarna med en agil implementering, men hur såg det ut i vardagen? Hur påverkade det det dagliga projektarbetet? Vilka var varningssignalerna som fick dig att förstå att något inte stod rätt till?

David Bishop: Det fanns ett enormt motstånd hos vissa team. Det var inte bara lite motstånd, utan mycket hårt motstånd och klagomål på att processen inte fungerade och inte kunde fungera. Orsaken var att det handlade om en miljö för inbyggda system. Eftersom företaget utvecklade IoT-produkter och industriella IoT-produkter var de inte bara programvara, utan fysiska enheter. Enheter består vanligtvis av inbyggda system där hårdvara, fast programvara och programvara utvecklas i olika spår, av olika team, avdelningar eller ibland företag.

Men till slut måste alla tre komponenterna testas och lanseras som en sammanhängande produkt. Det var det företaget gjorde. Det är också det som gör sammanhanget så intressant i dag, eftersom det är där mycket av innovationen sker. När manifestet först kom handlade det huvudsakligen om programvara. I dag handlar det inte bara om programvara.

Det handlar om enheter, smarta enheter, smarta mätare, smarta bilar och mobiltelefoner. I princip allt är en enhet med inbyggda system i dag. Företag som utvecklar sådana produkter har därför ofta störst problem med agilitet på grund av komplexiteten. I vardagen försökte vi tillsammans med konsulterna säga: ”Era programvaruteam arbetar i tvåveckorsintervall och har dagliga avstämningar, men vi får inte hårdvaruteamen att göra samma sak. De tycker inte att det är nödvändigt.”

Ben Aston: Just det.

David Bishop: Fastvaruteamen hade samma problem. De sade att det inte fungerade särskilt bra för dem och att det inte var logiskt. Och det stämde, eftersom programvaruteamen arbetade mycket snabbare. De kunde utveckla i iterationer, medan hårdvaruteamen inte arbetade på det sättet. Deras produkter hade en lanseringscykel på ungefär 12–18 månader.

Det tog helt enkelt lång tid att integrera ett kretschip i hårdvaran och testa det ordentligt. Dessutom verkar de flesta organisationer som utvecklar inbyggda system inom branscher med betydligt mer reglering, regelefterlevnad och statlig tillsyn.

Tänk på smarta mätare och energibolag, smarta bilar eller flygelektronik i ett flygplan. Riskerna är mycket större när människoliv kan gå förlorade eller när katastrofala fel kan inträffa. Därför måste de vanligtvis hålla en betydligt högre nivå när det gäller kvalitet, prestanda och tillförlitlighet än en vanlig programvara eller e-handelswebbplats.

Ben Aston: Det låter rimligt.

David Bishop: De flesta branscher som tidigt och snabbt tog till sig agila metoder var de där agilitet var enklare att införa.

Ben Aston: Om du vill läsa mer om Metagilitys ursprung kan du besöka inlägget på thedigitalprojectmanager.com. Där beskrivs hur idén utvecklades och hur boken skapades. I stället för att gå djupare in på den historien vill jag fokusera på själva ramverket och se om vi kan hitta några insikter som vi kan tillämpa i våra projekt. För många av oss är detta mycket relevant. Vi har kanske provat delar av vattenfallsmodellen och arbetar sekventiellt eftersom det verkar mest logiskt utifrån våra intressenter och hur våra uppdrag är strukturerade. Samtidigt använder vi agila arbetssätt: vi samarbetar och arbetar iterativt.

Vi plockar alltså olika delar och har tagit till oss filosofin: låt oss iterera och leverera värde ofta. Låt oss bygga, testa och lära. Men i praktiken måste vi ändå arbeta sekventiellt. Därför vill jag prata om metagilitet och hur vi kan tillämpa det i våra projekt. Agila metoder är populära och allmänt accepterade som det bästa sättet att hantera programvaruutveckling, men vad agil metod faktiskt betyder är öppet för tolkning.

Som vi har diskuterat innebär detta en verklig utmaning för många företag. Därför blir ett hybridarbetssätt, även om det inte alltid hyllas som den bästa lösningen, i praktiken resultatet för många som försöker kombinera olika ramverk och arbetssätt med organisationens begränsningar. Hårdvara kan ha en längre byggcykel än programvara, medan mellanprogramvara hamnar någonstans däremellan.

Vi har samma utmaning inom webbutveckling. UX och design kan arbeta snabbt, medan utvecklingen tar mycket längre tid. Jag vill därför prata om problemet och gå djupare in i prestandan och begränsningarna hos de agila metoder som du beskriver i boken. Vi har talat om arbetsrytmer och lanseringscykler, men kan du utveckla vilka begränsningar du ser hos de agila metoder som används i dag? Om vi jämför på en övergripande säkerhetsnivå med en taktisk nivå, exempelvis Scrum, vilka begränsningar ser du?

David Bishop: När man talar om ramverk som Scrum och Kanban finns det många andra: DSDM, LeSS och DA, eller Disciplined Agile, som nyligen köptes av PMI. Det ska bli intressant att se hur det utvecklas.

Ben Aston: Ja, jag köper inte ett ramverk. Det låter trevligt.

David Bishop: De försöker angripa problemet från olika håll. När det gäller varför man inför agila metoder tror jag att många missförstår det. I dag ligger fokus ofta på att agilitet får team att samarbeta bättre, gör dig till en bättre ledare eller ökar effektiviteten. Det är naturligtvis bra.

Men det egentliga syftet med agilitet handlar om konkurrens – om att bli nummer ett på marknaden. Det agila manifestet var inspirerat av lean-produktion. Det var en tillämpning av lean-produktionstekniker för programvaruutveckling, med rötter i Toyotas produktionssystem. Vad gjorde det för Toyota? Det förvandlade Toyota från en biltillverkare till en av världens ledande biltillverkare.

Hela idén med agilitet är alltså att försöka återskapa den typen av framgång och bli nummer ett på marknaden. Många av ramverken har enligt min mening glömt detta. SAFe fokuserar på företagsnivå och på att göra alla delar av organisationen agila, oavsett om det gäller HR eller juridik. Tanken är att göra alla delar av verksamheten agila i hopp om gradvisa förbättringar över tid.

Det lägger också för stor vikt vid processer. Det påminner om tiden innan användarberättelser och levande dokumentation skapad genom samarbetsverktyg, när vi använde långa standardförfaranden för stordatorer och äldre system. På vissa sätt påminner SAFe om detta eftersom det skapar omfattande och dyra procedurer för att hantera olika delar av verksamheten agilt. Det är inte nödvändigtvis fel, men på vissa sätt är det motsatsen till vad agilitet handlar om.

Ben Aston: Just det.

David Bishop: Scrum fokuserar på teamnivå. Det är en uppsättning ritualer som hjälper dig att leda team, vilket är bra. Dessa ramverk behöver inte stå i konflikt med varandra. Du kan använda Scrum, Kanban, metagilitet och SAFe i samma organisation.

Metagilitet fokuserar på produktutvecklingsmotorn: produkten, produktledningen, projektledningen samt utvecklings- och testteamen. Det handlar om hur kraven utvecklas och tolkas, hur produkten testas, hur den ska lanseras och hur ni samarbetar med kunden så att produkten uppfyller deras förväntningar och håller så hög kvalitet som möjligt.

Om du vill vinna ett dragrace måste du fokusera på motorn, transmissionen och drivlinan – inte på elhissar eller luftkonditionering. På samma sätt fokuserar vissa andra ramverk för mycket på periferin i stället för på det som faktiskt krävs för att bli nummer ett på marknaden.

Metagilitet bygger på forskning om fallstudier där organisationer lyckades uppnå det jag kallar en superagil anpassning. De använde agilitet för att bli marknadsledande. Metagilitet samlar det dessa företag gjorde rätt och försöker omvandla det till ett arbetssätt som andra organisationer kan använda för att uppnå samma resultat.

Ben Aston: Du beskriver det som ett heltäckande sätt att hantera en ny och mycket effektiv form av agilitet. Är metagilitet ett leveransramverk, en metod eller en handbok? Hur skulle du beskriva det?

David Bishop: Jag skulle beskriva det som ett ramverk. Det leder dig genom processen. Det första steget är att avgöra vilken typ av agil anpassning du behöver. Egentligen börjar boken med att lära dig tänka annorlunda och använda forskningsbaserade och vetenskapliga metoder för att fatta affärsbeslut.

Det finns ett helt avsnitt om detta och ett annat om hur det agila manifestet har förändrats utifrån forskningsresultat. När du kommer till den agila omvandlingen är en av de första frågorna vilken typ av införande du ska välja: ett helt agilt införande, ett hybridarbetssätt eller vattenfallsmodellen? I vissa fall kan vattenfall vara rätt.

Det finns mycket sakkunniggranskad forskning som hjälper till att besvara den frågan. En forskare som heter Barlow publicerade en artikel om hur beslutet kan fattas. Jag har inkluderat den i boken som ett diagram. Valet av agilt arbetssätt bör baseras på komplexiteten hos beroenden och ömsesidiga beroenden i produkten och organisationen samt teamens storlek.

När man har komplexa produkter, stora distribuerade team och många beroenden fungerar ett helt agilt arbetssätt vanligtvis inte i hela organisationen. Man behöver ett hybridarbetssätt. Om det görs medvetet kan det ge fantastiska resultat.

Hybridarbetssätt har ofta ett negativt rykte eftersom människor förknippar dem med en misslyckad implementering. Men om hybridarbetssättet är avsiktligt och bygger på vetenskapliga resonemang och forskning kan du vara säker på att organisationen rör sig i rätt riktning.

Ben Aston: Kan du beskriva hur ramverket fungerar och vilka delar det består av för personer som inte har läst boken?

David Bishop: I boken finns ett stort diagram som visar alla delar. Den första delen av metagilitet är att fatta beslutet om vilken omvandlingsstrategi man ska använda.

Ben Aston: Och hur gör man det?

David Bishop: Genom att använda Barlows diagram. Det är i grunden en funktion av teamens storlek, produkternas komplexitet och graden av samspel mellan teamen.

Metagilitet beskriver hur man kombinerar agila och sekventiella metoder. Programvaruteam kan exempelvis arbeta i tvåveckorssprintar och ha dagliga avstämningar, medan firmwareteam arbetar i längre intervall. Hårdvaruteam kan ha cykler på 12–18 månader och använda vattenfallsmetoder, men komplettera dem med exempelvis snabb prototypframtagning för att hålla jämna steg med andra team.

Målet är att bibehålla flödet genom hela processen. Metagilitet beskriver hur olika team anpassar agila eller sekventiella idéer. Etappgrindar kan användas som kontrollpunkter för att se till att spåren, som arbetar i olika hastigheter, fortfarande är synkroniserade.

Ramverket beskriver också vilka mätvärden och interaktioner som bör användas. Vi delar in interaktionerna i sex tydliga kategorier baserade på våra mest framgångsrika fallstudier och beskriver hur de ska införas och hanteras. På så sätt blir metagilitet en detaljerad handbok för att leda en hybridagil implementering.

Ben Aston: Hur avgör man den rätta blandningen av agila egenskaper? Hur vet man när nuläget är tillräckligt och när en utveckling eller revolution behövs?

David Bishop: Det går tillbaka till vetenskapliga metoder och engagerad forskning. Alltför ofta använder människor intuition, bästa praxis, intervjuer och konsensus. Det kan fungera i vissa sammanhang, men en agil, DevOps- eller digital omvandling kräver starkare metoder.

IT-miljöer är mycket kontextberoende. Det som fungerar i ett företag fungerar inte alltid i ett annat. Genom vetenskapliga metoder, exempelvis tolkande fallstudier och etnografier, kan man avgöra vad som går att generalisera mellan organisationer. Det tar tid, men det ger ett mer tillförlitligt svar.

Ben Aston: Det här är alltså inte ett universellt ramverk, utan ett anpassningsbart ramverk. Hur utvärderar man om implementeringen verkligen är metagil och om den lyckas?

David Bishop: En del av metagilitet är teorin om agil vorticitet. Den bygger på forskning och besvarar frågan om hur agil en organisation faktiskt är. Det har länge saknats ett sätt att mäta agilitet. Agil vorticitet ger ett sådant sätt. Det är ett komplext koncept som jag beskriver utförligt i boken och som gör det möjligt att mäta framgång.

Ben Aston: Vilken påverkan har du sett hos organisationer som har använt ramverket?

David Bishop: Många av våra fallstudier gällde marknaden för inbyggda system, eftersom den är både mycket utmanande och intressant. Organisationer som använde metagilitet blev i många fall marknadsledare eller hamnade mycket nära toppen.

Det innebar ofta större marknadsandelar och fler enheter på marknaden än konkurrenterna. Nyckeln till långsiktig överlevnad är att snabbt skaffa en kritisk marknadsandel innan konkurrenterna gör det. Det kräver att man tar till sig innovativ teknik och får ut den på marknaden före andra.

Agilitet är det bästa sättet att göra detta, och metagilitet är särskilt användbart. De mest framgångsrika fallstudierna lyckades minska cykeltiderna så mycket som möjligt, samtidigt som de bevarade kvaliteten, kundnöjdheten och förmågan att lansera innovativa produkter.

Ben Aston: Var har du sett att metagilitet inte fungerat? Vilka utmaningar har lett till misslyckanden?

David Bishop: Det finns två särskilt viktiga områden. Det första är ledningens stöd. Utan stöd från företagsledningen kommer man inte långt. Det gäller alla typer av omvandlingar. Ledningen måste förstå målet och hur arbetet påverkar resultatet. Man måste presentera ett övertygande affärsunderlag som visar att det handlar om konkurrenskraft, lönsamhet och resultat – inte bara om att göra människor nöjda.

Det andra området är bristande kravhantering. Vid en agil omvandling fokuserar man ofta på utvecklings- och testteam, sprintar och avstämningar, men lägger för lite vikt vid kraven och affärsanalytikerna. I en agil miljö utvecklar man krav tillsammans med kunden; man samlar inte bara in dem.

I vattenfallsmodellen vill man definiera allt från början och undvika förändringar senare. I en agil miljö finns däremot alltid en ny iteration. Om man försöker brainstorma fram alla krav skapas fler och fler krav, det blir svårt att prioritera och teknisk skuld växer okontrollerat. Det är så agila omvandlingar misslyckas. Alla ramverk, även metagilitet, kan misslyckas om man inte förändrar hur kraven utvecklas.

Ben Aston: Om någon är ny inom metagilitet, vilket första steg skulle du rekommendera för att få störst effekt?

David Bishop: Det första är att skapa nya kundrelationer. Det agila manifestet talar om kundsamarbete framför avtalsförhandling, men forskning visar att avtalsförhandling och kundsamarbete i praktiken är samma process. Förhandlingen sker på alla nivåer i organisationen och mellan många olika intressenter.

Kunden måste vara en samarbetspartner och delta i testningen, särskilt när man vill få ut en innovativ produkt snabbt. Våra mest framgångsrika fallstudier hade en tydlig vision för vart de ville komma på marknaden. De valde vilka kunder de skulle arbeta med och vilka de inte skulle arbeta med.

Vissa kunder behövde tackas nej till eftersom de inte ville delta i processen. Att hitta rätt kunder, etablera ett starkt samarbete och skapa en tydlig vision är därför sannolikt det första steget.

Ben Aston: Det är kloka råd. Om vi vill skapa värde för slutanvändare och kunder behöver vi en samarbetsmodell som uppmuntrar samarbete. Att bygga förtroende gör att vi kan säga att vi inte vet exakt vad vi kommer att göra, men att vi kommer att lösa det tillsammans för att nå bästa möjliga resultat.

Tack så mycket, David, för att du var med och pratade om metagilitet.

David Bishop: Tack så mycket.

Ben Aston: Jag vill gärna veta vad du tycker. Har du läst boken metagility ? Berätta gärna i kommentarerna vad du tycker. Om du vill veta mer om metagilitet och boken kan du besöka Agileworx.com. Där finns information om företaget och de utbildningar som erbjuds. Du kan också besöka metagility.technology för det senaste kursschemat.

Ben Aston: Tack så mycket, David. Om du vill lära dig mer och utvecklas i ditt arbete kan du gå med i DPM-medlemskapet på thedigitalprojectmanager.com/membership. Du får tillgång till vårt Slack-team, mallar, workshoppar, AMA-sessioner, kontorstider, e-böcker och mycket mer. Om du gillade det du hörde i dag, prenumerera och håll kontakten på thedigitalprojectmanager.com. Tack så mycket för att du lyssnade.