Milk Kanban
brodzinski.com
brodzinski.com
Edit: found a photo of this phenomenon on r/antiassholedesign https://www.reddit.com/r/antiassholedesign/comments/cfndfa/g...
Also common in commercial environments where you want to leave rolls out in the open, like a couple extra in every stall.
Wrapping with some tissue paper is probably more environmentally friendly than people buying 4-packs with non recyclable plastic.
Incidentally I've also worked somewhere with a little flag indicator on the milk cooler to let the kitchen staff know it's out and needs refilling (and to warn other users).
Why would they package those in larger packs? My guess is that the paper does help protect the roll while it's waiting to be racked. Dust/splashes/unravellng/etc. Might be where hotels get their TP.
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.
> In the Erisian Archives is an old memo from Omar to Mal-2: "I find the Law of Fives to be more and more manifest the harder I look."
https://penelope.uchicago.edu/misctracts/plutarchE.html
There's speculation that this was derived from an earlier Erisian mystery cult, but how it ended up in a temple of Apollo I'm sure I don't know.
When software developers say Kanban, they tend to think of whiteboards. For anyone who works in manufacturing they would have thought about replenishment first. It is completely ubiquitous anywhere where taking something from a location signals a need for replenishment.These days it is often virtually, where an ERP sees an order taking something below some level, triggering purchase or manufacture of a replacement.
I understand the literal translation of Kanban is 'coloured badge' btw
The term refers to a method to attach the logistical back pressure mechanism to the logistical items in question, basically distributing it to solve the problems of large central control. However the logistics of software development is very different, Software is mostly research and development with close to zero manufacturing and parts logistics. You would have to model each software feature as a one off custom item with a long lead time. and that is not what the kanban system is good at. Why do you need back pressure control when each item is a one-off?
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.
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.
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.
Management seems to latch on this system since they understand it; it's getting both better and worse in that a lot of management now days has actually written code in smaller companies, but in bigger ones they still bring in their buddies who last coded at Uni and still go hard into this "fungible developer" assembly line process.
Service ot service this is less appropriate, but extending an existing service is a bit more like assembly line stuff
(IMO) only if most of the assembly line has to be at least partially retooled every time you do it. No software feature in any but the most basic of systems stands alone.
Which, tbf, a lot of Lean/Kanban software teachings do account for, but most management likes to gloss over.
看板 - 看 "look at; watch", 板 "board; plank".
For the Japanese word, https://ejje.weblio.jp/content/%E7%9C%8B%E6%9D%BF has "看板 - signboard; billboard" (and also "hoarding", "draw; attraction", and "closing time").
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!).
If you planned for a ticket to go into the next sprint but you finished your work early and did it early, the program managers would start wringing their hands and beating around the bush asking if you could find a way to slip it to the next sprint. Having it go to “done” in a sprint that differed from the plan reduced your “planning accuracy” metric.
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.
that way you can see what state an entire flow is in at a glance and being able to co-ordinate effort accordingly.
Since my context is primarily IT I made some simplifications when describing the context.
Admittedly, the principles are the same. However, because of the differences in the nature of the work, different areas are stressed. A notable example is how differently "removing waste" is considered between IT and manufacturing.
Anyway, yes, whiteboards and sticky notes are staple artifacts of software development/knowledge work context. "Old-school" (since it started decades earlier there) manufacturing is much more creative with designing visual signals.
On the other hand, knowledge work typically handles uncertainty and variability of work way better. That stems from a different type of process (more creative, less repeatable) and unique nature of each individual task.
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
In the ideal case, in manufacturing, we repeat the same set of tasks to manufacture identical goods.
In software development, we have the same stages (development, code review, testing, etc.), but every task going through the workflow will be different. Depending on how these tasks are defined, the effort, interdependencies, etc., might vary wildly.
Both types of work, of course, will have variability related to the complexity of the process. And that variability will be correlated with the size of workflow, people and/or machines involved, etc.
It's just the knowledge work adds another dimension. By the way, that's why, in knowledge work, we rather talk about accepting variability instead of controlling it (which was the focus in Lean Manufacturing).
I recommend Don Reinertsen's work on that, since he worked in both contexts. While his book (Principles of Product Development Flow) is not an easy read, it's absolute gold.
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.
No, it's "signboard" or "billboard".
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"
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.
The authors never hid their intentions on this one.
BTW: both are great reading.
Also, the grand idea described in Goldratt's The Goal is the Theory of Constraints (ToC). While Kanban (as a method) draws from it with the limiting WIP practice, these two don't overlap that heavily.
I'm not sure if I can see a negative consequence for having more stories "on the board". Physically of course the board might get full, but we use computers these days. That doesn't mean spend all your time planning and none implementing, but if you realize we will most like need a given feature in the end we should not hide that realization from the team.
An error (or oversight) in specifications is much more costly than an error in design or implementation, is the old Waterfall mantra, which I think is true. But Agile of course might not agree with that.
Maybe it would make sense to carry some kind of "Plan for the Future" throughout the process. Be aware of the anticipated features even though they are not fixed into the "plan" yet.
I've been doing it for 25 years, and I'm yet to see a project where the above assumptions would be true. I don't expect to see it.
Requirements always change. So do priorities.
We have this saying that our clients always know what they want. Until they see it. Then they know they wanted something different.
But even if that wasn't the case, the requirements change because we learn as we build the thing. The moment we know the least about a project is at its beginning. After that, we only know more.
So if things change, keeping more tickets in flight (even in backlog) means that every reprioritization, every planning, every pull to development costs more. Heck, we're bound to add work that's already there, but we forgot about it.
It's the cognitive load we add to so many activities every day.
And it doesn't even solve the problem of having better design because there's too much to remember.
Your intuition is right, though, when it comes to understanding the big picture. Not only architecture but also business. When every engineer on the team understands these higher-level goals it's so much easier to make sound decisions about design and implementation.
But for that we don't need dozens/hundreds of tickets in backlog.
BTW: I have a rule of thumb that on a physical board, there shouldn't be more than 100 items altogether. Our brains are incapable of meaningfully processing more. On a virtual board, it's even less, as our visual capabilities are impaired by screen limitations and crappy design of the tools we use.
1) In Progress --> Started --> Completed: One cycle worth of WIP
2) Next Up: WIP for the next cycle (top third is highest priority, remainder is unknown priority until the cycle starts, these items are up for discussion)
3) Unscheduled backlog: Max count is less than 1 cycle worth of material
I've worked with small teams that can digest 5-10 "items/stories" in a cycle, for them there shouldn't be more than 30 items in view.
I've worked with larger teams that digested 30-40 items in a cycle and for them, seeing ~120 items was fine.
For larger teams, the work items tended to get broken down into smaller chunks as the communication overhead and carrying costs of implicit details was much higher.
How tactical, how coarse and how goal-oriented these work items are can vary widely by team/org interests and capabilities.
I agree that specifications always change. And that means it's good to be aware of what they might change to. Then we might more easily see how they might conflict with the current tasks, and thus in fact reduce the amount that specs would need to change in the future.
That said, the result of those discussions should be kept in a broad, narrative form that is focused on goals or outcomes. They should not generate multiple months-worth of concrete tasks that must be continuously curated, scheduled and negotiated.
In factory terms, this would look like quarterly or annual goals. One level higher than tactical activities.
"Stories on the Board" are more like raw materials that have been released and become Work in Process.
Overwhelming the line by pushing too much raw material has enormous, well-understood, negative consequences and usually results in far more waste than one can imagine.
Doing this well is hard and requires continuous balancing, and while there obviously isn't an exact rule that works for every context, there are thresholds at the edges that become pretty obvious with a little bit of experience and consideration.
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.
However, the labels under which they operated were taken over by the certification business. So, "grassroots" people either don't care about the labels at all or they invented their own.
By now, Agile is an empty buzzword. Unless someone explains what they mean by that, it means nothing.
Same with Kanban, by the way.
So far, it's gone pretty great, we'll see how long it holds!
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.
A bad system is a slack message once you get back to your desk.
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.
(This is probably overkill)
In an extreme case where there's a 100-floor building with Kaisa's desk on the first floor, it might well be more globally optimal to have boxes every 10 floors being polled, instead of everyone having to move 50 floors on average to her desk.
Having said that, the office is a single floor. The grocery order is once every few weeks.
There's quite some time flexibility in ordering stuff.
There is plan B (buying a couple of cartons in a grocery shop on the same block).
The system is scaled to what we need. And I don't say anyone should copy it blindly. If we talked about several floors, multiple coffee corners, etc., the flow of index cards might have required much more conscious thought.
In our case, we need none of this.
Also, continuous improvement (kaizen): start with something simple, then improve it. There's not much point in solving hypothetical problems with system design. Most of the time, we'd only be unnecessarily complicating the solution.
Which (tongue in cheek) is half of the history of software development :)
For n > 1 fridges at known locations, Kasia can be positioned anywhere (including partway along an edge) on an optimal TSP tour through them all.
OTOH, if fridges pop into and out of existence dynamically over time, then having a single Kasia traverse all of them is not feasible. In this case, other employees will need to walk to her desk when they discover the last carton of milk at some fridge. If we can assume that the density of fridge creation/destruction is uniform, then the strategy resulting in minimum total distance travelled in expectation is a spherical office building with Kasia at the centre.
> the system is self-explanatory
I've always known of this as an "affordance" - An available & apparent interaction between an object and its user.
On the one hand, the context is different. An affordance, as you point out, signals how we should use an item. In a way, it suggests a meaning. A kanban's meaning is typically defined as the process (largely) is known.
In the story about Milk Kanban, the index card is self-explanatory, but that's just an extra bit, to make the process more bullet-proof.
On the other hand, if we generalize both examples, we land in a place where the design (of things, of processes) should communicate how to act. I either interact with an object or I do my action within a process.
BTW: The Design of Everyday Things is another great reading recommendation in this thread.
I can't tell if the author asked Kasia how she came up with the idea? For all we know she's doing an MBA in the evenings and just wrote a paper on the history of just-in-time manufacturing in the Japanese auto industry.
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.
Also, she already does participate in core activities. It would be much easier for us to deal with losing a couple of our best engineers than losing Kasia. Which is also a response to some voices in the discussion downplaying the value of the "office manager's" job. I partially blame common perceptions of this job being "just a secretary to everyone," which could be farther from what we have.
https://en.wikipedia.org/wiki/Mechanism_design
...you have to squint a bit, but I've taken it to mean influencing the behavior of unknown or mildly uncooperative participants.
My main example of success was drawing a dotted line with a sharpie about 25% from the bottom of the water filter pitcher in the fridge (back with college roommates).
Basically overnight, the probability of me finding the water pitcher empty in the fridge went from 50% to like 10%.
The visual indicator (with only implied instructions) resulted in positive behavior changes.
Related is "poke-yoke/kaizen" of "mistake proofing, continual improvement, and making problems visible".
Being aware of these fields of study and their techniques can be applied to many areas in work and home.
But then nobody removed that cartoon from fridge so it started to stink, and remained in the fridge still. Then no-one in particual was eager to tackle the bad smell, it definitely was not their job.
Because "anyone could do it", it usually ends up that "no one does it".
But would it not mean that sometimes you had 3 weeks old milk in the fridge? :-)
On a more serious note, UHT milk can be stored for months, given it wasn't opened.
But, the grumpy and the veterans won out, because they just didn't see the value in making a change like this. sigh
In this whole sub-thread, I see quite a lot of signals along the lines of: - that's someone else's job, I shouldn't be bothered - I'm doing valuable work, others should make it easy for me - (all sorts of) managers are to make some problems inexistent for me
I'm not saying that's all in the original thread, but I read such sentiment.
So here's something that we do that may be unusual.
We respect everyone's roles and work. As much as Kasia wouldn't jump on a project as a developer, none of our developers would take her seat and handle all the stuff she deals with daily. Heck, she routinely helps people dealing with all sorts of paperwork that, especially for foreigners, are major pain in the butt. Which is "funny" because it's just "simple paperwork anyone could do."
And before someone throws at me that anyone can order milk online, that's like a hundredth priority or something like that.
Anyway, starting from a place where we all respect each other and everyone's work, dropping an index card on someone's desk on the way to one's own is a non-issue.
I acknowledge, though, that in an environment where people don't respect others' work because whatever (they have a less prestigious role, they're paid less, etc.), folks may totally perceive that a problem.
And yes, establishing such respect is so much harder than making sure that milk is in a frigging cupboard.
> it becomes a pain to check the cupboard with milk reserves every now and then
If freaking glancing into the shelf once a day (or more like once a week, because this milk has months of shelf life) in scope of full time office manager job is "a pain", maybe that office manager should rethink their employment there.
A near-universal feature of office managers is that they are continually rethinking their employment.
Bringing the card takes 5 minutes, 10 if you include time to a joke like "We are drinking too much milk, we should buy a cow next year."
Buying the milk includes going to the shop or calling the correct provider. Not the provider you used until two month ago because they usually deliver the requests too late at 5:05 when everyone is going home. Are you paying with the company card or your card and get reimbursed or they have to send an invoice and get paid later? Does the invoice need a magic tax number? Ensure they security guy and the payments department know about this so there are no surprise. [1] [2] This looks like half on hour at least.
When someone ask me to implement a trivial feature in software, I estimate "4 hours". Open the editor, find the correct file, take a look, make the obvious change, run the automated test, fix the obvious bug, cross the fingers, run the test again, [does it need new tests?,] write a nice commit message, google how "thoughtfully" is spelled, commit the change, close the editor, and it's done. Probably 2 hours, but I prefer to say for 4 hour in case there is a surprise.
[1] How many milks? 1%? 2%? 3%? Which brand? This may be included in the instructions, but in the second week of December you may want to buy less, and if there is a discount you may want more.
[2] Do you piggy back cookies or soap?
It is guaranteed to happen that as I grab the paper and walk to the person's desk, something more important comes up as somebody sees me, and then I have a meeting, and the piece of paper simply isn't important enough to remember next to my other responsibilities.
Employees are paid to do the work they're best at. It's a bad use of resources to have them tracking office supplies, emptying their wastebins, vacuuming their floor area, restocking toilet paper, or alerting the office manager when milk is low.
For a tiny, cash-strapped startup they might have to do all those things, but generally it's not optimal.
Edit: just to be clear and in response to downvotes, this isn't an ego or self-importance thing. It's just the fact that when in conflict, it is genuinely more important for the company for me to address an urgent technical issue, and show up to an important meeting on time, than to finish running across the office to drop off a post-it note about milk. I already never have enough hours in the day to do everything that needs to get done for my job, and everything is a question of prioritization. I'm just trying to give a realistic perspective here, that we separate out job responsibilities for a good reason.
There's no milk.
Also, anecdotally, my dad worked at a place where, if you needed something to be plugged into an electrical outlet, there was a person whose job was do do that. And if that person needed tools, there was another person whose job was to carry his tools.
One of their many rules was that nothing could be plugged into any electrical outlet on site unless the device had been inspected and signed off by a union electrician.
In a hurry to diagnose a problem with a printer I furtively plugged my non-approved oscilloscope in to a wall outlet. But then I inadvertently grounded a power line with the scope probe and caused a circuit breaker to trip somewhere on the main board. Shit!
A pompous electrician appeared and told me they would be shutting down the entire mill (10K+ workers) while the union decided how to punish me for my rule breaking.
It took much begging and pleading before he relented. My only leverage was that the printer was also used to print pay slips and he would not have got paid that week unless I fixed the printer.
Nobody really took guard duty seriously when it was just the platoon spending the night in the woods and between the three squads plus 'radio watch' there was always bound to be someone awake the penalty for falling asleep was usually just being assigned to the next shit detail so this system worked quite well.
I suspect this system is quite similar, if you want milk and the sticky note is on someone's desk because they can't be bothered to walk it over to correct person's desk because they are 'too important' then maybe people will start to question that person's true importance to the organization.
[0] during our time in Saudi Arabia/Iraq everyone took guard duty seriously and the leaders would make sure people were doing their jobs up to and including punishing people for petty infractions.
I'm saying that tracking milk shouldn't be part of your job, because it's not a good use of people's time. None of it has anything to do with "importance". It's about what is best for the business.
Would the business fail if the milk supply ran out?
And you understand that a lot of people don't drink their coffee black?
It seems pretty obvious to me that yes -- having coffee with milk available is very much best for the business. Kind of like having restrooms, chairs, and air conditioning are also best for the business.
- managing your own calendar, meetings, memos
- organizing transport and stay on business trips
- tracking and later correctly filling in forms to expense the above
- and yes, tracking supply of office consumables
This and many, many more things have been dumped on everyone by short-sighted beancounting. Salaries of secretaries, graphics departments, finance people, etc. are legible, therefore cutting them is a "big efficiency win". But their work does not disappear - it gets spread out, distributed in tiny pieces to everyone else. Then you have specialists with 10x the salaries of aforementioned departments getting constantly distracted by work that is not the reason they were hired. And people are surprised that productivity doesn't track promised economic improvements, and that everything gets slow to build and expensive for "unknown reasons".
As long as you’re holding the slip of paper in your hand, you won’t forget about it.
The issue is with creating random bespoke processes, that save maybe 60 seconds of work for that office manager per week, but now involve literaly every person in organization.
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.
A callback to indicate completion. Would have been better if the index card was taped to a carton towards the end, but still a few cartons remaining, to provide sufficient advance notice to restock.
And yes, using different kinds/colors of cards for different kinds of milk might have been an improvement to consider. It would, however, make the system more complicated. Was it me, I'd start with a simpler design and iterate only when I saw the need.
It follows the rule of thumb: make it as simple as possible.
If it were me, I would have a service handle this, they bring in whatever you want and make sure it's topped up.
I have seen this phrase a number of times. What does it mean?
If this discussion board was just a shared doc in which everyone could write, that might be a "too simple" solution. Basic control over one's writing is what we expect in solutions such as this.
With Milk Kanban, it might have been just asking people to tell Kasia when they take the last carton. Would it be a simpler solution? Yes. Would it work? Well, I guess there is a reason why we do have these index cards.
Things should be as simple as possible, with respect to your criteria. E.g. a scientific theory should posit as few objects as possible while still being able to explain all observed phenomenons.
Balancing the tasks between different actors within the system is a different concern.
If 30 seconds of my time saves someone else 10 minutes, it may be a good tradeoff, even if my time costs a few times more.
On one of the most effective teams I worked on, there was a tech lead who would throw himself into a role based on the team's needs based on insight from a morning daily. Most of the time, he played his strongest suit (back-end). However, there were days when he was helping with the most menial front-end tasks (he wasn't super-effective at that) or testing (same).
Was he efficient? If we look at him in isolation, then no. But because his work helped to remove bottlenecks and unblock the team, the whole team was more effective thanks to him.
What is interesting in some of the discussion threads here is how people look at the process effectiveness in a completely reverse way. Sometimes, they focus on their individual efficiency as if they were able to deliver value singlehandedly. Individual efficiency doesn't mean much.
A typical example would be a developer who's super efficient, but there's no one to do a code review (or test or whatever) just in time. By the time they get a list of issues to fix, they don't remember the context, they wrote so much more stuff relying on the things that they need to redo, etc.
Their efficiency would mainly be regarding coding in isolation. While the effectiveness would be measured in what the team could release/deliver to the clients.
As per Drucker's famous quote: "There is nothing quite so useless, as doing with great efficiency, something that should not be done at all."
Why is that supposed to be a problem? It's not like the person to monitor the milk stock belong to subhuman classes and doing work for them tarnishes your karma. In fact, in many tiny companies, it's more likely to be managers themselves doing non-scaling housewife like tasks. Less janitorial work for the boss and more time for executive tasks is good.
Something more efficient would be something like this:
- there is a closet in the kitchen with extra supplies: milk, sugar, ...
- Kasia goes in the kitchen once per week to do the inventory of remaining supplies. If items <= 1, then she order new extra items for each low in quantity supplies...
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.
Instead of all the things to be managed, the tickets that have to be written, with somehow a kind of brain fuck logic, someone going to this person desk at any interval, might even be interrupting the office manager, the other one having to keep and manage the tickets.
Like when things are ordered, you have to let the post-it in another place like "ordered but not here yet". And maybe the day after things are ordered, another ticket will arrive but sadly the order is already done, so will have to wait for next week anyway...
And think also, like when you are using milk for your coffee, and crap, it is the last drop, so you have to drop everything to bring this stupid ticket to the board or secretary desk.
If it is such a brillant idea, I'm wondering why no one use such a strategy for managing home supplies...
Besides, visually seeing stock going low helps the one doing purchases in deciding whether said supply needs immediate restocking, or that there's ample time to collect more low-velocity stock to batch them in one order.
As mentioned elsewhere, the person purchasing may not consume (in this example) milk at all!
In a ideal world where items could be ordered immediately individually, maybe it could have some value, but in that case you might as easily have an app or a shared excel with employees reporting what is running out.
But in a real world, things will be ordered in batch at a specific and fixed frequency time.
> So the office manager just need a minute passing by the kitchen to see what would have to be ordered.
This requires effort on her part, and is easy to forget to do. Sure, she could schedule it on her calendar or something, but that also takes effort, and can still be forgotten. This way, maybe she sees the ticket on her desk and immediately reorders on Amazon. In fact, it wouldn't shock me if she had considered your solution and rejected it for these reasons.
> In a ideal world where items could be ordered immediately individually, maybe it could have some value, but in that case you might as easily have an app or a shared excel with employees reporting what is running out.
At least here in the US, it is the world we live in now, with Amazon. Also, once again you are ignoring human factors. People having to remember to go to some spreadsheet and put it in an order. They'll often forget on the walk to their desk, or just not bother. Whereas taking a card around the corner and placing it on the manager's desk will likely have better compliance, and be more convenient.
> But in a real world, things will be ordered in batch at a specific and fixed frequency time.
Incorrect.
Very sadly it is a pattern that we see very commonly in current day software world. Like using Langchain for doing requests to openai, in llm world, and big company hiring expensive consulting firms to tell them what any low level employee in the firm could have told them.
If checking the milk reserves once a day is too much of a pain for a person hired as an office manager, the person should self-reflect on his/her choice to take the job.
This is why in places like I just described, you often have a shortage of particular items; the checks happen only every so often and usually by multiple cleaning employees. On the other hand, it's also exactly why Kanban came to existence, to solve a very similar problem in manufacturing.
This particular example feels weird because your job is not to drink milk, but in theory it should work and allow you to have just-in-time replenished stock for everything.