Milk Kanban

I love how you are not even realising that behind the oatmilk ticket is written "last oatmilk", the behind the half and half one is written "only 3 half and half" behind the foo ticket "foo down to f(frequency of foo use)", and the person now now only need to go through the tickets at the end of the week (or if more than N tickets).

I will let you ponder if you need to reticket all, or just the reordered product, wether a stack can have multiple ticket (a white one say 5 from the last and one red one two from the back know wether you need an urgent order) etc...

And whether or miracle, if you don't receive any ticket a week that you don't need to reorder !

It's amazing how if that was expressed in term of resource allocation, reference counting, tagged pointers, scaling heuristic, garbage collect... that would click in people's mind, but many are incapable at abstracting because they feel they are beyond this.

The central idea is that traditional manufacturing (and software) environments attempt to PUSH work through the system. This leads to tons of unintended consequences that ultimately sacrifices quality and throughput. Not only defeating the purpose of applying the pressure, but also (sometimes) destroying the reputation of the organizations that do it.

The observation of the Toyota Production System, was that we should make quality non-negotiable and then observe the system that emerges.

We let the system PULL work through it, rather than attempting to PUSH. In this way, we can make observations and improvements without applying negative pressure (that results in waste) on any given work center. Raw materials are only released into the process when the previous batch has nearly been consumed, regardless of some manager's desires.

The insight of early Agile practices, was that we might be able to use Stories as a metaphor for Raw Materials and the system we're working within converts those raw materials into something valuable to the customers and/or business.

There are a number of good reasons this metaphor doesn't fit perfectly, but one of the biggest ones is that while both manufacturing and software development can be creative processes, software development represents a much higher percentage of creative work than operating a cell in a generally well-defined production process.

The Kanban boards in Software Workflows were originally intended to make visible the actual throughput of a team, and help us resist releasing new stories into production if the team hasn't yet digested the previous set.

I've definitely seen environments that use these tools with little to no comprehension as to where (or why) they came from and I suspect that has become more of the norm as I've withdrawn into my own little corner of the universe.

If any of this sounds interesting, I highly recommend the book, "The Goal"

Definitely recommend "The Goal", it is fascinating to see its influence on "The Phoenix Project".

I would also offer a recommendation for any jaded hacker. Go and work for a manufacturing company. Seeing real world problems solved by lean experts and process engineers is fascinating. See Kaizen (Continuos incremental improvement) in action in critical systems, systems where a mistake can't be reverted easily and the consequences are huge. See them manage complexity. It is a real education.

> I suspect that has become more of the norm as I've withdrawn into my own little corner of the universe.

I often wonder what happened to the early grass roots agile community. I know I’ve withdrawn into my world too, I wonder how common that is?

I often feel like we’ve taken steps backward from where we used to be. Not sure how much of that is just my latent curmudgeon though.

This is a form of artifacts as reminders: https://pim.famnit.upr.si/wp/?p=288