I recently stumbled across a document called the “Lean Primer” by Craig Larman and Bas Vodde. This document is based on the “Toyota Way” which strives to build a culture of that results in sustainably great products. Although the Toyota Way is based on techniques used in automobile manufacturing I was struck by how applicable the framework is to software development. Indeed these parallels have not escaped the document authors who wrote a book on the subject - Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum – and advise companies on applying lean thinking.
The Primer quotes the book “Inside the Mind of Toyota: Management Principles for Enduring Growth” and states that “the essence of successful lean thinking is ‘building people, then building products’ and a culture of ‘challenging the status quo.’” The first part of that statement sounds like it could be taken right out of Tom Peters Good to Great – first the who, then the what.
The Larman and Vodde summarize lean thinking using a “house diagram” based on a 1973 diagram from Toyota’s then chairman Fujio Cho. The majority of the 45 page Lean Primer is devoted to explaining the house diagram.
At the top of the house is the goal of lean: deliver value fast. The shorter the cycle-time the better. This principle is fully transferrable to agile development which emphasizes getting working software into real user’s hands as fast as possible. I love their metaphor of the lake and rocks. “When the water is high (large batch or inventory size, or long-cycle time) many rocks are hidden.”
The first pillar “Respect for People” struck me as very analogous to a principle found in agile development where the manager is supports the team and allows individual engineers take ownership for their work. In an agile world, a manager’s job is to remove obstacles, coach, and offer expertise. It is not to micro-manage tasks and assignments, bury people in a storm of email, or unnecessarily tie them up with administrivia. Similarly the sprint planning meeting, daily scrum meetings, and the end of sprint review replace the thrashing that can occur when requirements change in a world of big-bang releases.
The rightmost pillar of the Lean house is “Continuous Improvement” and encompasses several useful ideas.
- Go see which reminds me of Management by Walking Around which I believe originated at HP. In the world of software management I believe it means looking at code yourself and actively being involved in the process whether by writing small sections of code, testing, or pitching in wherever necessary. For example, when he was at Microsoft Bill Gates was famous for actively participating in code reviews.
- The 5 whys refers to the notion of considering the same challenging problem 5 times. For example, why does the server keep crashing? Often times it’s useful to visually represent the problem as a fishbone diagram.
- The Sprint Retrospective is also highly compatible with the Continuous Improvement Pillar. The Retrospective is an opportunity for the team to discuss what went well, not so well, and what would be done differently. In the Army we used to call this the After Action Review.
The center pillar refers to a number of familiar concepts broadly categorized in terms of Product Development and the 14 Principles.
- Several of the product development bullets relate to the notion of leaders that build great teams that passionately care about the products that they build, the people they work with, the customers that use the products, and are grounded in a sense of purpose. In my view this type of leadership cannot be taught – your either have it or you don’t. Great teams, however, can be nurtured by senior management that is committed to a people-centric culture – employees and customers.
- The technique of having a team room and visual management is one that I have found to be particularly effective. The notion of having visual artifacts such as progress on a burn down list, the organization of database tables, or the layout of a user experience is consistently valuable in terms of communicating understanding.
- Cadence is the heart-beat of a regular software development life-cycle. “People appreciate or want rhythms in their lives and work.” Timeboxing work into short cycles where a reasonable amount of work can be done well is in my mind the equivalent of an agile sprint.
Toyota’s immense historical success using “Lean” development methods validates much of what software developers embracing agile methods have believed for some time. The Lean Primer is a very worthwhile read and is highly recommended.
Posted by scooter998 
