There's two sides to this: educating the rest of the organization as to the cost of interrupting programmers, and educating programmers on how to avoid being interrupted. Because, you can do a lot to reduce the cost of interruptions on your side too.
The thing is, many of the things managers and HR and accounts do are also necessary to the overall process you're embedded in, and so their issues have to be dealt with as well. But they don't have to get your attention right this second, not if they're properly organized. So beat into them that they must use email, the phone is for emergencies, and that meetings should be minimized.
But you can't get out of meetings entirely, as they're part of the mechanism that keeps your manager able to deflect the interruptions. So, schedule them, and try to keep big enough blocks of time free of them. If your company has a calendar system, chuck blocks of coding time into it; you're not free when you're not in a meeting (as a manager might think of it), you're working.
One of the big advantages of a process like Scrum is that it gives enough contact time with the managers to let them get most of their work done in standup meetings and scrum process time, leaving most of the rest of the programmer's time for code.
A scrum team can be pretty noisy, but also you get to look around the room and not call out if someone really is in focus mode; you can observe that if you look. Walls between team members are a problem because they force you to create interruptions before you find out if this is a good time or not, either by poking your head around the door or by calling.