On the Fractal Nature of Agile and Lean Product Development (Summary)

on
This is a very brief summary of the keynote speech I gave at LPPDE Europe 2011.


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
zn+1 = zn2 + 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
  • ...