5 ms·

> When people say Kanban, they tend to think of a specific set of practices. Whiteboards & sticky notes (both almost universally virtual). When software develo

> 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

eikenberry 2y ago
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.
- flail 2y ago
  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.
  - _betty_ 2y ago
    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.
- Aurornis 2y ago
  > 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!).
  - celticninja 2y ago
    How can a ticket be completed to early? Software features are like wizards.
    - Aurornis 2y ago
      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.
galaxyLogic 2y ago
So in terms of SW development would that mean we have slips saying "Only 5 Tasks left, come up with new ones"?
- pdpi 2y ago
  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.
  - galaxyLogic 2y ago
    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. :-)
- anymouse123456 2y ago
  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"
lotyrin 2y ago
It's closer to "sign" or a bit more specifically "signboard".
flail 2y ago
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.
- jimnotgym 2y ago
  >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
  - flail 2y ago
    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.
thaumasiotes 2y ago
> 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 https://ejje.weblio.jp/content/%E7%9C%8B%E6%9D%BF has "看板 - signboard; billboard" (and also "hoarding", "draw; attraction", and "closing time").
xtracto 2y ago
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.
- brightball 2y ago
  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.
somat 2y ago
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.
- celticninja 2y ago
  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.
  - michaelcampbell 2y ago
    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.
    - celticninja 2y ago
      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
brightball 2y ago
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."
Peteragain 2y ago
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.
wodenokoto 2y ago
> 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 https://jisho.org/word/%E7%9C%8B%E6%9D%BF

eikenberry 2y ago

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.

flail 2y ago
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.
- _betty_ 2y ago
  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.
Aurornis 2y ago
> 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!).
- celticninja 2y ago
  How can a ticket be completed to early? Software features are like wizards.
  - Aurornis 2y ago
    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.

galaxyLogic 2y ago

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

pdpi 2y ago
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.
- galaxyLogic 2y ago
  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. :-)
anymouse123456 2y ago
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"

lotyrin 2y ago

It's closer to "sign" or a bit more specifically "signboard".

flail 2y ago

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.

jimnotgym 2y ago
>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
- flail 2y ago
  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.

thaumasiotes 2y ago

> 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 https://ejje.weblio.jp/content/%E7%9C%8B%E6%9D%BF has "看板 - signboard; billboard" (and also "hoarding", "draw; attraction", and "closing time").

xtracto 2y ago

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.

brightball 2y ago
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.

somat 2y ago

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.

celticninja 2y ago
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.
- michaelcampbell 2y ago
  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.
  - celticninja 2y ago
    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

brightball 2y ago

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

Peteragain 2y ago

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.

wodenokoto 2y ago

> 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 https://jisho.org/word/%E7%9C%8B%E6%9D%BF