In most projects, when we ask people whether a task is done, they answer: “Yes”.

If we then ask “Is it really done?”, they answer: “Well, almost”.

Here we get the effect that if 90% is done, they start working on the 2nd 90%. We call this the "90% syndrome".This is an important cause of delays. Therefore, it is imperative that we define when a task is really 100% done and that we insist that any task be 100% done. Not 100% is not done.
In Evo cycles, we ask for tasks to be 100% done. No need to think about it any more. Upon estimating and planning the tasks, effort hours have been estimated. Weekly, the priorities are defined. So, every week, when the project manager proposes any team member the tasks for the next cycle, he should never say “Do this and do that”. He should always propose: “Do you still agree that these tasks are highest priority, do you still agree that you should do it, and do you still agree with the estimations?”. If the developer hesitates on any of these questions, the project manager should ask why, and help the developer to re-adjust such that he can give a full commitment that he will accomplish the tasks. The project manager may help the developer with suggestions (“Last cycle you did not succeed, so maybe you were too optimistic?”). He may never take over the responsibility for the decision on which tasks the developer accepts to deliver. This is the only way to get true developer commitment. At the end of the cycle the project manager only has to use the mirror. In the mirror the developer can see himself if he failed in fulfilling his commitments. If the project manager decided what had to be done, the developer sees right through the mirror and only sees the project manager.
It is essential that the project manager coaches the developers in getting their commitments right. “Promise me to do nothing, as long as that is 100% done!” shows the importance of completely done. Only when working with real commitments, developers can learn to optimise their estimations and deliver accordingly. Else, they will never learn. Project managers being afraid that the developers will do less than needed and therefore giving the developers more work that they can commit to, will never get what they hope for because without real commitment, people tend to do less.