Customer Reviews

Lean Software Development: An Agile Toolkit

5 star:		(9)
4 star:		(2)
3 star:		(0)
2 star:		(1)
1 star:		(0)

 

 

Although this book is from the Agile-series, the approach and advice extends to any methodology from the heavy (and still used) waterfall SDLC, to XP and agile methods.

Key steps in this book will show you how to streamline your development methodology in accordance with lean thinking:
- Eliminate waste by cutting the fat out of processes, reducing rework, viewing your SDLC as a value stream.
- Amplify learning, with an emphasis on iterative planning, feedback loops and team communications.
- Decide as late as possible, which is enabled by concurrent activities, depth-first versus breadth-first problem solving, and other effective tools and techniques.
- Deliver as fast as possible, based on analogies between manufacturing pull systems and scheduling, and how to accomplish the same in development.
- Empower the team, which is a fundamental element of lean thinking. The tools and techniques presented in this section of the book are a mixture of common sense, leadership and management.
- Build integrity in. If ever there were a direct connection between the lean thinking approach to manufacturing and software development, it is here. Tools and techniques given include model-driven development, refactoring and testing techniques.
- See the whole, which emphasizes system thinking, metrics, optimization, and the supporting tools and techniques.

Any or all of the above can be effectively applied to any SDLC or methodology and produce results. Lean thinking was developed by Toyota as a manufacturing paradigm, which has been extended through that company and is applied to business processes outside of the manufacturing domain. That this team of authors has applied it to software development is not as unnatural as it may seem at first glance given how vastly different software is to create versus cars, for example. But, the paradigm has been proven outside of manufacturing before this book was written, and the basic philosophy and principles can be applied - which this book evidences.

If you want to look at development from an entirely unique perspective purge the words agile, XP and any other methodology from your mind while reading this book. I can almost guarantee that you'll find something in every chapter that you can put to immediate use in your own organization. As an aside, a book on software testing that is consistent with lean thinking in many ways, and closely aligned to the content of this book is "Software Testing Fundamentals: Methods and Metrics" ISBN 047143020X.

I had pretty much the same feeling reading this book and Lean Thinking, as I did when I first started reading up on agile methods. It all felt like common sense and that's a comment I hear from a lot of people new to lean/agile. However, I feel, and have experienced, that there is a huge gap between viewing or perceiving something as common sense and actually applying that common sense to the work you are doing. Also, both this book and Lean Thinking put these principles and practices into a different perspective by showing how they have worked in the manufacturing business. Seeing the parallels between the work done in manufacturing a bicycle and crafting a software program is pretty powerful.

Mary and Tom do a great job in the book of presenting specific tools for applying all this "common sense". They start by introducing the seven principles of lean thinking when applied to software development:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

The rest of the book presents the 22 thinking tools that are all tied to the seven principles. Mary and Tom use a lot of real world examples of the usage of these tools and they do a very good job of explaining how each of them could fit into an agile ecosystem.

The book is pretty compact and the authors have clearly eliminated all waste from it because I was never bored.

I can't recommend it enough!

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.

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.

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.

If you already understand or use agile software development approaches such as XP or Scrum then this book will teach you WHY they work. It's beautifully written too.

I gave this book five stars becase that is the maximum I am allowed to give it, otherwise I would have rated it higher.

I think this book should be REQUIRED READING for anyone interested in agile software development methods, or even just general software process improvement. This book contains the kind of practical thinking and analytical tools about agility that I was starved for when the first book on agile development methods first hit the software development scene.

The early books on XP said what XP was and described its values and practices. But when wanting answers to the questions about why a particular practice works, where its strengths are, where its gaps are, and how they are/arent addressed by other practices, I was left wanting (particularly since a lot of folks wanting to adopt agile "in bits and pieces" perceived the need to do so incrementally and needed to understand where to begin, which core things to start with, how to adjust and adapt them to ones environment, and what to look for).

This book filled that void for me, showing me how to think about agile "systems" from a systems-thinking perspective, and how to analyze existing processes (agile or otherwise) to identify their "hot spots" and apply 22 practical tools to get on the road to lean/agility, (in an evolutionary fashion) without mandating instantaneous revolutionary organizational change to replace the entire process all at once.

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.

If you are intrigued by the concepts of Agile, this is an excellent book to help you begin to map Agile methodologies and techniques into your team's software development process. Mary and Tom Poppendieck present 22 tools in 7 categories to help you begin to map Agile methodologies and techniques into your team's software development process.

Mary and Tom Poppendieck are experts in getting software done. They've taken a number of the most important Agile techniques from Lean Manufacturing techniques, and shown how they relate to lean/agile software development. They do not pontificate on Agile. Essentially, they extract a number of the most critical concepts, examine them, and then help you to see how you might bring them into your own software development process and team. This is not a cookie cutter approach: One of my issues with the leaders of movements like SCRUM and XP is that they believe that you should be using their techniques verbatim -- I once heard one of them say "You're either doing XP exactly, or you're NOT agile!"

This is not the case here. After a strong introduction, this husband and wife team launch into it. Like their in-person seminars, it's clear that they've been there -- they know what works, and what doesn't. These authors have developed a lot of solid software, built teams of developers, and delivered high quality code on tight deadlines. There's no fluff here -- at less than 190 pages, they don't have room for it. The first four chapters focus on modifying your process: making it lean, creating feedback loops, encouraging flexibility, and delivering fast. The next one focuses on development teams -- empowerment, motivation, and leadership. The final two are about coding: building integrity into your code and creating code that matches the entire system that is being built. There's also a fascinating chapter on creating contracts appropriate to the Agile model, which is definitely required reading, and is a rarely discussed topic in the Agile literature.

If you are intrigued by the concepts of Agile, this is an excellent book to help you begin to map Agile methodologies and techniques into your team's software development process. With its pragmatic approach, informative examples, and succinct and clear writing, this is an excellent book to get you thinking about how to apply the powerful concepts of agile to your development process.

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.