One of the driving ideas behind many agile approaches is the removal of waste from traditional software processes. However, we need to be on our guard that we simply do not replace 'traditional waste' with 'agile waste'.
Obsessive Emphasis on Delivering Value
Here's a question for you. I had a recent discussion with someone on the amount of effort that some teams were spending to ensure they delivered user stories with the most business value before anything else. A release is usually a number of iterations (3 or 6 x 1 month sprints). On my backlog, I might have two user stories, A and B, with relatively similar business value. If I am spending a significant amount of effort to calculate whether A or B has the greater business value just to determine whether one is included in iteration one and the other done in iteration two, is that waste?
While, as a Product Owner, I definitely want to deliver as much business value in the next release as possible, my perspective is that I'm not going to lose sleep over whether user story A is completed in iteration 1 or 2. It is highly likely both user stories will end up being completed for the release unless I need to severely reprioritize due to some unforeseen event.
Obsessive Emphasis on Inspection and Adaption
Here's another question. Some people are talking about teams being continuously self-improving through continuous inspection and adaption. However, if the effort of the inspection is costing more than the benefit of the resulting adaption, is that waste?
An overly simplistic example to illustrate: Scrum proposes a few hours be spent at the end of each sprint on a retrospective. What went well? What could be improved? For a team of 7 each costing $Y an hour doing 2 hours of retrospective a month, the cost is of a year's retrospectives is 12 x 7 x 2 x $Y = 168 x $Y. If after a while, a year's worth of retrospectives is only producing improvements delivering an extra 100 x $Y of increased business value, then the cost of holding the retrospectives is more than the benefit they produce. To me that is waste and in those cases perhaps the retrospectives should be shortened, held less frequently or both.
To generalize, if the frequency and duration of the inspection of a process is not appropriate to the amount of process improvement it provides, then that is waste in the process and either the frequency, the duration, or both of the inspection can be reduced.
This is somewhat analogous to closed-loop control in industrial systems. Too high a sample rate is wasteful, as it does not produce a corresponding amount of improved process control.
Great Results from Sub-Optimal Parts
When working with the inventor of Feature-Driven Development, Jeff De Luca, he told me more than once to look out for effort being spent over-optimizing parts of a system that had negligible beneficial effect on the whole ... and this applied to both the software system we were building and the 'system' that was the project developing the software. In software, I had met this before and nicknamed it, Nanosecond Nobby Syndrome.
However, the same syndrome can affect agile software development proponents. To put it another way, it is only worthwhile turning up a best practice to eleven when it makes a significant difference to the process as a whole. The principle of barely-just-good-enough can apply to process improvement efforts as much as to the process itself.