When is a research project ever really done? When you submit an article? When you become interested in something else? When the funding runs out? What if the article is rejected or earns a revise and resubmit? Did that new direction you are interested in come from something in that original project? What if you are in limbo waiting to hear about a grant?
Same question with courses. When you turn in final grades? What if you have to teach the course again, the next semester or even a few years later? What if a student in that course wants to continue working with you on a project started that semester?
Andre service commitments ever really done? In my experience, even if the topic of the service changes, old service breeds new service. Do reports crafted by one committee just die, or are they taken up by other groups to guide new or extended work? Do decisions made by some committees, promotion and tenure for example, live on in the conversations and activities of the university and faculty lives for a long time to come?
In Agile software development, teams often have to come up with their collective definition of what done is, as they learned a good lesson from waterfall teams. In waterfall environments, when teams are separated by function, software was often considered done by a team when they “threw it over the wall” to the next team – developers punting their code over to the testers and wiping their hands of it, for example. But the project starts for the testers when it comes over the wall – and more often than not, the code doesn’t work or doesn’t mix with another developer’s code. Who is responsible for it now?
According to Mike Cohn, a Scrum team’s definition of done (DoD) is a set of things that must be true to consider the project or story done. It’s like a checklist, an agreed upon set of standards all code must meet before being released that says “this is ready.” Good teams post their DoD statement somewhere in the team room and use it to assess every story before they can check off a story at the end of sprint. Having an agreed upon DoD gets teams away from questions like “Are you done? No, I mean, done done? Having a common DoD on cross-functional teams makes sure that no one relinquishes authority and responsibility for the code until everything is done, soup to nuts, planning to testing.
Students definitely have school-specific definitions of done when it comes to course work and papers. Sometimes it feels like most will turn in a paper and not think about it again until they get it back with a grade. And even then they will often look at the letter or number value rather than process any carefully written feedback from the instructor.
Yes, that is a gross overgeneralization, but it’s important to talk to our students about what “done” means. As a rhetorician and writing professor, it’s my job to help students realize that all communication is part of a chain that is doing something in the world. Even if it’s them turning in a draft, me commenting, them revising, etc., that work accomplishes something – learning. Every email or meeting with me is an opportunity to build or break down a relationship. Every article they read and respond to is a link in a conversation going on all around us. It’s important students realize that writing, communication, collaboration are all parts of chains that get work done, not just assignments to earn the current currency of the realm.
And we as faculty need to assess our own definitions of done as a way of possibly managing our own productivity expectations and scheduling activities.
So how do you define “done” in your own work? For your students?