Kopplingen lean och Scrum

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

 

Russell Ackoff on Systems Thinking

UPDATE, JAN 11, 2009 Three short clips with Russell Ackoff have been posted to YouTube.

UPDATE, OCT 26, 2008: Kevin, who first pointed out to me that the video links in this post were broken, have managed to get in touch with Chicago-Kent. He received the direct links to the missing Ackoff lectures, and passed them on to me. Here they are:

UPDATE: Russell Ackoff’s talks on Girls Link seem to have been taken down. Readers Kevin and Lennart have asked me if there is a way to get hold of them again. I have not yet found such a way. I have, though, tried to get some more info on this via email, but without luck so far. If I find out more about this, I’ll post about it here. Check back here or/and post a comment if you want to know if I find a way to see them again.

UPDATE 2: Over on Anders Vesterberg’s blog, reader Eric posted links to the Girls Link talks in the comments section. The link’s go to cached content at Web Archive. I’m not able to access the talks, but some seem to be, so go ahead and give it a try.

UPDATE 2: I’ll be adding links to Ackoff material on this page as I come across it on the web.

Original post:

Oh my, oh my! Is this sweet or what? A full set of videos with systems thinker Russell Ackoff. Russell Ackoff can argue like no other for the idea that we are in the middle of a paradigm shift, in which we are moving away from the old Newtonian, or mechanistic, way of looking at the world, towards something else – something based on the realization of the importance of synthetic thinking.

Ackoff explains how analytical thinking can help us understand how something works, but it cannot help us understand why that same thing works the way it does. To understand the why, we need to look outside of that which we are inspecting – we need to look at its context.

For more on Russell Ackoff and systems thinking, check out these previous posts.

Mike Cohn on Agile Estimation

Author, consultant and speaker Mike Cohn has a twopart video out on YouTube. In it, he talks about his area of expertise – the planning and estimation of agile projects.

Mike will be visiting Sweden this fall, and do a couple of his popular courses, hosted by Citerus. Don’t miss out on this opportunity to learn about Mike’s accessible methods of planning agile projects – they will be an excellent addition to your toolbox.

Bring Yourself To Work Day

David Schmaltz, author of The Blind Men and the Elephant, and his wife Amy Schwab are introducing a “Bring Yourself To Work Day”. It seems it will occur on the fourth Thursday of May, which is the 24th this year. From http://www.bringyourselftoworkday.com/:

“Study after study finds the greatest barrier to increased productivity is not primitive process maturity but the inability of people to bring their full selves to work”

Don’t miss the preparation exercises (the links on the right hand side of the page)!

MVKJG 4: Gör en prioriterad lista

Att ha “för mycket att göra” är något som belönas i många sammanhang. Det ser helt enkelt rätt snyggt ut att ha mycket att göra, och en kort stund kan det kännas ganska bra också.

Tyvärr är “för mycket att göra” även ett utmärkt sätt att skjuta produktiviten i sank både för sig själv och för de man samarbetar med. Tråkigt nog (eller turligt nog, beroende på hur man ser på saken) brukar eventuella negativa sideffekter inte vara lika tydliga som svetten som stänker från den mer än fullt sysselsattes panna. De små, frekventa, och kanske lite imponerande stånken om att “det är så otroligt mycket just nu” gör också sitt till för att dölja det faktum att mycket är på gång men bara lite blir gjort.

Arbetsdagens längd varierar, men dygnet har exakt tjugofyra timmar, för åtminstone alla jag känner. Den som säger sig ha ont om tid menar alltså egentligen att det finns för mycket att göra. Någon gång då och då kan väl det problemet lösas med hjälp av en längre arbetsdag, men för de allra flesta producerar nog övertid mer magsår än affärsresultat.

Vad är alternativet till att jobba mer? Det är att lära sig hantera sin arbetsbelastning på ett sätt som ger resultat trots att tiden är begränsad.

Att lära sig hantera sin egen arbetsbelastning kräver två verktyg. Det ena är en personlig insikt om att den kortsiktiga nytta det innebär att “ha många bollar i luften” alldeles för ofta resulterar i långsiktig ineffektivitet. Det andra är förmågan att prioritera.

Lyckligtvis är inte båda dessa rekvisit lika svåruppnåeliga. Det ena av dem är faktiskt ganska lätt: att göra en prioriterad lista.

Varför göra en prioriterad lista? Tänk så här. Det är osannolikt att alla de saker du “måste” göra är lika viktiga. Alltså är vissa saker mindre viktiga än andra (dööh). De sakerna hamnar långt ned på listan.

Vad hamnar långt upp på listan? Längst upp på listan hamnar de saker som ger mest fyrverkerier för minst krut. Vissa kallar dessa saker lågt hängande frukt. Jag kallar dem ninjagrepp. Alla vet ju att de fruktade ninjorna (se upp för dem!) besitter kunskap om enkla grepp med dödlig effekt. Liten insats, hög verkningsgrad, eller på corporate-speak: bra nytto-kostnadsrelation.
Varför är det så effektivt att göra en prioriterad lista? Två saker gör metoden effektiv.

Här kommer den första: du kommer förmodligen ändå inte hinna göra allt du trodde du var tvungen att göra. När tiden är slut vill du självklart hellre ha gjort viktigare saker än mindre viktiga saker.

Här kommer den andra: när du gör en, rak och stilig, prioriterad lista så tvingas du göra svåra val. Två saker på en prioriterad lista kan nämligen aldrig (aldrig!) vara lika viktiga. Du måste välja. När vi verkligen måste välja tvingas vi tänka efter, och när vi tänker efter får vi mer kunskap om vad som är viktigt. Då ökar sannolikheten att när dagen eller projekttiden är slut, så har vi faktiskt åstadkommit något av värde både för oss själv och för andra.

Getting Started With Radiant

In the past, I have worked some with web content management systems. Both as a developer, and as a user. The state of the art can be summed up like this: web content management systems are typically crap. They seem to be written by developers for developers, not for fast and efficient publishing.

At Citerus, we still use a seemingly powerful but painfully unusable and inefficient CMS, for historical reasons. I have been looking around for an alternative for some time, but most of what I’ve tried so far suffers from the same issues: complicated user interface design.

I am now evaluating the Ruby on Rails-based Radiant. So far, things look good. Though it seems to lack well-written documentation, its simplicity makes it easy to get started with. It seems to have come about when the developers of the new ruby-lang site discovered that they, too, could not find a sensible content management system.

MVKJG 3: Intressera dig för dem du jobbar med

Det sägs att vi svenskar är svåra att lära känna, men att när man väl lärt känna oss är vi lojala vänner. Inget större fel med den approachen, slutresultat verkar ju bli bra. Ett problem finns dock. När vi är på jobbet har vi inte alltid flera månader eller år på oss att bygga upp relationer med varandra.

Bristen på tid, upplevd eller verklig spelar ingen roll, leder till ibland märkliga situationer. Som när en person i ledande befattning, något försenad såklart, stormar in i ett konferensrum och hälsar på en handfull människor han aldrig träffat förut med orden: – “Låt mig börja med att berätta hur vi ska göra saker på det här bygget”.

Kanske inte det bästa sättet att etablera en mänsklig relation. Kanske får vi inte alltid det gensvar vi förväntar oss när vi inleder nya relationer på ett sätt som förnekar vårt behov av djupare kontakt.

Låter det flummigt? Borde man inte kunna förvänta sig av relationer på jobbet att de är sakliga och professionella, snarare än djupa? Nej, ibland kanske man kan önska att det vore så, men jag tror inte man kan förvänta sig det. Jag tror inte ens att det är önskvärt.

Så måste man vara kompis med alla sina kollegor?

Nej, jag tror inte det. Men jag tror inte heller att man klarar sig helt utan djupare kontakt.

Genom sig själv känner man andra, lyder ordspråket. Tänk efter – hur reagerar du själv när någon du inte känner kommer till dig och ber dig om något? När en projektledare du aldrig träffat presenterar sig kortfattat, och berättar att du ska jobba med serverkoden, ger dig inloggningsuppgifter och försvinner?

Å andra sidan: hur reagerar du om någon du inte känner gör en uppenbart ytlig ansats att “intressera sig för dig”?

Personligen kräks jag lite lätt på båda tillvägagångssätten. Det första är kallt och obehagligt, det andra är sliskigt och beräknande.

Så vad är mellanläget? Vad är ett avslappnat sätt att lära känna sina kollegor, utan att det känns krystat och tillgjort?

Här är två saker som jag tycker fungerar ganska bra, och som du kan dra nytta av redan idag och utan att be om tillstånd.

För det första, och jag kommer inte ihåg var jag först hittade denna sköna slogan, men den är bra: “Warm-up is never wasted.” Inget möte blir bättre av att man hoppar över de inledande 2-3 minuterna småprat, hälsa (med handslag) på varandra, säga hej. Tvärtom, efter lite uppvärmning slappar gruppen som möts av, och resten av mötet blir effektivare.

För det andra: etablera relationen idag. Vänta inte tills du absolut måste. Hugg någon vid kaffemaskinen och prata en stund. Fråga vad de heter och vad de jobbar med. Kan de någon teknik du är nyfken på, eller har ni kanske gemensamma bekanta? Var har de pluggat?

Nysta lite. Krysta inte fram det, men var beredd på att du kanske måsta sträcka dig lite utanför komfortzonen, det måste i varje fall jag. Fråga om det du skulle vilja att någon frågade dig om.

Intressera dig för dina kollegor, så går arbetet lättare. Dessutom gör du en insats för att bryta legenden om svensken som svår att lära känna. Bara en sån sak.

Adobe Goes Agile, Makes Life Easier

In the article “Adobe edits the development cycle” on Regdeveloper, Mary Branscombe lets Adobe tell the story of how they switched to a more agile, incremental, development cycle. The result, according to Russell Williams of Adobe: “Better quality, plenty of features, fewer nights and weekends: what’s not to like?”

Note especially the focus on developing by feature and how the maintenance of excellent engineering practices makes this possible. “The goal is to always have the product in a state where we could say ‘pencils down. You have x weeks to fix the remaining bugs and ship it'”, says Williams.

Thanks to Jörgen Falk for the tip.