This was an infamous quote from a project that I worked-on several years ago. The project wasn’t going well because we didn’t have adequate requirements. Even worse, we were not being permitted to resolve the problem because it would embarrass the department. It was one of many problems.
In a meeting, the boss asked me when I would be done. I didn’t want to condemn anyone in a public forum like this, so I gave an unspecific answer and suggested that we talk after the meeting. He kept pressing me, so I confessed that I couldn’t give him an exact number because I wasn’t clear on what he meant by “done”. He responded by having a little fun with synonyms, “you know: done, finished, complete. Don’t you know what done means? Everybody knows what done means.” He leaned back in his chair and belly-laughed while pointing at me. That was the best answer he would offer that day. My friends and I still chuckle about it today but it wasn’t so funny at the time.
The deeper reality of the situation was more serious. Nobody could give a straight answer about what “done” meant because the criteria for “done” wasn’t defined. You just had to assume that everybody had the same understanding of it.
I was actually hoping that my statement would ring a bell with him and he would recognize that, “oh crap, we really should have a clear definition of “done” documented, but we don’t. Golly, we really must document our expectations better so everyone has a clear understanding of my expectations. ASAP”. LOL. That would have been magnificent. But no.
What “done” really means
When most people think “done”, they think: “There is nothing left to do. I can go do something else now.” However, with software development, I have seen the term “done” mean any of the following:
- I have run out of requirements to implement. Let’s give it to the testers now.
- I have tested it, the testers tested it, and there is nothing else to do but give it to the users. We expect to get a few bug reports, but they will taper-off after 2-3 months.
- Time has run out so we will ship it today, whether it is ready or not.
- It compiled. Let’s see if it runs.
- I’m tired. I’m going home now. This should do, for now.
- I don’t really have any requirements, so I did my best to wing it. Now, let’s give it to the users so they can give us feedback (and by feedback, I mean they will give us the actual requirements) so I can log them as “bugs” and “fix the bugs” (which really means: implement the rest of the requirements as I gather them in the bug tracking system).
Guess which one was their most common definition, prior to my arrival. Hint: it has the longest description.
[Collecting requirements via the bug tracking system] is a common technique for people who are not used to developing software. If you aren’t good at gathering requirements, then you will probably get your requirements from the users in the form of complaints or suggestions, but only after you have put it in their hands. They won’t like it and neither will you, but if you don’t have a better plan, then this is how it will turn out.
The awkward part of the whole thing is that this team had gone through this before and recognized that gathering requirements via the bug tracking system wasn’t very good. They remembered that it seemed to make the users cranky and unfriendly. They wanted to improve, so they grabbed a book and picked a methodology that was highly recommended. People probably said it was a no-brainer/can’t-miss/sure-fire.
However, they didn’t seem to have a means to determine if the methodology was working or not. They were chugging along, doing what the book said and waiting for that straw to turn into gold. So, they were quite astonished when anyone implied that it might not be working. “We did what the book said, so by now, it should be nearly done. When do we ship it?!” You almost have to admire optimism like that.
I said “almost” (let’s not get carried away now).
In the end, they did what most teams in this position would do: They blamed it on the contractors and fired them.
Every now and then, I think back on this project and try to think of how I could have fixed it or made lemonade out of it or something. Checkmate isn’t easy to get out of. Especially if you are a pawn. At least there are a half dozen or so, lessons to learn from this experience. Can you spot them?
One last thought on the matter. In case you were wondering, this is not an unusual phenomenon. Even the Microsoft ALM rangers struggle with “Done” sometimes. So, even some of the best people in the industry can struggle with arbitrary terms like “done”. No joke.