On the Fractal Nature of Agile and Lean Product Development Part 1

This will be a series of blog posts summarizing the keynote speech I gave at LPPDE Europe 2011. We will begin gently by explaining the concept of "fractals".


I learned about fractals, specifically Mandelbrot fractals for the first time from a wonderful article in Scientific American back in 1985. As a student, it was mesmerizing to watch the impossibly intricate images appear on the screen (pixel by pixel, at a painfully slow rate, as it were back then) and a great way to appreciate the beauty of mathematics (and bring some balance to the not-so-beautiful drudgery of integral calculus in class)

Much later in life, it dawned on me that some properties of fractals indeed apply to how I work with organizations when it comes to leading lean and agile transformations. When preparing the notes for my speech, I started to wonder, just for fun, how many of the fractal properties I could use to carry the topic - how lean and agile fits together? As it turns out, quite a few (although I had to stretch it somewhat, but I hope you will bear with me)

Definition of Fractals
According to Wikipedia at current date, a fractal is defined thusly:

• It has a simple (and recursive) definition  
• It has a fine structure at arbitrarily small scales
• It is too irregular to be easily described in traditional Euclidean geometric language
• It is self-similar (at least approximately)
• It also has a Hausdorff dimension which is greater than its topological dimension (although this requirement is not met by space-filling curves such as the Hilbert curve)

(At this point, most seemed straightforward, except for the Hausdorff one. I'm not sure how to deal with it, but I'll wing it somehow when we get there)


"It has a simple (and recursive) definition"
The Mandelbrot fractal is defined as

z_n+1 = z_n² + C

where C denotes the real and imaginary component of a complex number. When input into the above recursive formula, C is said to belong to the Mandelbrot set if, and only if the number z never escapes to infinity no matter for how long we let the algorithm iterate. 

Mandelbrot images are usually created by visualizing the real and imaginary part of C as coordinates in a plane, coloring the corresponding point in accordance with the number of iterations it takes for z to become infinite (often using black for points that seem to never grow to infinity, thus belonging to the Mandelbrot set) Even the simplest algorithm will be imprecise, as you will have to define a cut-off point, guessing that after perhaps 10 000 iterations, we will assume the z will behave, not taking off into infinity. But we will not know for sure unless we let it run an infinite amount of time, so we can only view an approximation of the set, with finite patience, that is. And then, we can add edge-crawling algorithms, to find areas that can be filled in quickly, to speed things up,  and ...

Oh.
I'm sorry. I got a bit carried away for a moment there.

Anyway.

"It has a simple (and recursive) definition"
This means, in practice, that simple rules can describe a chaotic system. (And if you know of things more chaotic than some software departments, please let me know)

In Scrum, we use a simple framework, with a brief set of rules, that can be easily described in a picture to bring some order to the chaotic day-to-day work. Of course, the framework is just the beginning of things, as it needs to be fleshed out with development skills, team and individual coaching skills, domain knowledge etc. (And unfortunately Scrum is sometimes used to cover up the actual problems of product development, but that will be the topic of another article)

But I hope you see my point? A simple framework makes it easier for us to describe some of the complexities of software development (or rather: iterative development with a high degree of variability) to our collaborators, customers, even ourselves!

So, which are our rules when it comes to agile and lean product development?

I'll mention a few, just to get you started. Feel free to look up from your desk, watch your colleagues, and think of how to best capture what you see and perceive, how you actually do the work - in a brief collection of simple rules. (You get an A+ if you can find a recursive one)

• Decisions need to be taken by, or close to, the people who need the decisions to move forward, when they need them
• We work together in teams, containing all knowledge and skills necessary to create value for our users
• We follow a rhythm (pulse, cadence, etc.)
• We allow, and deal with change and variability
• We have few roles, but possibly many skills
• We learn and improve continuously
• ...

To be continued

På språng!

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

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!

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

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?

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!