How to visualize the (IMHO) most important metric of the Kanban method

In my humble opinion the Lead Time Distribution is the most important metric in the context of the Kanban method.

Your mileage may vary, but that would be the topic for another post.

A brief mailing list discussion about ways to get this in Excel triggered me to make a list of some of the approaches I use to get to that metric. (Only some of them with Excel)

Content:

• Google Spreadsheet approach
• Hand-rolled Excel
  • Percentiles for given durations
  • Dates for given percentiles
• More versatile hand-rolled approach w/o Excel
• Closing thoughts

Plot and percentiles in Google Spread-Sheet

I would feel remiss not to mention the works of Emily Webber: https://emilywebber.co.uk/a-tool-for-tracking-kanban-projects-that-you-can-cut-out-and-keep/

This gives most of one could want for the evaluation of a physical board.

Unfortunately, it isn't Excel yet, but "only" google-docs. Exporting to Excel "kind of" works, but the most important formatting is rather distorted, so I wouldn't exactly recommend that route to get to Excel.

Maybe it is right for you, maybe not. Give it a shot.

Percentiles per given durations in Excel

I used Excel quite often to generate percentages (not yet percentiles), usually inversely by pointing out the percentile that a given duration falls into.

This leads to heat-maps like the one on the right (from my talk at the 2018 LKCE ) but you don't necessarily get the exact numbers for the percentiles – and it is achieved by a concatenation of manual bin sorting, Summing up the results for each bin and comparing that to the maximum number of occurrences for this type of work.

You can find a simplified example (for only on type of work) in [this Excel-Sheet.](http://www.consulting-guild.de/files/ExampleHeatMap-GeneratedData.xlsx) The raw data is in the first tab, the bin definition in the second and the evaluation in the third. All tabs are named accordingly.

Durations for given percentiles in Excel

Excel already has a built in function called PERCENTILE which yields the mathematically correct percentile over an array of numbers (e.g. lead-times)

For the Emily Webber Data this looks like this: (In the German Version of Excel they translated the names of the functions and hence PERCENTILE is called QUANTIL)

The more flexible approach (without Excel)

Still, sometimes this is not quite what you need and the whole structure of the "chains of Excel spreadsheets" which tends to arise from the Excel-based approach tends to become too brittle (or too solid) after the first two or three improvements-loops.

Nowadays I recommend evaluating Jupyter Notebooks for this kind of scenario. It seems to require programmings skills, since the statistics approach is based on (amongst others) Python, but actually it is quite approachable and most people who are comfortable with complex Excel sheets tend to fall in love with it quickly.

My colleague Martin for example is using this approach for a very flexible evaluation of data collected from physical boards.

It can look like this, but can be easily extended if you need more complex statistics or shapes.

Closing thoughts

IMHO – provided the work-items are coarse grained and the time you want to inspect is not too long – oftentimes it pays to ditch electronic tools in favor of more mechanical approaches as outlined in the talk I mentioned above. (Unfortunately in German)

And for more elaborate mathematical elaborations while still working in Excel I find Troy Magennis Excel-Sheets an extremely helpful ressource.

till next time
  Michael Mahlberg

Attention bias or Dunning-Kruger?

There is a lot of talk these days about the Dunning Kruger effect and cognitive biases in general like the fundamental attribution error or attention bias. While the Dunning-Kruger effect essentially describes the learners misinterpretation (notably: overestimation) of their level of competence after they have acquired the basics of a topic, it is often used for bashing people who seem to be over-confident without really knowing much about subject they are talking about. But does it always have to be just Dunning-Kruger? I don't think so.

A while ago, someone made a nice – or rather not so nice, but unfortunately very on point – joke about the incompetence of a company that wanted to hire a developer with "8+ Years of Swift experience" in 2018, pointing out that the programming language Swift came into life only three or four years before that.

Being annoyed with a lot of enterprise recruiting myself I answered with a picture of the Suzuki Swift car that was in production from 1983 onwards...

After some laughter we realized that we had fallen prey to some kind of bias, because actually Swift as a programming language is way older than Apple’s incarnation of it. There is a scripting language called Swift, targeted towards parallel processing in the high performance computing area) ... from 2007.

We obviously fell prey to cognitive bias, but I'm still struggling to find out which one.

But that was a good cue to pull out my favorite visualization cognitive biases that used to be part of the wikipedia article on cognitive biases, but now they have a really stunning list of cognitive biases.

The fascinating take away from this whole story for me was, that for days after I had toyed around with the infografic and the list, I caught myself repeatedly being more aware of potential cognitive bias pitfalls. It might not help against the Dunning-Kruger effect (or does it? I don't know, I'm not an expert in that area ;-) ), but it surely helped me with looking twice.

Or –as Alan Lokos might have said once– "Don't believe everything you think!" :-)

Cheers
  Michael Mahlberg

What change initiatives can learn from steam engines

[I once saw this on a slide at a conference – I'd love to give due cerdit,
but I can't find the original source. The conference was “Tools 4 Agile
Teams” 2017, but I can't identify the session in this picture]

Structure > Culture > Strategy

or

Structure trumps Culture trumps Strategy

That sounds catchy, but actually there also is quite a bit of a story behind it.

The second part originates from the almost famous quote “Culture eats strategy for breakfast" that is often used to explain why so many strategically motivated changes just dry up at the department or team level.

The first part comes from what Craig Largman calls “Larman's Laws of Organizational Behavior” in which #5 reads "Culture follows structure" and implies that culture itself can not be changed directly but only by changing the structure.

Whether these statements are true is hard to decide – neither of them claims to have any hard scientific evidence. I, for one, certainly have seen more than one case where these observations not only held true, but were also helpful to keep in mind.

A great example on the domination of structure over the other aspects comes from a blog-post on the time when steam engines started to be replaced by electric motors. At that point in time, steam-engine powered factories had widely replaced individual workshops and the usual layout of the shop floor was optimized to make the best possible use of the power provided –via mechanical shafts– by the steam-engine.
Along came electric motors, which –theoretically– offered a huge benefit in efficiency and effectivity. But when factories shifted to electric motors nothing much changed initially. Simply replacing the gears, shafts and belts of the steam engine didn't really enable more efficiency or effectivity.
Only when the factories started to change the fundamental way they worked did the electrification make a difference. Once the newfound flexibility was leveraged and the shop floor layouts were rearranged to follow the flow of production work, a steep increase in both effectivity and efficiency became apparent.

Kind of how agile approaches to product development enable business agility, but need to be leveraged to really make a difference.

till next time
  Michael Mahlberg

P.S.: I haven't yet read the book on “Building the Agile Business“ that Peter Abraham and Neil Perkin wrote (simply because I didn't find the time to read it yet) but I do love at least one of the points they make in their above mentioned blog post. So by now the book is definitely on my "to read" list.