Romere og Lean

Sådan sagde Asterix og Obelix igen og igen, men faktisk var der mindst en enkelt mand der havde fat i noget omkring Lean. Cicero sagde; Quis? Quid? Ubi? Quibus? Auxiliis? Cur? Quomodo? Quando? Som oversat betyder: Hvem? Hvad? Hvor? Hvorved? Hvorfor? Hvordan? Hvornår? Disse blev siden kaldt de 7 filosofiske grundbegreber.

Matthew May har skrevet om Lean, “Lean requires a precise understanding of value - the Who, what, when, where, how, and why. Og den skarpe kan jo se at han mangler en, nemlig Hvorved?. Den vender vi tilbage til.

Toyota lavede en prius på 15 måneder, og det er et stykke software på hjul. Toyota bruger Lean, og konkurrere på hastighed, altså hvor hurtigt de er i stand til at producere noget nyt, som er helt nyt og markeds skabende.

At konkurrere på hastighed, er svært i software udvikling. Fordi det der slår hastigheden ihjel er, komplexitet, inkonsistens og overload. Og software er komplext, så hvad gør man? - man holder det simpelt. Og det gør man ved at have en fælles infrastruktur i sit software projekt. En fælles arkitektur som er forståelig, fælles navne konvention, fælles værktøjer.

Det starter som regel godt, for software er jo ikke komplext fra begyndelsen, når der ikke er skrevet en eneste linie. Det kan godt være at kravende er svært og komplekse, men softwaren er det ikke endnu. Det sander til efterhånden som man kommer mere og mere funktionalitet på, fordi ens arkitektur ikke er i stand til at bære det. Der er ikke tænkt igennem som et framework der virkelig skal understøtte de ændringer der er nødvendige for at nå i mål med sit produkt. Derfor kræver software som regel hvad vi kalder refactoring. Det byder sig selv, at har man meget af det, er man lige vidt. Hvis man hver gang der kommer et enkelt nyt krav skal skrive det meste om, er er igen noget der tyder på at ens arkitektur ikke er tænkt igennem. Derfor er fleksibilitet i software arkitektur vigtigt, men pointen er at det framework som skal bære den fleksibilitet ikke kan ændres undervejs. Der skal være tilstede fra begyndelsen, for hvis det ændres får man inkonsistens og dermed bliver den begrebs verden man har bygget op undervejs i projektet hele tiden revet ned - og det gør at man er så langt fra at være agile og lean som man overhovedet kan være.

Scrum mennesker vil nok råbe, og sige - jamen det er perfekt for Scrum er jo netop en process, som er i stand til at håndtere ændringer. Pointen er bare at det er ligegyldigt, hvis ikke din software arkitektur er i stand til at rumme ændringer. Så kan det godt være din process kan, men din software kan ikke også er det håbløst. Hvis du vil have noget der over tid til stadighed kan ændres, skal du have arkitektur der understøtter det og ikke en process der understøtter det. Hvis du kun har processen sander det til, og det er præcist det som Scrum gør igen og igen når det møder virkeligheden.

Setbased design, er et koncept fra Toyota. Det handler basalt set om at have så mange strenge at spille på hele tiden så muligt. Det vil sige, hele tiden arbejde med flere løsninger på engang og vente så længe så muligt med at tage beslutninger om hvilken der skal bruges. Det kræver selvfølig at man har folk nok, men prøv lige og tænkt på følgene eksempel fra som Mary poppendieck, hev frem da hun talte om “competing on basis of speed” ved google. En der laver software til printere, har et problem. Han marketing folk siger at hvis de skal sælge printere i stort antal skal de have “red eye reduktion”. Det lyder simpelt nok, red eye reduktion er en kendt teknik, men her ville de gerne have en automatisk red eye reduktion så den selv var i stand til at detektere om det var nødvendigt uden menneskelig indblanding. Manden der skulle lave det havde to algoritmer, en god, og en dårlig. Den dårlige kunne let implementeres og på den aftalte tid, den gode tog længere tid og krævede flere ressourcer. Nu var manden jo softwareingeniør, og vi har jo hang til gode algoritmer, men han viste ikke hvor han skulle få ressourcerne fra. Mary sagde så, jamen hør nu her, du siger til mig at hvis i har den her teknologi kan i sælger mange flere printere, også så spørger du mig om hvor du skal få ressourcen fra`? - jamen hvad er alternativet!. Vil i sælge mange printere, eller vil i ikke?.

At arbejde med flere løsninger på samme tid, kræver frihed. Frihed til at lege og blive specialist, fordi at det er netop det der gør, at man er klar når kravet kommer. Det kræver altså det vi engang kaldte udvikling!. Ikke bare at udvikle løsninger til kunden men også at blive specialist i på sit område, så man er foran kunden. Det er en organisation der er i stand til at håndtere ændringer.