Milk Kanban

"Bye Bye Nerdie", S12E16, 2001 https://en.wikipedia.org/wiki/Bye_Bye_Nerdie : https://www.youtube.com/watch?v=u4rbW96R5GM https://www.reddit.com/r/TheSimpsons/comments/qhy6bi/that_ro...

The toilet paper we buy now comes in individually-wrapped (paper wrapping) rolls, and several rolls in every box are wrapped in bright red paper. Those rolls have the suggestion printed on them that you put them towards the bottom of the pile in the bathroom so that when you reach for a new roll and the one you pull out is wrapped in red paper, you know it's time to go get more from the box. It's a clever design, although it does somewhat rely on people remembering to order the rolls that way when putting them in the cabinet...

I absolutely did read this in Willies voice.

I've begun to notice the number five a lot. I was reading Tammy Wynette's wiki page the other day and noticed that it appears quite a bit -- born May 5th (5/5), married five times, dead at 55. She also collaborated with the KLF, a pop group from the early 90's which also had an unusual number of fives to do with them (as well as 23's...2+3=5? Oddly, Tammy has a memorial highway in Missippi, MS23). Which brings me back around to Nick Drake. One of the members of the KLF now runs a small web store which mostly just sells his books to do with his post-KLF career, but they also sell other things as well, like overstock Nick Drake album tuck boxes...which are designed to hold all five of Nick Drake's albums.

https://www.alimentation.cc/product/tuck-box/

Not sure what any of this means.

Edit: just noticed that I responded to your post five hours after you posted it.

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

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.

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.

It wasn't just coming up with a system that works for software and taking a cool name from manufacturing processes.

The methods in IT were built on the same principles (and, to a degree, values). It's just the implementation is different. In fact, in software, we emulate some things that are given in manufacturing. A notable example is making work visible. On a factory floor, piles of parts are clearly visible. The code in progress is not. Thus, we have index cards representing queues of work (piles of incomplete parts).

The approach to limiting work in progress is actually the same. Again, the solutions differ (replenishment triggered by visual cards in manufacturing versus numerical WIP limits on visual boards in software), but the outcome remains very similar.

There are differences, of course. The big one is how we react to variability. While in manufacturing, we, well, manufacture a lot of identical things, in software, each item is different. Thus, on a factory floor, we aim to control and reduce variability, while in software, we tend to accept and work around it.

There are other differences in flavor, too. Like in knowledge work we don't stress too much about waste reduction, while in manufacturing, it's a big theme, etc.

However, if we look at the ideas and not specific implementations, these systems are very similar. And I'm saying it as someone who trained people in that domain both in knowledge work and manufacturing.

Not that any of this helps with confusion in the naming. Even less so given the fact that some people are arguing the seemingly fundamental differences between using kanban (lowercase k) and Kanban (capital K). I guess people are people.I don't much care. As long as someone can explain what they mean by it, I'm fine with whatever naming they come up with.

> So software developers came up with a system that works well for them, but instead of giving it it's own name they reused the name from a manufacturing system. thus leading to endless confusion.

It's amusing to me, because without knowing any of this I've often felt & said that (especially scrum but kanban too) is depressing even just in the terminology used and seems designed to treat us like workers on a factory line. And lo, that is actually whence kanban at least came.

You would think that, but swap manufacturing and parts logistics for user design and content, so a new feature is designed, then content is written for it, then it is implemented. Each step requires the one before it.

I can recommend reading “The Phoenix Project”.

> 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.

>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

Lean applies to software probably more than any other methodology in my opinion.

The simple practice of aggressively removing waste in all of your processes offers more benefit than anything else. The result of that is often closer to a much more simplified kanban system in my experience as well.

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.

Sounds good, "THREE STRIKES AND YOU'RE OUT".

But would it not mean that sometimes you had 3 weeks old milk in the fridge? :-)

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

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

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.

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.