En diskusjon om lean, systemsthinking og smidig..

Et lite utsnitt av det jeg oppfatter som en spennende diskusjon som flere burde henge seg på.. (anonymisert diskusjon gjengitt med tillatelse)

a: lest denne? http://leanandkanban.wordpress.com/2009/06/10/lean-software-development-achieving-better-requirements/ b: vet ikke helt om jeg kjøper det derre flow-greine a: det ligger mye der, uten tvil, men om det er løsningen på alt er et åpnere spm...
b: det er jo opplagt ikke løsningen på alt a: spesielt i offentlg/helse mm a: NAV er jo et premieeksempel b: og jeg er svært usikker på hvor riktig jeg synes de sammenligningene med japansk bilindustri er b: software-utvikling er ikke det samme som samlebåndproduksjon av biler b: hadde vært artig å sett noen studier som beskriver hvordan de bedriftene jobber nå b: det meste av det det referers til er jo rimelig gammelt a: poenget er å analysere problemet/bruk for å løse de virkelige problemene og ikke det man tror er problemet.... spesielt der hvor man ikke har konkurranse og opplever at kostnadene går opp når man "automatiserer" b: "poenget er å analysere problemet/bruk for å løse de virkelige problemene og ikke det man tror er problemet.... " - er vel ingen, uansett metodikk, som er uenig i dette? b: jeg synes egentlig det er litt paradoksalt. b: veldig mange i smidig-miljøet er jo tilhenger av "start å kode tidlig -> rett opp underveis" b: det trenger seff ikke være en motsetning b: men det kan definitivt være det a: problemet med Smidig og Lean er at de henger seg på "trenden", men de har ingen forhold til metodikken for å analysere og måle den typen "waste" vi snakker om her a: så de tar ikke over seg det virkelige problemet/utfordirngen (f.eks ved en Sigma Six analyse eller tilsvarende) b: så de optimaliserer i blinde b: det er jeg helt enig i a: men i enterprise setting, så kan det å starte å kod etidlig ha en mening, iom at det ofte er raskere å utvikle en løsning enn det er å komme frem til enighet b: nedvurderingen av betydningen av grundige analyser er noe av det som jeg synes agile er dårligst på a: jeg skjønner motstanden på endel analyser... men det å få analysert problemet bør ikke nedprioriteres a: hvis det droppes, så er det bare flaks dersom man lager en løsning som løser problemet b: jeg er helt enig i at en del analyser er unødige, og at det da vil være mer hensiktsmessig å bare "Kjøre på". Et av problemene er kanskje at man ikke har noen metodikk for å skille disse situasjonene