One Minute Bottom Line
Is your Lean adoption not as successful
as you had hoped within your organisation? Maybe the way management
thinks about Lean and how it fits within the organisation needs to
change. Aimed at managers and team leaders, but relevant for
all those involved in Lean, this book presents Lean from a organisational and
My first introduction to Mary Poppendieck was her excellent The Tyranny of "The Plan” presentation
given at the UK Lean Conference in December of 2009, which touches on some of the concepts covered in this book, which she co-authored with Tom Poppendieck. After seeing her presentation and listening to the interview
at the same conference, I was excited to have the opportunity to review this book.
Through conversions with people at conferences and other meetings, Tom and Mary have come to the conclusion that it is often the organization itself being the greatest barrier when adopting Agile and Lean practices, that is, the organization has yet to come to terms with the often counter intuitive concepts of Lean software development. Targeting the project leaders and managers, this book draws upon the ideas, philosophy, and practices of highly successful companies and shows how their practices can be applied to developing software-intensive systems.
Tom and Mary introduce Frames, borrowed from cognitive scientists, arguing that we perceive the world around us through frameworks of assumptions and beliefs. They argue that successful organizations share a common set of Frames and ask the reader to reassess your own beliefs and assumptions to re-frame your own thinking of the system development process. Although they draw upon and make reference to Agile and Lean methodologies you don't need to be familiar with them to benefit from the book.
They give us 24 frames grouped together into 6 chapters. The objective? To bring together a picture of how the Lean development process should work within an organization and provide a framework for leadership in systems development. It identifies different leadership types from the product champion, the leader on the front line, leadership in technical competency, the mentor then recognize there is a requirement for great leaders at each level.
With focus on the customer's demands and expectations, the authors make the distinction between value demand and failure demand. Failure demand is the cost of responding to failures in the system. The aim should be to eliminate failure demand by recognizing the importance of high quality in the development of these systems. How do you achieve high quality? You need to recognize software is created by knowledge workers whose skills need to be developed and matched to the system development – you cannot force a project to meet its targets if those targets are beyond the capability of people. Having capable people matched to the task at hand will lead to successful results hence the subtitle Results are Not the Point. But what about my timeline and budget? If the system cannot deliver the required results then it does not matter if you were on time or on budget, and if milestones are met at the expense of quality then things will be made so much worse in the long term.
Using the example of Toyota and their Toyota Production System (TPS), which promotes problem solving, continuous improvement, and the respect for people, Mary talks about how the Toyota company fosters self-improvement both of the individual and the group through skill development. This book was published before the current crisis in Toyota requiring the recall of vehicles due to safety problems - what does this mean for the Toyota way
? It seems that Toyota's push to topple General Motors
as the worlds biggest car maker fell into the trap of forcing the system to meet its targets at the expense of quality. Since Toyota relies on Lean manufacturing using common parts and designs across multiple product lines, quality problems in one section could impact on many products.
The majority of programmers will not being developing “new” products, but maintaining existing code, yet how often have you encountered large monolithic systems which are almost impossible to maintain? We are told that good object-oriented code is loosely coupled but highly cohesive, code that is expected to be modified frequently is isolated together so it can be maintained over time. Agile practices promote change, where as monolithic systems are resistant to change because of their complexity therefore Mary and Tom argue for Agile to work in these types of organizations they must evolve the code base on a vision of low-dependency.
The subtitle of this book, Results are Not the Point, means to create a system and grow the people who are capable of delivering excellent results over the long term. It should be read by all managers because it provides not only a framework of ideas and tools to motivate managers to then motivate and nurture their staff, but to modify the organism of the organization to be able to adopt and benefit from Agile techniques. There is little to dislike about this book (and much to love), there are many books written on leadership, motivation, management of people, and this book does cover the same ideas contained in many of those books. But it places those ideas within the context of the a organization wanting to adopt Agile, the developers want to adopt it, the team leaders want to adopt it, but is the organization ready to change for it? This book will challenge your thinking, challenge your Frames of how you view the world, and it's a worthwhile journey.