Tobias Fors

Category: Lean

  • Retrospektiv och kanban

    Visuell styrning med kanbantavlor är intressant. På Citerus har jag hjälpt till att få upp en kanban-liknande lösning för vårt säljarbete. Precis som många Scrumteam använder en planeringsvägg för sprintbackloggen och Excel eller ett webbverktyg för produktbackloggen använder vi väggen för den löpande säljuppföljningen, och Salesforce för långsiktig loggning och datalagring.

    För oss funkar ett kontinuerligt flöde som styrs med en kanban bra, eftersom vi har svårt att få till regelbundna möten på kontoret. Vi är ju oftast ut hos kunder och jobbar. Men, med kanbantavlan kan vi ändå få en bra överblick över säljarbetet.

    En fråga som nyligen dök upp på kanban-dev-listan på Yahoo var hur man hanterar retrospektiv, eller återblickar. Jag presenterade den lösning jag föreslagit hos oss, och som vi prövat. I den samlar vi helt enkelt upp saker som behöver reflekteras över i en sorts “hink” – i vårt fall en A3-lapp på väggen. När A3-arket är fullt är det dags för ett retrospektiv. På så vis får vi en naturlig stopp-punkt för reflektion trots att vi inte jobbar i rytmiska sprintar. Eric Landes på listan gillade idén och skrev lite om den på sin blogg, där han också länkar till diskussionen vi hade.

  • Self-Preserving Geese and Humans

    Clarke Ching on the TOC Thinkers blog has republished an article by Tony Rizzo. Rizzo takes us through a beautiful explanation of how we adapt to the contexts we exist in, and how those adaptations can be seen in how we behave. Just like we can learn about the rules of flying by observing how geese fly in v-formations, Rizzo explains, we can learn about the rules of an organization by watching how people in it behave. It’s a nice analogy. We behave like we do for a reason, and that reason is not to be found only within ourselves, but in the systems we live in.

    I like to invoke systems thinker Russell Ackoff’s advice when it comes to observing behavior: whenever you observe something that seems remarkable, incomprehensible or just plain weird to you, ask yourself what would have to be true for that behavior to be useful to the person exhibiting it. That’s how you can start building understanding for the other person’s reality.

    Of course, the reasons you come up with are only your wild speculations, so to really do something useful, you need to go ahead and follow the advice of another systems thinker, Jerry Weinberg: you need to check it out. You need to go ahead and describe your observations and how you interpret them to the one you observed, and ask if you are correct. Why, well, many things can go wrong when observing, so let’s just say you need some error correction, just to be safe. Learn more about Virginia Satir’s interaction model for a way to observe your own observations and interactions.

  • 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

     

  • More Poppendieck on Lean

    Here’s a new interview with Tom and Mary Poppendieck on the topic of lean software development. Thanks to Rickard Johansson for the tip!

    Around 25 minutes into the interview, the topic of RUP appears. Tom points out the amount of knowledge available in the RUP, but also how it has often been implemented with a focus on the specific practices, rather than on the principles that lie behind the RUP: iterative, incremental software development.

    This problem is not entirely unexpected, since people who need the guidance provided by the RUP manuals are probably not yet at a skill level where they can work from principles. When learning something new, we need rules and practices. Unfortunately, in projects and management, the same rules and practices will not work for everyone. A skilled practitioner knows this, and works from the principles he believes in to deduce practices that are useful in the current context. When people “implement” the RUP by copying practices without knowing why, problems are likely.

    At around 36 minutes, Mary discusses the difficulty of applying lean and agile over company borders. This is an interesting question, but one that needs some care. Any project run over company borders is challenging. Lean and agile have the nasty and necessary habit of talking openly about uncertainties and risk, and recommending transparency. Obviously, this will put a strain on any relationship between parties who are used to contracting defensively with each other.

  • Mary Poppendieck on “Competing on the Basis of Speed”

    In a new clip on Google Video, Mary Poppendieck talks about lean software development on the topic of competing on the basis of speed.

  • Interview with Don Reinertsen on Product Development

    Here’s an interview with Don Reinertsen, author of Developing Products in Half the Time and Managing the Design Factory.

  • Notes from the dark side

    Here’s an interview with a guy who worked for three years at a Toyota Group company. His experience is that lean is hard to understand outside the context of the Japanese work culture, in which long hours and less workforce mobility is common.

  • The Visible Planning Calendar

    Planning is great. Too bad it’s so hard. Too bad it so often results in weird plans and deadlines that jump around in the calendar like drunken fleas.

    Here’s an idea (yet untried by me) for a counter-measure: The Visible Planning Calendar. Goal: to make planning more transparent by at least making dates somewhat less jumpy. Contents: an agile, or at least iterative, development methodology, plus some extra rhytm to it.

    Just an idea. Inspired by others. Credit given in pdf above.

  • Spark rakt i varumärket

    Tjabbigt att behöva återkalla 987 000 bilar när man byggt så mycket av sitt varumärke på att vara kvalitetsmärket nummer ett. Ingen är felfri.

  • Where Did the Time Go?

    Efficiency in an iterative mode of working requires that we have little overhead in all our processes. For example, if building a release candidate takes us several days of manual work, we will have a hard time working in two week iterations, since so much of the iteration will be consumed by release work. Add to this slowness in detailing specifications and test cases, and we’ll get even less product created in the iteration. Then add cumbersome and manual design/coding (developers have not yet learned how to utilize whiteboards to visualize holistically, and refactoring tools to fluidly change the source code), and we start to understand why so many development organizations have a hard time adopting iterative modes of development.

    What to do? Well, for starters, maybe we can try to look at our organization and how we work, and see where the time goes. Create an overhead scorecard, a simple table outlining how long activities take. Or try the value stream mapping technique, in an attempt to really nail down how you spend your development time.

    Then, attack your worst bottleneck. And, no, you do not have to be an expert in theory of constraints or some other thinking technique. Just scrutinize your own behaviour, and do something about the things that look bad. The need for this way of approaching challenges is, paradoxically, becoming greater and greater in the software industry as ideas about new ways of working spread. I see lots of people interested in learning about things like Scrum, lean, theory of constraints (of which I know very little myself), test-driven development and so on, but when it comes to going home to your back yard and do some cleaning up, many fail.
    So: try approving a bit, pluck some low-hanging fruit (there’s typically lots of it). When you start to see the limits of this simple approach, go ahead and learn about advanced techniques. There’s lot to learn out there, but you don’t have to know it all to be able to improve.