Lean-thinking and two product views with software development

Coined from a Toyota production system for the adaptability, flexibility, and free of waste, lean-thinking has two pillars: 1. Just-in-time, 2. mistake-proofing. At the heart, lean thinking is the elimination of waste – rework, overproduction, conveyance, waiting, inventory, etc. [1]

To achieve these, In general, lean-thinking relies on user collaboration (sensitive to needs), skilled people working together (team work), producing quantities in small batches (iterative development), and simple processes (adaptability). [1]

Can lean-thinking be used for software development and how? Software development seems perfect for lean-thinking comparing to other productions, such as building a bridge, which can neither be iterative nor be adaptable. For software development, all above requirements are desirable.

What software development is different from other production is refactoring – adjustment to the implementation so far. As new feature development progressing, the code base is not simply adding in new code, the old code are usually subject to change, which sometime could be fundamental like architecture adjustments. Refactoring should happen once in a while before following iteration of development can start.

To let refactoring to have a direction, the product has to demonstrate with a design or an architecture, or a set of construction guidelines (the product solution view). No matter what they are, the team must have a clear vision and an agreement. This more technical view of the product, comparing to the business or user view of the product (the product business view) that the product owner (PO) is responsible to communicate, is created by and communicated among the developers. And, as such, a development lead is a critical role to help building the agreements and the communication, as well as planning for development and refactoring tasks.

While looking at the production team and process, the essence of lean-thinking is a pulling model – demand-driven production, being just-in-time and just-in-size.

To avoid mistake and to eliminate waste, the product requirements in the first place must be justified. This comes to the PO and the product business view. User stories, business rules and data, and UI design are among the core elements of this view.

Once both product solution view and product business view are properly addressed and communicated in a continuous basis, the detail level execution of a project, including requirements breaking down for iterations and product delivery schedules, can be planned accordingly and in a more precise manner. From project perspective, both the work schedule (time) and the quality of the product can be better planned and controlled.

I have created a tool, MineralR, meant to help PO and developers manage those two views. If you are interested in a discussion, I can be reached at shi.luan@hotmail.com.

Reference:
1. The Business Value of Agile Software Method, by David F. Rico et al.