31–40 of 68 posts
Earlier quoted context omitted.
Well at least you can join the noble ranks of folk whose writing was tangentially nitpicked in the very first HN comment.
Happens every time. I have learned to expect it. It does make me spend a little more time though thinking through the counter arguments that are likely to be fired like spears.
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…
Earlier quoted context omitted.
They might know more about the product but in a functioning org if they know more about the customers or market -- something is terribly wrong (unless it is software for engineers). Agree?
I don't really agree with this view point that engineering should know less then PM. In a good team, Engineering knows what features are there, why are they there and what sales / customers are hankering for, and also how they where implemented. Sales is generally aware of what is more valuable to a given customer Marketing has an overall idea of how the market is behaving. PM is the crucible where all these informat…
Earlier quoted context omitted.
True. But PM needs to pick its head up and think more broadly. A "one in one out" queue is contrary to delivering winning product.
As I have said below ( https://news.ycombinator.com/item?id=6119175 ) You need to delink engineering releases from marketing releases. Where is it written that when the engineering releases a feature you need to make a marketing push? When you have a collection of features ready which as a whole makes sense for marketing, then you make a marketing release with all the related PR, hype cycle, etc ...
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 analyst/product owner handling out a tome of requirwments from on high with a thud, you break the work down into a minimally useful / marketable chunks, minimize work in progress, deliver according to some priority, and iterate and learn from the results.
This is the philsophical foundation of lean Startups (customer development), lean development, and much of the work on Devops.
So the article rails against Kanban ... And almost seems like its advocating for the same thing with its goal-driven approach to delivery (?).
Any methodology or process framework is subject to misinterpretation or abuse. This is why "agile" and "scrum" are dirty words to many - it's hard to tell what you're getting, as the term has been twisted to suit vested interests. It looks like it is Lean and Kanban's turn to be trashed due to ersatz versions being forced on teams.
But articles like this aren't helpful unless they explain what they mean Kanban, and what aspects are ineffective - clichés like "software is different" don't illuminate.
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…
The point is that it is a mistake to take a methodology that was created for incremental process enhancement along a manufacturing line and apply it to software development.
Earlier quoted context omitted.
This is a sure sign of a broken PM group (and product dev team in general). Great teams are made of equal parts PM, Eng, Design and a group of folks who can actually position and sell a product.
For sure, which is the fundamental reason why kanban doesn't work. If you have good teams basically all you need is a thin layer of process that prevents total chaos, kanban is a good fit for that, but most teams implement kanban in a cargo cult manner. I've worked on sales driven teams where I fundamentally trusted the sales guy because when he said if you make feature X I can sell it for $Y dollars and we made bank…
See -- The Holy Scrum War - http://blog.aha.io/index.php/the-holy-scrum-war/
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 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 shop floor and benefit from being organized in an end-to-end pull flow like Kanban.
I look at Four Steps to the Epiphany by Steve Blank, or Lean Startup by Eric Ries, while they aren't specifically dictating a Kanban board in their work, they're clearly philosophically in the camp of a pull-based approach to organizing work and limiting work-in-progress.
So, what I haven't determined from your article is, what specifically is flawed with these authors views and my experiences? Am I being over-broad in their inclusion? My interprtation of your article this far is a well-meaning but under-argued philosophical aversion to being lumped in with other industrial engineering practices.
Edit: clarity
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…
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…
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.
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.
So first time around you are going to see these issues, but then the question to ask is, are you measuring the activities? Are you looking at the metrics? Are you debugging the process by trying to ask questions on what the metrics are telling you?
If not any process will fail. And in case of Kanban, metrics are the most important data to understand your cadence. How else will you identify waste, identify bottlenecks and also get into "continuous improvement".
To me goal of any good process should be: a) Provide feedback as early as possible on every activity thus improving the possibility of success. b) Reduce the cost of transaction in some form by either improving productivity or reducing waste. c) Build a team which works as a collective whole with everyone aware of what needs to be get done and when and for what purpose.
If any process fails to do these, you have a failed process.