There has been a tendency to translate the seven wastes of manufacturing into wastes of software development. Not a bad start, but just that - a start.  There are several things about software development that is not at all like product development in the physical world.  These include:

• the invisibility of waste
• the appearance of a developer is the same when writing bug free code and when writing buggy code
• errors in software tend to take more energy to fix as time goes on (even prior to deployment)
• errors in manufacturing tend to repeat themselves, errors in software are unique, although they repeat a pattern

The point is, we need a new list of wastes for software development.  Here is a first cut:

• The Cause of Waste
  • Too much work in progress
  • Delays
  • Handoffs
  • Bureaucracy
  • Interruptions
  • Unclear workflow
• Waste Produced (note how this adds to the cause – endless cycle)
  • Extra features
  • Defects
  • Complexity
• Waste in Work (note how this adds to the cause – endless cycle)
  • Lowered efficiency due to interruptions and improper methods
  • Fixing bugs
  • Redoing requirements
  • Thrashing due to out of synch synchronization (poor integration)
  • Re-learning
  • Poor technical practices
  • Improper order of work
  • Duplicating code
  • Overbuilding frameworks

 Much of the source of the problem is doing too much work.  There are two general ways of managing the work of a team:

1. Plan it out ahead and give it to them
2. Let them pull it when they are ready

 Waterfall and pre-agile planning uses the first.  All Agile methods use the second. The challenge is how does one get executives to understand that there is an inherent capacity of the teams and that this must be respected?  From their perspective we need to provide the following information:

1. Evidence that the teams are working well
2. Evidence that they are working at capacity

We’re trying to learn a better way.   Undergoing a change can be hard on us, as well as the people we are providing services too. In situations like this, exposure into ones methods is always a good idea.  Both for the teams to learn how to better work and for others to understand why the changes represent a true opportunity for improvement.

Note; The above is an excerpt from tomorrow's upcoming Product Portfolio Management: Why It is Critical for Agile at Scale - the second webinar of our Lean-Agile at Scale and at the Team: The Value Stream Series which, is itself, based on our Lean-Agile Software Development training.

Alan Shalloway

CEO, Net Objectives