A few years ago, when the company I worked for at the time switched to agile development, I remember my boss saying how important it was to define ‘done’. I thought that sounded silly. Don’t we all know what done means? Do we really have to define it for the team? But as we discussed the idea, I realized it wasn’t as strange a question as it sounds. For instance, if I ask my wife if she’s done with the laundry, she might say she is. So, I assume that I can go to the closet and grab my favorite shirt. However, when I get there and don’t see it, I’m frustrated. Why did my wife tell me the laundry was done when it clearly wasn’t? Obviously, she and I had defined ‘done’ differently. To me, it means washed, folded, and put away. To my wife, it simply meant washed. We had both defined ‘done’ using a different criteria.
This same thing happens in software development. When we talk about software being done, we may mean that the development has been completed or that it’s been tested. Or, maybe we mean that it’s been deployed to a staging server or that it’s been through User Acceptance Testing. Maybe we mean that the source has been checked in to a branch or that it’s been merged to master. All of these things represent a drastically different definition of done.
As a customer of software services, you need to be able to define what you mean by done. If you don’t, you run the risk that your development team does not perform to your expectations since you were both defining the endgame differently.