So I finished my second book on Lean : Lean Software development An Agile Toolkit
(The first one was: Lean from the Trenches:Managing Large-Scale projects with Kanban  )

First the recommendation. Absolutely loved it.   4.5/5

The books gives with a decent history of Lean and throughout relates to the amazing success story of TPS ( Toyota Production System) and other  stories from various industries and organizations. The authors present 7 Lean principles as how they are relevant in Software development. Each principle is discussed in detail along with tools on how to apply those principles to Agile Practices. For me – the biggest takeaway was- that you cant  (or shouldn’t try to) bring in practices from Toyota or for that matter from any other organization and even another department in your company. It’s the principles that you should be looking for. The problem is- when you examine other organizations- what is obvious are the practices they follow. It takes a deliberate effort to lift the covers and understand and appreciate the principle behind those practices.

Google has the much coveted 20% time- where they allow developers to spend 20 % of their time on anything they wish to pursue. Any organization who blindly adopts the process- will not be successful – unless you appreciate and adopt the principle behind the process.

The Good…
Its well written and very easy to read. (I read it in less than three weeks . Not done that in a while)
The knowledge of the authors on Lean and software development is quite evident – so it was easy to develop a sense of trust.

The book has a good consistent theme.  I generally don’t like too detailed case-studies . I start to lose interest.  But I like the examples in this book- I think they had just the right amount of details.

Liked the tools section. Tips- not so much.

The tone of the book is conversational- something which I like. You get the feel as if the authors are talking to you and not to a wide audience.

The parts I didn’t appreciate much…
First of all- the preamble was too long.Copyright.Foreword. Another foreword. Preface. Introduction.
I hate that. Just my pet peeve. I want to get to the point- well quickly enough. (Isn’t that the whole concept behind Agile – eh ?)

I also had a small problem with assertion that this book is for managers and like. really? I think everyone should read this….

I also had some difficulty mapping some of the tools to the principles.

Overall- worth the time. Would definitely recommend who is curious about Lean . Experienced Agile practitioners would learn as well.

At times-I got lost and was tempted to skip the section. But I resisted, because the book is littered with gems everywhere.

The rest of this blog post – is my collection of highlights from the book.

——————————————————————————

On Eliminate waste…

“…anything that does not create value for a customer is waste. A part that is sitting around waiting to be used is waste. Making something that is not immediately needed is waste. Motion is waste. Transportation is waste. Waiting is waste. Any extra processing steps are waste. And of course defects are waste.”

“Eliminating waste is the most fundamental lean principle, the one from which all the other principles follow. Thus, the first step to implementing lean development is learning to see waste. The second step is to uncover the biggest sources of waste and eliminate them. The next step is to uncover the biggest remaining sources of waste and eliminate them. The next step is to do it again.”

“…until the software is integrated into the rest of the environment, you don’t really know what problems might be lurking, and until the software is actually in production, you don’t really know if it will solve the business problem.”

“If you must produce paperwork that adds little customer value, there are three rules to remember: Keep it short. Keep it high level. Do it off line.”

“A good test of the value of paperwork is to see if there is someone waiting for what is being produced.”

“It is difficult to resist the temptation to start several projects at the same time, but releasing too much work into a software development organization creates a lot of waste, since it actually slows things down.”

“Project tracking and control systems also do not add value, and further, they may be an indication of too much work in the system.”

“One way to discover waste is to think about what you would jettison if you had to get rid of all the excess baggage on a troubled project. It’s usually easier to see waste in a crisis.”

On Amplify learning…

“Think of development as creating a recipe and production as following the recipe.”

“In production, quality is defined as conformance to requirements specified in the design or “recipe.”

“In a service economy, quality does not mean conformance to a script; it means adapting to meet the changing expectations of many different customers.”

“Thus, quality in design means realization of purpose or fitness for use rather than conformance to requirements.”

“Somehow, the idea that variation is bad has found its way into software development, where people have tried to develop standardized processes to reduce variation and achieve repeatable results every time. But development is not intended to produce repeatable results; development produces appropriate solutions to unique customer problems.”

“In order to solve problems that have not been solved before, it is necessary to generate information.”

“One of the interesting features of the scientific method is that if your hypothesis is always correct, you are not going to learn very much.”

“Your objective should be to balance experimentation with deliberation and review. In order to do this, consider how you can generate the most knowledge at the least cost in your circumstances.”

“Most users relate better to seeing working screens than to a requirements document, so working software tends to generate better knowledge faster.”

“The important question in development is, How can I learn most effectively? The answer is often to have many short learning cycles.”

“…small batches moving rapidly through a system lead to all manner of good things.”

“…short iterations are an options-based approach to software development. They allow the system to respond to facts rather than forecasts.”

“…iterations are points of synchronization across individual and multiple teams and with the customer.”

“Since customers often don’t know exactly what they want at the beginning of a project, they tend to ask for everything they think they might need, especially if they think they will get only one shot at it.”

“…talking about constraints instead of choices defers making choices until they have to be made, that is, until the last responsible moment,”

“So how do you apply set-based development to software? You develop multiple options, communicate constraints, and let solutions emerge.”

On Decide as late as possible…

“There are some critical skills that must be in place in order for concurrent development to work.”

“On the average, more than half of the development work that occurs in a software system occurs after it is first sold or placed into production.”

“There are a few basic architectural decisions that you need to get right at the beginning of development, because they fix the constraints of the system for its life.”

“Lean software development delays freezing all design decisions as long as possible, because it is easier to change a decision that hasn’t been made.”

“The underlying dynamic is that people find it difficult to make irrevocable decisions when there is uncertainty present.”

“Economists and manufacturing managers alike understand that the adaptive paradigm of delaying decisions until uncertainty is reduced usually produces better results than a predictive approach.”

“Plans and predictions are not bad, but making irrevocable decisions based on speculation is to be avoided.”

“Options allow fact-based decisions based on learning rather than speculation.”

“Share partially complete design information.”

“Good design is a discovery process, done through short, repeated exploratory cycles.”

“Organize for direct, worker-to-worker collaboration.”

“Develop a sense of how to absorb changes.”

“Breadth-first involves delaying commitments, while depth-first involves making early commitments.”

“Marines plan, but they do not predict. A mission plan is both rapid and thorough, but it is not a scenario of how the mission will unfold.”

“A set of simple rules are guideposts; their purpose is to allow the people on the ground to make quick decisions about how to proceed, knowing that their decisions will not be second-guessed because they are making the same decision their managers would make given the same circumstances.”

On Deliver as fast as possible…

“Problems and defects, both large and small, often lurk in piles of partially done work.”

“… the principle deliver as fast as possible complements decide as late as possible.”

“There are two ways to assure that workers make the most effective use of their time. You can either tell them what to do or set things up so they can figure it out for themselves. In a fast-moving environment, only the second option works.”

“There are two ways to reduce cycle time; one is to look at the way work arrives and the other is to look at the way work is processed.”

“The way to increase throughput is to look for the current bottleneck that is slowing things down and fix it. Once that is done, find the next bottleneck and fix it. Keep this up and you will have a fast moving value stream.”

On Empower the team…

“We do not believe that focusing on getting things right the first time is appropriate for a design environment; instead, experimentation and feedback are more effective.We believe that the critical factor in motivation is not measurement,but empowerment: moving decisions to the lowest possible level in an organization while developing the capacity of those people to make decisions wisely.”

“We believe that transferring practices from one environment to another is often a mistake. Instead, one must understand the fundamental principles behind practices and transform those principles into new practices for a new environment.”

“Intrinsic motivation comes from the work we do, from pride in workmanship and a sense of helping a customer.”

“On a healthy team, everyone is clear on what the goal is and is committed to its success.”

“One of the fastest ways to kill motivation is what is called in the U.S. Army a zero defects mentality.”

“If a dedicated team is working at a sustainable pace and an emergency comes up, the members will rise to the occasion. If they are seriously over committed already, they can’t respond to an emergency.”

“Agile approaches recognize that architectures evolve and mature; the practical approach is to provide for an emerging design rather than try to stop it.”

“The real question is, When has enough design been done for developers to start working? This is where master developers fit in—they are the ones who make the call. It is the responsibility of master developers to judge the level of initial conceptual design necessary at the beginning of concurrent development, facilitate the emergence of the design as development proceeds, and assure that there are no downstream surprises that should have been anticipated.”

“Some knowledge can be codified and shared by documentation, but much knowledge is tacit knowledge that will only be shared through conversation.”

On Build integrity in…

“Perceived integrity means that the totality of the product achieves a balance of function, usability, reliability, and economy that delights customers. Conceptual integrity means that the system’s central concepts work together as a smooth, cohesive whole.”

“Perception is in the eyes of the beholder.Sometimes you come across software that suits you so well that you think the designer must have been inside your head.”

“If you had to rebuild your computer tomorrow, loaded with only the software you regularly use, how many products would you load?”

“If the most elegant architecture in the world does not do an exceptional job of meeting users’ needs, users will not notice the underlying conceptual integrity.”

“…the three fundamental requirements for improved software development performance are – Increased application domain knowledge across the entire software development staff. Acceptance of change as an ordinary process and the capability to accommodate emergent design decisions. An environment that enhances communication to integrate people, tools, and information.”

“If the vision of perceived integrity isn’t refreshed regularly, the engineers have a tendency to get lost in the technical details and forget the customer values.”

“…the chief engineer must understand what the engineers are grappling with as they proceed with the many tradeoffs they must make, in order to help them understand how their decisions will affect the integrity of the product.”

“Customers know what their problems are, but quite often, they can’t describe the solution. They will know a good system when they see it, but they can’t envision it beforehand.”

“Evans advocates this domain model as a ubiquitous language; that is, developers and customers alike should use the same words to mean the same things; typically, the words should come from the customers.”

“It is okay to create models that are useful for a time and eventually fall into disuse. But it is a waste to create and maintain models simply because it seems like a good idea. You know you have devised a useful model when it is eagerly referenced and maintained.”

“The key to communication about complex systems is to hide details behind abstractions when a broad picture is desired and move to lower levels of abstraction to flesh out the details.”

“…well over half of the spending on an application will occur after it goes into production.”

“…if a system is built under the paradigm that everything must be known up front so the optimal design can be found, then it will probably not be adaptable to change in the future.”

“…try to group things that are likely to change together and hide them from the rest of the system.”

“…use existing parts when possible. This means use off-the-shelf software when possible.”

“…use integrated problem solving. This means getting started on writing software before the design details are finalized.”

“…be sure there are experienced developers involved in all critical areas.”

“…complex systems require the leadership of a master developer with the skills to facilitate collaborative efforts across multiple development teams.”

“Improvement comes not just from meeting customer demands or adding features; improvements are also necessary because complex systems have effects that are not well understood at design time.”

“Microsoft keeps the same team working on a product such as Excel over multiple releases. After the team has worked hard to complete a release, the members are rewarded with a couple of months in which they are allowed to clean up the underlying structures of the code that bothered them the most while working on the release.”

“When a system begins to lose these characteristics, it’s time to refactor.”

“…the amount of refactoring that is appropriate for a system is a design judgment.”

“First, tests unambiguously communicate how things are supposed to work. Second, they provide feedback on whether the system actually works the way it is supposed to work. Third, tests provide the scaffolding that allows developers to make changes throughout the development process, making tools such as last responsible moment, set-based development, and refactoring useful in practice.”

“Suppose a developer has a conversation with a customer about details of a feature. The conversation should not be considered complete until it is expressed as a customer test.”

On See the whole…

“A system is not just the sum of its parts—it is the product of their interactions.”

“…the ability of a system to achieve its purpose depends on how well the parts work together, not just how well they perform individually.”

“One of the basic patterns in systems thinking is called limits to growth.”

“Finding and removing the limits to growth is the fundamental teaching of the theory of constraints.”

“A second basic pattern in systems thinking is called shifting the burden.In this pattern, an underlying problem produces symptoms that can’t be ignored. However, the underlying problem is difficult to confront, so people address the symptoms instead of the root cause of the problem.”

“Lean thinking uses five whys to counter the tendency to shift the burden to symptoms rather than addressing the root cause of a problem.”

“A third basic pattern in systems thinking is suboptimization. The more complex a system, the more temptation there is to divide it into parts and manage the parts locally. Local management tends to create local measurements of performance. These local measurements often create system wide effects that decrease overall performance, yet the impact of local optimization on overall results is often hidden.”

“Focusing exclusively on local measurements has a tendency to inhibit collaboration beyond the area being measured, because there is no reward for it. Using the testing department again, the testers were not measured on their ability to collaborate with developers and help decrease defects, so they probably didn’t get involved in improving the development process.”

“Yet a focus on cost and schedule would have distracted us from our ultimate objective: Develop and commercialize a profitable new product that meets a customer need and has a competitive advantage.”

“His premise is that people will try to optimize the measurements that their performance is measured against.”

“The basic rule that you get what you measure still holds. If you cannot measure everything that is important, partial measurements are very likely to turn into suboptimized measurements. If you can’t measure everything that is necessary to optimize the overall business goal, then you are better off without the suboptimizing partial measurements. Otherwise, you are in serious danger of encouraging suboptimized behavior.”

“The way to be sure that everything is measured is by aggregation, not disaggregation. That is, move the measurement one level up, not one level down.”

“I ran a software development company which prided itself in not exceeding the price and schedule quoted at the beginning of an engagement. In a three-year period, we had 78 projects, and 77 of them were delivered on time, on budget, and in scope. Then I surveyed the customers and found out that none of them was happy! The systems that we delivered did not solve their problems. Sure, we had protected ourselves by being on time, on budget, and in scope, but in doing this, we could not deliver what the customers really wanted. That’s why I sold my business.”

“Risk should be born by the party best able to manage it,”

“If a problem is technically complex, then the vendor is most likely to be in a position to manage the associated risk, so it is appropriate for the vendor to assume the risk. However, if a problem is uncertain or changing, then the customer is in the best position to manage the risk, so fixed-price contracts should be avoided.”

“…the vendor least likely to understand the project’s complexity is likely to be selected. Thus, fixed-price contracts tend to select the vendor most likely to get in trouble.”

“A fixed-price contract is biased in favor of the customer at the expense of the vendor, making it necessary for vendors to aggressively protect their interests, at the expense of the customer. ”

“In fact, many organizations find themselves using DoD-style project management controls internally. It seems incongruous that cost, schedule, and scope control mechanisms that add cost but not value and that were invented to prevent contractual parties from taking advantage of each other would come to dominate development inside of companies—the very place where they should not be needed.”

“…concurrent development is a safer approach for time-and-materials contracts than is sequential development and its associated controls.”

“…company can benefit more by allowing the system to evolve rather than be specified in detail at the beginning.”

“Jim Johnson of the Standish Group noted 64 percent of the features in a typical system are rarely or never used, suggesting that the most fertile ground for productivity improvement in software development lies in not implementing features that are not needed.”

Instructions and warranty…

“Eliminate waste does not mean throw away all documentation.”

“Amplify learning does not mean keep on changing your mind.”

“Decide as late as possible does not mean procrastinate.”

“Deliver as fast as possible does not mean rush and do sloppy work.”

“Empower the team does not mean abandon leadership.”

“Build integrity in does not mean big, upfront design. See the whole does not mean ignore the details.”

“One team’s prescription is another team’s poison.”

“It’s a lot more difficult to refactor users than it is to refactor code.”

“Instead of waiting for lean thinking to descend from above, use it to change your corner of the world.”

“This warranty is invalid if practices are transferred directly from other disciplines or domains without thinking, or if the principles of empower the team and build integrity in are ignored.”


   
© 2011 Technology Cafe Suffusion theme by Sayontan Sinha