Kanban – The Secret Engineer Killer
blog.aha.io
Kanban – The Secret Engineer Killer
1–10 of 68 posts
Re: Kanban – The Secret Engineer Killer
#2The 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.
Re: Kanban – The Secret Engineer Killer
#3Really 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."
Re: Kanban – The Secret Engineer Killer
#4The 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 stu…
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.
Re: Kanban – The Secret Engineer Killer
#5I'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.
Re: Kanban – The Secret Engineer Killer
#6Really 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.
Re: Kanban – The Secret Engineer Killer
#7The 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 stu…
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.
Re: Kanban – The Secret Engineer Killer
#8What 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.
Re: Kanban – The Secret Engineer Killer
#9I agree. It doesn't allow the engineer to really own a project from start to finish. Thanks for a great post.
Re: Kanban – The Secret Engineer Killer
#10I'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 proc…
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.