The first question in TPS always is what does the customer want from this process? (Both the internal customer at the next steps in the production line and the final, external customer).
Working on projects/features/tasks that adds no value to the larger goals of the organization is considered waste. Scope management is extremely important while the project is in progress. It is not that uncommon that wants are inserted into the project scope that are separate from the needs. These wants increase significant effort with design, code, test, etc. These efforts, which are unnecessary to start with, opens up chance for more design and coding, means more scope for defects and maintenance.
Lack of coordination among different groups cause team members wait for the next action. We may have seen many times developers waiting for completed requirements, testers waiting for the next build so that they can start testing. Some times even a minor change takes forever to be applied with significant overhead in the change control process. Acknowledging these issues itself is a battle that is half-won. For example, developers waiting for a central build to happen to know the issues with their code is counter-productive. They need to know that sooner; setting up a continuous integration system could help alleviate that concern.
Based on my understanding this point relates to overhead involved in performing development activities. For example, it may be a company policy to produce UML diagrams upfront. Architects spending significant time on this just for the documentation sake is not adding much value to the evolving design. The focus, as discussed earlier should be on value and value alone. Identify the overhead, eliminate it. Find different (lighter) ways to communicate. (Among many options Modeling in color using post-it notes is a useful design technique).
At macro level -- company's vision is not translated into tangible value-added goals by the middle management, individual architects/developers spending time working on tangential items that adds no value to the customer. Over processing has some overlap with overproduction mentioned above. Incorrect processing is more common in a heavier process environment with longer feedback loops. (On a lighter note, a cartoon describing what customer actually wanted and what was actually built).
Each group working independently, developing their own components for way too long and try integrating only during the final phases of the project. This would usually result in more work or the work in a wrong direction. Incorporating rapid feedback mechanism is the key. Again, a close-knit cross-functional team works much better minimizing this waste.
Unnecessary distractions could fall in this category. As is often quoted from Peopleware -- developers work their best when they are in the "flow" or "in their zone". Each distraction wastes significant development time. Needless to say but as much as possible developers must not be pulled into unnecessary meetings as they should concentrate as much as possible on the stuff they do the best.
This is a well known waste in the software development. A defect by itself is not such a bad thing, but the concentration should be on finding it sooner and as much early in the process as possible. Patching the fixes is not the best way to build the quality. The quality must be built into the process. Test automation is an absolute must (my experiences in this regard are documented here). It is equally important to learn from the earlier defects, recently posted my thoughts on root cause analysis
This is applicable to employees in any industry. It is extremely important to instill a sense of ownership in the team. In the author's own words -- losing time, ideas, skills, improvements, and learning opportunities by not engaging or listening to the employees is not acceptable.