In software engineering, there’s always a choice between waiting to be perfect and being wrong at speed. Remote.com speaks of the concept of ‘defaulting to action’ in such a situation. Sure, interrupting someone can help get your work close to perfection; but you can’t overlook the impact it has on the person who is unblocking you. Instead, you choose to be wrong at speed. It’s ok, if you have to backtrack at a later point, but it’s better than waiting to be unblocked. 

Defaulting to action optimises for speed and throughput, but it also encourages thoughtful communication. For example, a well written user story may preempt the need for a story kick-off, where a developer, product owner and tester discuss its implementation and testing approach. When in doubt, teams that adopt asynchronous communication just execute.