Risks of "definition Done"

Somehow I see some risk in agile projects working with definitions of Done. Here some risks which slips my mind.


Risks:

- Usually only the functionality which meets the "definition Done" will be shown in the demo to the customer. Undone functionality is in the code available although it is not presented in the demo. This might lead to failures in production because based on acceptance of items Done a release might be shipped in production;
- If there are minimal skills in the teams and organization the "definition Done" might also be too small. This might lead that although the software meets the definition huge errors related to fit to process and usability will occur.
- Business has too less knowledge to define a "definition Done" and the team supports the definition phase based on their current knowledge. Definition is written mainly from technical perspective due to expert knowledge of the team of coding and too less knowledge of the business processes;
- "Definition Done" is used by project management to meet their project goals and deliberately narrowing the scope and content of the definition during the project. Instead of proofing that the system fits the business it is turned into proofing that the system fits the project.


I know that there will be more risks to mention, these were just some few which slipped my mind. I certainly not am saying that Agile is not working. I certainly not am claiming that "Definition Done" is creating false trust. I just wanted to show that we have to precise on defining Done instead of stepping too easily over this important tool.