Leanspired

På språng!

2012-01-13T09:00:00.000+01:00

Det var ett tag sedan jag bloggade något nu. Ibland beror sådant på att entusiasmen brunnit ut, eller att man sysslar med något annat nu. Eller så kan det bero på tidsbrist, och det är ofta ett gott skäl (även om jag tillhör skaran som tycker att man måste avsätta tid för allt som är viktigt, hur var det nu?)

I mitt fall är det definitivt det senare. Jag har nämligen varit med och startat Levla AB! Namnet kommer av det lätt svengelska uttrycket "levla" som är taget från den engelska termen "level up" som i spelvärlden helt enkelt betyder att nå en ny nivå, att utvecklas och bli bättre. Detta speglar förstås vår idé, som är att arbeta med att hjälpa svensk industri att "levla upp". Och som VD, verksamhetskonsult, och i förekommande fall även webbmaster (jag jobbade med webb senast runt 1996, så ni anar ju att det hänt ett och annat sedan dess) tenderar tiden tyvärr att rinna iväg så här i början. Men, nu är vi uppe och i full gång sedan en dryg månad!

Det blir en blandning av gammalt och nytt. Gammalt, i det att jag fortsätter att arbeta som rådgivare, mentor och utbildare inom lättrörlig verksamhetsutveckling. Men nytt i att jag i högre grad införlivar kunskap och erfarenhet från Lean produktutveckling tillsammans med de agila ramverken, och med det följer bl.a. nya utbildningar i vår.

Sajten är en smula .. sparsmakad .. nu i början. En god vän sa snällt att den var "affärsmässig" (med en smiley) Men eftersom jag är en stark anhängare av iterativt arbete så är det ju inte mer än rätt att även arbeta iterativt med sin webbplats, eller hur?

Därmed passar jag också på att puffa för min nästa utbildning för produktägare, den populära CSPO (Certifierad Produktägare i Scrum) som går av stapeln 13-14 februari på Freys i Stockholm. Läs mer om utbildningen eller anmäl dig direkt.

On the Fractal Nature of Agile and Lean Product Development

2011-09-13T18:27:00.001+02:00

I'm giving a keynote on LPPDE in Gothenburg next week on the topic of similarities and differences between how LPD and Agile Product Development is being implemented currently in companies in Sweden. As interesting stuff happens in the borderline where Lean meets Scrum in some organizations, I found that fractals actually gives a fun way of describing it!

If you think that this sounds too mathematical, or too goofy for you, don't worry. It's not that theoretical, and just a bit goofy. As it is a morning session, I guess the right balance will be struck if I notice that people stay awake.

For those of you who won't be joining the session or the discussion afterwards, I'll post a summary of the talk as a blog post here later.

Konferens: LESS is more!

2011-08-03T13:41:00.005+02:00

Sakta börjar folk återvända från semestern, och om det känns en smula vemodigt så kan det vara bra att ha något att se fram emot. En av de mest spännande saker som är under utveckling när det gäller företag med mjukvaruutveckling är hur agila arbetssätt möter lean. "Lean" finns även som samlingsnamn för ett antal principer rörande produktutveckling, och kallas då ofta populärt LPD, Lean Product Development.

Jag arbetar själv idag i gränslandet mellan Lean, Scrum och XP, och kombinationen är så kraftfull, att ämnet förtjänar att studeras närmare. Därför börjar det nu dyka upp konferenser på temat, där nya studier och forskning varvas med vittnesmål om införanden, för- och nackdelar. Jag var med och drog igång Lean and Agile Software Development för några år sedan, och nu har en ännu ambitiösare samlingspunkt startats med högre internationellt fokus. Den går under namnet LESS (Lean Enterprise Software and Systems), och i år är Stockholm värd för evenemanget, med talare som Jean Tabaka, James Sutton och Steve Denning på listan.

Men- vi behöver fler talare! Alltså är du välkommen att sända in förslag på vad du vill dela med dig av, eller byta erfarenheter om. Och vill du bara komma på konferensen och vara med där det händer inom mjukvaruutveckling just nu, så går det förstås bra också.

Läs mer på den officiella sidan för LESS2011 och om du vill dela med dig av din erfarenhet kan du göra det här eller genom att kontakta mig!

Konferensen pågår mellan 30/10-2/11.

Konferens om Lean och Agile i Stockholm

2011-03-17T10:35:00.003+01:00

Mina vänner på Teknologisk Institut har engagerat några av de främsta utövarna av Lean och Agile till en konferens som går av stapeln 29-30 mars i Stockholm. Det blir förhållandevis mycket praktik, relativt liten dos av teoretiska utsvävningar, och möjlighet att få träffa Don Reinertsen som ger sin syn på lättrörlig produktutveckling.

(Dessutom kommer jag att gnabbas med experter på scen om likheter och skillnader mellan Lean och Agile, det blir spännande att se vad som kommer ut av det)

Läs mer här och innan du klickar på anmälan, kontakta mig, så ordnar jag 30% rabatt på priset eftersom du läser min blogg :)

Should we ban Kanban?

2010-03-30T07:55:00.009+02:00

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

2010-03-22T19:58:00.004+01:00

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

2010-02-25T17:14:00.004+01:00

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

2010-02-10T18:40:00.003+01:00

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

2010-01-27T11:41:00.009+01:00

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

2009-11-06T09:21:00.007+01:00

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

2009-09-30T18:32:00.004+02:00

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:

Wikin säkerhetskopierades automatiskt och regelbundet
Inloggning krävdes för att göra ändringar, vilket ger spårbarhet på ändringarna
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!

For English Readers

2009-09-14T21:17:00.003+02:00

I've added the attribute "In English" to the appropriate blog posts, as I do write some articles in English, and I have a few non-Swedish readers that can now filter stuff that is readable to them. Yes, it's an obvious thing, but I didn't think of it until now. And when I improve my Mandarin, I hope to add that as well. In a decade, or so... :)

Gästblogg på ProjectPlace

2009-06-26T23:19:00.002+02:00

Jag har blivit ombedd att gästblogga hos ProjectPlace. Du kan hitta mitt senaste blogginlägg här, och det är en sammanfattning av det föredrag jag höll om den lättrörliga organisationen på Projektverktygsdagen '09.

Det var en rolig sammankomst, speciellt för en verktygsagnostiker som mig, och jag fick möjlighet att träffa Tomas Gustavsson, som är en kunnig förespråkare för lättrörliga arbetssätt och deras plats i projektarbetet.

Tomas har skrivit en bok om lättrörliga arbetssätt som jag vill lyfta fram som en av de bättre grundläggande introduktionerna på svenska. En recension kommer!

A domain expert shares his views on requirements

2009-05-20T23:42:00.005+02:00

Ableton is a German company that has created one of the first virtual studios that blur the distinction between a music instrument and a recording studio, Ableton Live.

It's a software product that challenges the notion of "traditional" music recording, and as an avid user, I can vouch for the inspiration that comes from being able to create a performance out of a recording, and vice versa, without boundaries.

In this article, Robert Henke, musician and one of the founders of Ableton gives a small glimpse of his view on requirements specification as a domain expert, together with the software developers, and how it should capture both innovation and customer needs. And yes, most of it is readable even if you're not a music geek, like me :-)

"Specification is a huge area, ranging from tiny little but important details to big general questions. Specification is the most exciting, most annoying, most rewarding and most frustrating job in the software world."

Insikter från spelindustrin

2009-05-03T09:53:00.007+02:00

Jag har förmånen att arbeta med spelindustrin då och då, och det är alltid lika inspirerande. Nätbaserade spel som driftas på egna eller partners sajter utvecklas ofta i hög grad iterativt, med täta driftsättningar av nya funktioner till användarna, medan PC- och konsollspel har mer traditionella inslag, där projekten sträcker sig över något år, med en tydlig leverans i slutet och varierande grader av hierarki beroende på inblandning från filmindustrin.

Det som är utmärkande i dessa företag är att man har ganska få dåliga ovanor som "sitter i väggarna" och är förhållandevis öppna för att både lära sig beprövade praxis som att pröva nya grepp, och detta kan man låta sig inspireras av, vare sig man är intresserad av industrin som sådan eller ej - det är i övrigt stora likheter mellan de utmaningar som finns här som i andra produktutvecklande företag.

Inom spelindustrin är Shigeru Miyamoto en förgrundsfigur, som har skapat spel och figurer som blivit välkända för många och bidragit till Nintendos starka varumärke.

I sin keynote på GDC 2009 berättade Nintendos VD Satoru Iwata lite om de arbetssätt Miyamoto använt för sin framgång. Här finns en kort sammanfattning av hela föredraget, men detta är några saker jag tyckte var intressanta:

Man har konstaterat att fokus på deadlines framför kvalitet leder till en negativ utveckling för företaget på längre sikt (Iwata kallar det torrt för "Death Spiral").
Förtroendet finns från ledningen att utvecklingsteam kommer att färdigställa säljande produkter.
Det är viktigt att hålla flera koncept öppna en bit in i utvecklingen och låta utvecklingsteam pröva olika idéer och vägar till målet
Små team som prövar sig fram är effektiva jämfört med större team
Idéer kasseras inte, utan sparas för framtida utvärdering även om de inte kommer med i just den produkt som utvecklas för tillfället
Produkten under utveckling testas ofta av kunder och representanter. Man kan hantera såväl att visa upp (och kritisera) ofärdiga koncept som de kursändringar kritiken kan innebära

Produktägare i Scrum

2009-04-16T16:03:00.002+02:00

I takt med att intresset för lättrörliga arbetssätt med inslag av såväl Lean, Scrum som XP ökar, märker jag också ett ökat intresse och nyfikenhet från affärssidan i många verksamheter. Förståelsen för att dessa synsätt och tekniker kan tillämpas i organisationen i stort ökar, och sträcker sig idag bortom utvecklingsavdelningen. Detta ser jag som positivt, eftersom jag anser att det är en konkurrensfördel att ha ett tätt samarbete mellan marknads- och utvecklingssidan i verksamheten.

I arbetet med att sprida kunskapen ytterligare har jag i samarbete med Mike Cohn tagit fram en utbildning för verksamhets- och produktledare som heter Certifierad Produktägare i Scrum. Den är två dagar, och ger konkreta verktyg och rutiner för att använda Lean och Scrum i verksamhets- och affärsutveckling. Nästa kurstillfälle är redan nu på måndag den 20/4, och det finns fortfarande några platser kvar.

Du kan läsa mer och anmäla dig hos Citerus.

Guest Lecture @ Uppsala University

2009-03-25T07:57:00.004+01:00

I was invited to give a guest lecture on the topic "Lean & Agile Software Development" for Software Engineering students yesterday. Students are a tough crowd, with interesting questions and they will let you know if you bore them or lose your plot during the lecture. I love getting the opportunity to speak to students, sharing some of the insights I've got from the industry, and I had a blast yesterday - thanks to everyone that was there!

Four years ago, not many had heard much about Lean and Agile. Now, the students are knowledgeable, pose interesting questions, and I even had an entrepreneur in the crowd yesterday, that was comparing different product development styles for his own company.

If you would like me to give a guest lecture at your course or department, please get in touch!

An inspiring talk on obsession

2009-03-14T10:52:00.006+01:00

Wired.com has the story on MythBusters co-host Adam Savage, who gave a speech on obsession and motivation as a driving force.

I love people like him. I wish I had his energy and dedication, but lacking some of it (possibly from coming from the northern parts of Sweden...) I get inspired by it instead.

Watch the video on how he goes on a quest on recreating two famous birds for his living room - without even being a sculptor!

I would hire one or two people like Adam for my Creative Department. Wouldn't you?

Don't miss the sequence near the end where he shows the "wrapping paper" he ordered for it. The "I know" comment is priceless.

Agile contracts and collaboration

2009-02-06T14:26:00.013+01:00

One of the most common questions I encounter is how buying and selling software development can be made in a different, more agile, way. At least in Sweden, the purchasing of a software development effort is usually really waterfall-ish, requiring a lot of specification work up front, many times ending up in fixed-price, fixed content contracts with severe penalties for missing a deadline.

Agile contracts have been on the horizon for quite some time, but few cases have been presented so far. During Scrum Gathering 2008 in Stockholm, I had the opportunity to host an Open Spaces session with participants from various countries. These are my (brief) notes from this session, somewhat depicting the current state of agile contracts.

Session notes Agile Contracts & Collaboration

Trust is a central issue. If trust between the supplier and purchaser can be achieved and upheld through means of an agile contract, a lot of headway can be made. To ensure trust, the risk must be shared and the supplier can no longer keep the software hostage until the end of the contract, but rather be prepared to give up a complete DONE release every sprint.

It has a lot to do with managing expectations. To be able to share the risk, we must have good, agile ways of dealing with risk up front. There were discussions and a few examples on how to closely work with the customer initially to set up the road map (“sprint map?” :-) ) and build trust. Some charge for this collaboration, others don’t.

To move this forward, we have to find and present success stories where buyer and supplier both come forward and talk about a successful agile collaboration. It was a common thought that many organizations are waiting for “someone else” to come forward and share a success story before risking the leap oneself.

In such stories, the improved customer value and margin could be natural comparison metrics, as well as the aggregate business value. Metrics and comparisons are vital.

The legal issues became one of the big topics. A formal standard contract for agile collaboration would be a big step forward. How can Scrum Alliance work towards this goal, as well as paving the way through political/industry lobbying? A Certified Scrum Purchasing Manager was proposed, tongue in cheek, but also with a serious undertone. We need to find and infiltrate The Secret School of Purchasing Managers. Anyone had any luck so far? : -) At least, everyone could agree on the need for top management to understand and embrace these issues – which also would have impact on the economics and how we define project/product success.

Fokus på utvecklingspraxis

2009-01-24T14:27:00.004+01:00

Att ha ett formellt sätt att uttrycka sig, som kan användas av såväl domänexperter, produktchefer och systemutvecklare låter kanske som en utopi? Domändriven Design kan vara en lösning på denna gordiska knut, och en av flera utvecklingspraxis som strävar till att minska klyftan mellan produktledning och -utveckling.

Patrik Fredriksson och Peter Backlund kan förklara det där mycket bättre än mig, och det gör de bland annat på JFokus i nästa vecka. Se där, nu fick ni ännu ett tips, kära läsare!

Om tomatklockor och värdet av ett (J)fokus

2009-01-24T13:58:00.005+01:00

En gång var jag med om en rätt rolig incident när min gode vän Linus (som jag var kollega med då) skulle försöka agera urmakare på en trasig äggklocka i form av en tomat, istället för att lämna tillbaks den. Resultatet var fjädrande, men inte helt lyckat.

Nu föreläser Staffan Nöteberg om Pomodoroteknik på JFokus 2009 nästa vecka. Pomodoro är italienska för tomat, och ursprunget är just en tomatformad äggklocka. Mer tänker jag inte avslöja här, förutom att vi hade äran att få en duvning i Pomodoroteknik och lite annat av Staffan hos oss på Citerus i höstas. Ämnet är mycket intressant, och Staffan är en fantastiskt engagerande föredragare, så jag rekommenderar att inte missa honom!

Kanske börjar ni också skaffa äggklockor till era arbetsrum? Det har jag gjort.

Jag håller också ett kort föredrag, med den lätt pompösa titeln Den Lättrörliga Organisationen. Det är inte riktigt så illa som det låter, förhoppningsvis kan det bli både underhållande och lärorikt. De som känner mig vet att jag har en del synpunkter på ledarskapet och HR i många företag i vår bransch, och jag kommer att dela med mig av konstruktiva förslag kring detta, bland annat.

På tal om sommarens inlägg, och att Kalmar FF använde Kaizen som en del av sin filosofi i arbetet med fotbollslaget, fick Nanne Bergstrand utmärkelsen Årets Ledare vid Idrottsgalan. Han är coach för Kalmars fotbollslag. Ständigt lärande kan även ge andra framgångar!

Fotboll och Kaizen

2008-07-01T23:02:00.003+02:00

Så här i kölvattnet av fotbolls-EM kan man ju känna en viss tomhet om kvällarna - åtminstone om man är lite sportnörd som jag. Därför tänkte jag dröja mig kvar en smula vid ämnet.

Jag hörde nämligen ikväll på SVT att Kalmar fotbollsklubb arbetat med Kaizen som en del av sin filosofi kring lagets utveckling. Ständig förbättring som en del av att leda och utveckla ett fotbollslag.

Det är spännande, eftersom jag länge tyckt att det finns en del av ledarskapet inom idrotten som vi i industrin skulle kunna lära oss av. Coaching inom idrottsvärlden handlar om att bygga starka team som kan gå över berg för varandra, och individer som vill överträffa sig själva när det gäller. Det handlar om att bygga tillit, respekt, förtroende och glädje för det man åstadkommer.

Jag tycker att vår förre coach för handbollslandslaget, "Bengan" Johansson, kanske var en av Sveriges första Scrum Masters. I kritiska lägen i matchen såg Bengan till att spelarna kommunicerade med varandra, och stod upp för varandra. Under en timeout sade han sällan något, utan faciliterade tillfället, genom att se till att de informella ledarna klev fram och att laget själva enades om en taktik. (Ofta i bjärt kontrast till motståndarlagets coach som kunde stå och skrika sig röd inför sitt lag)

Låt oss hoppas bara att det inte går med fotbollsinitiativet som i en del företag - att tanken om ständig förbättring stannar på "utvecklingen" och aldrig når högsta ledningen och ekonomisidan...

Konferens: Agile Development 2008

2008-06-15T20:40:00.004+02:00

I veckan var jag ordförande för konferensen Agile Development 2008 som arrangerades av Citerus AB och IBC Euroforum. Det börjar finnas rätt många olika konferenser med lättrörlighet på temat, men ändå kom en hygglig skara deltagare från olika erfarenhet och bakgrund. Idén vi hade med denna konferens var att ta ett brett grepp på lättrörlig utveckling genom att ta pulsen på industrin idag, och se vart trenderna är på väg. Jag tycker vi lyckades rätt bra, trots allt.

Något som irriterar mig är den ökande mängden förståsigpåare som utan att ha erfarenhet inom ett område fäller kategoriska uttalanden om detsamma. Om man nu inte vet något om Scrum, hur vet man då att det inte lämpar sig för projektarbete? Själv blir jag mer och mer försiktig med generaliseringar av denna typ ju mer erfarenhet jag får inom området. Säkert är att den bästa utvecklingsprocessen är den som utvecklats av de som gör arbetet, som hålls ständigt optimerad utefter förutsättningarna, och som aldrig blir tyngd av en mängd leverabler vars syfte är att uppfylla processens checklista, inte att bringa resultat till verksamheten i form av nöjda betalande kunder.

Jag aktar mig för processer som är alltför tyngda av pynt. Pynt är för mig leverabler som inte är resultatorienterade, utan hör till uppfyllande av processen. Det är ofta dokument av olika form som dessutom ofta ska signeras av någon ansvarig chef eller liknande. En effekt av pynt som jag ofta noterat är att det verkar bli en trygghet för kvalitet, på något märkligt sätt. Det gör inte så mycket att kunden blev nöjd, för vi har ju allt pynt som visar att vi följt processen.

Jag förbryllas av Lean-och-agile-gurus som förespråkar att man inte behöver arbeta med ständig förbättring. Jag antar att de har någon djupare grund i sitt resonemang som jag helt enkelt inte begriper, för ständig förbättring är ju en av de saker som får de mest framgångsrika företagen att hålla ledningen jämfört med sina konkurrenter. Jag anser att om det finns en sak man ska välja att göra, så är det att börja förbättra sin verksamhet, ett steg i taget, med puls.

Här måste jag fritt citera Daniel Berg på ASSA ABLOY: "Vi ska alltid vara mycket bättre om sex månader!" Tänk att ha det drivet i sin utvecklingsgrupp!

Jag glädjs åt att träffa nyanställda på en sådan här konferens, som har blivit ditskickade för att deras chef ser möjligheten i att låta dem få en orientering i lättrörlighet, och träffa andra med erfarenhet. Och jag blev glad av tjejen jag träffade som arbetar med test som specialitet, och tycker det är självklart att testare och programmerare samarbetar för att ta fram mjukvara med kvalitet. Det värmde.

Lundgrens Lag / Lundgren's Law

2008-06-10T18:05:00.005+02:00

"Varje nytt sätt att bedriva produktutveckling på, som har potential att vara mycket bättre än de befintliga, kommer över tiden att perverteras till en variant på vattenfallsutveckling.

Sedan kommer den att avskrivas med ett 'vad var det vi sade, det fungerade ju inte' "

Jag hoppas innerligt att jag har fel. Men nu har jag sett det här hända lite väl många gånger.

---

"Every new way of developing products, that has potential of being a substantial improvement over the current ways, will eventually be corrupted into a form of waterfall process, at which point it will be dismissed with the conclusion 'we knew that it wouldn't be any better all along'"

I sincerely wish this would not happen. But I have seen it too many times already.

Produktägaren och Scrum

2008-05-28T14:21:00.004+02:00

Lättrörliga processramverk som Scrum sätter affärsvärdet i förarsätet, vilket leder till att produktledningen förväntas styra utvecklingen. Detta ställer onekligen krav på marknadssidan att såväl förstå utmaningar och kostnader involverade med utveckling av mjukvara, men också prioritera och leda arbetet.

I takt med att dessa arbetssätt prövas, börjar nu affärssidan intressera sig (eller 'drabbas' som någon uttryckte det) och tankesätten börjar genomsyra även denna del av organisationen i många verksamheter. Viktigt, eftersom det i min mening är en förutsättning för att verkligen kunna komma framåt.

Jag träffade själv ett 50-tal produktägare i samband med ett evenemang tidigare i veckan, och gladdes åt den entusiasm inför att testa nya vägar som fanns. Dock förbryllades jag också över historien en produktägare berättade för mig, nämligen att hennes Scrum Master förbjudit henne att delta i olika möten och att vara nära teamet.

Detta påminner mig om hur viktigt det är att vara tydlig, när man förklarar saker. Självklart ska en produktägare vara nära sitt team, det är inte möjligt att kunna leda utvecklingsarbetet annars! Däremot måste denne följa spelreglerna, och inte agera som en störande kraft mot teamet heller. För att balansera detta använder lättrörliga ramverk ofta en coach som i Scrum kallas för Scrum Master. Det ligger i dennes ansvar att se till att kommunikationen mellan utvecklingsteam och produktägare fungerar på ett bra sätt, och att stänga ute produktägaren känns inte som den bästa vägen framåt.

Lättrörlig organisation

2008-05-19T12:45:00.003+02:00

Hur organiserar man sig för att arbeta lättrörligt? De som följt Toyota under ett antal år är överens om att det krävs ett stort och kontinuerligt anpassningsarbete. Men alla förbättringar börjar ju i små steg, som floskeln säger, och det innebär turligt nog för oss att vi kan använda oss av granskning och anpassning för att iterativt och inkrementellt närma oss ett bättre läge.

På Agile Development 2008 kommer jag att hålla ett föredrag om lättrörlig organisation som jag hoppas kan inspirera i ämnet. För att få ytterligare verktyg kommer min kollega Patrik Fredriksson att prata om ett gemensamt designspråk för verksamheten, och Jonas Rundberg kommer att berätta om resan från ubåtsbefäl till lättrörlig utvecklingschef. För att plocka några godbitar ur kakan!

Den portabla Wikin

2008-05-18T23:53:00.004+02:00

Jag är ju till del anhängare av filosofin bakom GTD och även om jag inte följer alla principer så har till exempel mailhanteringen varit till stor hjälp (och fick mig att komma ikapp med min mail för första gången på åtta år...) Därför söker jag efter finurliga idéer och verktyg för att hjälpa till med GTD-tänket.

Inget går ju upp mot ett skoj verktyg för att få entusiasm över att pröva något - eller hur?

Till min glädje och förvåning snubblade jag över en portabel Wiki häromveckan, som inte kräver vare sig webbserver eller databas, och vars installation bestod i att kopiera en webbsida till min dator! Föredömligt!

TiddlyWiki heter den, och den har hjälpt mig att organisera upp idéer, kom-ihåglistor och liknande.

Lean vs Agile

2008-05-18T23:28:00.003+02:00

I had the opportunity to discuss knowledge-based product development over a dinner with Don Reinertsen the other day. More specifically, we discussed Lean vs. Agile, and I had the chance to pop my usual question: Why are almost always software companies exempt from the studies on how lean practices can improve the results? And, as usual, the answer is that we are portraying ourselves as being "too different to have general product development principles applied" to us - but he actually thought this would not necessary be the case.

Michael Kennedy has previously pointed out to me that he thought the software industry actually could be "more lean" because of the malleable nature of our products. And I have thought for quite some time now that we should be able to learn practices from other product development industries that they have been perfecting for decades now.

Perhaps it is time to realize that what we are doing involves a lot of handicraft, research, and trial and error, and need to be managed and controlled with apt practices.