Starting with the need - Taiichi Ohno, Toyota Production System
Searching for a definition
Lean is a systematic approach that offers a specific capability and/or offers solutions to problems from specific domains (for example software development).
Why do we need a clear, generic definition? Existing ones are focused on enumerating the “how”-s, and consequently exclude some of the great contributions to Lean.
Initial promised capability: efficiency.
For both manufacturing and knowledge work, there is a catch! You will not get efficiency by blindly following this goal. Effectiveness and efficiency are working together in any context defined by complexity and incertitude.
Concrete promised capability: work optimization (efficiency & effectiveness)
Lean Definitions Pitfalls
Jumping to solutions is prescriptive – The currently existing definitions are "enumerations", describing some of the main categories of solutions and do not fully address the promised capability or the problems to solve. This approach – jumping into solutions - is somehow prescriptive and cannot offer an optimum (leaner) response in context.
Example: The recommendation to reduce the delivery level feedback cycle with Kanban and continuous flow is a good general guideline, but for a specific context, the leaner option could be an iteration-based life cycle with Kanban used internally. In other contexts, the reverse could be true. Given these prescriptions, we will start to "believe" in labels. For example, one big confusion is the one between Kanban and Lean, where Kanban is just one of the Lean practices.
Disregarding significant problems - The most common problems for software development efficiency should be also covered by Lean. Some examples include:
Disregarding significant problems - The most common problems for software development efficiency should be also covered by Lean. Some examples include:
- undesired complexity
- lack of collaborative work
Both categories of problems are generating a lot of well-known wastes such as waiting, excessive handovers, and defects.
Most known Lean approaches have inherited from manufacturing the subject of the waste produced by defects but failed or forgot to discuss the main root cause of the defects - undesired complexity and poor design - that is specific to software development. Unfortunately, non-software thinking mode still predominates in lean.
No problem-solution traceability – we should
start from identifying the main problems and then find the best solution in context
instead of starting from a list of enumerated good practices. Unfortunately, Lean is currently still delivered in a "methods" based package: here is our solutions list, just do it.
We should extract and use knowledge from different sources as Al Shalloway points out here: ".. if we take from Scrum what we’ve learned, not about Scrum, but about the methods it pulls from, about the ideas, about the concepts it pulls from, about why getting quick feedback is good, why having teams is good. Now, what if we go to Kanban and say what have we learned about these axiomatic truths from using Kanban, why is managing queue size good, why is managing flow good, why are explicit policies so good. And then kind of throw away both Scrum and Kanban so to speak, but keep all that knowledge of this axiomatic knowledge and then say, well, what if we created a new method, what if the people who know Scrum and Kanban are really good at it and now understand these axiomatic methods were to come up with, what would we build now if we knew back then what we know now?"
It is interesting that the same thinking could be found in the foundations of world philosophy: “The fish trap exists because of the fish. Once you've gotten the fish you can forget the trap. The rabbit snare exists because of the rabbit. Once you've gotten the rabbit, you can forget the snare. Words exist because of meaning. Once you've gotten the meaning, you can forget the words. Where can I find a man who has forgotten words so I can talk with him?” - Zhuangzi, Chuang Tsu, Chapter XXVI.
Returning to software, we might have some similar goals in different software efforts, but the context is different, so we can't rely on prescribed process solution. So we should pay attention to what is a principle, an axiomatic knowledge, and what is closer to concrete practices. An excellent approach could be one expressed by Scott Ambler and Mark Lines:: "Our philosophy is to look for great ideas regardless of their source and to recognize that there are no best practices (nor worst practices). When we learn a new technique, we strive to understand what its strengths and weakness are and in what situation to (not ) apply it." [2]. We should creatively apply our domain principles and select the practices/process solutions that work better in our specific context.
Essential Lean Series
Read first: Principles of lean thinking (by Mary Poppendieck)
Essentializing Lean - essay
A point of start
We should extract and use knowledge from different sources as Al Shalloway points out here: ".. if we take from Scrum what we’ve learned, not about Scrum, but about the methods it pulls from, about the ideas, about the concepts it pulls from, about why getting quick feedback is good, why having teams is good. Now, what if we go to Kanban and say what have we learned about these axiomatic truths from using Kanban, why is managing queue size good, why is managing flow good, why are explicit policies so good. And then kind of throw away both Scrum and Kanban so to speak, but keep all that knowledge of this axiomatic knowledge and then say, well, what if we created a new method, what if the people who know Scrum and Kanban are really good at it and now understand these axiomatic methods were to come up with, what would we build now if we knew back then what we know now?"
It is interesting that the same thinking could be found in the foundations of world philosophy: “The fish trap exists because of the fish. Once you've gotten the fish you can forget the trap. The rabbit snare exists because of the rabbit. Once you've gotten the rabbit, you can forget the snare. Words exist because of meaning. Once you've gotten the meaning, you can forget the words. Where can I find a man who has forgotten words so I can talk with him?” - Zhuangzi, Chuang Tsu, Chapter XXVI.
Returning to software, we might have some similar goals in different software efforts, but the context is different, so we can't rely on prescribed process solution. So we should pay attention to what is a principle, an axiomatic knowledge, and what is closer to concrete practices. An excellent approach could be one expressed by Scott Ambler and Mark Lines:: "Our philosophy is to look for great ideas regardless of their source and to recognize that there are no best practices (nor worst practices). When we learn a new technique, we strive to understand what its strengths and weakness are and in what situation to (not ) apply it." [2]. We should creatively apply our domain principles and select the practices/process solutions that work better in our specific context.
Essential Lean Series
Read first: Principles of lean thinking (by Mary Poppendieck)
Essentializing Lean - essay
Essential Lean - Red Flags
References
[1] - Al Shalloway Discusses the Lean-Agile Method
[2] - Choose your WoW: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working, 2020 Edition, by Scott Ambler, Mark Lines
References
[1] - Al Shalloway Discusses the Lean-Agile Method
[2] - Choose your WoW: A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working, 2020 Edition, by Scott Ambler, Mark Lines
No comments:
Post a Comment