Skip to main content

Could Kanban be defined in a "Scale-free" manner?

Scale-free or scale-invariant processes are like fractals. They work independently of scale - from the intergalactic to the molecular if you like. Could a scale-free definition exist for an agile process such as Kanban - a process that would be robust and effective from the personal and small team scale to the scale of whole or multiple enterprises?
The Wiener process (random or Brownian variation) is scale-invariant (from Wikipedia)

I've recently returned from three days in Hamburg on +David Anderson's Kanban masterclass and this was one of the questions that was raised during the sessions. Uncontroversially Anderson stated that Kanban, like agile processes such as Scrum, XP and FDD, is not scale-free. Different definitions of Kanban exist at different scales. Personal Kanban applies to individuals and small teams. It uses a subset of the methods and techniques defined in Anderson's Blue Book and may have other techniques which are not applicable at higher levels. Equally Portfolio Kanban, which does not yet have a reference text, but exists in the experience of enterprises applying Kanban to multiple interconnected organisations and projects, is different enough to smaller-scale flavours of Kanban to be considered different in essence, not just in scale. 

I admit to finding this discussion frustrating since I think there is at least the possibility of defining Kanban in a scale-free manner. This would not be true of Scrum for example because the "immutable" roles, artifacts, events, and rules of Scrum are specific to the single-team scale. When you scale Scrum, even to a single scrum of scrums, the rules and practice have to be different at the larger scale. If we take the Blue Book definition of Kanban it maybe suffers from exactly the same problem. But the book is too large to be the process definition. Chapter 2 of the book might be a candidate, but it is not specific enough nor contains enough detail to test compliance.

I'm looking forward to the publication of a basic Kanban definition - Anderson stated it was in the pipeline - as my own feeling is that it should aim to be scale-free, at least over these three levels. Anderson positions Kanban as a process for organisation improvement in the knowledge work space. As such the practices relate to how to visualise work and improve, rather than the specifics of organising teams or indeed software development. At least at the first level of definition - the simplest and sparsest definition - keeping it scale-free should be both possible and useful.

Postscript: A possible candidate for a scale-free process is Feynman's Algorithm:
  1. Write down the problem.
  2. Think real hard.
  3. Write down the solution.
One could argue this is a process only for a single person - I'm sure he intended it that way. But arguably it is scale-free. It's just the difficult and interesting part of the process as far as team problem solving is concerned (how do you write down the problem? how do you think together? how do you write down the solution) remains completely obscured. In the end it is only a trivial scale-free process.

Is there such a thing as a (non-trivial) scale-free agile process?

Popular posts from this blog

Does your Definition of Done allow known defects?

Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?
... the Story will contain defects of level 3 severity or less only ... Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.

Let's look at the consequences of this policy. 

Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…

"Plan of Intent" and "Plan of Record"

Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many successful ventures and in a number of SIGs and conferences in which he is active. In spite of knowing Ron by correspondence over a long period of time it was only at JavaOne this year that we finally got together and I'm very glad we did.

Ron wrote to me after our meeting:

I told a number of people later at JavaOne, and even later that evening at the Software Engineering Management SIG, about xProcess. It really looks good. A question came up: It's a common technique in large organizations to keep a "Plan of Intent" and a "Plan of Record" - to have two project plans, one for the business partners and boss, one you actually execute to. Any support for that in xProcess?

Good question! Here's my reply...

There is support in xProcess for an arbitrary number of target levels through what we call (in the process definitions) P…

Understanding Cost of Delay and its Use in Kanban

Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to maximise the flow of value to your customers.

Don Reinertsen in his book Flow [1] has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most urgent items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of urgency (or CoD) divided by the time taken to implement them. Reinertsen called this appro…