Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Milk Kanban

brodzinski.com

Post reply on HN
Print view View original

111–120 of 173 posts

Re: Milk Kanban

#111

Post by galaxyLogic »

ramses0 wrote: post #106
galaxyLogic wrote: post #53

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? :-)

Re: Milk Kanban

#112

Post by y33t »

dhosek wrote: post #28
meindnoch wrote: post #14

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…

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.

Re: Milk Kanban

#113

Post by flail »

jimnotgym wrote: post #95
flail wrote: post #84

Earlier quoted context omitted.

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 w…

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

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.

Re: Milk Kanban

#114

Post by galaxyLogic »

flail wrote: post #89
jimnotgym wrote: post #75

Earlier quoted context omitted.

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…

"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 limiti…

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.

Re: Milk Kanban

#115

Post by galaxyLogic »

pdpi wrote: post #58
galaxyLogic wrote: post #51

Earlier quoted context omitted.

So in terms of SW development would that mean we have slips saying "Only 5 Tasks left, come up with new ones"?

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

Re: Milk Kanban

#116

Post by smusamashah »

askvictor wrote: post #101
smusamashah wrote: post #96

> It should be as simple as possible (but not simpler) I have seen this phrase a number of times. What does it mean?

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.

Re: Milk Kanban

#117

Post by flail »

blackeyeblitzar wrote: post #82

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

Re: Milk Kanban

#118

Post by flail »

galaxyLogic wrote: post #114
flail wrote: post #89

Earlier quoted context omitted.

"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 limiti…

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 imp…

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.

Re: Milk Kanban

#119

Post by gwern »

cameronh90 wrote: post #32
meindnoch wrote: post #14

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…

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

Re: Milk Kanban

#120

Post by gwern »

y33t wrote: post #112
dhosek wrote: post #28

Earlier quoted context omitted.

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 bac…

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

Post reply on HN