Reaching Done

Supports Pillars:

Confidence

Dependencies on Other Skills:

Zero Bugs

Root Cause Analysis

Five Whys

Definition:

Agile Team members know that any shortcuts today will likely haunt us tomorrow--and reduce our ability to work on something new in the future. Therefore, they challenge the meaning of done, they qualify it with unambiguous terms that touch upon technical and business aspects. Completion includes everything necessary to take an idea from 'concept to cash'; from design through deployment.

Resources:

Done Done, James Shore

Decomposition of this Skill:

There's an old joke about software development--it's 99% done 90 percent of the time. Unfortunately, that means the last percent of work takes 9/10th of the effort. So instead of giving inaccurate information, Agile developers report in a binary fashion--either a user story is not done, or it's DONE.

Teams need to agree on what they consider done. Sometimes it is not within a team's sphere of influence to deploy to a live customer every iteration--and so they may define done as making a deployable package. This entails risk that real client deployments may result in surprised customers, yet recognizing the deficiency is the first step in correcting it.

Any time a flaw or misunderstanding is found in the product, an Agile team member will ask what went wrong, and fix the root cause.

Obsession over being DONE involves constant questioning about what might go wrong, and addressing potential problems while they're cheap to fix. This doesn't mean doing more than necessary, but just doing things well.

Organizational Support of this Skill:

Cross-functional teams, product orientation (as opposed to project orientation),