Permission — do you need it?

I recently read a post by Derek Sivers — Never wait. It refers to a surprising answer that was given by an expert in the copyright law for a licensing question. Let me share as quoted in the post:

Someone asked her advice on a licensing problem. They had recorded their version of a famous song, but were unable to get the rights to sell it because they couldn’t get a response from the publisher.

The lawyer shocked the audience when she said, “Sell it anyway. Don’t wait for permission.

The post made me think how much time we waste in “waiting”. In case of a team delivering software, here are a few examples of “waiting”:

• Waiting for decision-makers to know what to build
• Waiting on QA/Testers to confirm that the software works as expected
• Waiting for Deployment schedules to deploy
• Waiting for the code to get merged

I am not saying the team doesn’t need to make the above decisions. It is essential to know what to build; it is critical to confirm that the software works fine, it is vital to do architectural and/or code reviews. But do we need a waiting period?

In many of the above situations, it can be seen as someone “granting permission” such as QA or someone else verifying that the software is ready to deploy. And we move to another task while waiting for the permission.

Considering “waiting” as one of the deadly wastes, what can be done to avoid the same? What is it required to bring in “no waiting” or reduce the “waiting” time to the minimum?

There are times waiting cannot be avoided. But, at times we wait for approval or permission which may not be needed all.

Continuous Delivery helps to avoid the waiting time to the minimum. Trunk-based development, automated testing, deployment pipeline, all focus on “getting things done” and “optimising for flow”.

We seek permission, either because we are afraid or we don’t have enough information to make a decision. Continuous Delivery done right helps us to improve learning and comfortable in making mistakes.