Cigarette rolling paper comes in a flat pack, from which you take the papers one by one, like a box of Kleenex. Towards the bottom of the pack, there's gonna be an odd-colored piece of paper, after which there still gonna be 10 pieces left in the box. The odd-colored paper tells you that it's time to buy a new pack, but you still have 10 cigarettes' worth.
One of the episodes of The Simpsons I saw as a kid that had a surprisingly large impact on how I think was where Willie had cameras in all of the bathrooms to monitor if they needed the toilet roll changed: “That roll of towels is nearin' its end! She's on double red stripe!”
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...
If you buy in bulk, the rolls come in a big cardboard shipping box and not a shrink wrapped pack like the supermarket. The wrappers prevent stuff from getting on the rolls. Who Gives a Crap does the red wrapper thing.
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).
Selling individual rolls used to be more common. I'm sure you'll still see it today in smaller stores without a dedicated aisle for toilet paper/towels.
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.
The practice of having a slip that read “Five leaves left” was where Nick Drake got the title for his first album (somewhat eerily recorded five years before his death).
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.
Receipt paper rolls also have this: When the roll is near the end there are pink stripes, telling the cashier to have a new roll nearby as the printer is about to run out of paper
I recently noticed that there was a "Time to order" message written on the outside of the cardboard core of my saran wrap. The visibility to the core became clearer as the wrap was consumed- giving both a sense of urgency, as well as not letting you forget. I thought it was pretty clever.
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.
> When people say Kanban, they tend to think of a specific set of practices. Whiteboards & sticky notes (both almost universally virtual).
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
It is a subject that bothers me far more than it should, but when I was first exposed to the term kanban I naturally look it up and go "what on earth does any of this have to do with software?"
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.
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.
My angst with this (IMO tortured) metaphor, is each step is different every time. If we were knocking out exact clones of software systems this would work more like it is expected to.
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.
I've worked on multiple Kanban software dev teams and a whiteboard never came into play, vs. the scrum or extreme-agile teams which loved them. Kanban seems more about having tickets organized into a priority ordered queue of tasks.
> 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!).
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.
i've been dreaming of a way that visualises the user flows in the software (rather than cards on a board), think spider map showing possible user flows then colour coded circles based on what stage they're in.
that way you can see what state an entire flow is in at a glance and being able to co-ordinate effort accordingly.
That's true. The notion of what Kanban is differs between knowledge work (stemming mostly from software development adaptations) and manufacturing.
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.
>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
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.
My wife has worked in manufacturing for 20 years. It's very interesting to hear all the "technologies" that they have developed: six sigma, Kanban, lean manufacturing and all that. A lot of of that really feels like REAL engineering. Vs "sprint review" and "retrospective" crap we deal with in software.
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.
When I say Kanban, I mean "strip away all of the unnecessary processes that scrum/safe likely gave you and instead, simplify your process so you can focus on getting the work done...with a WIP limit."
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.
"The Phoenix Project" is basically "The Goal" rewritten in the context of software projects so that people would pick up the ideas easier instead of dismissing them as the "unrelated context."
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.
Makes sense to me that everybody should be aware of all POSSIBLY ANTICIPATED features/stories as soon as they exist, because you can then avoid doing work that later stories would contradict.
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.
Looking out into the future is a great exercise and teams can and should discuss future facing ideas together with customers, design and product people. Having a general sense of why we're building what we're building is critical and does help inform the shape of what we build.
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.
Having more (all) the tasks in a backlog from the get-go might make sense if we knew that:
a) requirements wouldn't change
b) priorities wouldn't change
c) we would be able to keep the understanding of the work throughout the effort
Then we'd just pull ticket by ticket and fill it with the details when we need it.
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.
FWIW, my rule of thumb was to avoid more than 3 cycles worth of stuff in view.
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 think we could have "anticipated tasks" kept somewhere maybe not on the "board", and not being committed to (yet). Just raise awareness of what is the high-level view of where we are or might be going.
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.
My argument is that forward looking ideas can be helpful, but they shouldn't be broken down into "tasks" until someone is prepared to make a concrete investment.
People who genuinely want their teams/organizations to improve didn't disappear.
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.
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.
The Japanese symbols were translated by by Chinese PhD as "card to watch". Now that I think about it (the memory) I think there was something participatory in it? "the card for watching" perhaps? "The card for noticing"? The software use of the term certainly feels like it misses the point as used in manufacturing.
Another thing I really like about Kasia's milk system is that it is a zero-emotional overhead communication. Just take the ticket and put it on her desk, and all will be handled.
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.
Hm, you’re right. I’m thinking a nearby Raspberry Pi with a camera facing the box. It uses an LLM to identify the box contents and send update messages to Kasia each morning. I’m surprised they didn’t think of this already.
Technically that's not really a different problem than exists. With the current system, Kaisa has to poll her desk every day to see if new milk needs to be ordered. Depending on what her activities entail, maybe there are entire days when she's not at her office. Some place has to be polled in any case, but we can choose the best place(s).
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.
Appreciate thinking of problems that might have made it work not so well.
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 :)
If there is only one fridge, the solution that minimises total distance travelled is trivial: Move Kasia into the fridge.
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.
> In its original meaning, Kanban represented a visual signal. The thing that communicated, well, something. It might have been a need, option, availability, capacity, request, etc.
> the system is self-explanatory
I've always known of this as an "affordance" - An available & apparent interaction between an object and its user.
There is definitely a connection there, but affordance is a concept specific to interaction design and something having a physically self-evident purpose (handles, buttons, levers, knobs, etc).
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.
> And it’s a healthy wake-up call when someone who knows close to nothing about our fancy stuff designs a system that we would unlikely think of.
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.
Is there even a Kasia, or did the author print out that note to establish her invented character just for the benefit of her blog's narrative? Does it really matter?
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.
Perhaps Kasia should be offered a way to participate in core business projects, or a raise, or both. Seems only fair after such praise from colleagues and HN.
We don't need to "offer" that. Anyone can do this. Literally, anyone can make any decision (in a structured manner), so joining a core business initiative is obviously on the list.
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.
Anyone who would downplay the value of an office manager has never appreciated a great office manager. Most offices do not have a competent (if any) office manager, which is something we should all demand of our workplaces.
...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.
> A simple index card taped to the last milk carton in a row stating, “Bring me to Kasia.” That’s it.
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.
In the office I worked it was never an issue that we were out of milk. It was that people brought in their own milk cartoons and put them in the fridge, so others could have milk too. Nice. Thanks to whoever brought it!
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.
I implemented the "three sticker rule" at my office. Every Friday, put a neon dot sticker on _everything_ in the fridge. Instead of putting a fourth sticker on anything, throw it out.
Because "anyone could do it", it usually ends up that "no one does it".
While this can be mitigated somewhat by keeping backups on hand, the card helps because it gives you a convenient record of needing to restock, which you can just drop somewhere you know it will be used. Even in personal life that might be a good idea. Dropping an empty box of pasta or dental floss on the ground also serves as a convenient reminder, but it's harder to do with a can of tuna.
It’s an interesting idea, but I’m not convinced it’s a good one. Office managers (or any kind of managers, really) are hired to remove a class of problems, so other people can focus on their job. This is outsourcing bits and pieces of your responsibilities to random coworkers. That being said, none of it is uncommon in modern corporate workplace.
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.
Kasia, the person who placed the note and requests its return, is the office manager. Giving someone an easy visual cue and task for keeping things running smoothly seems like great office manager work and organization rather than shirking any type of responsibility.
Agree. I dig the idea, really cool, but quoting the article:
> 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.
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.
The job of the person drinking the milk presumably has nothing to do with moving cards to people's desks. The job of the office manager is literally to keep the milk stocked. When keeping the milk stocked becomes a sidequest for every other employee (who have other jobs to do), what is the office manager actually doing? Bringing the card to the office manager's desk doesn't actually sound much harder than ordering more milk. Why don't we just have the card say, "If you see this card, order more milk" with instructions for how to do that?
> Bringing the card to the office manager's desk doesn't actually sound much harder than ordering more milk.
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.
I'm interrupted in the office a hundred times a day.
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.
We outsourced all of those things. The office managers are gone.
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.
Decades ago my first real job was as an IBM engineer fixing computers at a heavily unionised timber mill.
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.
Here are some things that are not that in software teams:
- 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".
But that's what I'm saying. An office manager makes a team most effective. A team that has to track a bunch of office maintenance tasks makes them less effective. Their team priorities should be top.
In a 20-person office you'll pass by like 2 people on the way with the card, so it's not a problem. If the office was bigger, and it was a problem, you could just designate a spot for the card next to the pantry.
I totally agree with you. I'm actually (despite downvotes) totally fine with bringing the paper tag to someone from time to time. My ego isn't hurt either.
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.
When I was in the army we had a simple system to determine who fell asleep on guard duty during training exercises[0], who was in possession of the squad leader's watch when everyone woke up.
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.
That's not a relevant analogy. In your example, staying awake during guard duty is your job and it's a proper responsibility. You should be penalized if you fail at your job.
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.
Are you really asking if an office would suffer if coffee was unavailable?
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.
It's a shame that some comments in the original post are so toxic and unwelcoming. There are plenty of empathetic people on HN. Well HN is welcome if at least when the topic isn't website standards or a page failing to load in some commenter obscure browser.
If you carry enough inventory to stock out every 6-12 months, this might a good system. If you stock out every week it might become a pain, both for notification and for reordering.
If it were me, I would have a service handle this, they bring in whatever you want and make sure it's topped up.
They probably want to check anyway to see if anything else is getting low (or ran out because a note wasn't delivered) to decrease the number of restocking orders placed. The notes just help indicate when an order needs to be placed earlier than expected.
The order typically runs with not just milk but all the supplies. It's just the "going out of milk" trigger happens most frequently.
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.
There is a level of oversimplification beyond which the solution stops serving its purpose.
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.
It's a quote that originated as a paraphrase of Einstein about applying Occam's razor to development of scientific theories.
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.
This system was recommended to me from an old veteran manufacturing expert that was one of the consultants on an ERP implementation. The brilliance that this brought was anyone could easily pick up the inventory and restocking process. But the people that got in the way of this were people that thought it was "dumb". One person already knew all the bits and pieces and this was just extra work. (she was leaving the company in a few months...) The people that liked this idea were the new people that were replacing the older people, and people that only worked with the inventory periodically, so didn't have ingrained knowledge. (also, the part numbers were inconsistent and many other small issues that new people struggled with)
But, the grumpy and the veterans won out, because they just didn't see the value in making a change like this. sigh
I wouldn't be surprised if milk consumption on that office went down after this. Unless the table was very near, I just wouldn't take the last carton lmao.
I don’t know much about kanban but doesn’t this basically create work for others to bring the milk paper back? I can see how this works and is efficient in a way, but it removes the work for the person to monitor the milk stock.
If we look at it from the systemic perspective, the goal is to have enough milk at the office just in time.
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."
> but it removes the work for the person to monitor the milk stock.
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.
sure it creates some work for someone that is invested in getting more milk for their coffee. hardly onerous and removes a lot of daily checking for the purchaser.
> The tricky part is that when you don’t drink milk yourself, it becomes a pain to check the cupboard with milk reserves every now and then to ensure we’re stocked.
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.
What if there are eight floors with two pantries each, four types of milk, five other drinks, plus seven different snacks that need replacing. They'd spend the entire day peeking at fridges and cupboards.
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.
Typically you combine that with other householding tasks. If you don't visit the kitchen or pantry daily as an office manager, you're doing something wrong. And walking through 8 floors with 2 pantries doesn't take that long either. I don't really think expanding o. The example makes a better case for the article...
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...
more efficient and convenient for both in the end.
Imagine the burden to have to put a postit on all products, to manage them on your desk, to stack them and remember to count them to reorder.
Also because you will not pass your order item by item, like just ordering milk and then sugar 2 days later...
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.
I don't understand how you consider all this complexity to be better than to just have an inventory of what have to be ordered once in a while.
In a batch, at the secretary or office manager own time.
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...
Your proposal probably is an improvement (though there may be some reason it's not feasible in this case -- no closet in the kitchen, etc), but calling the original idea "very stupid" is quite the ungenerous overstatement. It's still clever, still works much better than not having it at all, and is only slightly less efficient that what you're proposing.
If you don't have a closet, it's even easier, everything will be outside in plain sight. So the office manager just need a minute passing by the kitchen to see what would have to be ordered.
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.
You are presuming a lot, and the proposed solution you are ridiculing does have possible advantages that you aren't taking account of.
> 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.
And I say that it is stupid because from my point of view, you bring a very complex and time costly solution to something that could be solved a lot more simply and efficiently.
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.
Cigarette rolling paper comes in a flat pack, from which you take the papers one by one, like a box of Kleenex. Towards the bottom of the pack, there's gonna be an odd-colored piece of paper, after which there still gonna be 10 pieces left in the box. The odd-colored paper tells you that it's time to buy a new pack, but you still have 10 cigarettes' worth.
Edit: found a photo of this phenomenon on r/antiassholedesign https://www.reddit.com/r/antiassholedesign/comments/cfndfa/g...
One of the episodes of The Simpsons I saw as a kid that had a surprisingly large impact on how I think was where Willie had cameras in all of the bathrooms to monitor if they needed the toilet roll changed: “That roll of towels is nearin' its end! She's on double red stripe!”
"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 get that it's paper so probably not that big of a deal environmentally, but why would anyone want to individually wrap TP rolls??
If you buy in bulk, the rolls come in a big cardboard shipping box and not a shrink wrapped pack like the supermarket. The wrappers prevent stuff from getting on the rolls. Who Gives a Crap does the red wrapper thing.
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).
Selling individual rolls used to be more common. I'm sure you'll still see it today in smaller stores without a dedicated aisle for toilet paper/towels.
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.
I absolutely did read this in Willies voice.
The practice of having a slip that read “Five leaves left” was where Nick Drake got the title for his first album (somewhat eerily recorded five years before his death).
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.
You have discovered the Law of Fives: https://en.wikipedia.org/wiki/The_Illuminatus!_Trilogy#Numer... ; as it is written:
> 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."
It goes back at least to Plutarch:
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.
What a fantastically unaware admission of confirmation bias.
https://en.wikipedia.org/wiki/Confirmation_bias
One of the best albums ever IMO, just finished the excellent biography that came out a couple years ago by Richard Morton Jack
Receipt paper rolls also have this: When the roll is near the end there are pink stripes, telling the cashier to have a new roll nearby as the printer is about to run out of paper
I recently noticed that there was a "Time to order" message written on the outside of the cardboard core of my saran wrap. The visibility to the core became clearer as the wrap was consumed- giving both a sense of urgency, as well as not letting you forget. I thought it was pretty clever.
I think this is now a common pattern. Simplehuman trash bag boxes have a tag that says "you are running low", on the 10th (or so) bag from last.
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.
SimpleHuman trashbags do the same thing. When you pull the 5th last bag, it has a big tag reminding you to order more.
Certain dog poop bags have this but they have a sticker about three bags left that says "three bags left"
Phenomenon makes it sound rare, this is standard in all packs of skins
> When people say Kanban, they tend to think of a specific set of practices. Whiteboards & sticky notes (both almost universally virtual).
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
It is a subject that bothers me far more than it should, but when I was first exposed to the term kanban I naturally look it up and go "what on earth does any of this have to do with software?"
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.
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.
My angst with this (IMO tortured) metaphor, is each step is different every time. If we were knocking out exact clones of software systems this would work more like it is expected to.
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.
I guess within a product this metaphor works better. For example a new page with a new form is likely to be an adaptation of an existing form.
Service ot service this is less appropriate, but extending an existing service is a bit more like assembly line stuff
I can recommend reading “The Phoenix Project”.
I've worked on multiple Kanban software dev teams and a whiteboard never came into play, vs. the scrum or extreme-agile teams which loved them. Kanban seems more about having tickets organized into a priority ordered queue of tasks.
> 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!).
How can a ticket be completed to early? Software features are like wizards.
The metric they used was “planning accuracy”.
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.
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.
i've been dreaming of a way that visualises the user flows in the software (rather than cards on a board), think spider map showing possible user flows then colour coded circles based on what stage they're in.
that way you can see what state an entire flow is in at a glance and being able to co-ordinate effort accordingly.
That's true. The notion of what Kanban is differs between knowledge work (stemming mostly from software development adaptations) and manufacturing.
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.
>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 failed to explain.
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.
> I understand the literal translation of Kanban is 'coloured badge' btw
No, it's "signboard" or "billboard".
https://jisho.org/word/%E7%9C%8B%E6%9D%BF
My wife has worked in manufacturing for 20 years. It's very interesting to hear all the "technologies" that they have developed: six sigma, Kanban, lean manufacturing and all that. A lot of of that really feels like REAL engineering. Vs "sprint review" and "retrospective" crap we deal with in software.
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.
When I say Kanban, I mean "strip away all of the unnecessary processes that scrum/safe likely gave you and instead, simplify your process so you can focus on getting the work done...with a WIP limit."
So in terms of SW development would that mean we have slips saying "Only 5 Tasks left, come up with new ones"?
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.
"The Phoenix Project" is basically "The Goal" rewritten in the context of software projects so that people would pick up the ideas easier instead of dismissing them as the "unrelated context."
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.
Makes sense to me that everybody should be aware of all POSSIBLY ANTICIPATED features/stories as soon as they exist, because you can then avoid doing work that later stories would contradict.
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.
Looking out into the future is a great exercise and teams can and should discuss future facing ideas together with customers, design and product people. Having a general sense of why we're building what we're building is critical and does help inform the shape of what we build.
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.
Having more (all) the tasks in a backlog from the get-go might make sense if we knew that: a) requirements wouldn't change b) priorities wouldn't change c) we would be able to keep the understanding of the work throughout the effort Then we'd just pull ticket by ticket and fill it with the details when we need it.
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.
FWIW, my rule of thumb was to avoid more than 3 cycles worth of stuff in view.
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 think we could have "anticipated tasks" kept somewhere maybe not on the "board", and not being committed to (yet). Just raise awareness of what is the high-level view of where we are or might be going.
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.
My argument is that forward looking ideas can be helpful, but they shouldn't be broken down into "tasks" until someone is prepared to make a concrete investment.
> 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.
People who genuinely want their teams/organizations to improve didn't disappear.
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.
I ejected from the craziness and slipped into a quiet little, inexpensive corner to work on things that trigger obsession.
So far, it's gone pretty great, we'll see how long it holds!
the pull/push distinction is excellent, thankyou
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.
Right, if we see the future we should tell others about it. One we see the milk will be stinky soon, tell someone about it. :-)
It's closer to "sign" or a bit more specifically "signboard".
> I understand the literal translation of Kanban is 'coloured badge' btw
看板 - 看 "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").
The Japanese symbols were translated by by Chinese PhD as "card to watch". Now that I think about it (the memory) I think there was something participatory in it? "the card for watching" perhaps? "The card for noticing"? The software use of the term certainly feels like it misses the point as used in manufacturing.
Another thing I really like about Kasia's milk system is that it is a zero-emotional overhead communication. Just take the ticket and put it on her desk, and all will be handled.
It is not an interruption, or a new todo. That's what makes it elegant.
A bad system is a slack message once you get back to your desk.
First install truck horns, and have that go off for the dev being assigned a ticket.
Depends how far away her desk is.
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”
That’s a very nice Kaizen of this Kanban. Very scalable. The office may not have thought of it yet.
And then they have to poll the reorder box every day?
Hm, you’re right. I’m thinking a nearby Raspberry Pi with a camera facing the box. It uses an LLM to identify the box contents and send update messages to Kasia each morning. I’m surprised they didn’t think of this already.
NFC tags are pretty cheap these days, so tape one on the back of the notice and drop it into a box with a sensor at the bottom?
(This is probably overkill)
Needs more blockchain
Technically that's not really a different problem than exists. With the current system, Kaisa has to poll her desk every day to see if new milk needs to be ordered. Depending on what her activities entail, maybe there are entire days when she's not at her office. Some place has to be polled in any case, but we can choose the best place(s).
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.
Appreciate thinking of problems that might have made it work not so well.
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 :)
If there is only one fridge, the solution that minimises total distance travelled is trivial: Move Kasia into the fridge.
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.
Put this card on Kasia's desk when the reorder box is full.
Yes, this is closer to subscribing to events, and more scalable.
> In its original meaning, Kanban represented a visual signal. The thing that communicated, well, something. It might have been a need, option, availability, capacity, request, etc.
> the system is self-explanatory
I've always known of this as an "affordance" - An available & apparent interaction between an object and its user.
https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things
There is definitely a connection there, but affordance is a concept specific to interaction design and something having a physically self-evident purpose (handles, buttons, levers, knobs, etc).
That's a great analogy!
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.
> And it’s a healthy wake-up call when someone who knows close to nothing about our fancy stuff designs a system that we would unlikely think of.
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.
Is there even a Kasia, or did the author print out that note to establish her invented character just for the benefit of her blog's narrative? Does it really matter?
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.
Perhaps Kasia should be offered a way to participate in core business projects, or a raise, or both. Seems only fair after such praise from colleagues and HN.
We don't need to "offer" that. Anyone can do this. Literally, anyone can make any decision (in a structured manner), so joining a core business initiative is obviously on the list.
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.
Anyone who would downplay the value of an office manager has never appreciated a great office manager. Most offices do not have a competent (if any) office manager, which is something we should all demand of our workplaces.
There's a field of study called "mechanism design"
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.
I like the trash bag bunches where the last three have a little tag on them that say “you’re running low”. Similar system. Very useful.
Or thermal receipt tape with a stripe of color near the end.
> A simple index card taped to the last milk carton in a row stating, “Bring me to Kasia.” That’s it.
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.
In the office I worked it was never an issue that we were out of milk. It was that people brought in their own milk cartoons and put them in the fridge, so others could have milk too. Nice. Thanks to whoever brought it!
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.
I implemented the "three sticker rule" at my office. Every Friday, put a neon dot sticker on _everything_ in the fridge. Instead of putting a fourth sticker on anything, throw it out.
Because "anyone could do it", it usually ends up that "no one does it".
Sounds good, "THREE STRIKES AND YOU'RE OUT".
But would it not mean that sometimes you had 3 weeks old milk in the fridge? :-)
is 3 week old milk that old? usually when I buy milk the best by date is 2-3 weeks away
Those dates assume unopened products. After being breaking the seal, they don’t last as long.
I generally trust the due dates printed on the items. But what would I know? Maybe it's a conspiracy to force us to drink old milk ;)
On a more serious note, UHT milk can be stored for months, given it wasn't opened.
I like the idea of a "cartoon" also meaning an expired carton.
While this can be mitigated somewhat by keeping backups on hand, the card helps because it gives you a convenient record of needing to restock, which you can just drop somewhere you know it will be used. Even in personal life that might be a good idea. Dropping an empty box of pasta or dental floss on the ground also serves as a convenient reminder, but it's harder to do with a can of tuna.
It’s an interesting idea, but I’m not convinced it’s a good one. Office managers (or any kind of managers, really) are hired to remove a class of problems, so other people can focus on their job. This is outsourcing bits and pieces of your responsibilities to random coworkers. That being said, none of it is uncommon in modern corporate workplace.
Wow! This escalated quickly.
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.
Kasia, the person who placed the note and requests its return, is the office manager. Giving someone an easy visual cue and task for keeping things running smoothly seems like great office manager work and organization rather than shirking any type of responsibility.
Agree. I dig the idea, really cool, but quoting the article:
> 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.
>>> 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.
The job of the person drinking the milk presumably has nothing to do with moving cards to people's desks. The job of the office manager is literally to keep the milk stocked. When keeping the milk stocked becomes a sidequest for every other employee (who have other jobs to do), what is the office manager actually doing? Bringing the card to the office manager's desk doesn't actually sound much harder than ordering more milk. Why don't we just have the card say, "If you see this card, order more milk" with instructions for how to do that?
> Bringing the card to the office manager's desk doesn't actually sound much harder than ordering more milk.
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?
I'm interrupted in the office a hundred times a day.
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.
We outsourced all of those things. The office managers are gone.
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.
Decades ago my first real job was as an IBM engineer fixing computers at a heavily unionised timber mill.
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.
Finish the one before you start the next.
As long as you’re holding the slip of paper in your hand, you won’t forget about it.
To each their own, but wow. In healthy environments people are paid to do what makes the team most effective.
Here are some things that are not that in software teams:
- 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".
But that's what I'm saying. An office manager makes a team most effective. A team that has to track a bunch of office maintenance tasks makes them less effective. Their team priorities should be top.
Don’t have to track it. Just have to put the slip on their desk.
Then don't drink milk. You have more important things to do.
In a 20-person office you'll pass by like 2 people on the way with the card, so it's not a problem. If the office was bigger, and it was a problem, you could just designate a spot for the card next to the pantry.
I totally agree with you. I'm actually (despite downvotes) totally fine with bringing the paper tag to someone from time to time. My ego isn't hurt either.
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.
When I was in the army we had a simple system to determine who fell asleep on guard duty during training exercises[0], who was in possession of the squad leader's watch when everyone woke up.
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.
That's not a relevant analogy. In your example, staying awake during guard duty is your job and it's a proper responsibility. You should be penalized if you fail at your job.
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.
So... how is café latte "best for the business"?
Would the business fail if the milk supply ran out?
Are you really asking if an office would suffer if coffee was unavailable?
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.
It's a shame that some comments in the original post are so toxic and unwelcoming. There are plenty of empathetic people on HN. Well HN is welcome if at least when the topic isn't website standards or a page failing to load in some commenter obscure browser.
If you carry enough inventory to stock out every 6-12 months, this might a good system. If you stock out every week it might become a pain, both for notification and for reordering.
If it were me, I would have a service handle this, they bring in whatever you want and make sure it's topped up.
The system seems inefficient, as the sticky notes look the same. So Kasia has to go to the cupboard and check what to buy.
They probably want to check anyway to see if anything else is getting low (or ran out because a note wasn't delivered) to decrease the number of restocking orders placed. The notes just help indicate when an order needs to be placed earlier than expected.
The order typically runs with not just milk but all the supplies. It's just the "going out of milk" trigger happens most frequently.
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.
Solution: The specific brand is written on the back of the card.
> It should be as simple as possible (but not simpler)
I have seen this phrase a number of times. What does it mean?
There is a level of oversimplification beyond which the solution stops serving its purpose.
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.
It's a quote that originated as a paraphrase of Einstein about applying Occam's razor to development of scientific theories.
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.
Any simpler and it would not be effective for it's intended purpose?
Oh! So 'any simpler and...' was the next statement being implied by 'but not simpler' in this phrase. I can make sense of it now.
Wow, 3.2 and 2% milk available in the same office? Where do I apply?
This is a form of artifacts as reminders: https://pim.famnit.upr.si/wp/?p=288
Event triggers.
This system was recommended to me from an old veteran manufacturing expert that was one of the consultants on an ERP implementation. The brilliance that this brought was anyone could easily pick up the inventory and restocking process. But the people that got in the way of this were people that thought it was "dumb". One person already knew all the bits and pieces and this was just extra work. (she was leaving the company in a few months...) The people that liked this idea were the new people that were replacing the older people, and people that only worked with the inventory periodically, so didn't have ingrained knowledge. (also, the part numbers were inconsistent and many other small issues that new people struggled with)
But, the grumpy and the veterans won out, because they just didn't see the value in making a change like this. sigh
I wouldn't be surprised if milk consumption on that office went down after this. Unless the table was very near, I just wouldn't take the last carton lmao.
I don’t know much about kanban but doesn’t this basically create work for others to bring the milk paper back? I can see how this works and is efficient in a way, but it removes the work for the person to monitor the milk stock.
If we look at it from the systemic perspective, the goal is to have enough milk at the office just in time.
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."
> but it removes the work for the person to monitor the milk stock.
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.
sure it creates some work for someone that is invested in getting more milk for their coffee. hardly onerous and removes a lot of daily checking for the purchaser.
> The tricky part is that when you don’t drink milk yourself, it becomes a pain to check the cupboard with milk reserves every now and then to ensure we’re stocked.
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.
What if there are eight floors with two pantries each, four types of milk, five other drinks, plus seven different snacks that need replacing. They'd spend the entire day peeking at fridges and cupboards.
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.
Typically you combine that with other householding tasks. If you don't visit the kitchen or pantry daily as an office manager, you're doing something wrong. And walking through 8 floors with 2 pantries doesn't take that long either. I don't really think expanding o. The example makes a better case for the article...
In other words, issue tracker todo/doing/done lists have nothing to do with kanban.
They do if your "doing" list has a line on it that prohibits/allows more tasks to start
The milk example looks very stupid in my opinion.
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 feel like you are confusing "more efficient" with "more convenient for me when I use milk because I think the secretary is my maid".
more efficient and convenient for both in the end. Imagine the burden to have to put a postit on all products, to manage them on your desk, to stack them and remember to count them to reorder. Also because you will not pass your order item by item, like just ordering milk and then sugar 2 days later...
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.
I don't understand how you consider all this complexity to be better than to just have an inventory of what have to be ordered once in a while. In a batch, at the secretary or office manager own time.
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...
Which is exactly what most spoiled children^W^W tech workers think of them, unfortunately.
Your proposal probably is an improvement (though there may be some reason it's not feasible in this case -- no closet in the kitchen, etc), but calling the original idea "very stupid" is quite the ungenerous overstatement. It's still clever, still works much better than not having it at all, and is only slightly less efficient that what you're proposing.
If you don't have a closet, it's even easier, everything will be outside in plain sight. So the office manager just need a minute passing by the kitchen to see what would have to be ordered.
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.
You are presuming a lot, and the proposed solution you are ridiculing does have possible advantages that you aren't taking account of.
> 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.
And I say that it is stupid because from my point of view, you bring a very complex and time costly solution to something that could be solved a lot more simply and efficiently.
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.
Why is this more efficient?
Batching.