Main Causes of Waste at Scale

September 27, 2014 — Posted by Al Shalloway

Note: this blog is part of the Series of Blogs on Scaled Agile, Lean and SAFeTM 

Much of the problems we face now are due to solutions we had at a team level that do not solve the problems at the cross-team and enterprise level.  This blog discusses what these wastes are which is our first step in avoiding them.

I have long maintained that the Lean Mantra of “eliminate waste” is a red herring in the software development space.  The reason is that in software development, waste is mostly invisible and what it is is even up for debate.  In the physical world, waste is evident and all around you on the factory floor. In the software world it is not so readily apparent.  But the sources of waste are visible.  And the root causes of these can often be traced by to delays in workflow and delays in feedback.

To make things actionable, I will discuss the root causes of waste in software development as well as practices that one can take to eliminate them.  Our goal is to create the most important items as quickly as possible with high quality.  We also want to do this right the first time. What’s in our way of doing this?

  1. Not having enough value density
  2. Building the wrong thing
  3. Taking too long for feedback
  4. Having the wrong capabilities to get the job done
  5. Having the team be overloaded
  6. Bad technical practices
  7. High technical debt

Not having enough value density.  Most companies of any size I have worked with have had the phenomenon of “getting while the getting is good.”  This takes place when development teams don’t work as fast as stakeholders think they should.  Be clear that in most cases, this expectation has nothing to do with reality.   Hence we get requirements piled up on requirements – many of which are not as useful as other things that could be being built.  Relatively few companies are using the notions of minimum viable products (MVPs), minimum marketable features (MMFs), or as we like to call them – minimum business increments (MBIs).  That is, discover what the minimum delivery can be that’s worth the development, deployment and consumption cost.  Using MVPs enables development organizations to focus on delivering the most important items quickly.  It also is the basis of small batches in a lean-flow system.

Building the wrong thing. The attitude that we never know what the customer wants is a hard one to kill. While it is truer we don’t know much of what the customer wants, it is possible to get clear enough to avoid building the wrong thing.  Techniques such as Acceptance Test-Driven Development (or Behavioral Driven Development if you prefer) help the customer (or their rep) understand what is needed and convey that to the development team.  This is one practice that is almost universally valuable, easy to do, with a quick return on investment.

Taking Too Long for Feedback.  There are many feedback loops in software development, including:

  • Stakeholder and product manager
  • Stakeholder and development team
  • Product manager and product owner
  • Product owner and team
  • Developer and tester
  • Teams developing software together where they need to integrate their software

It is for this reason that the software being developed needs to be decomposed into thin, end-to-end slices that can be validated within each of these feedback cycles.  It is not enough that we have small stories, they need to be vertically oriented. Just another reason to use ATDD, btw.

Having the Wrong Capabilities to get the Job Done.  This can often mean equipment and platforms, but usually means people with specialized skills.  Scrum hypothesizes this away by saying to have cross-functional teams.  But his is often not a viable economic solution.  Many companies have only a few people who were around when the code was written, have insufficient subject matter experts, or a shortage of architects.  But the reality is, many situations exist where only a few specialists are needed and can be shared across teams.  Saying you should have enough for every team is neither realistic nor responsible.   The real challenge is if you approach (e.g., Scrum) doesn’t provide visibility in where your bottlenecks lie.  Then you have little recourse but to guess what your real challenges are.

Having the Teams Be Overloaded.  When people do too many things delays in workflow are inevitable.  The power of the Kanban method is that it both helps manage and create visibility on the bottlenecks in a value stream.

Bad Technical Practices.  Writing solid code, automating testing and doing continuous integration are essential practices that all development teams should be doing.  Without them, much work is duplicated and delays in finding errors are significantly lengthened, greatly increasing the amount of time required to find and fix them.

High Technical Debt. Most companies have very high technical debt that easily doubles the amount of time to get things done.   Rewriting systems because they eventually can’t be maintained is an all too common practice.

There are, of course, many other causes of waste.  But these seem to be the essential ones.

Please discuss these on the Lean Systems Society Discussion Group.

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 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


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