Wastes of Software Development

June 17, 2012 — Posted by Al Shalloway

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

 

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.


Comments

You might have classified these under above but I feel they are either significant enough to call out or were missed:
* long cycle times
* old technology used (frameworks or tools)
* long build times
* long deployment times
* two people working on the same feature (unbeknown to each other)
* meetings
* unknown Takt?
* unknown rules
* unknown beliefs
* working on low value work when there is higher value work outstanding
* bloated/poorly designed code

I was trying to keep the list somewhat small and more manageable but all of these are good.

A more complete list is worth building,  Will create a structure for that later.

Thanks! :)

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