Rating: 
Summary: Practical Tools For Lean Software
Review: The authors have done a wonderful job in helping us to look for ways to improve toward "Lean Software Development". One of the great things about this book is the approach that it takes. Rather than giving a prescription of "do this, and you should get these results", they give a framework for thinking through the issues and making good decisions. Each chapter concludes with a section called "Try This". My organization has already benefited from the suggestions for identifying waste. Again, they don't tell you what waste to eliminate, but rather how to go about looking for wasteful items.Another thing that the authors have cleared up is the improper distinction between principles and practices. The authors claim that many of the problems in software today come from the fact that manufacturing *practices* have been applied to software development rather than manufacturing *principles*. The principles that are explained throughout the book are based on successful companies outside of the software business, e.g. 3M and Toyota, and how in turn these can be applied to software. One of the best points that they authors make - and they make many good ones - is that local optimization within an organization can actually slow down the overall process. The overall tone of the book is very pragmatic, and it is definitely going to be a shock to the system for anyone who is accustomed to CMMI or ISO certifications. However, the potential results from this shift in thinking are worth it.
Rating:
Summary: Ignore particular methodologies; think about efficiency!
Review: The word 'Agile' is in the title of the book, guaranteeing a place on the most important shelves and conferences. However, the contributions are much wider than just a buzzword of the day, and some of the chapters that aren't directly about Agile are applicable even in pre-Agile methodologies. Coverage of the Lean manufacturing principles and how they relate to software methodologies gives a good enough introduction to the field to get a nice feeling for how it all works and an intuition for why this style of development works better than ones that don't use feedback, continuous improvement, and the other techniques presented. Unfortunately, the section on contracts was weak and pretty under-motivated. One of the 'case studies' in it was even completely fabricated, in a departure from the rest -- I would've preferred seeing the chapter left out! Also, the book in general could've used some smithing by an editor, as some of the chapters didn't seem to have a good reason for grouping together the concepts that they did, making it hard to tie them into a single group rather than the many mini-chapters that they felt like. Still, a great book -- possibly the best single overview of Agile methodologies and their groundings on the market today.
Rating: 
Summary: Agile is good, provided there are proper safeguards
Review: There is no doubt in my mind that keeping your options open as long as possible is always the best approach to solving any problem. That in essence, is what agile (lean) software development is. When it is possible and done right, agile methods can lead to a dramatic improvement in the quality of the software you create and the amount of profit that it generates.
The authors make a convincing case for agile methods, citing many cases where the techniques have been successfully used, and not all are in software development. One example is Nucor, which operates a collection of profitable steel mills in the United States, at a time when the majority of steel companies are in severe financial straits. Another example is Xerox, and how their repair technicians were able to share their expertise.
The primary example used outside the software industry is from the auto industry. In the early days, all auto production was via the assembly line, where the goal was to have nearly all workers engage in mindless routine. Rather than be critical of the assembly line, the emphasis here is on the fact that it was a necessary strategy for the times. In 1915, shortly after the assembly line was introduced, there were 7,000 workers at the Highland Park, Michigan plant, speaking fifty different languages. Most of the workers were immigrants who understood little or no English, so the cost of training them for complex tasks would have been prohibitive. The only solution was to train each worker to do one task, one that could be demonstrated several times until they understood. If necessary, a translator could also be present during the training for questions and comments, but given the simplicity of the task, a worker could be completely trained in a matter of minutes. Furthermore, since the product was new, the consuming public was not as demanding in terms of style options as it is now.
However, the times have changed, and now people want cars to be custom made as much as possible, and segments of the auto industry have responded. However, this requires that two fundamental changes be made in the production process. The first is that where there are options, each of the possibilities is always available, and no choice significantly alters the flow of development. The second is that there be dynamic lines of communication always open, so the request accurately arrives at the production site as soon as possible.
These two changes are the fundamentals of lean software development. Rather than create the complete blueprint for the software and then stamp out each part in succession, where one must be connected before the next, a general outline is used. Options for construction are developed and there is near-constant communication between the software developers and all the stakeholders. The best situation is a "How's this?" format, where the developers perform a build and ask everyone with a stake what they think about it.
However, there are two primary problems to avoid, and both are fundamental to human nature. While delaying decisions until the last possible moment is an important feature of lean software development, the problem lies in determining when the last possible moment has arrived. In situations where delay is considered good, it is all too easy to go too far. While the authors' do a good job in emphasizing how decisions should be delayed, a bit more time could have been spent on knowing when it is time to move. I was reminded of the wise saying from legendary basketball coach John Wooden. He was constantly telling his players, "Be quick, but don't hurry." In other words, examine your options as long as you can, and then act as quickly as possible.
The second is avoiding the "looking over their shoulders" situation. If you talk to mechanics, they will tell you that the signs that say "Due to insurance reasons, customers are not allowed in the work area" are there for more than customer safety. They also allow the mechanic to do the work without the customer interfering in any way. Therefore, for any structure that allows for continuous customer input to work, there must be a mechanism whereby the customer (including management), can be told to, "Go wait in the lobby."
The information in this book is excellent, there are many good ideas that can help nearly all software development teams improve their performance. However, options always introduce additional complexity and managing some of that additional complexity is not thoroughly examined.
Rating:
Summary: This might be the only "Agile" book you'll ever need to read
Review: This is a book about the Principles behind the so-called Agile Methodologies. Those familiar with XP, Scrum and the like will understand where the Practices those methodologies propose came from. These Principles also explain where the iterative model of RUP came from, even when RUP may not be considered agile.
If you have any experience in software development, reading this book will repeatedly make you think "yes, that's exactly how things really are" and "yes! that idea WILL work for me!".
Unlike the methodologies, this book proposes no Practices at all. Finding them is left to you, after understanding the Principles and tailoring them to the practices that best fit your domain and context.
I'm pretty sure your way of working will never be the same after you read this book.
Rating:
Summary: Learning from Lean Manufacturing
Review: This is an excellent discussion of how the principles of Lean Manufacturing apply to Software Development. The authors explain why the usual metaphor of software as manufacturing is not quite right, and why the metaphor of Lean Manufacturing is something we can learn from. The book is clearly written and the authors provide examples and anecdotes to help you to understand their points. This was a fairly quick read, and I am likely to refer to it often.
|
