Michael Kennedy, Kent Harmon, Ed Minnock Ready, Set, Dominate: Implement Toyota's set-based learning for developing products and nobody can catch you. This is a continuation of the book I reviewed earlier this year: Product Development for the Lean Enterprise. The authors pick up the story of the Infrared Technologies Corporation (IRT) a year later. The company has piloted bits and pieces of the Toyota System with various levels of success. The progress is visible but it is not sufficient to achieve the company goals. To make matters worse, the Board of Directors has run out of patience with IRT's poor financial performance and has hired a new Chief Financial Officer to improve profits fast. The new CFO does not believe in product development transformation efforts and recommends a different strategy: selling non-profitable side of business, outsourcing manufacturing, reducing cost through an across-the-board workforce reduction, and using profits to buy high-growth and high-profit companies...

No doubt, IRT faces serious challenges: market share is shrinking, overhead is increasing, and profits are deteriorating. Will the company be able to turn the situation around? Read the book to find out!

In the form of a business novel, the authors allow us to experience a journey towards Lean Product Development with the focus on Lean Knowledge Management. They point out common implementation mistakes and show how to effectively integrate the flow of innovative knowledge into a planned cadence of product releases.

Included with the book are case studies of two companies that have been successful at understanding and applying Toyota principles. I would like to quote one of them: "... once the desired specification was put on paper, it was viewed as an absolute requirement. No variance from the goal was acceptable. Since the requirements were not a variable, the only variables left were time and money. That meant missed schedules and cost overrruns."

Happy reading!

Gerald M. Weinberg The Secrets of Consulting: A guide to giving and getting advice successfully As a consultant, I find it illuminating and resourceful as it puts rationality and structure around seemingly irrational subject area. As a manager, I find it full of wisdom and wit, but perhaps lacking clear message and specific take-aways. As a reader, I simply find it entertaining. What am I talking about? "The Secrets of Consulting" book by Jerry Weinberg. Jerry defines consulting as the art of influencing people at their own request. Even this definition alone makes me think hard and deep about my role as a consultant... or as a person who needs consulting help. In a casual conversational manner, Jerry introduces rules and laws helping a consultant become more effective and ultimately more successful at what she/he does.

To give you a taste of what this book is about, I listed a few of my favourite rules and laws below:

• The Duncan Hines Difference: It tastes better when you add your own egg.
• Prescott's Cucumber Principle: Cucumbers get more pickled than the brine gets cucumbered.
• Rhonda's First Revelation: It may look like a crisis, but it's only the end of an illusion.
• The Harder Law: Once you eliminate your number one problem, you promote number two.
• Fisher's Fundamental Theorem: The better adapted you are, the less adaptable you tend to be.
• The Bolden Rule: If you can't fix it, feature it.
• The Principle of Least Regret: Set the price so you won't regret it either way.

Happy reading!

Welcome again. Here is what I picked for this month's review:

Michael N. Kennedy Product Development for the Lean Enterprise: Why Toyota's system is four times more productive and how you can implement it. I first learned about Toyota production and product development around 5 years ago. Their numbers are truly impressive: Toyota is consistently named at the top in owner satisfaction surveys Toyota's  milestone dates are never missed Toyota's engineers and managers achieve incredible 80% of value-added productivity (vs. 20% auto industry average in the US) What does Toyota do differently from everybody else? How can we apply their principles to IT? Product Development is substantially different from Manufacturing. Which one is a better fit for an IT organization?

While there is plenty of information on wildly admired Toyota Production System (Lean Manufacturing), there is considerably less data on Lean Product Development (Knowledge-Based Development). In order to better understand how these two systems are different, take a look at the table below:

	Lean Manufacturing	Lean Product Development
Cycle Time:	Short (minutes, hours)	Long (days, weeks)
Core Material:	Physical material	Knowledge and information
Teams:	Smaller, focused	Larger, more diverse
Focus:	Focus is on executing predefined tasks and automation	Focus is on defining new solutions and building knowledge and expertise

In his book, Michael Kennedy introduces the principles of and key elements behind Lean Product Development:

• Set-Based Concurrent Engineering
• System Design Leadership
• Responsibility-Based Planning and Control
• Expert Engineering Workforce

In an engaging and humorous manner, he explains how these principles can be adapted and implemented in your organization. The book is thought-provoking, sophisticated, and extremely fun to read.  It appeals to my sense of humor and has a plot and engaging characters that no reader will forget. It will keep you occupied until early morning hours... ;-)

Principles of Lean Manufacturing work well for IT maintenance and support. Lean Product Development fits well IT software development teams. If you are a technical or functional leader in an IT organization, this is a must-read book for you!  I am sure you will enjoy it.

Happy reading!

Welcome again. Thank you for reading my monthly column. Today, we will talk about a classical book on project retrospectives by Norman Kerth.

Norman L. Kerth Project Retrospectives. A handbook for team reviews. In my consulting practice, I see many teams working very hard, constantly in a rush trying to save the day, making the most out of every single minute they have... and never having enough time to stop and think about how they perform. Retrospectives provide a formal way for teams to get away from their daily grind and take some time to reflect on their performance, seek an opportunity to learn and get better. In his book, Norman Kerth does an excellent job guiding readers on how to plan, prepare, and facilitate an effective retrospective on project performance. He describes a very thorough approach to how to prepare for a retrospective in a situation when you are an outsider and do not know the details and history behind the project. He spends quite a bit of time discussing how to make a retrospective safe for all participants and provides valuable methods for extracting related project data and capturing lessons learned.

Norman's approach to retrospectives is a bit heavier than mine. He advocates for 3-4-day preferably off-site residential sessions. I tend to like shorter more frequent meetings anywhere between 4-8 hours. In order for shorter more frequent meetings to work, you will need to minimize your project cycle time down to 1-3 months. A retrospective on a 3-year monster will certainly require substantial time and effort.

Remember, the greatest teams are great because they self-reflect and continuously improve. Happy reading!

Innovation was the theme of the Code Freeze 2008 conference last week. Mark Striebeck talked about innovation strategy at Google, Jon Spence explained how Agile methods were introduced at Medtronic, Jamie Thingelstad touched on innovation in product development at Dow Jones. Then after lunch, we had the pleasure to listen to Stuart Halloway, Nate Schutta, and David Hussman.

Most of the ideas discussed are common sense, but one point is interesting to think about. Jamie said that leadership by committee does not work. I tend to agree with this statement. I also trust Jamie's judgement - his organization managed to keep its innovative culture and efficient development environment through a number of merges and acquisitions. But I just keep wondering...

One of the responsibilities of a strong leader is to build a strong coalition to support her or his ideas and lead this coalition as a team to make the change and innovation happen. Could that result in leadership by committee?

At the OTUG meeting last week, Esther Derby was going over the change model, originally introduced by Virginia Satir to help families deal with change. The model consists of 5 stages: Late Status Quo, Resistance, Chaos, Integration, and New Status Quo and describes change patterns and early indicators that occur at each stage. The model also works well for the organizations.

One of the most interesting and somewhat underestimated stages of the model is Chaos. Old behaviors do not work, old relationships are not possible, the organization is filled with rumours and uncertainty, performance decreases, the changes are at their highest risk of being reverted back... and the leadership is tested. Do you recognize these symptoms?

If you are not familiar with the work of Virginia Satir, take a look at this book: Satir Model: Family Therapy and Beyond.