The rules of a roundabout are quite simple: you must yield to oncoming cars to your right – otherwise – go. Most of the time there are no cars coming and you can avoid the “come to a complete stop” law all together.
I find the iterative development cycle works in much the same way. In older more classic models, a product manager and their stakeholders work diligently to make sure specs are completed thoroughly before marking them as “ready for development.” In reality, the a majority of what *can* be done dramatically changes as new information is made available (digging into the problem, user feedback, stakeholder feedback, complexity etc.) The “stop” heavy culture of elaborately planned tasks are often thrown away the seconds after development, and issues, start. The real knowledge comes from implementation and iteration once each atomic feature is released. It also requires trust in those that implement to have a good enough understanding of the high level purpose of what your product is trying to achieve.
What if something goes wrong? Well, just like with a round about, development yields when there is” oncoming traffic” (AKA an issue getting flagged.) In scrum, the flag can be raised at standup meetings or planning meetings. If there is no flag then the developer does the best they can to implement the best way they can. In essence, they are entering the intersection and driving on through. This lack of congestion on spec creation can be better spent on feedback, iterations, and issues that come up. (In reality it is where the most critical time has always been.)
So, next time you’re concerned about how a task *should* be completed, and feel the need to surround yourself with stop signs, imagine the steady flow of a roundabout. Give your team the freedom to produce, stay available for issues that *may* come up, and when a change needs to be made revisit the task at hand.