3 viktige likheter mellom Lean- og smidige metoder
Prosjektledere arbeider alltid med å finne de beste måtene å skape 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 gylne balansen mellom de to – å levere fantastiske produkter på kortest mulig tid.
Måten dette oppnås på, avhenger av teammedlemmene du arbeider med. Det finnes et enormt 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 å avgjøre hvilken metodikk man skal velge. Begge disse er svært nyttige på hver sin spesifikke måte. 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 selskaper bruker det ene navnet om det andre, eller bytter ofte mellom de to.
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 begge ideene om lean- og smidig ledelse nærmere oppstartsselskapet ditt og hjelpe produkteieren med å avgjøre hvilken 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. Ved å undersøke forskjellene mellom dem blir det lettere å se likhetene.
Opprinnelsen til lean-prinsippene
Røttene til lean-produksjon – i likhet med fossefallsmetoden – kan spores tilbake til 1950-tallet og Toyotas bilfabrikker i Japan. De oppdaget et overskudd av ressurser som blokkerte arbeidsflyten. Derfor satte de seg som mål å redusere lagerkostnadene og på denne måten forbedre hastigheten i hele prosessen. Slik ble Toyota Production System til.
Toyota brukte visuelle indikatorer for lagerbehovene sine. De fikk presis informasjon om når de trengte hver enkelt vare i arbeidsflyten, og reduserte det totale svinnet. Ved hjelp av lean-tenkning klarte de å optimalisere hele driften.
Opprinnelsen til smidige prinsipper
Smidige arbeidsmetoder oppsto senere, på 80- og 90-tallet, og ble utviklet sammen med dataprogrammerere. Før smidig metodikk tok prosjektene deres lang tid å fullføre – noen ganger flere år. Programmerings- og databransjen er imidlertid stadig i endring – og det samme gjaldt siste halvdel av det tjuende århundret. Dette betyr at da programmererne endelig klarte å lansere produktet, var det stor sannsynlighet for at det allerede var utdatert. Derfor trengte de en ny tilnærming til arbeidet.
Hovedproblemet var at kostnadene for hele prosessen aldri kunne rettferdiggjøre sluttproduktets manglende levetid. Samtidig som bransjen endret seg, var det kundebehov for nye produkter – og mangel på faglærte arbeidere. Dermed fortsatte kostnadene å stige i stedet for å synke.
Hovedfokuset for smidig metodikk ble derfor 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 å forme metodikken – og derfor ble Det smidige manifestet skrevet i 2001. Det beskriver hovedmålene og gir i tillegg 12 smidige prinsipper som veileder metodikken. På samme måte som lean-metodikken startet den innenfor én nisje, og ble deretter raskt tatt i bruk av andre virksomheter.
Kanban mot Scrum – et eksempel på forskjeller mellom lean og smidig
Et av de beste eksemplene på bruk av disse to prosjektledelsesmetodikkene er å sammenligne Kanban og Scrum. Dette er to ulike prosesser for programvareutvikling som kan gi et tydelig bilde av både lean- og smidig metodikk, og av hvordan du kan skille mellom dem.
Først har vi Scrum – et smidig rammeverk for programvareutvikling som utviklingsteamet ditt kan bruke for komplekse produkter. Akkurat som gjennom historien er hovedvekten lagt på programvareutvikling, men det har også blitt tatt i bruk innen andre områder. Det passer perfekt for et mindre utviklingsteam – fra én til ti personer.
Hovedpoenget 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 oversikter for å 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 bruker den en Kanban-tavle for å hjelpe deg med å synliggjøre problemer og løse dem. 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, både penger og tid var 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 fremragende kvalitet for kunden. Du ønsker også å levere dette 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å kundens tilbakemeldinger.
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 til å eliminere alt som ikke tilfører arbeidet ditt verdi. Det betyr at du reduserer tidkrevende møter så vel som 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.
Samtidig lar smidig metodikk deg 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 til å tilpasse arbeidsflyter underveis, omprioritere oppgaver og fremme kontinuerlig forbedring (derav navnet smidig). Det betyr at du kan endre den smidige arbeidsflyten trinn for trinn, 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 tid på tilfeldig programvareutvikling slik at de kan 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. Programmererne 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 produktets høye kvalitet i sentrum. Ved å gjøre dette slipper du å gå tilbake og oppdatere produktet etter at du har levert det til kundene dine.
Dette skiller seg fra smidig prosjektstyring, som krever kontinuerlige oppdateringer.
Tillit til teammedlemmene 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 skal velge 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.
Samtidig fremmer de tre følgende utsagnene fra Det smidige manifestet, som vi nevnte, samarbeid og taler for seg selv:
- «Individer og samspill fremfor prosesser og verktøy.»
- «Kundesamarbeid fremfor kontraktsforhandlinger.»
- «Forretningsfolk og utviklere må arbeide sammen daglig gjennom hele prosjektet.»
Legg merke til at den tredje setningen er én av de 12 smidige praksisene i det smidige manifestet. En konklusjon du kanskje kan trekke, er at smidig metodikk ikke engang 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. Innspillene deres kan gjøre underverker og gi deg et mye bedre produkt, så sett av tid til å lytte til dem.
Finn ut mer om smidig metodikk og viktige smidige prinsipper ved å ta en av disse sertifiseringene innen smidig metodikk.
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å være oppmerksom på arbeidsflyten din og hvordan du kan optimalisere den. 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 bestemt deg for en metodikk, vil virksomheten din være på vei mot suksess på kort tid!
