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 base, the product has to demonstrate with a design or an architecture, or a set of construction guidelines. 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 that the product owner (PO) is responsible to communicate, is created by and communicated among the developers. And, in such a case, a development lead is a critical role to help building the agreements and communication, and, as a result, planning for 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 view of the user and business. User stories, business rules and data, and UI design are among the core elements of this view.
Once both product design view and product user view are properly addressed and communicated in a continuous basis, the detail level execution of a project, including requirements breaking down for iterations and production delivery schedules, can be planned accordingly and in a more precise manner.
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.
![]()
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 base, the product has to demonstrate with a design or an architecture, or a set of construction guidelines. 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 that the product owner (PO) is responsible to communicate, is created by and communicated among the developers. And, in such a case, a development lead is a critical role to help building the agreements and communication, and, as a result, planning for 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 view of the user and business. User stories, business rules and data, and UI design are among the core elements of this view.
Once both product design view and product user view are properly addressed and communicated in a continuous basis, the detail level execution of a project, including requirements breaking down for iterations and production delivery schedules, can be planned accordingly and in a more precise manner.
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.