After my last email, I was tempted to leave it at that. But I don't want people to fear uncertainty because if they ask the question, it might look like they failed.
When they ask if it's done, I want to understand what's behind that question.
Sometimes, "is it done" means we haven't checked. The implementation looks right, but nobody has tried completing the booking with a keyboard for example. So we need evidence. The answer is then, no, it's not done.
Sometimes it means we never agreed on what done meant. People have different expectations and now we need to resolve them. The answer is again, no, it's not done.
And sometimes everyone knows the button doesn't work with a keyboard. The deadline is tomorrow and someone asks whether we can call it done anyway.
They're basically asking for permission to ship work that's not done.
I understand why it happens. Changing a release date is uncomfortable. People have made commitments and nobody wants to disappoint them. And yes, we can make the call to accept the work isn't done and still ship the release. That means we know about it and we accept the risks. It won't however make that work done.
So we need to somehow keep those conversations separate. Otherwise, approval makes the unresolved problem disappear from the status report while users still come across it.
If we decide to release, we need to figure out who's still blocked by what we did, what support they'll need and who will take responsibility for the fix. It's a known issue and a known issue needs a known fix, no matter how cumbersome.
When we already know what doesn't work, though, we owe each other a more honest question. Are we choosing to release with this still in place?