Scrum är en praktiskt orienterad grundstomme för hur man kan bedriva lättrörlig mjukvaruutveckling. Lean är en etikett satt på det system av principer som man uppfattat legat till grund för bland annat Toyotas sätt att organisera sig.
Hur förhåller sig egentligen Scrum och lean till varandra? Att förstå detta är användbart både för den som vill ha en teoretisk grund för att förstå eller argumenta för Scrum, och för den som idag använder Scrum, men som vill förstå hur man kan justera och vidareutveckla arbetssättet utan att göra supoptimala justeringar.
Ett sätt att se på förhållandet är detta: scrum är en implementation av lean.
Vad innebär detta? Det innebär att Scrum i praktiken är utformat så, att arbetssättet stödjer de principer som lean baseras på. Scrum är alltså en tolkning av leanprinciperna, som den hågade kan utgå ifrån för att komma igång med en effektivisering av sitt sätt att utveckla mjukvara.
Jag och Mikael Lundgren höll för rätt länge sedan en dragning på detta tema i Dataföreningens regi (PDF). Då var intresset ganska litet, men jag misstänker att vi får tillfälle att återkomma till denna koppling, nu när intresset för både Scrum och lean ökar. Ju fler intresserade, ju fler som funderar över detta.
Här är en snabb sammanfattning av några kopplingar mellan Scrums handfasta riktlinjer, och leans teoretiska principer.
Lean-princip: Eliminera slöseri
Scrums implementation av principen:
- detaljplanera i aktiviteter endast en iteration framåt (eftersom detaljplaner snabbt blir inaktuella och måste göras om),
- ha ett enkelt, “tillräckligt bra”, system för tidsestimat och statusrapportering – fokusera på åstadkomna resultat, inte på tidrapportering,
- se till att teamet har arbetsro under iterationen.
Lean-princip: Ständigt lärande
Scrums implementation:
- teamet tar själva ansvar för kravförståelse och utformning av den mest optimala lösningen på givna problem,
- daglig uppföljning i hela teamet och tydlig statusrapportering utåt till intressenterna,
- återblickar i slutet av varje iteration – kombinerat med planering av förbättringsåtgärder
Lean-princip: Ta beslut sent (så sent att du har maximal information, men inte så sent att skada hinner ske)
Scrums implementation:
- rullande produktplanering,
- detaljplanering just-in-time i början av varje iteration,
- se till att så många beslut som möjligt är lätta att ändra – använd disciplinerad refactoring för att ständigt förbättra produktens design och därmed göra den lätt att ändra
Lean-princip: Leverera snabbt
Scrums implementation:
- fokus på tidig releaseförmåga, varje iteration slutar i en intgrerad produkt av hög kvalitet,
- implementation i nyttoordning ger möjlighet till tidig leverans,
- minimal administrativ overhead – en dags gemensam planering första dagen i iterationen och en dags gemensam uppföljning sista dagen i iterationen,
- effektiv utveckling tack vare fokuset på att bygga upp ett självorganiserande team,
- möjliggör snabba buggfixar med hjälp av automatiserad testning och integration
Lean-princip: Bygg in kvalitet (istället för att försöka “testa in” den i slutet)
Scrums implementation:
- skapa ett team som förstår kundens definition på kvalitet genom att jobba nära kunden och kundens problem,
- använd ett tvärfunktionellt team för snabb och effektiv problemlösning,
- varje iteration slutar med “färdig produkt”/”done product backlog”,
- använd automatiserade tester,
- utnyttja “peer programming” – alltså att teammedlemmar från olika discipliner (testare, programmerare etc) angriper problem gemensamt,
- etablera ett gemensamt klarkriterium – alla i teamet och beställaren ska vara överens om vad det innebär att säga att en given produktfunktion är “klar”
Lean-princip: Decentralisera ansvar
Scrums implementation:
- små tvärfunktionella team med långtgående befogenheter och tydliga ramar,
- aktivitetsplanering för varje iteration görs av teamet själva under varsam handledning av “ScrumMastern”,
- det dagliga arbetet planeras, genomförs och följs upp av teammedlemmarna själva
Lean-princip: Se till helheten
Scrums implementation:
- använd tvärfunktionella team för att garantera lösningar på hela problem och undvika suboptimering,
- utveckla vertikalt – implementera per funktion “från skärm till databas” aldrig “ett skikt i taget”,
- etablera ett resultattänkande – teamet följs upp på hur väl det implementerar en värdefull produkt snarare än på hur bra det är på att fylla i tidrapporter och annan administratrivia,
- fokus på affärsnyttan – det är viktigare att bygga den produkt kunden vill ha när projektet är slut än att bygga den produkt kunden bad om när projektet började