I merge the feature branches into develop, then at the end of sprint I merge to master and code goes into production.
You can certainly do that if you wish, but typically in Git Flow you don't merge develop directly into master because of the exact problems you are running into:
This can cause lots of blockers, as work needs to be pushed to master, tested and signed off before other work can be committed into develop.
The way Git Flow avoids these problems is with release and hotfix branches. (See diagram for details.)
You simply create a release branch for testing prior to releasing, and therefore work on develop never has to stop. (Note you don't have to create a release branch from the tip of develop; you can use any prior commit that you wish to branch from.)
When you need to do a hotfix into production, you create a hotfix branch off of master.
After your code is merged into master from either release or hotfix branch, then you would also merge master back into develop. (Or you could merge the release and hotfix branches back to develop just prior to merging them into master, but merging master back after is IMHO slightly cleaner and easier to manage.)
Side note: the release and hotfix branches are usually well-defined, however, since you are currently working without them, you still can work without them but with a few slight tweaks. For example, suppose you take your current develop and start testing a build somewhere, and then you like it and want to release it into production. You actually have a release branch, but it isn't named. It's just the commit ID of what you tested. When you release, simply merge that commit ID from develop into master instead of develop which might be ahead of that commit. That way you won't also merge in any new code that happened on develop after you started testing. Essentially this is identical to making a dedicated release branch, but without actually naming it. The same goes for a hotfix. Typically hotfixes are a minor change in a single commit. I would recommend branching off of master into some branch, but it doesn't have to be called hotfix; any name will do. Then PR that branch into master and merge master back into develop when done, or, as Git Flow points out, if a release branch already exists, then merge master back into release instead of develop (though you could also merge release back to develop too if you want that fix there sooner).
Side Side note: the most common complaint I hear about Git Flow is that it is unnecessarily complex. I find the complexity to be absolutely necessary for some organizations, and of course not necessary for others. You can pick and choose which parts of it you wish to use, and adjust when necessary. If you haven't needed release branches yet that's great- just tweak your workflow to merge in just the commit ID from develop into master when you release. But if you find you need a bugfix against that commit ID, maybe then you could create a release branch on the fly. This was you could get by without dedicated release branches most of the time.
