Milk Kanban

I absolutely did read this in Willies voice.

One of the best albums ever IMO, just finished the excellent biography that came out a couple years ago by Richard Morton Jack

I just put a few at the bottom of the trashcan, so when the box runs out I still have some time to buy a new supply.

My first thought as well. Simplehuman, whose products and designs I admire, also include QR codes to reorder on the reminder and a refrigerator magnet included with the trashcan.

>On the other hand, knowledge work typically handles uncertainty and variability of work way better.

I am not sure that is true, they are very different but I wouldn't say one handles it better.

One of the factories in involved in builds to order on a short lead time. We produce 2500 machines a day, from a wide range with many configuration options. There are various sub assemblies that have to be built first. On any given day there will be shortages on various components, meaning we can't build what we want. There will be quality issues with materials meaning reworks and changes in process. There will be design up-issues to address material changes, firmware problems, or customer demands. There are 400+ people to coordinate. This is all done whilst still shipping 99.9% within the lead time. We don't know anything for certain about our demand in 10 days time. It seems much more complex and adaptable to me than when I ran a software team

> I've worked on multiple Kanban software dev teams and a whiteboard never came into play,

Most teams don’t literally use a physical whiteboard, they use some software that represents the whiteboard.

Do an image search for “Kanban board” and you’ll get a mix of physical whiteboards and software dashboards that imitate the same columnar style.

Though one thing about software development practices is that names have become nearly meaningless as people have adopted different variations. I worked at one company recently that proudly bragged about their “agile methodology” but also demanded everything be planned 6-9 months in advance and made a big deal about tracking metrics for sprint accuracy and failure to complete tickets on time (including too early!).

That is an interesting observation.

The first two (and I would say key) practices of Kanban (as a method) are: - visualize work(flow) - limit work in progress

So I wonder, how did these Kanban teams visualize work exactly?

Now, I don't say the whiteboard (virtual or physical) is the only way to do it, yet it's almost ubiquitous.

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"

Only 10% disk space left. Peak memory usage at 90% available RAM. $CRITICAL_PACKAGE version update has been available for 2 months.

Once you see the pattern, it can be used all over the place: Pre-programmed proactive reminders for all sorts of upkeep chores that you don't want to spend mental bandwidth on.

For all but 4 people, it's on the way to their own desks.

I bet that when someone just drops the card on the kitchen table, someone else would carry it to Kasia. As far as I know, dropping the card has never happened.

Nonetheless, the comment is spot on. If people needed to go far from their regular tracks, it might have been less reliable. Good system design means that doing the right thing is the easy/easiest thing.

Yeah, I think i would make it “put this card in the reorder box”

Oh, there is a real Kasia. Although she's a person of many talents, I would be genuinely surprised if she spent evenings studying Japanese management methods.

The solution she designed, however, is as if she already knew all of that part of the MBA program :)

Which shows how significant parts of these methods have roots in basic awareness and perceptiveness to how the work gets done. Lean/Agile only codified some of these good practices. Unfortunately, they also petrified a lot of specific techniques. But that's another story.

>>> maybe that office manager should rethink their employment there.

A near-universal feature of office managers is that they are continually rethinking their employment.

If its only milk, then this polling might work. But might be also coffee, printer paper, pencils, whatever and you end up doing nothing else than checking shelves all day

That’s all the more reason to go event driven right?

If the milk needed replenishing more often, maybe polling the shelf makes more sense - hey the rate of consumption is higher today, I’ll re-order early. That high throughput optimisation doesn’t really shake out if you’re always just waiting for the replenishment event to fire.

Or maybe if putting a piece of paper on someone's desk for precise restocking is too much of "a pain" to the person who drank the milk, then they should rethink their employment there.