3 viktige likheter mellom Lean- og smidige metoder
Prosjektledere arbeider alltid med å finne de beste måtene å utvikle produktene sine på eller bidra til programvareutvikling. Mesteparten av tiden kan dette ses på som en kamp mellom effektivitet og produktivitet. Hovedmålet er å finne den perfekte balansen mellom de to – å levere fantastiske produkter på kortest mulig tid.
Måten man oppnår dette på, avhenger av teammedlemmene du arbeider med. Det finnes et stort utvalg av prosjektmetodikker, men bare to som oftest konkurrerer om favorittplassen. Den første kalles lean-metodikk. Den andre er en smidig metodikk.
Det kan være vanskelig å bestemme hvilken metodikk man skal velge. Begge disse er svært nyttige på sine egne, spesifikke måter. Derfor handler en av de vanligste diskusjonene om forskjellene mellom dem. Det som imidlertid gjør grensene enda mer uklare, er likhetene mellom dem. Noen ganger går dette så langt at bedrifter bruker det ene navnet om det andre, eller bytter mellom de to ofte.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Derfor ser vi i dag nærmere på likhetene mellom smidig og lean utviklingsmetodikk. Med denne artikkelen håper vi å bringe ideene bak lean og smidig ledelse nærmere oppstartsselskapet ditt og hjelpe produkteieren med å avgjøre hvilken av dem som passer best for teammedlemmene dine.
Forstå både lean- og smidige metodikker
For å forstå hva hver metodikk representerer, må vi se litt nærmere på historien til begge. Når vi undersøker forskjellene mellom dem, blir likhetene tydeligere.
Opprinnelsen til lean-prinsippene
Røttene til lean-produksjon – på samme måte som fossefallsmetoden – kan finnes på 1950-tallet og ved Toyotas bilfabrikker i Japan. De oppdaget et overskudd av ressurser som hindret arbeidsflyten. Derfor satte de seg som mål å redusere lagerkostnadene og på denne måten forbedre hastigheten i hele prosessen. Slik ble Toyotas produksjonssystem til.
Toyota brukte visuelle indikatorer for lagerbehovene sine. De fikk presis informasjon om når de trengte hver enkelt del i arbeidsflyten, og reduserte det samlede svinnet. Ved hjelp av lean-tenkning klarte de å optimalisere hele driften.
Opprinnelsen til smidige prinsipper
Smidige arbeidsmetoder oppsto senere, på 1980- og 1990-tallet, og ble utviklet sammen med programmerere. Før smidig metodikk tok prosjektene deres lang tid å fullføre – noen ganger flere år. Programvare- og databransjen er imidlertid i stadig endring – og det samme gjaldt andre halvdel av det tjuende århundret. Det betyr at da programmererne endelig klarte å lansere produktet, var det stor sjanse for at det allerede var utdatert. Derfor trengte de en ny tilnærming til arbeidet sitt.
Hovedproblemet var at kostnadene for hele prosessen aldri kunne rettferdiggjøre at sluttproduktet hadde så kort levetid. Samtidig som bransjen endret seg, fantes det etterspørsel fra kunder etter nye produkter – og mangel på kvalifiserte arbeidere. Dermed fortsatte kostnadene å øke i stedet for å synke.
Derfor ble hovedfokuset for smidig metodikk tid. Hovedmålet for de smidige teamene dine er å ha kontinuerlig oppmerksomhet på leveringen av produktet – først gjøre det raskt og deretter fortsette å oppdatere det etter å ha fått tilbakemeldinger fra kundene.
Det tok noen år å utforme metodikken – og derfor ble Det smidige manifestet skrevet i 2001. Det beskriver hovedmålene og gir 12 smidige prinsipper som veileder metodikken. I likhet med lean-metodikken startet den i én nisje, før den raskt ble tatt i bruk av andre virksomheter.
Kanban vs. Scrum – et eksempel på forskjeller mellom lean og smidig
Et av de beste eksemplene på bruk av disse to prosjektstyringsmetodikkene er å sammenligne Kanban og Scrum. Dette er to ulike programvareutviklingsprosesser som kan gi et tydelig bilde av både lean- og smidig metodikk, samt hvordan du kan skille mellom dem.
Først har vi Scrum – et smidig rammeverk for programvareutvikling som utviklingsteamet ditt kan bruke til komplekse produkter. Akkurat som gjennom historien er hovedvekten lagt på programvareutvikling, men det har også blitt tatt i bruk på andre områder. Det passer perfekt for et mindre utviklingsteam – fra én til ti personer.
Hovedideen er å dele produktutviklingen opp i mål (kalt prosjektkøen), som du deretter kan nå gjennom kontinuerlig forbedring. Disse kortvarige iterasjonene kalles sprinter og tar vanligvis rundt to uker. På slutten av hver sprint holder dere et møte for å gjennomgå sprinten og fremdriften i den smidige utviklingen. Mange team bruker smidige kontrollpaneler til å visualisere sprintmålinger og følge fremdriften i sanntid under sprinten.
På den annen side er Kanban en utviklingsmetode som er laget for å støtte hele produktutviklingsprosessen. Sammenlignet med smidig utvikling bruker den en Kanban-tavle for å hjelpe deg med å synliggjøre og løse problemer. Dette gjør den ved å måle livssyklusen og gjennomløpstiden for både hele prosessen og verdistrømmen din (som består av delene i prosessen).
Lean- og smidige metodikker fokuserer begge på kundeverdi
Slik det ofte er (og bør være) i næringslivet, var kunden eller oppdragsgiveren hovedårsaken til begge metodikkene. Ja, det var også penger og tid involvert, men både lean- og smidige metodikker ble utviklet for å gjøre kundene fornøyde med produktet, samtidig som prosessen skulle bli enklere for teammedlemmene.
Legg merke til at begge har som mål å tilby en bedre og raskere tjeneste. Det som skiller dem fra hverandre, er den grunnleggende måten de oppnår målene sine på.
Hvis du bruker lean-metodikk, ønsker du teknisk kvalitet for kunden. Du ønsker også å levere den på kortest mulig tid. Den smidige metodikken skiller seg ikke fra dette når det gjelder tid – rask levering står i sentrum.
Du trenger imidlertid ikke et perfekt produkt. I stedet kan du fortsette å arbeide med det og oppdatere det basert på tilbakemeldingene fra kunden.
Hastighet i prosjektstyringen er målet for både lean- og smidige metodikker
Som du kanskje har lagt merke til, har begge metodikkene som mål å øke effektiviteten din – eller hastigheten du utvikler et produkt med. Dette er en av de viktigste innsatsfaktorene i begge metodikkene. Det du må endre for å oppnå effektivitet, er imidlertid forskjellig mellom de to.
På den ene siden bruker du lean-metodikk for å eliminere alt som ikke tilfører arbeidet ditt verdi. Det betyr at du reduserer tidkrevende møter og unødvendig byråkrati. Du vil også slutte å arbeide med ting du «kanskje trenger» i fremtiden. Til slutt vil du unngå ineffektive arbeidsmåter – som å gjøre flere ting samtidig.
Den smidige metodikken lar deg på sin side velge praksiser og oppgaver som fungerer best for deg. Det viktigste er at du ikke blir bundet av valgene du tar. Team bruker ofte programvare for smidig styring for å tilpasse arbeidsflyter underveis, omprioritere oppgaver og fremme kontinuerlig forbedring (derav navnet smidig). Det betyr at du kan endre den smidige arbeidsflyten litt etter litt, og det er her den store forskjellen mellom de to ligger.
Hvis du bruker lean-metodikk, legger du vekt på og fokuserer på utformingen av arbeidsflyten som helhet. Det krever at du tar et skritt tilbake og ser på den fra et overordnet perspektiv. Dette gir deg bedre kontroll over hele prosessen, samt muligheten til å redusere alt som er overflødig.
For å illustrere dette trenger du ikke at medarbeiderne dine bruker tiden på tilfeldig programvareutvikling for å være 100 % klare når du trenger dem. I stedet må du stole på at de vil være klare og gjøre sitt beste når tiden er inne. Programmørene dine trenger for eksempel ikke å lage et verktøy du kanskje ikke engang kommer til å bruke.
La dem i stedet utforske og utvikle ferdighetene sine. På denne måten setter du søkelyset på den høye kvaliteten på produktet ditt. Dermed slipper du å gå tilbake og oppdatere produktet etter at du har levert det til kundene.
Dette skiller seg fra smidig prosjektstyring, som krever konstante oppdateringer.
Tillit til lagkameratene dine er viktig i både lean- og smidige metodikker
Som du ser, må du tenke nytt om hvordan du leder teamet ditt når du velger mellom de to metodikkene.
Det er imidlertid viktig å merke seg at begge involverer teamet ditt tett i hele arbeidsflyten. Tross alt er teamarbeid grunnleggende for alle virksomheter. Uten det vil både effektiviteten og produktiviteten lide store tap.
Med lean-metodikk kan folk lære av hverandre. Gjennom samarbeid finner dere de beste og mest effektive løsningene og reduserer sløsing.
I mellomtiden fremmer de tre neste utsagnene fra manifestet for smidig utvikling som vi nevnte, samarbeid og taler for seg selv:
- «Individer og samspill fremfor prosesser og verktøy.»
- «Samarbeid med kunden fremfor kontraktsforhandlinger.»
- «Forretningsfolk og utviklere må arbeide sammen daglig gjennom hele prosjektet.»
Merk at den tredje setningen er én av de 12 smidige praksisene i Det smidige manifestet. En konklusjon du kan trekke, er at smidig metodikk ikke bryr seg om verktøyene eller prosessen på samme måte som lean-metodikk gjør. I stedet fokuserer denne metodikken på menneskene i prosessen. Den oppmuntrer deg også til å samarbeide tett med kundene dine. Deres innspill kan gjøre underverker og gi deg et mye bedre produkt, så sett av tid til å lytte til dem.
Finn ut mer om smidig utvikling og viktige smidige prinsipper ved å ta en av disse sertifiseringene innen smidig utvikling.
Konklusjon
For å konkludere kan det være like mange likheter mellom smidig og lean programvareutviklingsmetodikk som det er forskjeller. Selv om de har ulik opprinnelse, har de fortsatt det samme fokuset – kundetilfredshet.
Du bør også rette oppmerksomheten mot arbeidsflyten din og måter du kan optimalisere den på. Leveringshastighet er viktig i begge – men det er opp til deg og teamet ditt å finne ut hvilken som fungerer best for dere. Det kan kreve litt utforskning og eksperimentering, men når du først har funnet en metodikk, vil virksomheten din snart være på vei mot suksess!
