Re-Thinking “Eliminate Waste” and “Last Responsible Moment”

February 25, 2017 — Posted by Al Shalloway

Re-Thinking “Eliminate Waste”

A common refrain in Lean-Manufacturing is “eliminate waste.”  However, this can be very misleading when applied to software development (product or IT).  There are two main reasons for this.  The first is that manufacturing involves trying to refine a single repeatable process.  The other is that because manufacturing exists in the physical world (whereas software is more virtual) waste is more easily seen in manufacturing than in software development.   There have been many disagreements about what “waste” is in software.  Is planning, documentation and design waste?  Clearly, we need some of these but many people argue that they are waste.  Going for as little as possible is likely not the right answer. 

In Principles of Product Development Flow, Don Reinertsen said “If you only quantify one thing quantify the cost of delay.”  Although he was stressing the importance of quick delivery, it provides a clue to shift our focus to delay in delivery.  This, of course, is affected by many things.  But the causes of delay in the realization of business value are insidious in software development because most delays create additional work to be done (typically in the form of rework).  By eliminating delays, we eliminate much of this additional work – freeing up time for creating more value. 

So yes, we do want to eliminate waste, but we do so by eliminating delays in workflow, feedback and business value delivery.  Focusing on delay instead of waste shifts the conversation from “is this waste?” (something people often disagree about) to “is this delay causing problems?” (something we can mostly agree on).  Consider this – few people will argue for delays.

Re-thinking “Last Responsible Moment”

The mantra to make decisions “at the last responsible moment” has a similar challenge.  Many people won’t agree on what that last responsible moment is.  However, if we consider delays, what we want to do is to minimize the delay between making a decision and acting on it.  The greater this gap the greater the risk of it being a poor decision. Let’s consider requirements as an example.   Getting all of the requirements up front is clearly too early – as implementing some will affect others.  Shifting from “the last responsible moment” to “when will I need the information this decision entails?” will improve the timing of the decisions involved.

The Key Is Alignment

It is straightforward to begin a transformation to Agile at scale.  But after the initial training and kickoff, it quickly becomes more of a “how do I shift people’s mindsets?” than a “what do I do?” challenge.  We’ve all seen Agile “transformations” where people kept the same mindset adversely affecting real change.  Shifting mindsets is necessary to achieve alignment across the organization. We need to consider not just the end-result (eliminating waste and making decisions at the right time) but what questions can we ask that will have people work together better.  As has been said by many people in different ways “we will get better answers when we have better questions.”  The power of better questions is illustrated by Jonas Salk’s comment – “what people think of as the moment of discovery is really the discovery of the question.”

It you found this post of value you should attend my upcoming Break Through Agile Transformation Stagnation, March 2.  And, as always, I love to talk to people about their challenges, so feel free to contact me about this.

Al Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban