> 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.
> but extending an existing service is a bit more like assembly line stuff
(IMO) only if most of the assembly line has to be at least partially retooled every time you do it. No software feature in any but the most basic of systems stands alone.
Which, tbf, a lot of Lean/Kanban software teachings do account for, but most management likes to gloss over.
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.
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.
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.
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.
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