Using Lean - Optimization strategies

There are several strategies to optimize our work and to reduce or avoid waste. We will discuss the advantages and disadvantages of each strategy and a possible holistic approach that includes them all.

Correct: assess final symptoms - Most important final symptoms are defects and delays. I use the term final, because all other sources of waste could end up causing defects and delays. After discovering the delays, for example, we can assess these effects and then try to find the root causes and correct them.
Advantages -  This is like the "Year-end accounting": if we have flaws in our approach, most likely it will translate in these kinds of waste.
Disadvantages - It may be too late. We discover the problems late and apply the corrections even later.

Correct early: assess intermediate symptoms - we should consider and discover all known significant sources of waste, including those with delayed effects such as lack of built-in quality (which creates defects and delays later). We should also take into account the trends of wastes. See more on the previous post.
Advantages -  The problems are corrected early. For example. we can improve the quality before inducing significant delays.
Disadvantages - Has a good accuracy, but we cannot evaluate exactly how much possible delays and defects are reduced.

Avoid: use past experience. If we know how to avoid the waste, we can do the right thing the first time.
Advantages - that should produce a maximum effect and best work optimization.
Disadvantages - it is not so clear how much waste has been avoided.

Question: When and how can we apply the three approaches?

A simple answer might be to use them in this sequence:

• Avoid, use past experience
• Correct early. What cannot be solved by experience should be discovered and resolved early 
• Correct, assess final symptoms. This should be the last line of defense, but it is also very important and must not be skipped.
  

 A better answer will have some additional comments:

• Make an initial assessment based on existent information and metrics. Apply last two steps (corrections) based on historical information.
  
• Always use conclusions from late steps to learn and shift to the left the optimization. 
  

We need to evolve from correction to prevention 

This approach is consistent with Disciplined Agile Guided Process Improvement logic: succeed early instead of failing fast. My recommendation is to use DA Toolkit or any similar guidance in all three steps. At the same time a good experience in using Lean to avoid waste will be very useful.

Essential Lean - Searching for a Definition

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:

• 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.   

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 - Searching for a definition

Essential Lean - Analyzing existent solutions

Essential Lean - Goal-Driven Lean
Essential Lean - Avoiding Defects Goal Guidance (example)

Essential Lean - Waste avalanche effect

Essential Lean - Red Flags


References
[1] - Al Shalloway Discusses the Lean-Agile Method

• https://www.infoq.com/interviews/al-shalloway-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 

Work Optimization: Avoiding Waste with XP, DA and Scrum

Avoid Waste (!Waste)

Here are some of the most known work optimizing principles related to Avoiding Waste, where many of them have as source TPS philosophy to avoid sources of Muda/Waste (it is better to return to original ideas, beyond various further Lean evolutions; see biblio-TPS) The other two are the ones that bother me the most, and could be specific for knowledge work: Not Used Talents and Improvement Stalemate.  In our case, these sources of waste will be interpreted from software domain point of view.

Principles & practices. XP, Scrum and DA  

As in the case of Core Agile Capability we need have a traceability between principles, values and the practices that bring them to live. A such trace could be found at the end only from what is useful in the real work.

In the following parts, we will try to present how this realization is done by practices from original main Agile methods: XP-Extreme Programming and Scrum and how we can get a more robust approach using DA - Disciplined Agile. We mention only practices that are explicitly mentioned by the methods & their guidance ... and what we have found that works in real practice. Here it is summary, I will come back with details for each part.   

"What we need" - description of what we have find that it is working to manage that aspect of the waste.

Important: if Core Agile Capability – Responding to Changes - is not met, the software development is not optimized from the start: this core capability address all the optimizing work principles at their fundamentals.
.

No Inventory: reducing work in progress

What we need

·   First, we need to “make the work easy” (See biblio-Kent_Beck): a big work in progress (inventory) will exponentially increase the complexity & incertitude, will reduce reaction time (core required capability) and quality.

·      Reduce the work in progress (WIP) on all possible dimensions, from making the release smaller to avoid multi-tasking   

Avoid Defects

What we need

·    To prevent defects & catch them as early as possible ~ provide build-in quality; all the practice that “shift left” the quality risks will be useful  

·    First, to make the work easy: see Avoid Overproduction and Avoid Big Inventory    

Avoid Waiting

What we need

·  Work should be “Ready” – actionable (!) -  before start using main resources: we do not want to wait for dependencies related to information, artifacts and others; what is missing usually is the overall perspective, that a Rolling Wave approach could bring: product, release, iteration, inside iteration   

·    We want to avoid bottlenecks in work, such skills (specialization) bottlenecks   

Avoid Overproduction

What we need

·   To avoid “Big work” that bring many risks: it is hard to include & manage required changes, it is a high probability to deliver results that are no more needed       

·   To develop and be ready to deliver big value first; will be much easier drop not started “junk stories” on request

·  To not guess about production needs: mixing envisioning and JIT on requirements and solution, implement what and if is needed

Avoid Over-Processing

What we need

·   Avoid extra work, not required by customer

·   Avoid process ceremonial that does not bring value

·  See also dedicated sections for:  Avoiding Defects (Built-In Quality), Avoid “Transport & Motion”, Avoid Re-Work  

Avoid “Transport & Motion”

What we need

• If, in case of manufacturing, products could be damaged by transport & motions, we can found an equivalent for this waste, also for knowledge work/software development: unnecessary long chain of information handover & information duplicate in a long chain of artifacts.
• Successive handovers could be caused by lack team ownership over information and lack of cross-functional skills   

Avoid Not-used talents

What we need

·        Practices support to quick and effective learning & skills improvement

·        To develop cross-functional skills. Example: a programmer with requirements & testing skills will perform TDD and design better   

Continuous Improvement & no persistent impediments

What we need

·        To avoid blockage on process improvements 

·        A process that make the impediments visible & it is effective on removing them

Avoid rework

What we need

·        To avoid “Waterfall rework”: big work with too few feedbacks could increase rework to infinite  

·        To avoid “Scrum-Agile rework”: lack of look ahead on requirements & solution could induce need of rework 

·        To avoid late defects detection – see Avoid Defects

·        Finally, we need to balance envisioning and defer of the commitment (JIT) and also get as much feedback it is possible   

Final thoughts

Work optimization it is related to some main ideas:

·        Teams should choose the optimum practices and ways of work in context

·        A good range of skills and known practices maximize the also the range of available options  

Disciplined Agile principles are about choices and growing team’s members, offer a solid fundament and guidance for work optimizations, while including also XP and Scrum related practices.

Notes about practices

Specific for Agile is that with one practice we can get multiple benefits. If the same practice could address more sources of waste, we could consider that practice as more valuable for our process.

See specified bibliography for each method for more details about mentioned practices

  

Bibliography

Biblio-TSP

·        Toyota Production System: Beyond Large-Scale Production 1st Edition, by Taiichi Ohno, Productivity Press; 1 edition (March 1, 1988)

·        https://en.wikipedia.org/wiki/Toyota_Production_System

Biblio-Kent_Beck

·        https://www.facebook.com/notes/kent-beck/mastering-programming/1184427814923414/

Biblio-DA Disciplined Agile

·        http://www.disciplinedagiledelivery.com/

·        Agile Modeling Practices - http://www.agilemodeling.com/

·        “Disciplined Agile Delivery:  A Practioner’s Guide to Agile Software Delivery in the Enterprise”, by Scott Ambler and Mark Lines

Biblio-XP Extreme Programming

·        Extreme programming explained: embrace change, Kent Beck, Addison-Wesley Professional; US ed edition (October 5, 1999)  

Biblio-Scrum

·        Scrum Guide 2016, US edition - http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100

·        Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust 1st Edition, by Ken Schwaber , Jeff Sutherland