... that is not the Question!
This is exactly the Problem, most do not understand the agile methodology described in the Agile Manifesto. Now lets have a closer look at that...
disclaimer: I am a software dev, team lead and head of IT and not a scrum evangelist or expert. All I write here is based on experience
former softwareengineering
there was the maybe good, but definitely old waterfall model. Most people should know that by know. In short, you cut your project in 2 pieces: 1st conceptional phase, then implementing whats in the concept. That was copied from other areas like constructing a house. There you have a plan first, then you build it.
That is totally legit and does have its right to exist in engineering as well: you write a fine granular concept, test everything hundreds of times in theory before the first line of code is written.
And if you follow that principle, you end up with software Development processes used by organizations like NASA. And there it needs to be like that, as you cannot just fly up to mars to replace something on the rover that was not considered during conceptional phase.
Agile software development
But nowadays all do this agile methods, which is totally the shit...
you can quadruple your productivity with that, without doing anything, just like that fingersnip
"That is what we're going to do now!"
With that mindset some start introducing agile development in the IT department. Or even worse: in the whole company.
The enthusiasm for Scrum is fine, but that alone is not enough. Its not enough to have a scrum coach for a couple of weeks in the company, read a book. You might think you know Agile management processes now - but you don't!
That is doomed to fail, saw that several times now.
Scurm is not a set of rules or constraints
Scrum is a set of methods and tools that were helping some teams to increase productivity and be successful.
But you need to have a closer look at those stories. When you look at where these teams started from, it is not hard to increase productivity a lot 
A lot of departments and areas do already work in an agile fassion nowadays, often without actually knowing it. For example, support teams often use tools from 'Kanban' in order to have the support ticket processing a bit more structured and processes well defined in an area where you do not know what will happen in the next 15 minutes. Very often those tools or processes are not named Kanban or alike, although the whole department needs to be agile.
So, if you want to improve something, have a close look at the real proflem.
And that means, that the team does not have to implement everything ever written in a scrum book or what is mentioned in the scrum guides. These are good examples, scaffolds so to say. You need to decide, what is best for your team, what will work, what will probably not work. This is strongly related to the company culture!
Some of the Scrum-Nazis (that’s what I call people, who do scrum literaly out of the book with out being flexible at any point) will scream out loud now. But from my experience, this is true. That is actually also enforced by the "inventors" of scrum. I did a PO Certification end of 2016 with Jeff Sutherland, the only inventor of Scrum (his own words). In the company I worked for at that time, there was a Scrum consultant, who also was trained by Jefff, to help us introduce scrum. End even those two differ in tools, or statements. The consultant used Tools, never mentioned by Jeff and vice versa. Also some of the Statements in reference to our team did contradict the Statements Jeff did in the training.
And that is the beauty of it. the consulten, who has a close look at the circumstances can do better decisions then any "scientist". The trainer can only give overall advice.
But that shows, that Scrum is not written in stone, adapt it to your own needs, your team, your culture. You should only use these tools and concepts of this methodology, you feel good with. And the team also needs to feel fine for that.
There are a lot of things influencing what tool and methodology would work with your team. One of the most important ones is: Trust! Trust from the management in the team and vice versa!
If the team does not trust the management, it will not work (well, nothing will really, but scrum especially not).
Scrum and the company culture
Trust is very important. Unlike the old methodologies, scrum tries to empower the team, reverse the trust. But empowering also brings responsibility and trust.
In waterfall, the Project Manager would tell, when what will be implemented. In scrum the team tells, what will be implemented. And the order of those things is determined by the prioritization the PO created. But the team will also be held accountable for what it promised. That’s the beauty of it...
But if the team does not trust the management will to the right things for the project and the team, will not interfere with ceremonies and stuff, then this will definitely cause conflicts. And after a while, we end up with "pseudo"-Waterfall.
The team seems to be in charge of what is done when, but if that differs from the opinion of the management, you start endless discussions until one of them - the engineering or the management - will indulge.
Example:
at the refinement the CEO is taking part (which is wrong on its own, as this is one of the POs meetings), the team is working on a user story. Lets say, there is an architectural decision to be made as part of the story. There are 3 options, A, B and C. The team is going for A.
The CEO answers this with "hmm... yes, good Idea, but we should think that through"
The team things, B is a valid solution, but never C! But C is the favorite way of the CEO.
So, the CEO keeps saying things like "yes, good Idea - but we should go on a bit"
Eventually somebody will say something like "but then only C is left!". The CEO in that case will jump on it "cool, C, that is what we do"
Later, the Devs are right, things will explode. The CEO comes in and asks what happened. the Devs state, that it is due to option C instead of A... the answer of the CEO is "But you wanted C, so fix it"
You think that is far fetched? Really?
No - something similar happened to me and my team, I was there! of course, this is a bit overstated - but it was similar to what i wrote here.
So, where does something like that come from? Lack of trust, not willing to let go and pass on responsibility! and a weak scrum master role. Not the person, but the role was not lived to what it should be. The scrum master was not allowed to do the things he needed to do!
In that case, it was also combined with a very strange error culture. Although the management stated not to be interested in errors, they were discussed over and over again. Especially when decisions had to be made. But in exactly those moments, at least once the management stated, that "we have a great error culture... BUT..."
So, the team ends up not wanting to do any decision anymore. If it is my fault anyway, and I cannot decide also. So... as long as i am there, just sit it through.
And this kills every agile process. From the outside you "look" agile, but internally there is some mixture of Waterfall and... well... what? Monarchy?
Scrum is about transparency
A lot of things you do in Scrum (or other agile methodology) tries to optimize transparence in all areas. If done correctly, scrum will help identify problems and show them in all their beauty to everyone, who dares to look. Also it will help identify ways of improvement and show that an improvement did work - or not.
In the upper example, in the retro those problems were discussed very often. But the Scrum Master could not change the ways the management worked. So it did not change... and at some point, people stoped complaining about it.
Of course, scrum or agile methodologies do not only help in those complex and conflict situations. Also the normal day to day work will be more effective if everybody knows everything he needs to know to do the job best. If you know, where the journey is headed, you can do a better job.
But that is exaclty the problem: a lot of managers do not feel comfortable to "let go", not be on the helm anymore, to let the team do the things they were hired for. This is cause of a lot of conflicts and in the end, there is mutual "un-trusting" between team and management.
Of course, the transparency scrum offers is not everybodys cup of tea. Even in engineering not everybody does want to have this kind of responsibility. And for those, the good ol' waterfall method is better fitting. But there you only have "programmers" not "engineers" again a bit exaggerated, but I thing you know where I am going: some people like to im plement a fine granular concept, rather than doing something that is not as clearly defined.
"Heros"
Especially in Softwareengineering there are some "Leads", who do work agile with their team, at least it looks like, but the do not act agile. Those are usually quite experienced people, good engineers. And the end up doing everything themself. These "heros" are a big problem in agile teams. They can break everything. And if they are or act as teamlead, you and up with a team of "a lot of drudges and on head". This is frustrating as the team as a whole will not evolve, will not develop. And the team will be only as fast, as the one guy - more or less. Scalability? No way!
For this "Hero" the situation usually is as unpleasant as for the team. As he is doing everything on his own, or wants at least to know everything in details, he usually ends up with a lot of overtime, and the others just sit there nosepicking...
Scrum should show something like that, but often these Leads also define the Scrum they want to do. And those methods and tools that would help showing this, are - for whatever reason - not in place or will just not be used...
Agile methods and tools will also help in this case, but everything needs to fit.
Scrum in the company
Agile development works great in engineering teams, as this is the "natural" way devs would organize their work in an own (opensource) project. You would do this iteartive approach to the optimum. But how do you talk to the other teams?
Excaclty there is the problem: I saw that this Interface between the departments did work extraordinary well, although the whole company was not agile, only the engineering used scrum. I remember working for a consulting company where it worked that way. The Dev-Teams were working agile, the Managers and the Project Managers were not.
This worked astonishingly well, although there was a fraction in methodology
Of course, that is not always the case. If the management wants you to report and plan like waterfall, you will have a tough time working agile.
That happened in another company. They heard of "this scrum thing" and for test purposes they wanted to do a project in a agile fashion. At the end, this was an utter failure! The kommunication did not work, the expectations were totally different and at the end, there were a lot of "lessons learned"-Meetings to avoid a lawsuit.
If the management tries to be hip and wants to do scrum without knowing what that means - this is the worst thing, that could happen.
In those cases (have seen that twice in my career), the mangement tried to bend the scrum ceremonies to their gusto, for example to turn a scum of scrums into a Reporting.
Scrum in management can only work, if the management did understand scrum and have a lot of experience with it. And than they would probably not use Scrum for the management, but maybe some other agile methodology.
If that happens, you need a very strong unwavering scrum master. And Patience is also helpful...
This will otherwise end up in conflics: the CEO who understood scrum to 50% and could gain about 3 months of experience already (experience in like, he saw somebody do it) and the Scrum master just sees all his ceremonies fail, as they are misused by the ceo. If the Scrum Master does not have the standing against the CEO, things will not work.
That is a really tough call, and I really do not know one company which is agile in all aspects. Not to mention, using scrum in all departments (as if that would make any sense).
Agile methodology is totally awesome, especially in software engineering or you want to "build" something, you actually do not know exactly what it will turn out to be. So you will iteratively improve you solutions..
So, if in management you have that approach, like in the mangement does not know, what they want to achieve and iteratively try to get things done... this sounds a bit scary, doesn't it?
so, if you are in management, you have agile teams, why not take a look at Agile Management Methods? This is not Scrum but still agile and maybe the right tool for the job...
Just remember, just because you have a hammer, not every problem is a nail!
Links: