Done means done. What else could it mean? Actually, it doesn’t matter how it’s defined, just as long as the parties that use it when achieving a common objective agree to its meaning.
That’s the lesson Mario Batali, a prominent chef and cookbook author, learned as a kid when it was his turn to do the dishes. In this New York Times interview, Batali describes how his father once called him when he was at a friend’s house to tell him to come home; apparently, his father found chunks of food in the drain.
Sometimes “done” is what some higher-up says it is.
Computer-programmer-turned-author Ellen Ullman wrote in her novel, The Bug:
His problem was not to remove every error, but to remove the most serious errors he and the testers could find, knowing all the while that the process of finding errors was infinite. At some point the program would be declared “done”; it would be distributed to users around the world; but it would still be riddled with as-yet-undiscovered bugs. There was nothing to be done about it; this was just the way it was.
“Done,” in this case, meant eliminating the most serious bugs and accepting that others remained.
Agile coach Brian Bozzuto was on a project that used a task board with three columns labeled “not started,” “in process,” and “done.” But when crossteam integration created problems, the team, half in jest, changed “done” to “done done.” When they learned that the business had signed off on stories that weren’t fully approved and systems people voiced performance concerns, the board was updated to read “done, done, DONE.”
So sometimes, “done” is a moving target, meaning “completed except for the things we’ve yet to include.”
Whatever your definition is, it can be influenced by the Zeigarnik effect. This psychological effect is the tendency to experience intrusive thoughts about an objective that was undertaken but left incomplete. According to Daniel Frank, the way this effect relates to software development is that once a feature is classified as “done” in your mind, it gets shifted to a much lower priority and you stop thinking about it. But
if the feature isn't really “done” done, and still needs work, then this can have serious consequences. All too often, testing a feature that's already written gets pushed to the end of the sprint, or ignored entirely, in favor of writing the code for another feature and calling that “done” too.
On an agile team, it’s critical to have a shared definition of when a feature is done, and in Frank’s view, it’s not done until it’s fully integrated, tested, and shippable. By including testing in the definition of done, he maintains, the team will be exploiting the Zeigarnik effect by ensuring that until testing is done, the team won’t forget about it.
Speaking of “done,” did you know that the word “deadline” arose during Civil War times? A deadline was an actual line—indicated by a fence, railing, or by a line in the dirt—intended to restrict the movement of prisoners in Civil War stockades. Any prisoner who crossed the line was shot dead by guards. Thus, the line came to be called “the dead line.”
If you ever thought that getting the job “done” in time to meet your deadline was a plot to kill you, now you know.
Naomi Karten is a writer and speaker who draws from her background in both psychology and IT. Naomi's recent books are Presentation Skills for Technical Professionals and Changing How You Manage and Communicate Change. Readers have described her newsletter, Perceptions and Realities, as lively, informative, and a breath of fresh air. Naomi is a regular columnist for StickyMinds.com.