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

Kanban – The Secret Engineer Killer

blog.aha.io

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Kanban – The Secret Engineer Killer

#41

Post by bdehaaff »

parasubvert wrote: post #38
bdehaaff wrote: post #36

Earlier quoted context omitted.

I tried to clearly define Kanban as a "Kanban (meaning signboard or billboard) is a scheduling system for lean and just-in-time production. It’s a system to control the logistical chain from a production point of view. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. The Kanban Method was later added to as an approach to incremental, evolutionary pr…

So, I've had the opposite experience: lean-type incremental process enhancement has had dramatic improvements on the end-to-end results of more than one company I've been involved with. I look at a book like The Phoenix Project, written by some fairly respected software industry folks like Gene Kim, and they also recommend the opposite: that software development and IT operations actually are a lot like an industrial…

From my experience and from what I am hearing it (meaning Kanban) does not work for most folks or companies. That's it. It might work well for you and that's great too. I don't think Kanban and Agile philosophies are the same though - but that's at least another long blog post.

Re: Kanban – The Secret Engineer Killer

#42

Post by bernardom »

As an industrial engineer, this is the equivalent of a developer walking into a factory and hearing about how "the mythical man-month" is a terrible book/idea because it allows for waste.

Right. The Mythical Man-Month is a great book/concept for creative/engineering projects. Kanban is a wonderful way of implementing a Just-In-Time manufacturing system.

Props to the OP for explaining the origin of kanban. May this post help fix the co-opting of an IE term for something totally different.

Re: Kanban – The Secret Engineer Killer

#43

Post by bdehaaff »

snorkel wrote: post #39
bhattisatish wrote: post #12

I am a fan of Kanban, so whatever I say will be through the rose tinted glasses of a fan. There maybe various reasons why Kanban has failed for many companies. I haven't worked in those teams so I have no way to say is it because of Kanban or is it because of management misunderstanding kanban. From your article, the main reason touted is that the Marketing loses it's way. Which to me sounds strange! In fact I have s…

Unfortunately not all of us are blessed to work with well organized stakeholders who are able to plan ahead rather than wait until the last minute to request whatever they need from engineering. Agile only works when the entire organization abides by its rules, sure engineering teams can train their stakeholders to some degree but upper management can just overule the process and insist engineering should be like a s…

So what methodology have you found that works well in that environment? I am curious what helps you manage the madness as best you can when PM is not organized and "management" meddles.

Re: Kanban – The Secret Engineer Killer

#44

Post by bdehaaff »

bernardom wrote: post #42

As an industrial engineer, this is the equivalent of a developer walking into a factory and hearing about how "the mythical man-month" is a terrible book/idea because it allows for waste. Right. The Mythical Man-Month is a great book/concept for creative/engineering projects. Kanban is a wonderful way of implementing a Just-In-Time manufacturing system. Props to the OP for explaining the origin of kanban. May this po…

I appreciate that. I really do. It's rare to receive an ounce of props on HN. I must admit that I was totally surprised to learn that it was not designed for software development and that the author of the Lean Methodology has been trying to convince folks to stop using it.

Re: Kanban – The Secret Engineer Killer

#45

Post by bhattisatish »

snorkel wrote: post #39
bhattisatish wrote: post #12

I am a fan of Kanban, so whatever I say will be through the rose tinted glasses of a fan. There maybe various reasons why Kanban has failed for many companies. I haven't worked in those teams so I have no way to say is it because of Kanban or is it because of management misunderstanding kanban. From your article, the main reason touted is that the Marketing loses it's way. Which to me sounds strange! In fact I have s…

Unfortunately not all of us are blessed to work with well organized stakeholders who are able to plan ahead rather than wait until the last minute to request whatever they need from engineering. Agile only works when the entire organization abides by its rules, sure engineering teams can train their stakeholders to some degree but upper management can just overule the process and insist engineering should be like a s…

I agree. That's the reason I love Kanban. It allows us to capture metrics on what is being done, how long it took and where are we spending most of our time. This numbers in turn allow us to push the story to management on what they are doing wrong.

For e.g. We worked on a team where Sales made a feature request (1 day, PM and design team worked on it and released it to engineering (5 weeks) and engineering released it to sandbox (2 weeks), qa tested it and released it to production (1 week).

Guess where the bottleneck is? The whole cadence for the feature was 8 weeks. Obviously Sales where jumping on us for not getting it done on time. This way of looking at the whole board, allowed us to identify a bottleneck and push for changes on how the whole company operates. If you kanban a board only for engineering then you lose the big picture, How is the system as a whole operating.

Re: Kanban – The Secret Engineer Killer

#46

Post by parasubvert »

bdehaaff wrote: post #41
parasubvert wrote: post #38

Earlier quoted context omitted.

So, I've had the opposite experience: lean-type incremental process enhancement has had dramatic improvements on the end-to-end results of more than one company I've been involved with. I look at a book like The Phoenix Project, written by some fairly respected software industry folks like Gene Kim, and they also recommend the opposite: that software development and IT operations actually are a lot like an industrial…

From my experience and from what I am hearing it (meaning Kanban) does not work for most folks or companies. That's it. It might work well for you and that's great too. I don't think Kanban and Agile philosophies are the same though - but that's at least another long blog post.

Fair ball. I'd say if its being latched onto as a panacea, almost all approaches to process will fail if you lack the basics: a good market, an insightful product owner/manager, good engineers, and at least an adequate morale in the company.

I've seen companies/projects with all of those things still fail because of a poor process. This is where something like Kanban can help, IMO. Not trivial to implement though.

Re: Kanban – The Secret Engineer Killer

#47

Post by bdehaaff »

bhattisatish wrote: post #40
bdehaaff wrote: post #32

Earlier quoted context omitted.

I think that we would actually agree. I don't really care how Eng gets to a major milestone and delivers a good portion of the required features. The issue is that when the teams lose focus of the bigger picture and stop thinking about key dates and what collection of features are needed to win. When any dev methodology becomes the goal and not the means to an end -- companies and their customers suffer.

Isn't that the role of PM, and management? That's what they are for. To ensure that people do not lose sight of the bigger picture. When you first implement a process, any process (waterfall, kanban, scrum, whatchamighticallit) the first cycle is going to be hard as everyone is trying to adjust to the new way of doing it. Some people will buy in, some people will call it a fad, some people will like to wait and watch…

Fair enough. I think there is they Why (strategy) the What (features and user stories) and the How (engineering getting bits out the door). I am poking at when the How overshadows the Why and What. That's when things go sideways.

Re: Kanban – The Secret Engineer Killer

#48

Post by hencq »

bdehaaff wrote: post #36
parasubvert wrote: post #35

This is a confusing argument. Kanban/lean is a pretty simple idea (not always easy to execute): eliminate waste in your work by smoothing the flow of requirements/changes. This treats your end-to-end delivery capability as a syatem and one that should not be overburdened. The clearest sign of being overburdened is when you have a lot of work in progress but nothing to show for it. So instead of a genius PM/business a…

I tried to clearly define Kanban as a "Kanban (meaning signboard or billboard) is a scheduling system for lean and just-in-time production. It’s a system to control the logistical chain from a production point of view. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. The Kanban Method was later added to as an approach to incremental, evolutionary pr…

I don't know much about Kanban as a software development method, but from the description it seems more closely related to the original Kanban concept than the Kanban Method. Kanban (the card system) is mainly about controlling work in progress and not so much about 'incremental process enhancement'. It sounds like the software methodology tries to mainly control the amount of in progress work as well.

This isn't really a criticism on the point your making in the article by the way, which I think is still valid. I find it weird too that software development is being shoehorned into a manufacturing job control system.

Re: Kanban – The Secret Engineer Killer

#49

Post by bdehaaff »

hencq wrote: post #48
bdehaaff wrote: post #36

Earlier quoted context omitted.

I tried to clearly define Kanban as a "Kanban (meaning signboard or billboard) is a scheduling system for lean and just-in-time production. It’s a system to control the logistical chain from a production point of view. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. The Kanban Method was later added to as an approach to incremental, evolutionary pr…

I don't know much about Kanban as a software development method, but from the description it seems more closely related to the original Kanban concept than the Kanban Method. Kanban (the card system) is mainly about controlling work in progress and not so much about 'incremental process enhancement'. It sounds like the software methodology tries to mainly control the amount of in progress work as well. This isn't rea…

Totally agree. That's what was shocking to me as well when I started to drill into it after hearing so many folks complain about it. I think it is a sign of engineering managers struggling to find a simple process to deliver product more predictably. Unfortunately, it seems to be doing more harm than good.

Re: Kanban – The Secret Engineer Killer

#50

Post by bhattisatish »

bdehaaff wrote: post #47
bhattisatish wrote: post #40

Earlier quoted context omitted.

Isn't that the role of PM, and management? That's what they are for. To ensure that people do not lose sight of the bigger picture. When you first implement a process, any process (waterfall, kanban, scrum, whatchamighticallit) the first cycle is going to be hard as everyone is trying to adjust to the new way of doing it. Some people will buy in, some people will call it a fad, some people will like to wait and watch…

Fair enough. I think there is they Why (strategy) the What (features and user stories) and the How (engineering getting bits out the door). I am poking at when the How overshadows the Why and What. That's when things go sideways.

This is where I see the trouble when How is limited to engineering! (As an e.g. https://news.ycombinator.com/item?id=6119340)

You need to be able to capture every activity and every team that gets involved in the process. If not you will have a dysfunctional company where each department does not see the whole picture of how we push features. How = PM setting out the stories, Marketing putting down the value (how else are you going to sort the que?), Engineering building it, IT managing it, PM measuring the usage, and capturing the actual value denoted by the customer. The board should be able to capture all these. In turn providing feedback to every team. For e.g. if Marketing is constantly assigning wrong values to features, then we need to figure out what do we need to do put in right estimates for them? etc ... Kanban is about looking at the whole picture by breaking it down into the actual activities you as a team are involved in. You could be actually following a waterfall process internally but still observe it, capture it, measure it and then improve upon it. That's when its a kanban process. Everything else is cargo culting.

Post reply on HN