TL;DR
Based on your question, it seems likely that you are practicing command-and-control project management rather than functioning as a coach or process referee within the Scrum framework. You should fully embrace the principles of the Agile Manifesto and empower your team to find their own solutions within the twin constraints of the Sprint Goal and the Definition of Done.
Command-and-Control Isn't Agile
I am coming up with ideas in order to deliver better software...I realized that the team is not making enough progress from improvement perspective even though the ideas are small to implement.
These statements are an indication of Scrum gone wrong. Agile frameworks like Scrum are based on self-directed teams, not top-down management directives. As a member of the Scrum Team, the Scrum Master may certainly propose improvements during the Sprint Retrospectives, but it is up to the team as a whole to determine how to optimize its processes.
In addition, you seem to be trying to hold the team accountable for "improvements" that they have not agreed to, presumably have not estimated for level of effort, and for which you have not defined any objective metrics. Specifically:
Who says the ideas are "small to implement?"
In Scrum, stories, tasks, and processes must always be estimated by the task performers (e.g. the Development Team) rather than decreed from on high. Just because you believe a process change is simple or lightweight doesn't make it so; only the task performers are in a position to judge.
Who says they haven't made "enough progress?"
What problems are you trying to solve? How are you measuring progress? Are you measuring internal processes or deliverable outcomes? Unless you have clearly identified a process problem, and clearly defined a set of objective metrics to measure outcomes, you're practicing voodoo management.
In addition, measuring adherence to a process is almost always a mistake; in Scrum, you want to measure value delivered rather than the process for delivering that value. In other words, focus on "Does the sausage taste good?" instead of on how the sausage gets made.
Why isn't the team empowered and engaged in finding its own solutions?
Scrum will not make mediocre teams into superstars. All agile frameworks rely on self-directed engagement by the team members. If your team isn't populated by individuals who are self-starters capable of producing a workman-like product and interested in continuous improvement, then you should probably review your management and hiring practices before spending time on frameworks like Scrum.
If you already have capable, engaged team members, then the best thing you can do is to empower them to build their own self-organized processes. If you've correctly defined the goals and the constraints, the power of Scrum lies in giving the team leeway to optimize the implementation details internally.
Leverage Retrospectives
If your software has a quality problem, you should review your Sprint Goals, your Scrum processes, and your Definition of Done to ensure that you are providing an adequate framework for success. If you're still falling short, then use your Sprint Retrospectives to ask the team about the problems and to brainstorm solutions that the entire team can get behind.