141–150 of 173 posts
> It should be as simple as possible (but not simpler) I have seen this phrase a number of times. What does it mean?
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.
> 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…
> 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…
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.
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.
Earlier quoted context omitted.
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…
Earlier 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.…
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.
Earlier quoted context omitted.
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, alt…
> 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…
> 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…
> 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…
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.
Earlier quoted context omitted.
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.
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.
that way you can see what state an entire flow is in at a glance and being able to co-ordinate effort accordingly.