[dead]
Milk Kanban
161–170 of 173 posts
Re: Milk Kanban
#162> 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 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 deve…
> 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.
Re: Milk Kanban
#163Earlier quoted context omitted.
> 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 be…
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.
Re: Milk Kanban
#164Earlier quoted context omitted.
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.
Re: Milk Kanban
#165> 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…
> I understand the literal translation of Kanban is 'coloured badge' btw
No, it's "signboard" or "billboard".
Re: Milk Kanban
#166Earlier 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…
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.
Re: Milk Kanban
#167Earlier quoted context omitted.
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.…
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.
Re: Milk Kanban
#168Earlier quoted context omitted.
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 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…
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.
Re: Milk Kanban
#169Earlier quoted context omitted.
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 p…
Yep! And indeed, this is Who Gives A Crap. I've been really impressed with their product. I do still intend to buy bidets for the house to cut down on TP use overall, but theirs is pretty darn environmentally friendly for the product that it is, and the subscription has been just the right amount that we're not having to buy extra at the grocery to cover shortages nor winding up with stacks and stacks like a doomsday prepper.
Re: Milk Kanban
#170Wow, 3.2 and 2% milk available in the same office? Where do I apply?
3.2% is just whole milk.