
2. Writing Tools: 50 Essential Strategies for Every Writer.
3. Diffusion of Innovations.
4. The Little Book of Common Sense Investing.
5. Implementing Lean Software Development: From Concept to Cash.
6. Writing to Learn.
7. On Writing Well.
8. Pragmatic Thinking and Learning: Refactor Your Wetware.
9. Thinking In Systems: A Primer.
10. The Startup Owner's Manual: The Step-By-Step Guide for Building a Great Company.
"Lean" manufacturing, a term from Womack & Jones, is based on their research into this.
If you want to dive in, here is my reading list for essential books on how Toyota came to build high quality cars at scale, and how it transfers to other disciplines.
W. Edwards Deming - the grand old man of the field, building on a strict statistical discipline. His book "Out of the Crisis" is a wonderful treatise on his thinking including his famous "14 Points for Management". This is definitely a must read that will change the way you think about management and quality. Deming provided the inspiration for the quality movement that powered post-war Japanese manufacturing.
Taiichi Ohno - one of the greatest industrial innovators of the 20th century, the father of the Toyota Production System. After spending his career relentlessly optimizing manufacturing at Toyota he wrote the book "Toyota Production System: Beyond Large-scale Production" that describes his work.
Womack & Jones - Their books are great and it is well worth to read them all to see a lot of the principles and case studies for lean thinking. Also, it is quite interesting to see that software development is now rediscovering some of the things that manufacturing learned much earlier - in the case of Toyota as early as in the 1950s and 1960s. Begin your studies with "The Machine That Changed the World", a five-year study of the global auto industry from MIT and go on with the "Lean Thinking" and "Lean Solutions". They give a fascinating perspective on manufacturing and plenty of examples of the lean principles and they applications. These are the books that brought lean to the mainstream.
Mary and Tom Poppendieck - with a background in manufacturing and software they were leading the effort to translate the concepts of lean to software development. They have written two great books, "Implementing Lean Software Development" and "Lean Software Development - an Agile Toolkit". Both books are well worth reading a present a both the principles and lot of cases in a friendly, colloquial manner. Highly recommended!
Matthew May - I really like his approach to elegance and simplicity. May has worked with Toyota and their corporate university and his book "The Elegant Solution" offers insight into their innovation process - the principles it is built on and the practices that make it work.
Jeffrey Liker - his "The Toyota Way" is a very good introduction to the application of lean methods at Toyota. This is one of the best lean books I have read. Definitely a favourite!
This list covers up to around 10 years ago. Please comment with recommendations for more recent books on the topic.
If there's an inverse correlation between the speed of deployment and the quality of your software, you're doing it wrong.
The Continuous Delivery philosophy is borrowed from Lean Manufacturing, and a fundamental tenet of that movement is "Build Quality In." In fact Lean is nearly synonymous with TQM, or Total Quality Management. If you've separated the two, then you've missed the entire point.
This tenet is carried over into the software world by Martin Fowler in his book Continuous Delivery, as well as all of the major advocates of lean software processes, for instance David Anderson and the Poppendiecks in their highly influential series of books on Lean Software.
Essential to a successful continuous deployment process is unit testing, continuous integration and built-in testing processes all along the way to feature deployment. These should be focused on quality all along the way: that's the point of continuous deployment, to allow for focused feature development that is highly tested and can be released with higher confidence than the old method of multiple feature release, which are heavy, harder to test and have more integration concerns.
The point of fast releases should never be to allow for "shitty software," but rather to deliver features that users can enjoy as soon as possible, create a process where deployments become highly automated, low-risk events, and gather feedback early and often on the experience of users with finished polished features so that effective product evaluation is happening constantly and the company can adapt quicker to new data and new trends.
A quick perusal of even the first chapter of any of the major volumes on Continuous Delivery should clear this up:
http://martinfowler.com/snips/201006021426.html http://www.amazon.com/Lean-Software-Development-Agile-Toolki...
http://www.amazon.com/Implementing-Lean-Software-Development...
And there's a fantastic presentation by David Anderson on Kanban on InfoQ, which nicely illustrates why quality is one of the major reasons you should consider a rapid release process like Kanban:
I read books on the commute to work (on the train) so this time feels less wasted. I especially liked: - Implementing lean software development - Implementing scrum - Domain Driven Desing - Head first rails - The leaders guide to radical management - Presentation zen
This is not only technical stuff, but I think the non-technical books are important too - they give you context and perspective.
As the longer-payoff/higher-risk companion to Chrome OS as the longer-payoff/higher-risk companion to Android, in a nested generalization of the Poseidon-and-Polaris strategy discussed as a model (among other places) in Mary and Tom Poppendieck’s Implementing Lean Software Development.
It’s kind of a go-to strategy for Google in important markets; when you are essentially made of more money than you can figure out ways to spend, internal diversification so that you literally don’t make the choice between the immediately useful but maybe future-limited approach and the longer-time-to-payoff, higher-risk approach less tied to what is currently optimal makes a lot of sense.
It's been a while, but as I recall the latter two can be treated something like workbooks. How to go from "traditional" project management towards lean/agile. The former introduces many Lean concepts but within the software development world. So that's where I got the idea (maybe I'd seen it before I read that book?) about treating developed, but not integrated, code as "inventory". It has a cost because we have to eventually integrate it but it'll become "stale" over time as its interfaces or other features become further from the main branch.
If you have a Safari Books Online account they're probably in there. I found them to be fairly easy reads, perhaps spending 2-3 weeks on each. Applying it at work, of course, has taken a lot longer.