Short Answer:
In most cases, no. It is not uncommon for people to use techniques such as rubber duck debugging in software-centric businesses or departments. If a company is more business-centric in its culture, then there may be concerns from management who are not familiar with the method.
Long Answer:
The culture of many modern software-centered offices would allow for a variety of common (if odd, to the outside world) developer practices, such as talking to a rubber duck. However, if you work in an environment where verbalizing your process to a rubber duck would be considered distracting or frowned upon, there are other, more silent alternatives you could consider:
Compose a Letter
Whether via text, hand-written, or diagramed, composing a note as if you were explaining the software to someone else can be used in a similar method to verbal rubber duck debugging.
Chat With a (Secure) Bot
If you find yourself more effectively debugging when you bounce ideas off of another person instead of an inanimate object, you could download and build the numerous open-source chat bots available.
One example is the original chatbot: Eliza, designed to use Rogerian psychotherapy methods for conversing. Eliza comes standard in copies of Emacs, for those who use prefer it as a text editor. The one thing to remember is to use a secure chatbot, if you have concerns about leaking corporate or trade secrets.
Utilize Unconventional Tools
If your issue is that you are having difficulty approaching your problem from a new perspective to gain clarity on the issue and find a solution, then a variety of similar techniques exist for reframing your perspective.
One example is to use an external prompt of some kind, such as a deck of cards, a set of story dice, or a tarot deck where each card has a predefined meaning. Comparing your software to these prompts forces you to draw unconventional parallels and think of your software issues in new ways.
Another example is to attempt to draw your software as a physical machine, to describe the relationships between the components. In doing so you may realize how you intended the software to operate is missing a key step somewhere.
The benefit of using unconventional debugging techniques is that it forces you to think creatively, and can help to unblock your process when you find yourself in a mental rut. The downside is that how easy it becomes to get off track from your goal, and find yourself spending more time finding parallels than you are actually accomplishing development goals.