Defining “Finished”: Don’t Leave Trash In The Forecourt
We recently had some (relatively minor) repairs done on the roof of our house. If you’ve ever had to arrange repair work on a house, you’ll know that the process can be tricky. It’s necessary to find a credible and reputable tradesperson, and then actually get a quote and arrange a date. What is made worse, of course, is when it comes to roofing problems there tend to be peaks in demand. When there’s stormy weather and rain, roofers are in sudden demand!
Following a few phone calls we found a suitable roofing firm, who were really easy to deal with. They turned up when they said they were going to, did the job with minimum disruption to us, and then left. They took photos of the work, and even alerted us to some other potential maintenance issues we might want to consider. This is pretty much everything you could hope for when it comes to having work done on a house!
And Then They Were “Done”
Shortly after they had finished for the day and left, we received a message from the owner of the company confirming the work was complete and attaching an invoice. He also let us know that the rubbish they’d left behind would be collected in the next few days. That’s pretty important to us, as they had included removal of the rubbish in their quote, and as a ‘zero car’ household, it’s difficult to get rid of bulky waste.
This got me thinking about what the term “finished” actually means. I know there’s all sorts of debate about ‘definition of done’ in agile and I just don’t want to open that can of worms. Here, I’m speaking more generally about how different perspectives can exist on what ‘finished’ or ‘done’ actually means. For example: