Eric Ries Tells Lean Startups: “Stop The Line So That The Line Never Stops”
techcrunch.com
techcrunch.com
part 1: http://techcrunch.com/2011/09/23/founder-stories-eric-ries-l...
part 2: http://techcrunch.com/2011/09/24/founder-stories-eric-ries-v...
I worked at GM during the lean craze and read my fill of these "we should be doing it like the Japanese" articles back then. If the Japanese pooped in a paper bag and left it by the door, then our managers thought there must be genius in that bag and would force us to do the same. It was insanity.
Lean == Snake Oil
Lean startup is "Lean" in the sense that it advises the use of small batch sizes. Calling validated learning "Snake Oil" only shows that you haven't read the book and are unfamiliar with the Author and the other relevant info on the topic.
I was at Ford when the way to win an argument was to just say, "that is how the Japanese do it". If the Japanese had DC rundown tools, we got DC rundown tools. If the japanese tradesman rode bikes, we got bicycles. If the Japanese don't inspect incoming parts, we don't inspect incoming parts. Yes it was annoying, but it did work, as the results speak for themselves.
No. I will not read the book, because all information in it will be stretched analogies.
Trust me when I say this, the two fields are different.
It's actually a fantastic read, with wonderful depth. You might actually learn a thing or two. I was pleasantly surprised with it. It should be the 'Crossing the Chasm' of this decade.
I haven't read Ries's book but the "Lean Software" book by the Poppendiecks was full of over-stretched analogies and feel-good management book style anecdotes. There was a push to make "Lean Software" into an enterprise software fad to succeed "Agile", but it never really took off. I hope "Lean Startup" doesn't become the new "Agile" (lots of consultantware and repackaging of simple and old concepts and not enough "meat" for working devs/PMs). It does have that fad-of-the-day smell though. Lots of marketing and glibness and sizzle. How much steak? Time will tell.
PS: I don't agree with the folks downvoting you. You have a valid point worth considering. If you could post a few lines on what you see as the specific differences between the two fields and the "snake oil" bits that you perceive that would be cool.
And when you say "it never really took off", please show your facts. Kanban has been around for a couple of years really, and I don't see it decreasing in interest.
It would be good if people who talk about fads and buzzwords actually knew what they are talking about before criticizing. Just saying...
this doesn't show it "taking off" which would mean an increasing rate of adoption with something like a "hockeystick" curve.
"lean software" got a few early adopters who tried visualising software production as an asembly line analogue, (with all the accompanying "kanban", "muda" etc bullshit, without ever having worked on or designed an assembly line. fwiw I am an Industrial Engineer, though I work in sw these days and I daresay I have seen more real world assembly lines than most lean software evangelists have) but it never became anything like mainstream. In contrast, Scrum , though borderline scammy with people sitting through 2 day courses becoming "scrum masters" became widely adopted. What Scrum, however scammy, has is "take off". What "lean software" has is an early fizzle.
Lean manufacturing may have been a revolution, but the jury is very much out on whether lean software has any real impact.
"it would be good if people who talk about fads and buzzwords actually knew what they are talking about before criticizing. Just saying"
must be lonely, up on that cliff of superior wisdom and snap judgement, where you are the only one who knows about lean software,agile etc and anyone who has a contrary view to yours is a clueless moron ;)
sure. I have (and your assumption otherwise, as evidenced in your "if only people knew what they were talking about" opinion is revealing).
Here is a war story fwiw I didn't decide the methodology on this project, I was just part of the team - (the only "methodology" I believe in for sw dev is "hire bright people and let them figure it out")
On this particular project,there was a "lean and agile coach" (who had a PHB backing his efforts) who had a card wall where he monitored the "work in progress" and "queue size" and so on. It was obvious he had zero manufacturing experience, had never seen a real assembly line (or work cell or kanban card) and had just read this stuff up in the 'lean software' books (the authors of whom, in common with the agile gurus have zero credibility as devs or product designers) .
As expected, the project ran into trouble, the devs revolted at being treated like assembly line workers, the "coach" eventually got fired (along with the middle manager who mandated the change) and the team went back to their previous "we figure what makes sense to us and fits our environment " 'methodology' and software delivery improved, the clients were happy and all was well again. The lean terminology is a source of team jokes now -eg: "I just visited the bathroom to get rid of some muda", "Anyone monitoring he WIP for a coffee?"
And oh yes I expect to hear the "No True Scotsman" defense. "That wasn't real lean software. Hire me and I'll tell you how to do it 'right' ". Right.
The more important point is, without experience in both manufacturing and software dev, it is terribly easy to get carried away by stories about Toyota's success in car making (and the 'lean software' authors and consultants are careful to sprinkle Toyota anecdotes throughout their books and slides - none of them have worked at Toyota afaik) and adopt random elements of their assembly line processes, (or to be more precise, what you THINK is happening in a Toyota factory) into your sw dev.
"cleverly tailored" my ass. "Cleverly marketed" is more accurate. Any successful "tailoring" would need the tailor to be an accomplished expert in both sw dev and lean manufacturing and be at the top of their game in both fields - a combination of Linus Torvalds and Taichi Ohno. I am not sure such people even exist.
What we have are consultants with mediocre dev skills and zero manufacturing experience who scramble from RUP to agile to lean software to whatever-fad-is-next and are always looking for the next fad to ride, the next book to write, and the next conference to speak at.
Once again, good luck to find any success in your angry little ivory tower, as luck seems to be the only thing that can save you. End of trolling.
heh but you used equally anecdotal data and equally shaky evidence to support the snake oil methods. I quote
"I have experienced lean software first hand and I can tell you it is no fad. I have set up Kanban in companies a couple of times and the results were excellent"
So you say. Your anecdotes and experience are valid but mine are not. ;) Very convincing.
This is the standard snake oil salesman defense- when a methodology fails it is always because people didn't do it right. Nothing intrinsically screwy with the fad itself.
And when you claim some unverifiable successes that is convincing evidence about the intrinsic soundness of whatever you are defending. Pathetic. For every anecdotal "success story" you can find an equally anecdotal "failure story". Which was the point. And went right over your head. There was no claim this was evidence. (as someone trained in engineering and stats, I use the word "evidence" and "proof" very carefully).
"But I'm the one who should get a stats education, right?"
well you are the one who brought in an agile methodologists silly home grown survey as 'evidence' (when specifically asked for a non vendorware peer reviewed citation mind you) for some grandiose claims.
This shows (assuming you weren't just trolling) that you don't know how to judge the statistical validity of a survey or when to use one as evidence. If you really believe Ambler's marketing spin on agile is some kind of convincing 'evidence' for the validity of "lean software" you definitely need to learn some stats (among other things).
"End of trolling."
Thank You for finally admitting you were trolling. That clears things up. Wrong forum. On HN the assumption is that people are being genuine even if their writing style is abrasive. If I thought you were trolling (vs just being a bit incoherent) I wouldn't have responded to you at all. Live and learn :)
Isn't it already? They seem very similar to me.
What I don't understand is why he hopes Startup doesn't become the new Agile. Agile methodologies have transformed an entire industry in awesome ways and greatly decreased the failure rate of IT projects. I would hope Lean Startup will decrease failure rates in the same proportions for startups.
(Reliable non vendorware) Citation needed.
How have "agile methodologies" made "awesome transformations" any more than the previous methodology fad(RUP I believe)? Then, a lot of consultants ran around raving about uml diagrams etc and the rate of failure of projects didn't change. With the formulation of agile, a lot of consultants ran around raving about TDD and Scrum and so on.
Do you have any non anecdotal evidence about this massive industry transformation and "great decrease of failure rates"? If so you should publish pronto because, afaik, no one has that kind of evidence to date.
This kind of sweeping hyperbolic pseudo religious statement is the problem with the cult of agile.
Scott Ambler has been running these surveys for a few years now, and they are consistent. In 2010, agile and iterative methodologies (that include RUP, which is rybbish I agree, but looking at the facts here) lead to +10% in success rate compared to ad-hoc or waterfall.
But now you are going to tell me Scott Ambler is one of these agile consultants preaching for his own church, right?
No need for that. All he asked for was a citation; nobody's 'discarding' anything.
PS: You really should get a stats education, so you can properly judge (and see through) such shaky "evidence"
Eric Ries took the jump to startups, but the seeds were already there. He took Agile from known problem/unknown solution to a situation with unknown problem/unknown solution situation.