What You're Doing Wrong
[T]he development team personnel eventually end up working on bugs, client requirements etc. This impacts sprint delivery and the development team is now missing the sprint deadlines.
By failing to protect the development team from unscheduled work, and not following the rules of Scrum by calling for an Early Termination and a return to Sprint Planning as soon as you learn that the Sprint Goal can't be met, you have gotten exactly the results you should expect from your current process.
Sometimes sprints fail. Sometimes unscheduled work happens. However, there are well-defined Scrum procedures for dealing with those events. If you don't follow them, why are you expecting success?
Why You're Doing It Wrong
Your organization is not prioritizing work, and it's not acknowledging real-world velocity or work-in-progress limitations. In your comments you say:
So one release may result is many clients finding issues and needing quick fixes as well as they may have small customization that needs to be done to them ASAP. So how do I tackle that without impacting the mainstream development?
In other words, the organization is not making wise strategic choices about how to spend its time, money, or resources. Support and change-requests will add drag to your new-feature velocity, and that should be clearly reflected in the priority of items in the Product Backlog and in your teams' velocity metrics.
It is the Product Owner's job to prioritize, and the teams' responsibility to only accept as much work into each sprint as they realistically expect to complete. Meanwhile, the Scrum Master must ensure that everyone is playing by the same set of rules.
If the Product Owner tells you support and new features are both of equal priority, that person is not fulfilling the requirements of the role. The Product Owner's job is to allocate available capacity to whatever is most important to the organization for the duration of the current Sprint.
If the teams aren't saying "no" to work that they know they can't accomplish, they aren't fulfilling the requirements of their roles either. The job of a Scrum team is to estimate the work involved as accurately as possible, and only commit to the volume of work they can complete at a sustainable pace.
If the Scrum Master isn't educating the organization about how to apply Scrum, or is not playing referee and calling a time-out when the Product Owner or the team aren't fulfilling their roles properly, then the Scrum Master isn't fulfilling that role either. A process failure isn't the Scrum Master's fault, but not making the process failure visible and transparent is.
What To Do Instead
Don't flog your team until morale improves. Don't turn every sprint into a death march. Instead, fix your process by:
- Making sure everyone understands their roles.
- Making sure that the organization continually inspects-and-adapts its process.
- Teaching everyone from the CEO down to the mailroom clerk the differences between estimates, targets, and money-back guarantees.
- Pulling the emergency brake when the process is failing, and fix the underlying problems before restarting the assembly line.
- Making all work (planned or unplanned) a visible cost to the project.
- Making the cost of not planning the work or addressing the process issues visible.
Basically, stop basing your project plans on the hope that unplanned work will get done during the night by magic pixies without impacting your schedule or consuming project resources. There is no magic pixie dust; just visibility, transparency, realistic estimates, and continual process improvement.