Should we ban Kanban?

In the wake of organizations just beginning to reap benefits from agile practices, some of them are already starting to look for the next thing. A natural way to look now is towards Lean product development companies as they seem to have a firm grasp of development practices since decades ago that we in the software industry have been somewhat oblivious to.

Being an early adopter myself, it's hard to argue against trying out new stuff. But when it comes to organizations that find it too hard to navigate their political climate into adopting Scrum, I become a little concerned when they instead jump on flow development, which is inherently even more difficult to grasp and implement.

A brief look at Kanban

Kanban originally was a technique deviced by Toyota to allow workers at different stations in the production halls to signal upstream that more (or less) parts were needed, allowing the workers to control and maintain the optimal flow at any given time. Instead of just sending a note to Buck telling him to "hey, send me more parts, I'm running out", information about the velocity was added. "Hey Buck, why don't you send me five extra units as well, I'm picking up steam here".

The interesting thing about Kanban is when upper limits are applied, essentially giving a tool to limit work in progress thus constraining the flow to the theoretical (and indeed often practical) maximum.

Transferred to our world, one of the key benefits of Kanban limits is actually to stop us from working on too many things in parallel. It's actually faster to focus on finishing a few things instead of starting many things. I believe most people know this, deep within, but some of us still like to surround ourselves with freshly started projects and half-baked code rather than to actually finish some of it. Kanban limits helps us, in the smug way that only scientific arguments can have, to be faster at what we do, even when it feels counterintuitive.

There's just one catch. Kanban comes from manufacturing, not development.

In the world of software development, Kanban has almost become synonymous with "whiteboard". Blurring the concepts of visual planning and Kanban, the typical Kanban board in software departments now often consists of a backlog with sticky notes, and a number of stages the task will go through, each with a WIP limit stating the maximum number of open tasks allowed at that particular stage.

There are primarily two pitfalls to watch out for when trying this technique:

Variation in task size

A consequence of product development is the fact that tasks will not be uniform in size, and they may change in size during their lifetime. For a Kanban to work properly, all tasks need to be of a defined size and stay that way. It doesn't make much sense to have a WIP limit of three tasks at a certain stage, if the first task will take two hours and the other two three days each.

As Donald Reinertsen often likes to point out, much waste in product development actually comes from trying to minimize the variability of development tasks, instead of accepting and managing it. "Kanban" used this way may put focus back on trying to remove variability, in a bad way.

Handovers

Manufacturing may have handovers from one station to another, meaning that work in progress will pass through a number of stations on the way to become done. This is why I, and many others, have had success with implementing Kanban in support- and operations departments, where work is typically more consistent in size and has defined stages to go through.

In software development, much uncertainty and quality issues comes from the fact that we often organize from a manufacturing standpoint, where documents and half-baked code is passed from requirement specialists to designers, to coders, to QA and so on. Scrum has showed to many of us that it is more efficient and gives more control to work in cross-functional teams that are able and skilled to produce complete functionality, thus adding value to the product in small increments.

What worries me is that I start seeing "Kanban" boards appear in project rooms, that have states such as "Design", "Code", "Test" and "Ship" as states, thus implying a sequence of events and that different people will be doing different things to code as it flows through.

Congratulations, you've just re-invented waterfall development in your own organization, but under a new and catchy name.

Conclusion

I think it is time for me to finally answer the question posed by my headline: Should we ban Kanban?

The answer is: Of course not. It is a great tool when used under the proper circumstances. Just make sure you know why you use it, when to use it, and what results you expect from it.

Personally, I would be careful to use it for product development, unless tasks are well defined and has inherently low variability.

Using your Gmail as a simple mail Kanban

If you use Gmail, or any other similar web mail, you know how it works - instead of a scrolling list of mail, you get to choose to show 25, 50 or 100 mail per page.

I'm a fan of some aspects of GTD and the way to deal with mail in particular as it got me back in control of the constant inflow of mail to my mailbox for the first time in 20 years or so! But the fact that I had to switch between pages to get an overview of all my mail annoyed me, being an old (and avid) Outlook user.

Then I realized that this was in fact a Kanban limit. (Or a WIP limit to be precise, if we consider queued email to be constantly gnawing away at the back of our mind, stealing focus and causing stress)

Every time the number of email in your inbox reach your page setting (be it 25 if you are bold, or 50 if you are more like me), it's time to schedule a few minutes to process mail and empty the page. Or schedule an email-Pomodoro.

Off you go now, you have reached your mailban limit while reading this!

Enkel introduktion till lättrörlig produktutveckling

För verksamheter och företag som blivit nyfikna på vad som händer inom lättrörlig (agil) utveckling och hur de kan tillämpa praxis själva håller jag ett föredrag och grundutbildning om detta. Jag har destillerat ner de viktigaste delarna i en liten bok på 11 sidor med titeln Introduktion till lättrörlig produktutveckling med Lean och Scrum som du kan läsa eller ladda ned i PDF eller till din favoritläsare (jag använder själv Sonys PRS-600). I den sätter jag verktyg som Kanban, pulsmöten, visuell styrning i samband med att organisera, leda och arbeta i en lättrörlig verksamhet.

Är du nyfiken på mer? Boka mig eller någon av mina kollegor på Citerus.

Introduktion till lättrörlig utveckling

The Scrum Picture Debate

There's some discussion regarding the way Scrum is depicted in books and articles.

Although the difficult part about agile work should not be about a process image, I have to agree that I too found the pictures lacking somewhat in focus, always tending to convey the notion that stuff just went through the loops once. As air in a trombone.

In my published material and presentations, I have used this image for a number of years to illustrate Scrum. Sure, any talented art designer would make it much prettier in a moment, and I even left it in black and white (so you can fill in your own corporate colors and put it on the wall - I'm really in a sharing mood today!)

But aesthetics aside, it does help people understand and remember the important points of Scrum.

• There's the cycle of producing useful things ("Do" and "Release") and pausing for a moment to ponder how things are going, and ("Adjust") the work methods and environment to remove impediments for efficient work. I have given these aspects of the cycle equal weight in the image, to show how constant adjustment is an important part of Scrum.
• There's the daily/frequent synchronization of work, planning and prognoses ("Synchronize")
• The cycle itself causes a pull of useful things from the backlog, the flow being controlled and planned by the team ("Plan") and prioritized by the product owner ("Prioritize")

Note that I did not create specific images for the Scrum Master or product owner. They are of course at the table, close to the team, participating in all aspects of the Scrum cycle.

Software craftsmanship, and a bread machine

So, I bought myself a bread machine. Yes, I'm a sucker for useful technology, and if something catches my eye as an interesting use of technology, I'm already standing in line. Yes, I'm an early adopter, and with that comes equal amounts of frustration and joy.

In my closet of stuff that just didn't cut it lies the old DCC digital cassette recorders (yes, they were the only affordable digital medium at the time, but that didn't make them any better) , MiniDisc (just waiting for increased internet bandwidth to gobble it up) and my robot vacuum cleaner of which I actually have two, as I just couldn't let go of the idea even as the first one broke down from inhaling too much carpet hair and ... eh, dust.

So, where does the bread machine go? Well, actually it's not a particularly new technology, but rather something that has been around for 20 odd years, but dropped out of fashion during the '90s. Fond memories of waking up to fresh bread when I grew up has resurfaced lately. Surely, bread machines must have improved vastly over the last two decades.

So, setting out to buy my household another machine, I noted with amusement that there seems to be a newfound interest in bread machines, as the household stores now carry them, and most of the bigger (and some less known) brands now proudly display a breadmaker in their lineup.

What struck me first was the fact that they all look like buckets.

Glorified buckets, with a display, but buckets nonetheless. It became apparent that these are not machines that are supposed to be prominently displayed on your kitchen counter (unlike say, the espresso machine, which usually is designed to make all other kitchen utensils fade into the background). Instead, you are supposed to be slightly embarrassed to even own one, and they all come with a practical bucket-like handle so they can be quickly stoved away when not used.

I finally settled for a white bucket from OBH Nordica.

Eager to try it out as I came home, I immediately decided to program it to produce a french bread for breakfast the next day. Adding all the ingredients was simple enough, and then it's just the simple matter of selecting the bread type, size, crust, and finally my breakfast time...

And this is where things went wrong.

Instead of just entering the time as "9:00", I was presented with "3:50" in the display. Checking the manual revealed that this was the total baking time for this type of bread.

"Oh, jolly. It takes you 3 hours 50 to bake a french bread. Good for you. Now, where do I enter my breakfast time?"

Except I couldn't. According to the manual, I have to take the number of hours left to breakfast, subtract the total baking time, and give that number to the machine.

This is where it becomes ridiculous. I can imagine the product owner writing a user story going something like: As a consumer, I want to enter the time I want the bread to be ready, so that I can enjoy freshly baked bread for my breakfast.

The software engineer replies "Can't do it, it's too complicated. Why don't we just let the user punch in the number of minutes left, that way we can just reuse the timer class. Makes the code simpler too, less bugs you know"

Hold on, it gets worse.

At 5 in the morning, I was unexpectedly woken up by a number of adamant, loud, angry beeps from the kitchen. I got up in a hurry, concerned that some kind of error had occurred with the baking process.

It turns out that this is standard procedure. Before starting the second kneading cycle, the machine can alert us if we want to open the hatch (open the pod bay door, Hal) to insert fruit or other late ingredients to the dough.

So, naturally, I looked for the setting to switch it off. And of course, there isn't one.

Incredulously, I checked the FAQ section of the manual. And, there, among a row of queries as asked by the tentative user:

"Question: Can you shut off or lower the noise of the beep signal?"

"Answer: No unfortunately not. The sound level is pre-set and meant to be heard during day time when you have a lot of noises around you."

This rates among the worst excuses I've heard yet. Either a) there was an outcry of users who does not have the kitchen in the west wing separated by sound-proof walls from the bedroom or b) they realized themselves that this was indeed a stupid feature, and had the poor tech writer try to prevent the storm by "explaining" it in the manual.

To be a bit more honest, the proper answer should probably have been:

"Answer: No, because we forgot that user story, since we don't use our own products nor test them in user conditions. " or possibly:

"Answer: No, because our programmers were rushed to write the software in two days after we had let our other engineers perfect the oven/kneader/control design for months"

This might be a silly example to some of you. But it just continue to display the immaturity of software product development compared to other development professions. It is just yet another oh so tiresome example (YAOSTE) of how we bolt software onto the final product as a kludge that must be there, and it is costly too.

And if you don't believe me, it's 2010 now, and we still have new operating systems that are still allowed to surprise you by opening a new window on top of the password dialog you're just typing into. (And if your password contains the letter 'y', let's hope that the dialog that suddenly appeared and disappeared didn't just ask you permission to post all your private pics on to Facebook)

It's 2010! We have to be better at doing these things, and we need to start getting better now! According to Clarke, we're supposed to go to Jupiter with the aid of advanced software, clever software, that will lay out the course for us and plan the trip, without asking us to subtract Jupiter's gravity coefficient from the wanted arrival date manually! Making sure in every way that the mission is not at risk...

...hey... wait a minute....

Långa krav och korta sprintar

I morse satt jag och filosoferade över en kopp kaffe med Björn, som är utvecklingschef. Specifikt kom vi att diskutera något som är lite av ett återkommande tema; hur hanterar man krav som kräver så mycket analys att man inte hinner göra klar funktionalitet under sprinten?

Verksamheten i stort kan vara överens om en viss sprintlängd. Men ibland kan den tyckas för kort för vissa utvecklingsinsatser som kräver en större del förundersökning och analys. Det kan få effekten att man ägnar sprintplaneringen åt större analysarbete, vilket i sin tur gör att den kan bli väldigt lång, och sprinten känns som ett litet vattenfall.

"Kan man leverera och demonstrera delresultat vid slutet av en sprint? Ska vi inte alltid visa upp affärsnytta?"

Jo, förvisso. Men bedömningen av vad som är affärsnytta görs ju av produktägaren - och om produktägaren ser ett värde i att få strategiskt underlag för vägval i kommande sprintar, så är ju det gott nog. Om vi dessutom lyckas leverera något övrigt i form av funktion eller kvalitet som har affärsnytta så är det ju utmärkt!

Att ständigt försöka leverera ett klart men inte komplett system efter varje sprint är ett sätt för oss att bygga in många aspekter av taktat arbete i verksamheten. Därför ska vårt rättesnöre vara att försöka bryta ned problem till "sprintformat" så långt möjligt. Men i lägen där vi har svårt att uppskatta storleken på ett krav, är det betydligt mer relevant att försöka uppskatta storleken på att utreda kravet och ta fram lösningsförslag, gärna med ett provskott, och lägga in det som en arbetspunkt i sprinten.

Upskattningar måste tillåtas vara av inkrementell och iterativ karaktär, precis som annat arbete. Det innebär att skattningen vi gjorde på hög nivå, för att se vilken härad en uppgift skulle kunna vara inom (dagar? månad? år?) kan behöva förbättras i en senare sprint och det är ett arbete i sig, som ska tidsuppskattas och planeras i en sprint. Erfarna utvecklare arbetar med min/max/medelestimat och liknande tekniker för tidsuppskattningar.

Jag mindes ett tillfälle då jag coachade ett team som frågade mig när reder vi ut saker egentligen. Pedagogiskt (tyckte jag) att jag svarade med motfrågan "när brukar ni reda ut saker?" Svaret överraskade mig:

"Vi brukar förväntas göra det på annan tid"

Vilken annan tid? Det visade sig att verksamheten var så van vid att tidsestimaten skulle baseras på att koda funktioner, att teamet ägnade kvällar och i vissa fall helger åt att reda ut hur de skulle implementeras! Dolda-kostnader-sirenen ljöd plötsligt över kontorslandskapet!

Ni kan tro att det blev en smärre initial chock när vi började synliggöra den faktiska kostnaden för utvecklingsarbetet genom att börja planera in utredningsarbete i sprintarna.

Tillbaks till min gode vän Björn. Han uttryckte det på ett bättre sätt än jag själv någonsin kunnat göra det, så jag återger det här:

"Jag antar att vi kan välja mellan två angreppssätt, och låta tillfället och uppgiften styra.

Antingen kan vi betrakta vissa typer av utredningar som hinder för effektiv mjukvaruproduktion, och därigenom avsätta tid i sprintarna för att röja undan dessa hinder.

Eller så betraktar vi resultatet av vissa utredningar som nytta, som produktägaren kan förstå och prioritera som separata arbetsinsatser med leverabler i form av resultat"

Lättrörlig kravhantering med Wiki

Idag blev jag ombedd att dela med mig av råd och erfarenheter rörande lättrörlig kravhantering i praktiken - vilka verktyg ska man använda, hur hanterar man nedbrytning, spårning mellan krav och specifikationer, osv.

Frågan har kommit upp många gånger förut, och det lustiga är att den mest effektiva lösningen jag varit med och skapat var också den allra första.

När jag som projektledare en gång började experimentera med XP och Scrum var jag tämligen skeptisk mot de kravhanteringsverktyg jag upplevt dittills, och var måttligt sugen på att brottas med de jag hade tillgång till eller lära mig något nytt. Och då har jag inte ens pratat om hur svårt det var att få mitt än mer skeptiska utvecklingsteam att dokumentera i det verktyget. (Som givetvis var så dyrt att vi inte kunde ha licenser till alla, vilket skapade ett alltför bra dåligt exempel på köteori i praktiken)

Någon i teamet föreslog att vi skulle skapa en Wiki för kraven istället. Jag lät mig lätt övertalas, och förundrades över hur denna konkurrent till det hårt reglerade intranätet snabbt växte till en överblick över projektläget.

Den första sidan innehöll en kort beskrivning av projektet. Den fylldes snart på med en produktbacklog, som helt enkelt utgjordes av en lista med alla högnivåkrav. Listan kunde enkelt exporteras till Excel för de traditionella (slöseri-)rapporterna o dyl.

Efter ett tag började saker på produktbackloggen förvandlas till länkar, i takt med att teamet började planera upp nästa sprint. Varje länkat krav pekade på en sida som innehöll kravnedbrytning och mål för kravet. I takt med att kraven började bli implementationsfärdiga växte teknisk dokumentation som skildrade lösningsförslaget in, och tekniska specifikationer länkades in.

Det riktigt intressanta hände när teamet började blogga om arbetet med varje krav på respektive undersida. Resonemang kring valda lösningar, och hur de skulle testas (och resultatet av tester och eventuella korrigeringar) vävdes in i bloggen av deltagarna, och växte snart till en sökbar kunskapsdatabas om de olika funktionerna i systemet. Delar av ledningen började intressera sig för detta nya "projektintranät", och när CTO glatt deklarerade på ett fredagsfika att han såg fram emot att läsa om nya utmaningar och lösningar på wikin eldade det förstås på motivationen än mer hos alla inblandade!

Själv var jag förundrad. Visserligen hade både personalchef och några andra intressenter uttryckt oro för att detta inte skulle fungera utan en redaktör - men själva naturen av egenmoderering verkade fungera utmärkt utan uppmaning - sidor som blev pratiga, svåröverskådliga eller helt enkelt för stora sammanfattades eller bröts ned till mer fokuserade avsnitt. Och till och med Anders, en av de mer erfarna och skickliga utvecklarna i teamet, som var notorisk för att ogilla dokumentation i alla former, satt nu ofta och skrev koncisa och förträffliga sidor om designval och lösningsförslag - inte utan en viss lakonisk ton.

Genom det kollektiva ägandet följde också ett kollektivt ansvarskännande. Då flera projektexterna parter gärna följde wikin var deltagarna måna om att hålla den läsbar och nyttig, och det fanns aldrig någon redaktör som var flaskhals, eller för få licenser som ställer till kö och glömda uppdateringar.

Efter några spännande kursändringar i verksamheten fanns en reell möjlighet att projektet skulle utsättas för en granskning av FDA. Eftersom de ställer mycket hårda krav på mjukvaruutveckling (dock mer i form av process än kvalitet, men ändå) anlitade vi en specialist från USA som skulle gå igenom våra arbetssätt och dokument inför en eventuell granskning. Det blev förstås viss oro och tandagnisslan från ledningen som förfasade sig över att vi hade så lite dokumentation utskriven i pärmar. Nå, för-granskningen genomfördes, och experten granskade vår wiki med nyfiket intresse - och godkände den, eftersom den enligt honom uppfyllde samtliga krav inför en fullständig granskning:

1. Wikin säkerhetskopierades automatiskt och regelbundet
2. Inloggning krävdes för att göra ändringar, vilket ger spårbarhet på ändringarna
3. Den versionshanterades automatiskt, vilket ledde till att information inte kunde gå förlorad genom misstag.

Detta var många år sedan, och wikitekniken var betydligt mer exotisk då. Idag finns många att välja på, och exempelvis kan man få backlogtabeller som enkelt kan prioriteras om genom att dra och flytta elementen direkt i listan, och man kan ofta utbyta data enkelt mellan exempelvis Office och wiki. Det finns wikis som är specialgjorda för att ha en hög andel grafiskt innehåll för publikation, och wikis man enkelt kan ladda ned till ett USB-minne och flytta med sig på det sättet.

...

Efter denna framgång har jag använt wiki med lyckat resultat i många sammanhang. Ibland finns det en it-avdelning eller informationsansvarig (eller metodchef) som av någon anledning försöker bromsa det hela, och då har vi skapat en server lokalt i vår projektmiljö och satt upp den där. I två fall har t.o.m. den blygsamma projektwikin med tiden kommit att ersätta det tröga och svåradministrerade intranätet!

Ibland kan en wiki bli vildvuxen eller yvig, och det är ofta ett tecken på att ansvarskännandet för wikin gått ned - antingen börjar informationen bli gammal och sällan använd, eller så är helt enkelt inte tillräckligt många intresserade av den. Då kan det vara läge att arkivera den och börja om!