The year 2011 is almost done as I write this. “Almost” is fully defined when it comes to calendar dates because there are a fixed number of days, hours and minutes left until 2012 is here. There will not be any delays or extensions. The end is near.
My latest software development project is also almost done. But you have no idea what I mean by almost in the context of my project. In fact, my definition of almost is likely to be quite different from yours. To better understand the state of the project, a few questions need to be answered:
- Is the project nearing a drop dead date? (No, not soon.)
- Are all of the stories written. (No, but the remaining stories are trivial.)
- Is all of the code written and awaiting final deployment? (No, but what’s left is simple.)
- Is the team in the last cycle or sprint? (Not quite; maybe 2 or 3 more.)
- Is the burn down chart about to hit bottom? (No, but most of the work is done.)
- Are all of the test cases written? (No, but we’re on it.)
- Is the project about to be cancelled? (Not that I’m aware of.)
It’s pretty clear that “almost done” is meaningless when discussing a work product that is not precisely timed. Software projects are never precisely timed. Even when hard deadlines exist, there are many corners that a team can cut in order to hit dates. Here are a few examples:
- Cut the testing time short.
- Avoid fixing defects by relegating them to the backlog.
- Don’t bother making the source code maintainable.
- Forget about adding comments to the source code.
- Hard code parameter and database values.
- Ignore user experience issues.
- Incorporate open-source code while ignoring license restrictions.
Get the point? Any date can be met. How much are you willing to sacrifice to meet the date? How much risk are you willing to take? How much technical debt are you ready to assume?
Now that I’ve thought about it more, my software project is not almost done after all. I have a lot left to do, starting with writing down a clear definition of done.
“almost done” became a running gag within our team. It used to be the standard answer in our daily standups when we started to introduce agile. Only after the team realized how stupid this answer was and developers started to take full responsibility to finally finish their stuff “almost done” became a joke rather than a serious answer.
I’m happy to hear that you realized the problem and were able to get a laugh out of it. That’s teamwork! Done is a binary condition … it is or it’s not.