Agilt arbetssätt i Industriföretag

Vad är agilt?

När vi är ute och träffar kunder och diskuterar projektverksamhet så händer det allt oftare att vi kommer in på ämnesområdet ”agile”. Ibland handlar det om agila metoder och arbetssätt och ibland handlar det om att behovet av att vara agil på marknaden. Agil i meningen att snabbt kunna anpassa sig till helt nya förutsättningar och krav. Stora, snabba förändringar tycks vara det nya normalläget. Ett bra exempel på att man kan mena vitt skilda saker när man pratar om agila projekt kom på förra årets Passion for Projects i Malmö. En av huvudtalarna var Klaus Steen Mortensen, VD på Vestas. Han berättade att mycket av Vestas framgångar kom från deras agila projektverksamhet. Vi var många i publiken som förväntade oss en beskrivning av hur de organiserat sig i team, om backlogs, features och sprintar. Istället var det Vestas affärsmodell för projektåtagande som var agil. Genom att anlita lokala resurser för mer än 90% av arbetet i projekten blev Vestas flexibelt och agilt. Kapacitetsmässigt och tidsmässigt klarade man av anhopningar av affärer genom att minska det egna engagemanget och öka det externa. Kostnadsmässigt blev man adaptiv och agil genom att kostnaderna anpassades till landet i fråga.

För många mjukvaruföretag kommer den affärsmässiga ”agiliteten” direkt från det agila arbetssättet. Genom att utveckla inkrementellt, med små funktionstillägg som stäms av mot kund och som integreras och testas kontinuerligt levererar man det kunden vill ha. Man har då uppnått ett slags agilt idealtillstånd. De egna medarbetarna trivs och utvecklas i den agila team-miljön med stor frihet och inflytande samtidigt som kundernas behov tillgodoses. Det finns många exempel på sådana företag inom underhållning, app-utveckling och spelindustri.

Måste industriföretag bli agila?

I meningen att hela tiden försöka förstå och uppfylla kundens behov och önskningar är framgångsrika industriföretag redan agila. Många har dessutom organiserat sina produkters uppbyggnad i moduler för att snabba upp produktutveckling och kundanpassning. Vissa erbjuder också sina kunder att själva konfigurera produkterna.

Att kunna hantera fler och fler projekt samtidigt och framförallt att få igenom fler projekt snabbare blir en allt viktigare konkurrensfaktor. Är de agila arbetssätten lösningen för att hantera utmaningarna? Hur ska industriföretag ta till sig de agila arbetssätten? Kan de kopiera mjukvaruföretagen rakt av eller behövs anpassning och komplettering?  Frågorna är många och handlar egentligen om det finns något i industriföretagets projektmiljö som hindrar eller begränsar hur bra de agila metoderna fungerar. Vi ser tre områden där industriföretag ofta skiljer sig från mjukvaruföretag och där skillnaden är sådan att den kan påverka hur bra de agila arbetssätten fungerar.

Skillnader mellan industriföretag och mjukvaruföretag

Med industriföretag menar vi företag som tillverkar fysiska produkter. Industriföretag kan också syssla med mjukvara men då oftast som en av flera beståndsdelar i produkten. Med vår definition av industriföretag vill vi särskilja dessa från tjänsteföretag och rena mjukvaruföretag. Vi ser tre viktiga skillnader. Det handlar om organisation, fler projekt med beslutat måldatum och innehåll och fler projekt med behov av intern synkronisering i projekten.

I en annan artikel, som finns på vår hemsida, belyser vi skillnaden mellan komplexa och komplicerade projekt och hur komplexa projekt lämpar sig väl för agilt arbetssätt medan komplicerade eller enkla projekt lämpar sig bättre för ett mer målstyrt arbetssätt.

Om vi börjar med organisation så omfattar ett industriföretag en mer komplicerad produktlivscykel som förutom utveckling, marknadsföring och försäljning också involverar resurser inom produktion, logistik och inköp. Skillnaden fortsätter inom utveckling där behovet av kompetenser för ett enda företag kan spänna över vitt skilda områden som tex mekanik, elektronik, biomedicin, mjukvara och materialteknik. Att organisera ett sådant företag i en permanent tvärfunktionell teamorganisation är kanske inte omöjligt men det skulle vara mycket dyrare och svårt att duplicera alla specialister. För att upprätthålla viktiga stödfunktioner för respektive kompetens som laboratorium prototypverkstäder med mera är den traditionella funktionella organisationen att föredra.

Nästa skillnad handlar om hur begränsat projektet är, när det gäller leveranstid och innehåll. I industriella projekt är det vanligt att det finns en kravspecifikation och en tid när projektet ska vara klart. För mjukvaruprodukter kan ett experimenterande och en gradvis överenskommelse av vad som ska levereras vara värdefullt både för kund och för leverantör. När det gäller industriella produkter är det vanligt att kravbilden för produkten är tydlig redan från början och att det istället handlar om att leverera på tid och kostnad. För industriprojekt är det därför sannolikt att begrepp som 100% leveranssäkerhet och att leverera enligt överenskommelse är och förblir centrala.

Den tredje skillnaden handlar om behovet av synkronisering. I ett agilt projekt fångas projektets syfte och mål som en sorterad backlog av önskade funktioner eller produktförmågor. Tanken är att teamen som ska genomföra projektet drar det arbete som har störst kundvärde först för att säkerställer att projektet åstadkommer maximal kundnytta. I ett projekt där flera olika discipliner skall åstadkomma gemensam kundnytta kan det vara nödvändigt att hitta synkroniseringspunkter där de olika disciplinerna, som tex mekanik och elektronik synkroniserar sin funktionstillväxt så att det sammantagna resultatet kan användas för det fortsatta arbetet inom respektive disciplin. En sådan synkronisering innebär att teamen inte kan välja enbart efter kundvärde utan att de måste planera arbetet så att de kan hålla utfästelser mot andra discipliner. Vi kallar detta att det finns ett behov av synkronisering av leveranser eller resultat, med andra team eller delprojekt.  

Agila styrkor och tillkortakommanden

Det verkar onödigt att skriva om fördelarna med det agila. Det finns redan en uppsjö av artiklar, presentationer, seminarier och video-clips där de agila arbetssätten presenteras och hyllas. Det finns också en lång rad av case stories och andra vittnesmål där representanter från kända och oomtvistat framgångsrika företag beskriver de framgångsrikt anammat det agila. Vi kan även konstatera att vi själva har goda erfarenheter och att vi använder backlog, sprintar, task boards, retrospectives, ståupp-möten, burn ups, minimum viable product mm, både i vår egen verksamhet och hos kund. Det är viktigt att vi i denna anstormning av goda vitsord inte förlorar omdömet och sveps med i en okritisk hyllning av de agila arbetssättens universella förträfflighet.

Vi vill därför uppmärksamma och bjuda in till diskussion om att det för industriföretag finns områden där de agila arbetssätten inte är tillräckliga och ibland inte ändamålsenliga.

Det första området är hantering av kritisk kompetens. I ett industriföretags mer komplicerade behov av olika kompetenser finns verksamhetens flaskhals. Det finns minst en kompetens vars tillgänglighet bromsar hur många projekt som kan levereras. Vi kallar en sådan kompetens för projektsystemets kapacitetsflaskhals. Även om flödet snabbas upp och förbättras både uppströms och nedströms om flaskhalsen så kommer det inte ut mer projektresultat än vad flaskhalsens kapacitet tillåter. Att kunna se och hantera sina resursflaskhalsar är av yttersta vikt för organisationer som är hårt belastade.

I en projektportfölj bestående av projekt med tydliga krav och kontrakterade leveransdatum kommer det att uppstå olika prioriteringskonflikter. I dagsläget är det oklart hur de agila metoderna fungerar under sådana omständigheter. Att prioritera efter kundvärden i backlogs är inte tillräckligt. Det bör finnas uppföljning av hur leveranser ligger till mot utlovade datum, information om hur mycket arbete som återstår på respektive leverans och information om tillgänglig kapacitet för att motåtgärder ska hinna sättas in i tid och på rätt plats.

Den tredje utmaningen för det agila handlar om förmågan att synkronisera projekthändelser så att olika delar av projektet inte måste stanna upp och invänta delresultat. Ett trivialt exempel är att fortsatt arbete med elektriska styrkort kräver att vissa dimensionerande mekanikbeslut måste vara fattade. Oförmåga att hantera nödvändig synkronisering leder till förskjutning av arbetet och därmed till ledtidsförlust.

Det är viktigt att notera att de tre problemen som beskrivs inte skapas av det agila arbetssättet. Det tre problemen finns som en inneboende utmaning för industriella företag. Att leverera projekt på utsatt tid, att hantera flaskhalsar och att hantera överlämnanden ”just in time”. Problemet med de agila arbetssätten är att de inte adresserar de tre problemen.

Velocity från VMG

På VMG är vi djupt engagerade i att lösa ovanstående problem och vi har idag en lösning som är väl utprovad för konventionella projektportföljer. Den kallas Velocity och den har över 3000 dagliga användare i industriföretag. Sen en tid tillbaka, i nära samarbete med våra kunder har vi utvidgat Velocity till att också omfatta agila projekt. 

Med Velocity erbjuder vi ledare inom multiprojektverksamheter en unik möjlighet att identifiera och nyttja kapacitetsflaskhalsarna på de sätt som ger bäst projektflöde för hela projektportföljen. På samma sätt hanterar vi alla leveransåtaganden och vi identifierar tidigt förseningsrisker och lämpliga motåtgärder. Okomplicerat och enkelt hanteras överlämning och synkronisering.

Velocity bygger bland annat på idén om flödesoptimering av projektflöde. Med smart metodik och signalering gör vi det enkelt för alla att arbete i den sekvens som är mest gynnsamt för projektflödet. Att införliva ett agilt arbetssätt i detta har visat sig vara mycket enkelt och rättframt. Att dra arbete och genomföra det i en timebox och att sen dra nytt arbete är nämligen helt i linje med det gängse arbetssättet i Velocity.

Med Velocity och Velocity SprintMaster kan vi i ett verktyg hantera både agila projekt, blandade projekt, konventionella projekt, agila team, virtuella kompetenser och individer. Vi kan upptäcka och nyttja flaskhalsar, upptäcka och åtgärda förseningsrisker och säkerställa smidiga överlämnanden.     

Läs mer om