Tobias Fors

I det förra inlägget skrev jag om bakgrunden till att jag börjat arbeta med visuell styrning med kanban. Det här inlägget ger en första titt på verktygen vi kan använda.

Utöver ett uppdrag att slutföra och kunskap om hur kanban fungerar behövs följande för att komma igång med en egen kanbantavla:

• En rymlig whiteboard med tillhörande pennor
• Post-its i olika färger
• Pennor som det går att skriva tydligt på post-its med (vanliga bläck eller blyertspennor ger så tunn skrift att det blir svårt att läsa vad det står när man står en bit från whiteboarden)

Att jobba med en kanbantavla (för till exempel sitt drifts- eller supportteam) handlar om att synliggöra sitt arbete så att man istället för överbelastning kan ha rätt mängd arbete igång, och därmed få fler saker klara snabbt och med rätt kvalitet.

Vi använder post-its (eller något annat flyttbart) för att dokumentera vad vi jobbar med - en sak per lapp. Målet är inte att dokumentera varenda liten sak som görs. Tvärtom funkar det hela bäst om man på lapparna skriver ned små nyttiga delresultat, snarare än aktiviteter.

Arbetets aktuella status visar vi genom att placera våra lappar på rätt ställe på whiteboarden. På den har vi nämligen ritat upp vår grupps arbetsprocess, så att lapparna kan sättas i kolumner som visar de olika steg arbetet går igenom, från ax till limpa.

Vi vet att kanbantavlan börjar fungera när vi med en snabb blick kan se vilket arbete som väntar, vad som pågår, och vad som gjorts klart. Från dag till dag kan vi lapparna röra sig över tavlan, från en kort prioriterad lista, genom de olika stegen i arbetsprocessen, på väg mot leveransklara resultat.

En whiteboard och post-its kanske verkar vara primitiva vertyg? Det stämmer, och det är helt avsiktligt. De är nämligen också mycket kraftfulla.

Genom att använda dessa enkla verktyg gör vi det lätt att anpassa vår process när vi märker att det behövs - det kostar bara lite suddande, omritande och lappflyttande. Med andra ord hindras inte våra förbättringsambitioner av att verktyget inte hänger med i svängarna (något som i min erfarenhet händer oftare än vad som är önskvärt). Med andra ord: Ingen hittar den optimala arbetsprocessen på första försöket. Verktygen finns till för att stötta processen. Därför måste det vara lätt att justera verktygen.

När synligheten är stor är det också lättare för var och en att veta var man kan hjälpa till. Gruppen får tydliga signaler när den behöver samarbeta för att lösa problem. Hur klyschigt det än kan låta så är ett team mer än summan av sina medlemmar. En grupp som lär sig samarbeta effektivt, till exempel med hjälp av en kanban-tavla, har tagit ett steg på vägen mot att bli ett effektivt team. Ett team låter inte sina medlemmar kämpa ensamma, det kliver in och hjälper individen att komma vidare och växa. Alla verktyg som kan hjälpa oss att komma närmare det idealet är värda en andra titt.

Använder du visuell styrning med enkla verktyg? Vad är dina bästa tips?

De senaste åren har jag jobbat med att hjälpa team och organisationer att förstå och använda Scrum. Jag har jobbat en hel del med produktutvecklande företag, och det är i utvecklingsarbete Scrum verkligen kommer till sin fulla rätt. Samtidigt består arbetet med att lansera mjukvaruprodukter av så mycket mer än bara själva utvecklingen. Drift, support och marknadsföring är några exempel på aktiviteter som är avgörande för framgång.

Förra hösten åt jag lunch med en branschkollega på en restaurang i Uppsala och vi pratade om hur det gick för deras utvecklingsteam, som nyligen börjat använda Scrum. Det gick utmärkt. Arbetet var fokuserat och tydligt, och man hade lyckats genomföra ett komplext projekt framgångsrikt.

Samtidigt kände man på driftssidan att man ville ha ett lika engagerande och tydligt sätt att styra och följa upp sitt arbete. Jag berättade om något jag studerade just då - visuell styrning med kanban. Så vitt jag kunde se var de bakomliggande principerna sådana vi känner igen från Scrum, även om de praktiska handgreppen ibland ser lite annorlunda ut. Vi kom överens om att försöka få till ett kort och fokuserat samarbete för att få till en kanbanlösning för deras driftsgrupp. På så vis skulle även de kunna dra nytta av tankarna bakom Scrum.

Kanban är japanska, och betyder till vardags helt enkelt skylt eller tavla. Inom tillverkningsindustrin har begreppet däremot fått en mer specifik betydelse. Där betyder kanban ett signalsystem som styr flödet i produktionen. Jag är absolut ingen expert på industriell produktion, men jag kan göra ett försök att förklara systemet som jag förstått det.

Här är ett konkret exempel. En person som arbetar med att montera en komponent för en viss maskin behöver en mängd olika delar för att kunna göra sitt jobb. Hur många av varje? Det skulle man kunna försöka styra med ett avancerat datorsystem som prognosticerar behoven framöver. Eller så använder man kanban.

I ett kanbansystem signalerar varje del i en produktionskedja sitt behov av nytt material från ett föregående steg genom att tydligt flagga upp behovet. Rent praktiskt kan signaleringen ske genom att en låda med delar tömts, och därför skickas för påfyllning tillsammans med ett litet instruktionskort - en kanban - till den som kan fylla på lådan. Lådan fylls, och skickas tillbaks till beställaren. På samma sätt fortsätter beställningarna “bakåt” i produktionsledet. Fördelen? Processen styrs efter behov istället för efter spekulativa prognoser. Kanban blir därför en nyckelteknik i Just-in-Time-processer.

Så vad har kanban att göra med till exempel drift av mjukvara? Vi kan inspireras av metoden för att styra och följa upp arbetet i till exempel en driftsgrupp på ett sätt som är både tydligt och enkelt.

Våra kanban blir helt vanliga post-it-lappar som vi flyttar på en whiteboard. Whiteboarden designar vi för att ge en helikopterbild av arbetsprocessen. Resultatet: ungefär samma som när vi sätter upp sprintbackloggen på väggen och får en visuell sprintbacklogg, men anpassat för den typ av situation som till exempel ett drifts- eller supportteam befinner sig i. En vanlig invändning mot Scrum från denna typ av grupper är att det är svårt att få till iterationer, eftersom man arbetar så reaktivt med plötsligt inkommande saker. Mot det kan man förstås invända att man då borde fokusera på att eliminera så många oväntade saker som möjligt, och det är väl rätt i teorin. I praktiken måste man förstås ända styra arbetet under tiden, och varje sätt att få mer fokus och lite lugn och ro kanske gör det lite lättare att faktiskt börja eliminera rotorsaker till problem. Kanban kan vara ett sådant verktyg.

Med kanbantavlan blir det lättare för samtliga i arbetsgruppen att se vilket arbete som väntar, vad som pågår, och vad som är på väg att göras klart. Gruppen får också lättare att ta på sig rätt mängd arbete vid varje givet tillfälle, något som är viktigt inte bara för att undvika utbrändhet, utan också av mer kortsiktigt ekonomiska skäl. Man får helt enkelt mer klart om man undviker att överbelasta sig, och kvaliteten på arbetet blir högre.

För gruppens intressenter (t.ex. mottagare av de arbetsresultat gruppen levererar) finns också fördelar, som att det blir lättare att se status på arbetet. När synligheten ökar minskar ofta stressen. Det är helt enkelt svårare att bli stressad när man känner att man har koll på läget. När stressen minskar ökar lugnet, och vi fattar som regel bättre beslut när vi är lugna än när vi är uppjagade.

I nästa bloggpost tänkte jag skriva lite om hur det kan se ut rent praktiskt.

Känner du till en arbetsgrupp som skulle vilja dra nytta av fördelarna med att jobba lättrörligt, men som inte riktigt känner att Scrum passar perfekt? Hur gör de för att få bästa möjliga delaktighet och tydlighet?

This article by Dave West on InfoQ might be an interesting read if you’re interested in theories of software development.

“Both Lean and Agile must stop applying, in a literal and rote manner, the tools and practices. Tools and practices are nothing more than expressions of values, principles and philosophy. They are not the only possible expressions and may not even be the best expressions. Neither side will be able to realize their respective founders’ admonition to “use, adapt, and transcend” until and unless they come to understand why the practices and tools are what they are.”

In today’s Computer Sweden, Ivar Jacobsson plugs his company’s latest offerings and requests a theory of software development. I haven’t tried his latest products, so I won’t comment on them. They might be great. However, one thing that puzzles me about the article is the absence of anything concerning useful theories applicable for software development.

Ivar Jacobsson rails at the prevalance of practices but, at least in this article, doesn’t even come close to touching on any relevant theories. Instead, it seems to me that he promotes even more practices. I’m sure things will clear up for me once I get my hands on his latest toolbox. Unless, of course, I have to pay a lot of cash to get it, in which case I probably won’t get my hands on it.

In that case, I might just spend my time by learning a bit more from those who seem to come closer to a set of working theories useful for understanding software development work. Like Gregory Howell and Lauri Koskela, in their provocatively titled paper “The Theory of Project Management is Obsolete”. Or like Don Reinertsen, who uses queueing theory to understand certain aspects of getting stuff out the door. Or like Mary Poppendieck, who also likes lean thinking and has made her own attempt at translating those thoughts to our world. I’m not sure these three would necessarily agree with each other if they met, but they are trying to find new ways of understanding the theoretical underpinnings of development work.

Clarke Ching has written a nice little piece that’s available as an online read on Slideshare, and embedded below. It’s short and plain enough that it has the potential of becoming widely read. I’m predicting it will spread quite fast. Executive summary: releasing wanted software soon and frequently ties up capital for shorter durations, which is A Good Thing in cash-tight times.

David Schmaltz writes:

“Within SEI, there were (probably still are) two factions. I heard (just hearsay) that two principals at SEI approached two of the Agile Manifesto signatories to wish them luck shortly after the manifesto was made public. Apparently they had carried the same intentions in founding the SEI, but were compromised when the suits showed up.”

I have no idea whether this specific story is true or not, but I wouldn’t be the least surprised, because this is something that seems to be happening all the time. It’s probably a part of How Things Are. Something new starts growing, and as attempts are made to describe and spread that new thing, it gradually changes from being new to being something stale and overly simplified. In fact, the very things needed to spread that new thing are the same things that prevent it from staying fresh. So the new things dies - or rather transmutes into a new form. Gradually, the pressure builds for some other new thing to emerge, and eventually it does. When the changes are great, the transitions are painful.

So what can you do? I’ll tell you what I will do. I will keep checking my value compass, and if it shows me running off into the wild as I blindly follow my practice map, I’ll trust my compass over my map.

David concludes, in the comments to the post:

“I’ll serve spaghetti with sourkraut if I’m hungry and that’s what’s in the pantry. This because whenever a method gets embraced ideologically, whatever the method, the result is exactly the same. Mindfulness replaced by certainty. Thoughtfulness replaced by enforcement. Degrees of freedom transformed into degrees of imprisonment.”

- - -

Why not read a little tonight?

• The Blind Men and the Elephant: Mastering Project Work
• Secrets of Consulting: A Guide to Giving and Getting Advice Successfully
• The Structure of Scientific Revolutions
• General Principles of Systems Design
• The Fifth Discipline: The Art & Practice of The Learning Organization
• Beating the System: Using Creativity to Outsmart Bureaucracies (”Surprise or the unexpected is the bête noire of the typical bureaucrat and others whose sole purpose is to guard and defend to the metaphorical death the status quo. Their modus operandi is unidimensional, namely, the usual and conventional ways of doing things; deviation or variation in any fashion is to be fought against, even when the deviation makes matters better. Surprise, then, is the Achilles’ heel of the bureaucrat.”)

I’m back from a course in Stockholm on the topic of lean software development. While it was definitely not a waste of my time, it’s lack of depth and long lectures disappointed and puzzled me. Longing to learn some new stuff, I spent some time tonight googling for articles about, or written by, systems thinker Russell Ackoff. Coincidentally, I found a good article that managed to touch both a lean concept (although the moniker “lean” had yet to be adopted when the article was written) and mention Ackoff. What I found was a funny piece on some of the practical applications of queueing theory from the September 25, 1988, edition of the New York Times.

“One way to take some of the sting out of waiting is to entertain customers. Since 1959, the Manhattan Savings Bank has offered live entertainment during the frenzied noontime hours. In 13 branches, a pianist performs and one branch has an organ player (Willard Denton, the former Chemical chairman who dreamed up the idea, liked organs, though present management thinks they are a trifle loud for a bank). Occasionally, to make line-waiting even more wonderful, Manhattan Savings has scheduled events such as a fancy-cat exhibit, a purebred dog show and a boat show.”

I also came across an elegant article about the differences between push and pull.

“Now reverse the logic. Suppose the customer pulls the product or service required through your system. Because you’re making what someone has actually ordered, you don’t have to guess or predict sales and production. You don’t have to add extra features or colours to tempt people to buy. If you’re not making things on spec, you don’t need the space, computers or people to store and track the inventory. “

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.

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.

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