Amazon Co UK Review 3 Dec: of Eric Ries, Lean Startup book
I loved this book! I am recommending it to all my adventurous and open minded professional friends. I enjoyed reading is as an ebook alternately on my iPad and iPhone. The length is nice and short. The practical examples still rich. The deep understanding of a high Risk, high uncertainty learning Process is impressive.
Eric believes in the same basic ideas of development that many of us have championed for years. Clear quantified ideas of real world progress, being tested rapidly and frequently in feedback cycles. The emphasis being 'learning what is real and true, asap'.
The difference is that Eric applies these ideas at an extreme that I personally have not dared to think or experience. He is operating at the 30 to 50 real changes a day being measured and learned from, from the real world. This is about gathering 'requirements' from the real world by continuously (every day) and frequently (dozens of measured hypothesis per day). This is about testing alternative designs just as early and continuously, and letting design and Architecture emerge as whatever really works in satisfying the simultaneously emerging Requirements.
This is revolutionary! But for the skeptic, Eric documents in detail how it works in real named busnesses. Eric is very clear about his sources of ideas, the classical gurus like Deming, Drucker, Toyota-Ohno, and many such more. He is equally clear that his method's Role is primarily a framework to allow extremely rapid learning about what really works, and for whom it works.
He clearly positions 'Lean Startup' as a way of managing system-building Processes such as agile methods like XP and Scrum. I and my professional friends, have long campaigned for much better multidimensional quantified Quality Requirements, for a rich variety of Stakeholders (gilb.com).
But the majority of 'agile' developers don't want to know about such disciplined thinking. They would rather fail.
Eric speaks openly of his earlier failed projects (using conventioanl wisdom), and those of other businesses and clients. The conventional startup, and software development methods are inevitably highly failure-prone, and have been for decades.
The Lean Startup ideas convincingly show how to avoid the embarassing pervasive development project waste. History shows that the developers themselves, while intelligent enough to use these disciplined Lean Startup methods, are not likely to jump in and adopt them on their own initiative. They (developers) clearly prefer to get well paid to code fast - using Agile methods alone, using relatively little Engineering discipline (and Lean Startup is rigorous scientific method and Engineering discipline). They seem to feel no real responsibility for successful outcomes. Failure still gets well paid, at their Level.
So this brings up the question of who this book is for. And who will in fact make sure the ideas are implemented. This has to be the people laying the investment on the table, hoping to get a return for it. Directors, CEOs, CTOs, Angels (startup investors).
They need to demand, as a precondition for their investment, the kind of rapid learning, and rapid early 'pivoting' (major changes in Architecture, Stakeholders, markets, Product design) that Lean Startup teaches. It is this Level of power and responsibility that needs to understand the basics of Lean Startup, and to demand their use.
I think this executive Level has to far too long, in the history of software development, totally abdicated their responsibility to ensure serious management of IT and software projects.
My extensive experience shows they rarely bother to even have clear quantified trackable Requirements for massive (like $100 million) investments. Business schools have not been helpful in training managers to deal with multimensional critical project Requirements. If history is any guide, we are not going to change our irresponsible software investment culture in the short term.
But Lean QA is a clear opportunity for the wiser top managers to make sure THEY will succeed, and hopefully in the longer term the amateur, non-scientific. non-engineering methods of the current software culture will die out.
Get the book, read it now, spread the word, and see Erics many good Googleable presentations and videos as a supplement.
Here are some links
The official website of all things Lean Startup presented by Eric Ries.
Eric Ries' presentation on lean startups. From Steve Blank's Customer Development course at Berkeley. Learn more and hear the audio at http://bit.ly/ 3qsvJ.
8 Sep 2008 – (Update April, 2011: In September, 2008 I wrote the following post in which I (ER)published my thoughts on the term "lean startup" for the first time
Slides bySteven Blank and Eric Ries. “The Lean Startup, Low Burn by Design , not Crisis”
If you or someone you know are interested in learning the Competitive Engineering / Evo / Value Management methods in a light fun way, there is now a new option available. Introducing KickAssProject.com an online video based training class.
The class is aimed at people running smaller projects than the projects we normally are involved in. It is a way to reach out to people who run projects that Tom & I normally don't reach. It is also a very Cost and time effective way to learn. No travel and no expensive public workshops needed to learn.
There are lots of free preview videos there.
You can start watching right away.
Head over to www.KickAssProject.com
Tom Gilb Says:
January 1st, 2011 at 1:38 pm
I notice that, as usual, there is no mention of consciously trying to deliver real Value to Stakeholders early and at every iteration. This is the fundamental sickness of Agile Today. Plenty mention of code, none of Value to Stakeholder. Plenty mention of learn only at the end, none of learning what´s real at each increment.
If you had focused on delivering measurable high Value, prioritised early, then the whole discussion of 3 months or 18 months would be moot. You have a big bang mentality, not real Agile.
You have either learned your agile from poor teachers or failed to implement the good stuff they taught. As I have long predicted we will continue to build a bad rep for agile until the Next Big Religion catches our fancy.
I am happy you all felt so nice about your teams, but how did the Stakeholders feel? Not happy bunnies if I read between the lines.
Grow up and serve the people who pay you.
Stop blaming the stupid organisation, and start delighting them with results.
See Demming, “Radical Management” for a mature criticism of the Agile Manifesto (page 88), and some really mature advice (from great agile people massively!) on focusing on delighting the customer incrementally. That is what it was supposed to be all about, in Principle.
Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity
Part 3 of 7 Stakeout Stakeholders
!!!Part 3 of 7: Stakeout Stakeholders or Stakeholders will stake you out.
Agile theory, teachings and practices mainly* focus on the users and sometimes the customer. They preach use-cases, user stories and the customer-in-the-next-room Type techniques.
* *I’m sure someone can and will point to projects that takes a wider approach to Stakeholders. I applaud and support that. Please link to sensible information about capturing complete set of Stakeholders, especially those that target Stakeholders that are not customer and users. I’m in support, not against great Agile implementations. Yet 95% of what I see practiced, written, thought, and preached takes the limited approach to Stakeholders.
Any system being developed has multiple Stakeholders. Stakeholders being the people, groups and things (laws, other systems etc.) that have Requirements related to the system. Stakeholders have a ‘stake’ in the system. Critical Stakeholders can potentially determine success and failure of the system. Stakeholders require something from the system.
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity
Part 3 of 7 Stakeout Stakeholders
!!!Part 2 of 7: Agile “Baby Talk” Kills Developer Creativity
Conclusions up front Scrum is practiced as a huge cooperative todo list. By not focusing on the critical "how well" Attributes of the system, Scrum is reducing sw development to tasks, not needing skillful creative knowledgeable Developers. Developers are told what to code, not asked how to best satisfy a Product Quality need. When developers are given the challenge to improve a system (Product-Quality) they not only rise to the challenge, but excel at it. This is also observed in Scrum teams where they are given the challenge. There is little or no understanding for how to create a competitive Product. Rather, the opposite is happening, by requiring 'solutions' (made by amateurs (users), not architects), more-competitive options are systematically censored. The Agilists sell Agile as an answer to increasing market pressure, as a way to be more competitive. But Agile falls short of giving its applicants a competitive advantage, because it doesn't say anything about Requirements. The popular Agile practices, teach and practice Use Cases or User Stories and other Function and Feature centric ways to describe the most critical input and outcome of development. There is little or no specification to help us differentiate between a Function “the what”, a Value “how well”, and a Solution “how”. Most Agilists teach and practice 'mixing the required Function with the optional solutions'. They don’t seem to teach anything useful when it comes to the most critical Type of Requirements, the “how well”. In practice, by teaching User Stories, they teach not to use the critical “how well” types of Requirements, at least not in a way that can be used to guide decisions in the solutions. The real Value and Cost of a system comes from creating the "how well" Attributes. This “baby talk” Requirements practice makes the popular Agile methods useless to anyone creating competitive systems, to anyone creating systems requiring high Value, and to business.
that is it, the rest of this blog is fill :-) to better explain the conclusions above.