Ok, you get it. Applying the scrum methodology to software development is supposed to be great, but it still is not working for you. Your environment is stressful, if not more stressful than it was prior to scrum. Developing software is complicated enough. The manner in which your environment goes about building it, however, should not be.
Who's to blame? The Business Analysts? The Consultants? The Developers? The Designers? Management? The ultimate answer will always be "Management" for not taking the time to proactively determine the efficiency of an endeavor. When implementing a methodology, you may find out that it is more complicated than it "appears" to be worth. When that happens you need to determine if you are actually applying the methodology as it should be. If you truly are, then you can either make adjustments or find one that better suits your environment or particular project.
If you are higher than normal management, say Senior Management, then whose fault is it if your managers do not properly communicate problems to you? For example, you have monthly meetings, yet at some point every meeting is about how far behind the project is... Who's fault is it? Unfortunately, it is your fault. It is your job to make sure your managers are doing their job well. That means you need to survey the people that actually do the work. The people that are actually in the trenches that are trying to provide your business value. This prevents your managers from lying to you. What? You've never experienced a lying manager? Trust, it happens.
So - back to scrum for producing software... There still are a great deal of companies that get it wrong because they took a simple scrum lifecycle diagram for face value and ran with it. And boy did they Haul Ass. Later - the problems start. After that first demo, a billion changes are thrown at the team. A trillion refinements are pouring in after sprints. After giving your time and mental energy fully building something, the last thing you want to hear is that you need to change a zillion things. STRESS, STRESS, AND MORE STRESS. At some point your worker bees get use to the abuse and stop caring. It has been studied that the average worker will produce 6 hours of work in an 8 hour schedule. When the poop starts repeatedly hitting the fan, how much work do you think they will start producing? If you’re thinking definitely less than 6 hours, you are correct. Now you know one of the reasons why projects fall behind schedule.
How do you implement scrum properly so that you can avoid zillions of changes and keep your teams healthy? The trick is to perform scrum in a pattern that makes sense for software development. This same pattern is used for designing cars, but for some reason people try to awkwardly build software differently. What gets complicated is maintaining the discipline in pulling that off, yet that is what Scrum Masters are for (assuming they actually understand Scrum). Life Element, Inc. can show you how to get the most out of your scrum practice so that your resources are not being wasted.
If what you need to accomplish in software development is a significant endeavor, scrum can get you to the promise land. If your environment does not know how to ride the horse, then you will fall off.