The 95%-of-diets-fail number comes from a single study in an obesity clinic performed in 1959. Followup studies, also at obesity clinics, found comparably high rates of recidivism.
But when you take the most pathological cases of obesity in a time before obesity was the norm, unsurprisingly those cases are ... pathological. There is a pathology.
These aren't normal people who grew overweight under conditions of stunning caloric abundance.
So let's stop quoting this statistic because the sample bias is kindly stupidly important to its interpretation.
Thanks for the comment. I actually spent a considerably amount of time looking for a meaningful reference. I found the Popkess-Vawter 1998 reference, but could not find the original text. Do you have a better number for "failure" or reference that I could use? I would be happy to update the post.
Hard to say. Either you rely on clinical studies, which give you pathologically-skewed sample bias, or you use the National Weight Control Registry, which will be skewed to people wanting to report successful weight control.
Thanks. I am not an expert in this area (diet success data) and was simply trying to use an analogy. I guess I will leave it as is. I am not sure what else to do -- it seems that leaving it with no reference would be worse.
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.
Really interesting piece. It is amazing that a technique used to optimize shop floors has been applied to the engineering field which I believe to be so creative versus "industrial."
That surprised me as well. I think engineering managers are willing to try just about anything to regain some control and deliver software more predictably. My sense from talking to many companies is that it is unfortunately having the opposite effect.
I'm loath to take this on faith without better description of the dataset. 150 companies sounds impressive, but, where are they based? What areas do they work in? How long have they been doing it? Have other factors, such as the health of these companies, been considered?
Still, many of these points resonated with me.
I started recently on a team that follows kanban-ish practices. Fortunately nobody here is that process-focused that we follow it exactly. Also, there is nothing that says you have to work on only one thing at a time, and we typically don't. In fact, I work part-time on another team, and the other one does not do kanban.
But I don't much like the kanban system: Give me a satisfyingly large component, and let me work on it entirely.
So for kanban in general, here's another facet to consider, and one that probably explains why engineers are "leaving in droves": As TFA says, you end up working on many small pieces of a larger whole. The good part is, you could end up becoming aware of all parts of the system that you touch.
But! When you interview elsewhere, or heck, even when you're updating your resume, and it comes to answering the inevitable question, "What did you work on in this project", the honest answer is, "Uhh, many parts but nothing overarching as such..."
And right then, even to yourself, that sounds like such a weasel-wordy answer. You could go on and explain, "Well, I wrote method A of component X, and feature B of webpage Y and an implementation C of interface Z for cases where Q is R." But to an interviewer, I'd guess it all sounds like "I worked on nothing worthwhile."
On the other hand, since you have better awareness of the project as a whole, you could say you worked on all of it, and make up more impressive-sounding responsibilities as you go along.
But I find it much easier if I just do something impressive and be straightforward during interviews.
Thanks for the comments. The companies have been distributed across the country (with a few outside of the US as well). They have been of different shapes and sizes, but I did not do a good job tracking all of their characteristics. The purpose of the calls was to discuss Aha! -- not different engineering methodologies. A few trends jumped out at me and this was one of them, so I decided to write about it and try to be fair that the ideas are based on qualitative research (discussions). I appreciate your thoughts and the idea that engineers should own large components of a project or entire projects resonates with us. We think it creates real pride of ownership and interest in customer success and it has been how we have organized our engineering teams at three different companies now. It's clearly better for individuals (as you mentioned) and the companies they work for.
What the heck do kanban have to do with project management? Speaking -as- a Lean Six Sigma Black Belt (still can't type that with a straight face) in the healthcare sector, I can't even imagine how someone would set out using a kanban to run a company.
That's just so wildly divorced from what it is or what it's for that that article made no sense to me.
Like 'fad diets' most of the reasons that kanban fails is because the organization was sick to begin with and kanban would have helped if not for the structure of the organization in the first place.
Fad diets mostly fail because people go back to eating the same shitty way they did before, just as when a team adopts kanban marketing and product go back to the same stupid way of doing things they did before.
The sad part is that in the vast majority of organization engineering actually knows more about the product than product or marketing.
The core of it is that most engineers don't want to work on the stupid fucking ideas that product and marketing come up with instead preferring to make the product 'good' instead of creating feature parity with some competitor.
If product and marketing were actually good at their jobs they should at least be able to convince the engineers in their own fucking company that what they are thinking is a good idea. Right now I'm picturing the eye-rolls at Porsche when product and marketing announced the idea for the Panamara.
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 information comes in and they need to define how product will be built.
But please note, each subteam should have a strong idea of the market. If not, then people are not effectively communicating.
Lack of communication is a sure sign of dysfunctional team, which results in each teams working on their pet projects, but no one knows when what will come out of the whole process.
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.
I agree with your thoughts around dysfunction as it relates to fad diets and poor habits. I also think that many engineers think they know best, but in a well functioning org PM actually knows the customers and market and has a collaborative relationship with engineering. Do you think that PM has no role or that in most cases they just don't do it well?
On the contrary in the Kanban process, PM is the pivotal role. They control the que, the cadence of feature releases, etc ...
Without an effective PM, the whole thing will fall as a pack of cards.
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 ...
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.
It's easy for product and marketing to convince engineers by demonstrating results. Usually they come up with some stupid idea, engineers waste time building it, and then it fails. But instead of letting it die, they add yet more sub-features to their stupid fucking feature no one wants.
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 doing that.
Conversely I've worked on teams where everyone was trying to avoid being fired and would only make decisions that were defensible, eg. company X is doing Y so lets do Y, resulting in the usual follow the leader failure.
> Right now I'm picturing the eye-rolls at Porsche when product and marketing announced the idea for the Panamara.
The sad thing is that the Panamera (in stark contrast to any rational thought and sense of aesthetics) is not a complete commercial failure. People with too much money are weird.
Fad diets don't work because they are ineffective, not because people go off them. Frankly, if you always followed fad diets, you'd end up killing yourself. Your logic is flawed.
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 seen it the otherways. We effectively delink marketing cadence from engineering cadence! Thus resulting in derisking the whole big bang releases.
For e.g. Marketing decides that they are going to make a big marketing push on a conference or a tradeshow. So the PM come up with a list of features they will showcase for the given event. (say 10 features are decided upon).
The engineering team works on these features as a que. Releasing each of these as and when they are done. But do note an engineering release to production does not mean a marketing release. This allows the PM to experiment on features, build up case studies, etc ... for these features.
And as the marketing releases dates come closer, everybody knows that we always have a working copy with only the pending items in the que.
This results in a high confidence level within the marketing / engineering on what is being touted about. There are no last minute scramble to get a working system. etc ... The most valuable feature was heavily tested and used by everyone before the big bang marketing release.
It also allows the PM to make A/B experiments before the actual marketing push. Thus adding another confidence layer to the whole process.
In a worst case scenario the least valuable features never get released for the marketing push.
I see this as an effective way to derisk the whole marketing push and reduce their dependency on the engineering team to deliver stuff when they said they would.
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.
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.
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.
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.
I think that is your more advanced product development system. I don't that is the definition of Kanban or what it was devised for. It reminds me of Agile -- everyone is now Agile but no one describes it the same way. Thanks for your feedback.
I think that actually is exactly what Kanban was devised for and largely the context of the David Anderson quote in your article: Kanban is not for software development, it is a technique for seeing, organizing, and improving the end-to-end process of how an organization accomplishes stuff. It is not a complete software process: it says nothing about QA/testing for example. Nor is it a complete marketing process: it doesn't say anything about how you determine market values.
It's about making all these sub-processes flow together, and identifying where the bottlenecks are.
Not an easy read. That said, it aligns to what you've been saying in your article (I think): the WHAT and WHY is irrelevant to Kanban, it can't help you there. The HOW, sure: but even there it is more of an overlay on existing process, not a catch all "one method to rule them all".
Where we get into trouble is that I think your article is saying "Kanban doesn't work, do this process instead". But the process you sketch out probably would fail too in many organizations that lack a good handle on what they're doing and why. Any process will, even goal-driven ones (which IME tend to work only in small scales with few cross-department interactions)
Agree, though in fairness I've found it's necessary to get away with "black boxing" certain non- cooperative groups in the short run, and treating them as a fixed constraint.
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 service desk that responds to whatever is needed today. Sucks, but it's a reality in many workplaces.
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.
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.
Fair point. I was not certain where to add it. My belief, based on my conversations was that many have heard about it -- so I did not want to bore those in the know.
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.
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 process improvement for organizations."
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.
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 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.
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.
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.
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.
Have you read any of David Anderson's book? Are you aware that the Kanban Method is an adaption of Taiichi Ohno and W. Edward Demings guidance in lean manufacturing to the knowledge work domain? The Kanban Method is specifically designed for knowledge work organizations, which also includes software development activities.
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.
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.
What do you mean the author of the Lean Methodology has been trying to stop folks from using it? Are you suggesting David Anderson wants us to stop using Kanban for Knowledge Work?
David Anderson, the creator of The Kanban Method (discussed above) wrote the following in late 2010.
“Kanban is NOT a software development life cycle or project management
methodology! It is not a way of making software or running projects that make software!”
Unfortunately, the tendency to overload terms with multiple meanings is confusing the situation. It is very common for the word kanban to be used incorrectly because there are three commonly confused meanings for the word.
kanban - visual signal, signboard
kanban system - pull-based, wip limited flow management system
Kanban Method - an approach to incremental, evolutionary process and systems change for organizations
So yes, the Kanban Method is not an SDLC method. It is a meta-method that will allow for the emergence of an appropriate SDLC within an organization. That SDLC may be Agile (very good things in Agile mindset), may be waterfall, may be Scrum or Scrumban-ish, but it should be appropriate for then context.
You don't see any SDLC specific tactics or guidance in there. That is true. You don't see any Agile language in there. It doesn't provide any specific Agile guidance.
You won't find any specific tactics for software development in the Agile Manifesto either. But out of the mindset comes specific SDLCs that are aligned to the manifesto like Scrum or XP or any of the million "custom" Agile methodologies that have no name but are used by IT organizations everywhere.
David Anderson absolutely wants the Kanban Method to be used (as appropriate) in organizations that do knowledge work (software development is knowledge work) to help those organizations develop the best workflow and capability for a given context and to create a culture of learning, growth, and continuous improvement. I've talked to him many times about these very topics! Many of the case studies that we quote in our work are from software development organizations.
The quote used above has been taken out of context, isolated, and used to create fear, uncertainty and doubt about The Kanban Method and I find that kind of behaviour negligent at best.
As others have noted the definition of kanban comes too late in your article. Also, I think a citation to wikipedia is in order if you're going to copy it and simply expand the initialisms.
Regardless, it's not a particularly helpful definition for anybody that's never heard of kanban, and certainly doesn't help anybody familiar with kanban to know what specifically you're evaluating; you need to get everybody on the same page from the outset.
Given lack of concrete examples and your previous posting history I would consider this more of an advertisement for your product, to which I've now applied for an invitation, but you seem to be genuinely responding to comments here and nobody else has complained. I suppose either way, well played.
I have other comments but I'll hold them until I find out exactly what you mean by kanban, because I've been admittedly self-identifying the process I'm using as kanban and maybe it's not.
I will say this much though, the practices of kanban (visualization, limited work-in-progress, managed flow, feedback loops, etc.) are all valuable in my opinion and I wonder which of these you see leading to, or how you see them leading to, the problems you've cited. Also, I wouldn't mind some more concrete metrics to back up such an inflammatory title.
If you just read the subtitles, I'd almost think your article was a piece in favor of Kanban.
Engineers aren't assembly workers: so why do other methodologies seem to be so prescriptive on what can be accomplished in a given time frame? New problems arise, priorities shift, and unexpected news arrives. I appreciate the flexibility of a pull-type system because it lets me transparently show what I'm working on.
I've really hated telling people no or watching a manager struggle to change up something we really need just because it doesn't fit in the right shape time box or might affect the current sprint's plans.
You can't trust yourself: I always ended up hating sprint planning meetings where "points" are a constant source of conflict between stakeholders and estimates are fantastical. These sort of meetings just allow the quality knob to turn down while scope and schedule remain fixed. Having an entire team minimizes estimates problems, but for the effort involved I'm not sure the gains are worth it.
Also, I think you may have inadvertently taken Anderson's quote out of context as well—Kanban isn't a way to run software. It's merely a way to expose your current process so you can improve it. Kanban is something that sits on top and allows you to identify bottlenecks, be realistic about results (instead of estimates) and provide immediate transparency into what you're working on. It doesn't specifically prescribe what the steps are.
Thanks for the quality comments. I want to pick up the last one in particular and respond. I think that while you appreciate that Kanban is not a "way to run software" the folks who I have spoken with do not understand that. They consider it to be a leaner and more pure form of "agile." So, they do not use it to improve an existing dev methodology, rather they think it is one -- and there is the crux of the problem.
tl;dr: author of the article is laboring under many false assumptions about Kanban (and lean software development in general) likely due to a combination of inexperience using such methods personally and unfamiliarity with the available literature. The following is a rather long attempt to correct the base misunderstandings in the article, with pointers to relevant source material. Enjoy!
First, an operational definition: Kanban as it's used in lean software development is 1. visual representation of the work that's in the system and what state it is in and 2. an opportunity to limit the amount of work that can be in each state.
That's it.
Almost every organization that writes software uses something to keep track of the work, and what state it is in - by this logic the title of the article could be "spreadsheets - the secret engineer killer", or "JIRA - the secret engineer killer".
According to the article though, Kanban is ruining engineering teams in "nearly every company" that has adopted Kanban out of the 150 companies the author talked to in the last 60 days. (Some numbers on how many of them are using Kanban, and for how long, would have been nice facts to include, btw.)
So, let's unpack some reasons why this is:
"Engineers are not assembly line workers" - Implying Kanban and pull-based systems only work for "widget producers" and forces engineers to focus on the individual trees, not the forest. I think this sort of highlights the author's misunderstanding of Kanban (and to an extent any pull-based system) and what role it serves in an organization. Kanban isn't magic - it not an organizational design, it's not a product development strategy, and it's definitely not a substitute for leadership. It's a chart on a wall that shows what the work of the product development organization looks like, right now.
For an example of an overall software product development strategy that incorporates pull-based systems as one component, I recommend checking out "Principles of Product Development Flow" by Don Reinertsen.
"It teaches you that you and your engineers cannot be trusted to estimate work or handle complex multi-faceted projects." - How does it do this? Nothing about Kanban implies no estimates. In fact if you use Kanban and measure cycle time, you will be doing evidence-based scheduling which will allow you to make better estimates. As for "complex multi-faceted projects" - I don't know what the author is talking about. Please read "Scaling Lean & Agile Development" by Craig Larman and Bas Vodde for some actual evidence and lessons learned on lean / agile approaches being used on huge software projects. Also "Scaling Agile at Spotify" by Henrik Kniberg is worth a read, as Kanban features there (by team choice!) as one small component in a lean software development org design / product development strategy.
"Kanban forces a 'one work item at a time' mentality and resists milestones."
This is simply not true and such a basic misunderstanding I have to wonder if the author of the article has taken the time to read any of the introductory literature. If not, I suggest the aptly titled "Kanban" by David J. Anderson.
Kanban wants you to limit work in progress, which is one of the basic goals of any product development system. It doesn't say how much it should be limited, or where it should be limited. Every system, everywhere, already has limited-WIP in the form of bottlenecks. The hopeful goal of pull-based systems in general and lean software development specifically is that you'll use these simple tools to look at your process and eliminate wasteful activities and streamline those bottlenecks that must exist to deliver maximum value to your customers. In this sense, you can use Kanban as a tool to maximize the whole of the product development process which is certainly a macro (org level) go...
Well said. I find it is very common to use the straw-man criticism technique http://en.wikipedia.org/wiki/Straw_man about bad management practices. The quality of management is often bad. The quality of management, even of good practices, is often bad.
Criticizing those implementation of the practice is perfectly fine. But claiming that the practice is suppose to be something different than it is, is not fine. I agree with you here, that is the biggest problem. If you understand how kanban for software is suppose to be done, the criticisms don't make sense.
Summary of this article: Kanban sucks, use our tool to make roadmaps! To me, this is clearly a case of trying to stir up controversy to get people to sign-up for his tool.
Pick the right tool for the right job. For a product team Kanban does not make much sense. I agree with your comments in general. But for a PS or Custom Development team, where most projects are integration type projects or custom reports and tend to take 2-3 days to complete, it is a good way to go.
67 comments
[ 4.2 ms ] story [ 135 ms ] threadBut when you take the most pathological cases of obesity in a time before obesity was the norm, unsurprisingly those cases are ... pathological. There is a pathology.
These aren't normal people who grew overweight under conditions of stunning caloric abundance.
So let's stop quoting this statistic because the sample bias is kindly stupidly important to its interpretation.
Still, many of these points resonated with me.
I started recently on a team that follows kanban-ish practices. Fortunately nobody here is that process-focused that we follow it exactly. Also, there is nothing that says you have to work on only one thing at a time, and we typically don't. In fact, I work part-time on another team, and the other one does not do kanban.
But I don't much like the kanban system: Give me a satisfyingly large component, and let me work on it entirely.
So for kanban in general, here's another facet to consider, and one that probably explains why engineers are "leaving in droves": As TFA says, you end up working on many small pieces of a larger whole. The good part is, you could end up becoming aware of all parts of the system that you touch.
But! When you interview elsewhere, or heck, even when you're updating your resume, and it comes to answering the inevitable question, "What did you work on in this project", the honest answer is, "Uhh, many parts but nothing overarching as such..."
And right then, even to yourself, that sounds like such a weasel-wordy answer. You could go on and explain, "Well, I wrote method A of component X, and feature B of webpage Y and an implementation C of interface Z for cases where Q is R." But to an interviewer, I'd guess it all sounds like "I worked on nothing worthwhile."
On the other hand, since you have better awareness of the project as a whole, you could say you worked on all of it, and make up more impressive-sounding responsibilities as you go along.
But I find it much easier if I just do something impressive and be straightforward during interviews.
That's just so wildly divorced from what it is or what it's for that that article made no sense to me.
Fad diets mostly fail because people go back to eating the same shitty way they did before, just as when a team adopts kanban marketing and product go back to the same stupid way of doing things they did before.
The sad part is that in the vast majority of organization engineering actually knows more about the product than product or marketing.
The core of it is that most engineers don't want to work on the stupid fucking ideas that product and marketing come up with instead preferring to make the product 'good' instead of creating feature parity with some competitor.
If product and marketing were actually good at their jobs they should at least be able to convince the engineers in their own fucking company that what they are thinking is a good idea. Right now I'm picturing the eye-rolls at Porsche when product and marketing announced the idea for the Panamara.
http://blogs.cars.com/kickingtires/2012/09/of-course-we-need...
This so much.
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 doing that.
Conversely I've worked on teams where everyone was trying to avoid being fired and would only make decisions that were defensible, eg. company X is doing Y so lets do Y, resulting in the usual follow the leader failure.
See -- The Holy Scrum War - http://blog.aha.io/index.php/the-holy-scrum-war/
The sad thing is that the Panamera (in stark contrast to any rational thought and sense of aesthetics) is not a complete commercial failure. People with too much money are weird.
From your article, the main reason touted is that the Marketing loses it's way. Which to me sounds strange! In fact I have seen it the otherways. We effectively delink marketing cadence from engineering cadence! Thus resulting in derisking the whole big bang releases.
For e.g. Marketing decides that they are going to make a big marketing push on a conference or a tradeshow. So the PM come up with a list of features they will showcase for the given event. (say 10 features are decided upon). The engineering team works on these features as a que. Releasing each of these as and when they are done. But do note an engineering release to production does not mean a marketing release. This allows the PM to experiment on features, build up case studies, etc ... for these features.
And as the marketing releases dates come closer, everybody knows that we always have a working copy with only the pending items in the que. This results in a high confidence level within the marketing / engineering on what is being touted about. There are no last minute scramble to get a working system. etc ... The most valuable feature was heavily tested and used by everyone before the big bang marketing release.
It also allows the PM to make A/B experiments before the actual marketing push. Thus adding another confidence layer to the whole process.
In a worst case scenario the least valuable features never get released for the marketing push.
I see this as an effective way to derisk the whole marketing push and reduce their dependency on the engineering team to deliver stuff when they said they would.
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.
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.
It's about making all these sub-processes flow together, and identifying where the bottlenecks are.
There's a presentation from DJA on where Kanban is not appropriate here: http://www.slideshare.net/AGILEMinds/david-anderson-kanban-w...
Not an easy read. That said, it aligns to what you've been saying in your article (I think): the WHAT and WHY is irrelevant to Kanban, it can't help you there. The HOW, sure: but even there it is more of an overlay on existing process, not a catch all "one method to rule them all".
Where we get into trouble is that I think your article is saying "Kanban doesn't work, do this process instead". But the process you sketch out probably would fail too in many organizations that lack a good handle on what they're doing and why. Any process will, even goal-driven ones (which IME tend to work only in small scales with few cross-department interactions)
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.
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.
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.
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'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.
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.
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.
kanban - visual signal, signboard kanban system - pull-based, wip limited flow management system Kanban Method - an approach to incremental, evolutionary process and systems change for organizations
So yes, the Kanban Method is not an SDLC method. It is a meta-method that will allow for the emergence of an appropriate SDLC within an organization. That SDLC may be Agile (very good things in Agile mindset), may be waterfall, may be Scrum or Scrumban-ish, but it should be appropriate for then context.
Please refer to this wikipedia entry: http://en.wikipedia.org/wiki/Kanban_(development)
You don't see any SDLC specific tactics or guidance in there. That is true. You don't see any Agile language in there. It doesn't provide any specific Agile guidance.
Does the Agile Manifesto have any specific SDLC tactics? Please refer to http://www.agilemanifesto.org
You won't find any specific tactics for software development in the Agile Manifesto either. But out of the mindset comes specific SDLCs that are aligned to the manifesto like Scrum or XP or any of the million "custom" Agile methodologies that have no name but are used by IT organizations everywhere.
David Anderson absolutely wants the Kanban Method to be used (as appropriate) in organizations that do knowledge work (software development is knowledge work) to help those organizations develop the best workflow and capability for a given context and to create a culture of learning, growth, and continuous improvement. I've talked to him many times about these very topics! Many of the case studies that we quote in our work are from software development organizations.
The quote used above has been taken out of context, isolated, and used to create fear, uncertainty and doubt about The Kanban Method and I find that kind of behaviour negligent at best.
Regardless, it's not a particularly helpful definition for anybody that's never heard of kanban, and certainly doesn't help anybody familiar with kanban to know what specifically you're evaluating; you need to get everybody on the same page from the outset.
Given lack of concrete examples and your previous posting history I would consider this more of an advertisement for your product, to which I've now applied for an invitation, but you seem to be genuinely responding to comments here and nobody else has complained. I suppose either way, well played.
I have other comments but I'll hold them until I find out exactly what you mean by kanban, because I've been admittedly self-identifying the process I'm using as kanban and maybe it's not.
I will say this much though, the practices of kanban (visualization, limited work-in-progress, managed flow, feedback loops, etc.) are all valuable in my opinion and I wonder which of these you see leading to, or how you see them leading to, the problems you've cited. Also, I wouldn't mind some more concrete metrics to back up such an inflammatory title.
Engineers aren't assembly workers: so why do other methodologies seem to be so prescriptive on what can be accomplished in a given time frame? New problems arise, priorities shift, and unexpected news arrives. I appreciate the flexibility of a pull-type system because it lets me transparently show what I'm working on.
I've really hated telling people no or watching a manager struggle to change up something we really need just because it doesn't fit in the right shape time box or might affect the current sprint's plans.
You can't trust yourself: I always ended up hating sprint planning meetings where "points" are a constant source of conflict between stakeholders and estimates are fantastical. These sort of meetings just allow the quality knob to turn down while scope and schedule remain fixed. Having an entire team minimizes estimates problems, but for the effort involved I'm not sure the gains are worth it.
Also, I think you may have inadvertently taken Anderson's quote out of context as well—Kanban isn't a way to run software. It's merely a way to expose your current process so you can improve it. Kanban is something that sits on top and allows you to identify bottlenecks, be realistic about results (instead of estimates) and provide immediate transparency into what you're working on. It doesn't specifically prescribe what the steps are.
If your underlying process (or lack of process) sucks, then you'll still be in trouble. Fix your process first.
First, an operational definition: Kanban as it's used in lean software development is 1. visual representation of the work that's in the system and what state it is in and 2. an opportunity to limit the amount of work that can be in each state.
That's it.
Almost every organization that writes software uses something to keep track of the work, and what state it is in - by this logic the title of the article could be "spreadsheets - the secret engineer killer", or "JIRA - the secret engineer killer".
According to the article though, Kanban is ruining engineering teams in "nearly every company" that has adopted Kanban out of the 150 companies the author talked to in the last 60 days. (Some numbers on how many of them are using Kanban, and for how long, would have been nice facts to include, btw.)
So, let's unpack some reasons why this is:
"Engineers are not assembly line workers" - Implying Kanban and pull-based systems only work for "widget producers" and forces engineers to focus on the individual trees, not the forest. I think this sort of highlights the author's misunderstanding of Kanban (and to an extent any pull-based system) and what role it serves in an organization. Kanban isn't magic - it not an organizational design, it's not a product development strategy, and it's definitely not a substitute for leadership. It's a chart on a wall that shows what the work of the product development organization looks like, right now.
For an example of an overall software product development strategy that incorporates pull-based systems as one component, I recommend checking out "Principles of Product Development Flow" by Don Reinertsen.
"It teaches you that you and your engineers cannot be trusted to estimate work or handle complex multi-faceted projects." - How does it do this? Nothing about Kanban implies no estimates. In fact if you use Kanban and measure cycle time, you will be doing evidence-based scheduling which will allow you to make better estimates. As for "complex multi-faceted projects" - I don't know what the author is talking about. Please read "Scaling Lean & Agile Development" by Craig Larman and Bas Vodde for some actual evidence and lessons learned on lean / agile approaches being used on huge software projects. Also "Scaling Agile at Spotify" by Henrik Kniberg is worth a read, as Kanban features there (by team choice!) as one small component in a lean software development org design / product development strategy.
"Kanban forces a 'one work item at a time' mentality and resists milestones." This is simply not true and such a basic misunderstanding I have to wonder if the author of the article has taken the time to read any of the introductory literature. If not, I suggest the aptly titled "Kanban" by David J. Anderson. Kanban wants you to limit work in progress, which is one of the basic goals of any product development system. It doesn't say how much it should be limited, or where it should be limited. Every system, everywhere, already has limited-WIP in the form of bottlenecks. The hopeful goal of pull-based systems in general and lean software development specifically is that you'll use these simple tools to look at your process and eliminate wasteful activities and streamline those bottlenecks that must exist to deliver maximum value to your customers. In this sense, you can use Kanban as a tool to maximize the whole of the product development process which is certainly a macro (org level) go...
Criticizing those implementation of the practice is perfectly fine. But claiming that the practice is suppose to be something different than it is, is not fine. I agree with you here, that is the biggest problem. If you understand how kanban for software is suppose to be done, the criticisms don't make sense.