Lean = Mini waterfall?

Facebook

Twitter

Linkedin

Min gode kollega Hans Brattberg ställde denna provocerande fråga:

Vad i Lean hindrar oss från att göra en kejda av
Req Spec -> Architecture -> Design -> Program -> Test -> Production

Med handovers hela vägen?
Utan kommunikation?
Utan Cross Functional?
Utan Feedback?

Kedjan "Req Spec -> Architecture -> Design -> Program -> Test -> Production" som Hasse beskriver är visserligen ett vattenfall i den bemärkelsen att man gör saker i en viss ordning. Det gör man ju alltid i en verksamhet med litet koll på läget; "bäst att tänka litet först innan jag kodar" eller "det går ju inte att driftsätta innan koden finns".

Det är alltså inte dåligt utan bra att  göra saker och ting i rätt ordning.

Det som gör en kedja till en vattenfallsprocess av det dåliga slaget är:

• om varje steg i kedjan innebär ett (del-)projekt i sig. Man gör t.ex. design av hela systemet innan man börjar programmera.
• om varje steg i sig innebär en överlämning. Det är inte samma människor som gör efterföljande steg och man kommunicerar t.ex. via dokument (designspecar) istället för ansikte mot ansikte.
• om det finns få tillfällen där man kan ändra kraven, innehållet eller konstruktionen. När t.ex. designen av systemet är satt och inte får ändras eftersom tidsplanen kommer att gå åt skogen då.
• om det finns få återkopplingstillfällen att förbättra processen. Exempelvis en projektavslutning var 18:e månad.

Så vitt jag vet motverkar lean varenda en av ovanstående punkter. I lean handlar det om kontinuerligt flöde, små köer och korta cykeltider. För att uppnå detta försöker man:

• bara göra saker som är kopplade till den aktuella produktelementet (ett försök till översättning av "feature") man jobbar med. Allt annat (t.o.m. andra produktelement = parallellt pågående arbete) betraktas ju som waste.
• minimera antalet överlämningar och effekten av detta. Bara för att man gör saker i en viss ordningeng behöver man ju inte ha olika stationer med olika kompetenser på varje station. Till skillnad från biltillverkning där man måste ha olika stationer pga att maskinerna man använder i många fall bara står på en fysisk plats behöver vi mjukvaruutvecklare inte lida av detta. Vi kan använda samma dator till alla steg i kedjan om vi vill. Skall man slippa överlämningar är tvärkompetenta team (en ny lyckad översättning av "cross functional teams" 🙂 att föredra.
• eftersom man bara bygger ett produktelement i taget och cykeltiden för denna är kort kan man innan man startar nästa element prioritera och välja vilket man vill göra härnäst. Kanban är ju ett exempel på detta då PO får prioritera varje dag vad som skall göras.
• I Scrum har man återkoppling (retrospective) minst en gång i månaden. I lean skall man ju ha det varje dag hela tiden, eftersom det är katastrof om man inte gör saker bättre idag än man gjorde igår (efter vad jag hört om Toyota).

Sammanfattningsvis tycker jag inte det blir vattenfall bara för att man gör saker i en viss ordning. I så fall är allt utom kaos vattenfall. Lean motverkar det som vi anser är problem med traditionella vattenfallsprocesser på ett rätt explicit sätt.